OASIS Openopen access

ebXML Registry Information Model (RIM) v3.0 (2005-05-01)

OASIS Open · OASIS Open

OASIS Open · Standards · License: Open Access

ebxml information model os registry regrep rim v3.0

oasis, standard, oasis open, specification, open standard, oasis_regrep-rim-3.0-os, ebxml, registry, information, model, rim, v3.0, regrep-rim-3.0-os, regrep, os, 3.0

ebXML Registry Information Model Version 3.0

OASIS Standard, 2 May, 2005

5 6

Document identifier: regrep-rim-3.0-os

7 8

Location: http://docs.oasis-open.org/regrep-rim/v3.0/

Editors:

Name Sally Fuger Farrukh Najmi Nikola Stojanovic

Affiliation Individual Sun Microsystems RosettaNet

10 11

Contributors: Name Diego Ballve Ivan Bedini Kathryn Breininger Joseph Chiusano Peter Kacandes Paul Macias Carl Mattocks Matthew MacKenzie Monica Martin Richard Martell Duane Nickull

Affiliation Individual France Telecom The Boeing Company Booz Allen Hamilton Adobe Systems LMI Government Consulting CHECKMi Adobe Systems Sun Microsystems Galdos Systems Inc Adobe Systems

May 2, 2005 Page 1 of 78

12 13 14 15

Abstract: This document defines the types of metadata and content that can be stored in an ebXML Registry. A separate document, ebXML Registry: Service and Protocols [ebRS], defines the services and protocols for an ebXML Registry.

16 17 18 19 20 21

Status: This document is an OASIS ebXML Registry Technical Committee Approved Draft Specification.

22 23 24 25

Committee members should send comments on this specification to the [email protected] list. Others should subscribe to and send comments to the [email protected] list. To subscribe, send an email message to [email protected] with the word "subscribe" as the body of the message.

26 27 28 29

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the OASIS ebXML Registry TC web page (http://www.oasis-open.org/committees/regrep/).

May 2, 2005 Page 2 of 78

Table of Contents

1 Introduction.............................................................................................................................................10 1.1 Audience.........................................................................................................................................10 1.2 Terminology....................................................................................................................................10 1.3 Notational Conventions...................................................................................................................10 1.3.1 UML Diagrams.........................................................................................................................10 1.3.2 Identifier Placeholders.............................................................................................................10 1.3.3 Constants.................................................................................................................................10 1.3.4 Bold Text..................................................................................................................................11 1.3.5 Example Values.......................................................................................................................11 1.4 XML Schema Conventions.............................................................................................................11 1.4.1 Schemas Defined by ebXML Registry.....................................................................................11 1.4.2 Schemas Used By ebXML Registry........................................................................................12 1.5 RepositoryItems and RegistryObjects............................................................................................13 1.6 Canonical ClassificationSchemes..................................................................................................13 1.7 Registry Information Model: Overview............................................................................................15 1.7.1 Class Relationships View........................................................................................................15 1.7.2 Class Inheritance View............................................................................................................15

1.7.2.1 Class Identifiable................................................................................................................................16

2 Core Information Model..........................................................................................................................18 2.1 Attributes of Information Model Classes.........................................................................................18 2.2 Data Types......................................................................................................................................18 2.3 Internationalization (I18N) Support................................................................................................19 2.3.1 Class InternationalString.........................................................................................................19

31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

50 51 52 53 55

2.3.1.1 Attribute Summary..............................................................................................................................19 2.3.1.2 Attribute localizedStrings....................................................................................................................19

2.3.2 Class LocalizedString..............................................................................................................19

2.3.2.1 Attribute Summary..............................................................................................................................20 2.3.2.2 Attribute lang .....................................................................................................................................20 2.3.2.3 Attribute charset..................................................................................................................................20 2.3.2.4 Attribute value.....................................................................................................................................20

58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

2.4 Class Identifiable............................................................................................................................20 2.4.1 Attribute Summary...................................................................................................................20 2.4.2 Attribute id...............................................................................................................................20 2.4.3 Attribute home.........................................................................................................................20 2.4.4 Attribute slots...........................................................................................................................21 2.5 Class RegistryObject......................................................................................................................21 2.5.1 Attribute Summary...................................................................................................................21 2.5.2 Composed Object....................................................................................................................21 2.5.3 Attribute classifications............................................................................................................22 2.5.4 Attribute description.................................................................................................................22 2.5.5 Attribute externalIdentifier.......................................................................................................22 2.5.6 Attribute lid..............................................................................................................................22 2.5.7 Attribute name.........................................................................................................................23 2.5.8 Attribute objectType................................................................................................................23 regrep-rim-3.0-os Copyright © OASIS Open 2005. All Rights Reserved.

May 2, 2005 Page 3 of 78

2.5.9 Attribute status........................................................................................................................23

2.5.9.1 Pre-defined RegistryObject Status Types..........................................................................................23

2.5.10 Attribute versionInfo..............................................................................................................24 2.6 Class VersionInfo ...........................................................................................................................24 2.6.1 Attribute Summary...................................................................................................................24 2.6.2 Attribute versionName.............................................................................................................24 2.6.3 Attribute comment...................................................................................................................24 2.7 Class ObjectRef..............................................................................................................................24 2.7.1 Attribute Summary...................................................................................................................24 2.7.2 Attribute id...............................................................................................................................25 2.7.3 Attribute home.........................................................................................................................25

78 79 80 81 82 83 84 85 86

2.7.3.1 Local Vs. Remote ObjectRefs.............................................................................................................25

2.7.4 Attribute createReplica............................................................................................................25 2.8 Class Slot .......................................................................................................................................25 2.8.1 Attribute Summary ..................................................................................................................25 2.8.2 Attribute name.........................................................................................................................25 2.8.3 Attribute slotType....................................................................................................................25 2.8.4 Attribute values.......................................................................................................................26 2.9 Class ExtrinsicObject .....................................................................................................................26 2.9.1 Attribute Summary...................................................................................................................26 2.9.2 Attribute contentVersionInfo....................................................................................................26 2.9.3 Attribute isOpaque..................................................................................................................26 2.9.4 Attribute mimeType.................................................................................................................26 2.10 Class RegistryPackage.................................................................................................................26 2.10.1 Attribute Summary.................................................................................................................26 2.11 Class ExternalIdentifier.................................................................................................................27 2.11.1 Attribute Summary.................................................................................................................27 2.11.2 Attribute identificationScheme...............................................................................................27 2.11.3 Attribute registryObject..........................................................................................................27 2.11.4 Attribute value.......................................................................................................................27 2.12 Class ExternalLink .......................................................................................................................27 2.12.1 Attribute Summary................................................................................................................27 2.12.2 Attribute externalURI............................................................................................................27 3 Association Information Model...............................................................................................................28 3.1 Example of an Association.............................................................................................................28 3.2 Source and Target Objects.............................................................................................................28 3.3 Association Types...........................................................................................................................28 3.4 Intramural Association....................................................................................................................28 3.5 Extramural Association...................................................................................................................29 3.5.1 Controlling Extramural Associations.......................................................................................30 3.6 Class Association ..........................................................................................................................30 3.6.1 Attribute Summary...................................................................................................................30 3.6.2 Attribute associationType........................................................................................................31 3.6.3 Attribute sourceObject.............................................................................................................31 3.6.4 Attribute targetObject..............................................................................................................31

88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119

May 2, 2005 Page 4 of 78

120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164

4 Classification Information Model...........................................................................................................32 4.1 Class ClassificationScheme...........................................................................................................33 4.1.1 Attribute Summary...................................................................................................................33 4.1.2 Attribute isInternal..................................................................................................................34 4.1.3 Attribute nodeType.................................................................................................................34 4.2 Class ClassificationNode ..............................................................................................................34 4.2.1 Attribute Summary...................................................................................................................34 4.2.2 Attribute parent.......................................................................................................................34 4.2.3 Attribute code.........................................................................................................................35 4.2.4 Attribute path...........................................................................................................................35 4.2.5 Canonical Path Syntax...........................................................................................................35 4.2.5.1 Example of Canonical Path Representation.......................................................................................35 4.2.5.2 Sample Geography Scheme...............................................................................................................35

4.3 Class Classification .......................................................................................................................36 4.3.1 Attribute Summary..................................................................................................................36 4.3.2 Attribute classificationScheme...............................................................................................36 4.3.3 Attribute classificationNode....................................................................................................36 4.3.4 Attribute classifiedObject.......................................................................................................36 4.3.5 Attribute nodeRepresentation................................................................................................36 4.3.6 Context Sensitive Classification.............................................................................................37 4.4 Example of Classification Schemes..............................................................................................38 5 Provenance Information Model..............................................................................................................39 5.1 Class Person...................................................................................................................................39 5.1.1 Attribute Summary...................................................................................................................39 5.1.2 Attribute addresses.................................................................................................................39 5.1.3 Attribute emailAddresses........................................................................................................39 5.1.4 Attribute personName.............................................................................................................39 5.1.5 Attribute telephoneNumbers...................................................................................................39 5.2 Class User......................................................................................................................................40 5.2.1 Associating Users With Organizations....................................................................................40 5.3 Class Organization.........................................................................................................................40 5.3.1 Attribute Summary...................................................................................................................40 5.3.2 Attribute addresses.................................................................................................................41 5.3.3 Attribute emailAddresses........................................................................................................41 5.3.4 Attribute parent........................................................................................................................41 5.3.5 Attribute primaryContact.........................................................................................................41 5.3.6 Attribute telephoneNumbers...................................................................................................41 5.4 Associating Organizations With RegistryObjects...........................................................................41 5.5 Class PostalAddress.......................................................................................................................42 5.5.1 Attribute Summary...................................................................................................................42 5.5.2 Attribute city.............................................................................................................................42 5.5.3 Attribute country......................................................................................................................42 5.5.4 Attribute postalCode................................................................................................................42 5.5.5 Attribute stateOrProvince........................................................................................................43 5.5.6 Attribute street.........................................................................................................................43

May 2, 2005 Page 5 of 78

165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201

5.5.7 Attribute streetNumber...........................................................................................................43 5.6 Class TelephoneNumber................................................................................................................43 5.6.1 Attribute Summary...................................................................................................................43 5.6.2 Attribute areaCode..................................................................................................................43 5.6.3 Attribute countryCode..............................................................................................................43 5.6.4 Attribute extension..................................................................................................................43 5.6.5 Attribute number......................................................................................................................43 5.6.6 Attribute phoneType................................................................................................................43 5.7 Class EmailAddress........................................................................................................................44 5.7.1 Attribute Summary...................................................................................................................44 5.7.2 Attribute address.....................................................................................................................44 5.7.3 Attribute type...........................................................................................................................44 5.8 Class PersonName.........................................................................................................................44 5.8.1 Attribute Summary...................................................................................................................44 5.8.2 Attribute firstName...................................................................................................................44 5.8.3 Attribute lastName...................................................................................................................44 5.8.4 Attribute middleName..............................................................................................................44 6 Service Information Model.....................................................................................................................45 6.1 Class Service..................................................................................................................................45 6.1.1 Attribute Summary...................................................................................................................45 6.1.2 Attribute serviceBindings.........................................................................................................45 6.2 Class ServiceBinding......................................................................................................................45 6.2.1 Attribute Summary...................................................................................................................46 6.2.2 Attribute accessURI.................................................................................................................46 6.2.3 Attribute service.......................................................................................................................46 6.2.4 Attribute specificationLinks.....................................................................................................46 6.2.5 Attribute targetBinding.............................................................................................................46 6.3 Class SpecificationLink...................................................................................................................46 6.3.1 Attribute Summary..................................................................................................................46 6.3.2 Attribute serviceBinding..........................................................................................................47 6.3.3 Attribute specificationObject..................................................................................................47 6.3.4 Attribute usageDescription.....................................................................................................47 6.3.5 Attribute usageParameters....................................................................................................47 7 Event Information Model........................................................................................................................48 7.1 Class AuditableEvent.....................................................................................................................48 7.1.1 Attribute Summary...................................................................................................................48 7.1.2 Attribute eventType.................................................................................................................49

202

7.1.2.1 Pre-defined Auditable Event Types....................................................................................................49

203

7.1.3 Attribute affectedObjects.........................................................................................................49 7.1.4 Attribute requestId...................................................................................................................49 7.1.5 Attribute timestamp.................................................................................................................49 7.1.6 Attribute user...........................................................................................................................49 7.2 Class Subscription..........................................................................................................................49 7.2.1 Attribute Summary...................................................................................................................50 7.2.2 Attribute actions.......................................................................................................................50

204 205 206 207 208 209

May 2, 2005 Page 6 of 78

212

7.2.3 Attribute endTime....................................................................................................................50 7.2.4 Attribute notificationInterval.....................................................................................................50 7.2.5 Attribute selector.....................................................................................................................50

213

7.2.5.1 Specifying Selector Query Parameters..............................................................................................50

214

210 211

226

7.2.6 Attribute startTime...................................................................................................................50 7.3 Class AdhocQuery.........................................................................................................................50 7.3.1 Attribute Summary...................................................................................................................51 7.3.2 Attribute queryExpression.......................................................................................................51 7.4 Class QueryExpression..................................................................................................................51 7.4.1 Attribute Summary...................................................................................................................51 7.4.2 Attribute queryLanguage.........................................................................................................51 7.4.3 Attribute <any>........................................................................................................................51 7.5 Class Action...................................................................................................................................51 7.6 Class NotifyAction...........................................................................................................................52 7.6.1 Attribute Summary...................................................................................................................52 7.6.2 Attribute endPoint....................................................................................................................52 7.6.3 Attribute notificationOption......................................................................................................52

227

7.6.3.1 Pre-defined notificationOption Values................................................................................................52

228

7.7 Class Notification............................................................................................................................53 7.7.1 Attribute Summary...................................................................................................................53 7.7.2 Attribute subscription...............................................................................................................53 7.7.3 Attribute registryObjectList......................................................................................................53 8 Cooperating Registries Information Model............................................................................................54 8.1 Class Registry.................................................................................................................................54

215 216 217 218 219 220 221 222 223 224 225

229 230 231 232 233 234

8.1.1.1 Attribute Summary..............................................................................................................................54

235

240

8.1.2 Attribute catalogingLatency.....................................................................................................54 8.1.3 Attribute conformanceProfile...................................................................................................54 8.1.4 Attribute operator....................................................................................................................54 8.1.5 Attribute replicationSyncLatency............................................................................................54 8.1.6 Attribute specificationVersion..................................................................................................54 8.2 Class Federation ............................................................................................................................55

241

8.2.1.1 Attribute Summary..............................................................................................................................55

242

8.2.2 Attribute replicationSyncLatency............................................................................................55 8.2.3 Federation Configuration.........................................................................................................55 9 Access Control Information Model.........................................................................................................57 9.1 Terminology....................................................................................................................................57 9.2 Use Cases for Access Control Policies..........................................................................................57 9.2.1 Default Access Control Policy.................................................................................................58 9.2.2 Restrict Read Access To Specified Subjects..........................................................................58 9.2.3 Grant Update and/or Delete Access To Specified Subjects...................................................58 9.2.4 Reference Access Control.......................................................................................................58 9.3 Resources.......................................................................................................................................58 9.3.1 Resource Attribute: owner.......................................................................................................58 9.3.2 Resource Attribute: selector....................................................................................................58 9.3.3 Resource Attribute: <attribute>...............................................................................................58 9.4 Actions............................................................................................................................................58

236 237 238 239

243 244 245 246 247 248 249 250 251 252 253 254 255

May 2, 2005 Page 7 of 78

256 257 258 259 260 261 262 263 264 265 266 267 268 269

9.4.1 Create Action...........................................................................................................................59 9.4.2 Read Action.............................................................................................................................59 9.4.3 Update Action..........................................................................................................................59 9.4.4 Delete Action...........................................................................................................................59 9.4.5 Approve Action........................................................................................................................59 9.4.6 Reference Action.....................................................................................................................59 9.4.7 Deprecate Action.....................................................................................................................59 9.4.8 Undeprecate Action.................................................................................................................59 9.4.9 Action Attribute: action-id........................................................................................................59 9.4.10 Action Attribute: reference-source........................................................................................59 9.4.11 Action Attribute: reference-source-attribute..........................................................................60 9.5 Subjects..........................................................................................................................................60 9.5.1 Attribute id...............................................................................................................................60 9.5.2 Attribute group.........................................................................................................................60

270

9.5.2.1 Assigning Groups To Users .............................................................................................................60

271

9.5.3 Attribute role............................................................................................................................60

272

9.5.3.1 Assigning Roles To Users..................................................................................................................60

273

9.6 Abstract Access Control Model......................................................................................................60 9.6.1 Access Control Policy for a RegistryObject.............................................................................61 9.6.2 Access Control Policy for a RepositoryItem............................................................................61 9.6.3 Default Access Control Policy.................................................................................................61 9.6.4 Root Access Control Policy.....................................................................................................62 9.6.5 Performance Implications........................................................................................................62 9.7 Access Control Model: XACML Binding.........................................................................................62 9.7.1 Resource Binding....................................................................................................................63 9.7.2 Action Binding..........................................................................................................................63 9.7.3 Subject Binding.......................................................................................................................64 9.7.4 Function classification-node-compare....................................................................................64 9.7.5 Constraints on XACML Binding...............................................................................................65 9.7.6 Example: Default Access Control Policy.................................................................................65 9.7.7 Example: Custom Access Control Policy................................................................................69 9.7.8 Example: Package Membership Access Control....................................................................72 9.7.9 Resolving Policy References...................................................................................................74 9.7.10 ebXML Registry as a XACML Policy Store...........................................................................74 9.8 Access Control Model: Custom Binding.........................................................................................75 10 References...........................................................................................................................................76 10.1 Normative References..................................................................................................................76 10.2 Informative References.................................................................................................................76

274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294

May 2, 2005 Page 8 of 78

Illustration Index Figure 1: Information Model Relationships View......................................................................................15 Figure 2: Information Model Inheritance View..........................................................................................16 Figure 3: Example of RegistryObject Association

................................................................................28

Figure 4: Example of Intramural Association............................................................................................29 Figure 5: Example of Extramural Association...........................................................................................30 Figure 6: Example showing a Classification Tree.....................................................................................32 Figure 7: Information Model Classification View.......................................................................................33 Figure 8: Classification Instance Diagram................................................................................................33 Figure 9: Context Sensitive Classification................................................................................................37 Figure 10: User Affiliation With Organization Instance Diagram..............................................................40 Figure 11: Organization to RegistryObject Association Instance Diagram..............................................42 Figure 12: Service Information Model.......................................................................................................45 Figure 13: Event Information Model..........................................................................................................48 Figure 14: Federation Information Model..................................................................................................55 Figure 15: Instance Diagram for Abstract Access Control Information Model..........................................61 Figure 16: Access Control Information Model: [XACML] Binding.............................................................63 295

May 2, 2005 Page 9 of 78

296

Introduction

297 298

An ebXML Registry is an information system that securely manages any content type and the standardized metadata that describes it.

299 300

The ebXML Registry provides a set of services that enable sharing of content and metadata between organizational entities in a federated environment.

301

This document defines the types of metadata and content that can be stored in an ebXML Registry.

302 303

A separate document, ebXML Registry: Services and Protocols [ebRS], defines the services provided by an ebXML Registry and the protocols used by clients of the registry to interact with these services.

304

1.1

305

The target audience for this specification is the community of software developers who are:

306

•

307

•

308

1.2

309 310 311

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in IETF RFC 2119 [RFC2119].

312 313 314

The term “repository item” is used to refer to content (e.g. an XML document) that resides in a repository for storage and safekeeping. Each repository item is described by a RegistryObject instance. The RegistryObject catalogs the RepositoryItem with metadata.

315

1.3

316 317

Throughout the document the following conventions are employed to define the data structures used. The following text formatting conventions are used to aide readability:

318

1.3.1

319 320

Unified Modeling Language [UML] diagrams are used as a way to concisely describe concepts. They are not intended to convey any specific Implementation or methodology requirements.

321

1.3.2

322 323 324 325 326

Listings may contain values that reference ebXML Registry objects by their id attribute. These id values uniquely identify the objects within the ebXML Registry. For convenience and better readability, these key values are replaced by meaningful textual variables to represent such id values. For example, the placeholder in the listing below refers to the unique id defined for an example Service object:

Audience

Implementers of ebXML Registry Services Implementers of ebXML Registry Clients

Terminology

Notational Conventions

UML Diagrams

Identifier Placeholders

327 328

<rim:Service id="${EXAMPLE_ SERVICE_ID}">

329

1.3.3

Constants

330 331

Constant values are printed in the Courier New font always, regardless of whether they are defined by this document or a referenced document.

May 2, 2005 Page 10 of 78

332

1.3.4

Bold Text

333 334 335

Bold text is used in listings to highlight those aspects that are most relevant to the issue being discussed. In the listing below, an example value for the contentLocator slot is shown in italics if that is what the reader should focus on in the listing:

336 337 338 339 340

<rim:Slot name="urn:oasis:names:tc:ebxmlregrep:rim:RegistryObject:contentLocator"> ... </rim:Slot>

341 342

1.3.5

Example Values

343 344

These values are represented in italic font. In the listing below, an example value for the contentLocator slot is shown in italics:

345 346 347 348 349 350 351

<rim:Slot name="urn:oasis:names:tc:ebxmlregrep:rim:RegistryObject:contentLocator"> <rim:ValueList> <rim:Value>http://example.com/myschema.xsd</rim:Value> </rim:ValueList> </rim:Slot>

352 353

1.4

XML Schema Conventions

354 355 356 357 358

This specification uses schema documents conforming to W3C XML Schema [Schema1] and normative text to describe the syntax and semantics of XML-encoded objects and protocol messages. In cases of disagreement between the ebXML Registry schema documents and schema listings in this specification, the schema documents take precedence. Note that in some cases the normative text of this specification imposes constraints beyond those indicated by the schema documents.

359 360 361 362

Conventional XML namespace prefixes are used throughout this specification to stand for their respective namespaces as follows, whether or not a namespace declaration is present in the example. The use of these namespace prefixes in instance documents is non-normative. However, for consistency and understandability instance documents SHOULD use these namespace prefixes.

363

1.4.1

Schemas Defined by ebXML Registry

364

Prefix

XML Namespace

Comments

rim:

urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0

This is the Registry Information Model namespace [ebRIM]. The prefix is generally elided in mentions of Registry Information Model elements in text.

rs:

urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0

This is the ebXML Registry namespace that defines base types for registry service requests and responses [ebRS]. The prefix is generally elided in mentions of ebXML Registry protocol-related elements in text.

query:

urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0

This is the ebXML Registry query namespace that is used in the query protocols used between clients and the QueryManager service [ebRS].

May 2, 2005 Page 11 of 78

Prefix

XML Namespace

Comments

lcm:

urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0

This is the ebXML Registry Life Cycle Management namespace that is used in the life cycle management protocols used between clients and the LifeCycleManager service [ebRS].

cms:

urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0

This is the ebXML Registry Content Management Services namespace that is used in the content management protocols used between registry and pluggable content managent services [ebRS].

1.4.2

Schemas Used By ebXML Registry

365 366 367

Prefix

XML Namespace

Comments

saml:

urn:oasis:names:tc:SAML:2.0:assertion

This is the SAML V2.0 assertion namespace [SAMLCore]. The prefix is generally elided in mentions of SAML assertion-related elements in text.

samlp:

urn:oasis:names:tc:SAML:2.0:protocol

This is the SAML V2.0 protocol namespace [SAMLCore]. The prefix is generally elided in mentions of XML protocol-related elements in text.

ecp:

urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp

This is the SAML V2.0 Enhanced Client Proxy profile namespace, specified in this document and in a schema [SAMLECPxsd].

ds:

http://www.w3.org/2000/09/xmldsig#

This is the XML Signature namespace [XMLSig].

xenc:

http://www.w3.org/2001/04/xmlenc#

This is the XML Encryption namespace [XMLEnc].

SOAPENV:

http://schemas.xmlsoap.org/soap/envelope

This is the SOAP V1.1 namespace [SOAP1.1].

paos:

urn:liberty:paos:2003-08

This is the Liberty Alliance PAOS (reverse SOAP) namespace.

xsi:

http://www.w3.org/2001/XMLSchema-instance

This namespace is defined in the W3C XML Schema specification [Schema1] for schema-related markup that appears in XML instances.

wsse:

http://docs.oasis-open.org/wss/2004/01/oasis200401-wss-wssecurity-secext-1.0.xsd

This namespace is defined by the Web Services Security: SOAP Message Security 1.0 specification [WSS-SMS]. It is used by registry to secure soap message communication.

May 2, 2005 Page 12 of 78

Prefix

wsu:

XML Namespace

Comments

http://docs.oasis-open.org/wss/2004/01/oasis200401-wss-wssecurity-utility-1.0.xsd

This namespace is defined by the Web Services Security: SOAP Message Security 1.0 specification [WSS-SMS]. It is used by registry to secure soap message communication.

368 369

1.5

RepositoryItems and RegistryObjects

370 371 372

An ebXML Registry is capable of storing any type of electronic content such as XML documents, text documents, images, sound and video. Instances of such content are referred to as a RepositorytItems. RepositorytItems are stored in a content repository provided by the ebXML Registry.

373 374 375 376

In addition to the RepositoryItems, an ebXML Registry is also capable of storing standardized metadata that MAY be used to further describe RepositoryItems. Instances of such metadata are referred to as a RegistryObjects (or one of its sub-types, as described later in this document). RegistryObjects are stored in the registry provided by the ebXML Registry.

377

To illustrate these concepts consider this familiar metaphor:

378

•

An ebXML Registry is like your local library.

379

•

The repository is like the bookshelves in the library.

380 381 382

•

The repository items in the repository are like book on the bookshelves. The repository items can contain any type of electronic content just like the books in the bookshelves can contain any type of information.

383

•

The registry is like the card catalog. It is organized for finding things quickly.

384 385

•

A RegistryObject is like a card in the card catalog. All RegistryObjects conform to a standard just like the cards in the card catalog conform to a standard.

386 387

•

Every repository item MUST have a RegistryObject that describes it, just like every book must have a card in the card catalog.

388 389

To summarize, ebXML Registry stores any type of content as RepositoryItems in a repository and stores standardized metadata describing the content as RegistryObjects in a registry.

390

1.6

391 392 393 394

This specification uses several standard ClassificationSchemes as a mechanism to provides extensible enumeration types. These ClassificationSchemes are referred to as canonical ClassificationSchemes. The enumeration values within canonical ClassificationSchemes are defined using standard ClassificationNodes that are referred to as canonical ClassificationNodes.

395 396 397 398 399

This section lists the canonical ClassificationSchemes that are required to be present in all ebXML Registries. These Canonical ClassificationSchemes MAY be extended by adding additional ClassificationNodes. However, a ClassificationNode defined normatively in the links below MUST NOT be modified within a registry. In particular they MUST preserve their canonical id attributes in all registries.

400

Note that all files listed in the Location column are relative to the following URL:

401

http://www.oasis-open.org/committees/regrep/documents/3.0/canonical/

Canonical ClassificationSchemes

402

ClassificationScheme Name AssociationType

Location / Description SubmitObjectsRequest_AssociationTypeScheme.xml Defines the types of associations between RegistryObjects.

May 2, 2005 Page 13 of 78

ClassificationScheme Name ContentManagementService

Location / Description SubmitObjectsRequest_CMSScheme.xml Defines the types of content management services.

DataType

SubmitObjectsRequest_DataTypeScheme Defines the data types for attributes in classes defined by this document.

DeletionScopeType

SubmitObjectsRequest_DeletionScopeTypeScheme.xml Defines the values for the deletionScope attribute in RemoveObjectsRequest protocol message.

EmailType

SubmitObjectsRequest_EmailTypeScheme.xml Defines the types of email addresses.

ErrorHandlingModel

SubmitObjectsRequest_ErrorHandlingModelScheme.xml Defines the types of error handling models for content management services.

ErrorSeverityType

SubmitObjectsRequest_ErrorSeverityTypeScheme.xml Defines the different error severity types encountered by registry during processing of protocol messages.

EventType

SubmitObjectsRequest_EventTypeScheme.xml Defines the types of events that can occur in a registry.

InvocationModel

SubmitObjectsRequest_InvocationModelScheme.xml Defines the different ways that a content management service may be invoked by the registry.

NodeType

SubmitObjectsRequest_NodeTypeScheme.xml Defines the different ways in which a ClassificationScheme may assign the value of the code attribute for its ClassificationNodes.

NotificationOptionType

SubmitObjectsRequest_NotificationOptionTypeScheme.xml Defines the different ways in which a client may wish to be notified by the registry of an event within a Subscription.

ObjectType

SubmitObjectsRequest_ObjectTypeScheme.xml Defines the different types of RegistryObjects a registry may support.

PhoneType

SubmitObjectsRequest_PhoneTypeScheme.xml Defines the types of telephone numbers.

QueryLanguage

SubmitObjectsRequest_QueryLangScheme Defines the query languages supported by a registry.

ResponseStatusType

SubmitObjectsRequest_ResponseStatusTypeScheme.xml Defines the different types of status for a RegistryResponse.

StatusType

SubmitObjectsRequest_StatusTypeScheme.xml Defines the different types of status for a RegistryObject.

SubjectGroup

SubmitObjectsRequest_SubjectGroupScheme Defines the groups that a User may belong to for access control purposes.

May 2, 2005 Page 14 of 78

ClassificationScheme Name SubjectRole

Location / Description SubmitObjectsRequest_SubjectRoleScheme Defines the roles that may be assigned to a User for access control purposes.

403 404 405

1.7

Registry Information Model: Overview

406 407

The ebXML Registry Information Model defined in this document defines the classes and their relationships that are used to represent RegistryObject metadata.

408

1.7.1

409 410 411 412 413 414

Figure 1 provides a high level overview of the metadata classes defined by the model and their “Has-A” relationships as a UML Class Diagram. It does not show “Is-A” or Inheritance relationships nor does it show Class attributes. Further, it only shows a subset of classes in the model rather than all the classes in the model. The relationship links in the figure are either UML association or composition relationships (solid diamonds). In case of UML composition, instances of a class on the far side of the solid diamond are referred to as composed objects in the [ebRIM] and [ebRS] specifications.

Class Relationships View

Figure 1: Information Model Relationships View

416

1.7.2

Class Inheritance View

417 418 419

Figure 2 shows the inheritance or “Is-A” relationships between the classes in the information model. Note that it does not show the other types of relationships, such as “Has-A” relationships, since they have already been shown in Figure 1. Class attributes are also not shown to conserve page space. regrep-rim-3.0-os Copyright © OASIS Open 2005. All Rights Reserved.

May 2, 2005 Page 15 of 78

420 421

Detailed description of attributes of each class will be displayed in tabular form within the detailed description of each class.

422

1.7.2.1

423 424 425

The RegistryObject class and some other classes in RIM are derived from a class called Identifiable. This class provides the ability to identify objects by an id attribute and also provides attribute extensibility by allowing dynamic, instance-specific attributes called Slots.

426

Class Identifiable

Figure 2: Information Model Inheritance View

427 428 429

The RegistryObject sub-classes are shown in related groups as follows:

430 431

•

Core Information Model: Defines core metadata classes in the model including the common base classes.

432 433

•

Association Information Model: Defines classes that enable RegistryObject instances to be associated with each other.

434

•

Classification Information Model: Defines classes that enable RegistryObjects to be classified.

435 436

•

Provenance Information Model: Defines classes that enable the description of provenance or source information about a RegistryObject.

437

•

Service Information Model: Defines classes that enable service description.

438 439

•

Event Information Model: Defines classes that enable the event subscription and notification feature defined in [ebRS].

May 2, 2005 Page 16 of 78

Cooperating Registries Information Model: Defines classes that enable the cooperating registries feature defined in [ebRS].

440 441

•

442 443

The remainder of this document will describe each of the above related group of classes in a dedicated chapter named accordingly.

May 2, 2005 Page 17 of 78

444

Core Information Model

445

This section covers the most commonly used information model classes defined by [ebRIM].

446

2.1

447 448 449

Information model classes are defined in terms of their attributes. These attributes provide information on the state of the instances of these classes. Implementations of a registry typically map class attributes to attributes and elements in an XML store or columns in a relational store.

450 451

Since the model supports inheritance between classes, a class in the model inherits attributes from its super classes if any, in addition to defining its own specialized attributes.

452

The following is the description of the columns of many tables that summarize the attributes of a class:

Attributes of Information Model Classes

453

Column Attribute Data Type Required Default Value Specified By

Description The name of the attribute The data type for the attribute Specifies whether the attribute is required to be specified Specifies the default value in case the attribute is omitted Indicates whether the attribute is specified by the client or specified by the registry. In some cases it may be both. Specifies whether an attribute may be changed once it has been set to a certain value

Mutable 454 455

2.2

Data Types

456

The following table lists the various data types used by the attributes within information model classes:

457

Data Type

XML Schema

Boolean String4 String8 String16 String32 String ShortName Language

Data Type boolean string string string string string string language

LongName FreeFormText

string string

UUID

anyURI

Description

Used for a true or false value Used for 4 character long strings Used for 8 character long strings Used for 16 character long strings Used for 32 character long strings Used for unbounded Strings A short text string A string that identifies a local language. Values MUST be natural language identifiers as defined by [RFC 3066] A long text string A very long text string for free-form text A URI of the form urn:uuid:<uuid> where <uuid> MUST be a DCE 128 Bit Universally unique Id.

Length

4 characters 8 characters 16 characters 32 characters unbounded 64 characters 32 character

256 characters 1024 characters 64 characters

May 2, 2005 Page 18 of 78

ObjectRef

referenceURI

URI URN Integer DateTime

anyURI anyURI integer dateTime

Set

sequence

Bag

sequence

Sequence

sequence

In XML Schema the referenceURI attribute value is a URI that references an ObjectRef within the XML document. If no such ObjectRef exists in the XML document then the value implicitly references a RegistryObject by the value of its id attribute within the registry. Used for URL and URN values Must be a valid URN Used for integer values Used for a timestamp value such as Date As defined by OCL. An unordered Collection in which an object can occur only once. As defined by OCL. An unordered Collection in which the same object can occur multiple times. As defined by OCL. An ordered Collection in which the same object can occur multiple times.

64 characters

256 characters 256 characters 4 bytes

458 459

2.3

Internationalization (I18N) Support

460 461 462

Some information model classes have String attributes that are I18N capable and may be localized into multiple native languages. Examples include the name and description attributes of the RegistryObject class in 2.5.

463 464

The information model defines the InternationalString and the LocalizedString interfaces to support I18N capable attributes within the information model classes. These classes are defined below.

465

2.3.1

466 467 468

This class is used as a replacement for the String type whenever a String attribute needs to be I18N capable. An instance of the InternationalString class composes within it a Set of LocalizedString instances, where each String is specific to a particular locale.

469

2.3.1.1

Class InternationalString

Attribute Summary

470

Attribute

Data Type

Required

localizedStrings Set of LocalizedString

Default Value

Specified By Client

Mutable Yes

471 472

2.3.1.2

Attribute localizedStrings

473 474

Each InternationalString instance MAY have a localizedStrings attribute that is a Set of zero or more LocalizedString instances.

475

2.3.2

476 477 478

This class is used as a simple wrapper class that associates a String with its locale. The class is needed in the InternationalString class where a Set of LocalizedString instances are kept. Each LocalizedString instance has a charset and lang attribute as well as a value attribute of type String.

Class LocalizedString

May 2, 2005 Page 19 of 78

479

2.3.2.1

Attribute Summary

Attribute

Data Type

Required No No Yes

Default Value en-US UTF-8

Specified By Client Client Client

Mutable

lang charset value

language String String

Yes Yes Yes

481

2.3.2.2

Attribute lang

482 483

Each LocalizedString instance MAY have a lang attribute that specifies the language used by that LocalizedString.

484

2.3.2.3

485 486

Each LocalizedString instance MAY have a charset attribute that specifies the name of the character set used by that LocalizedString. The value of this attribute SHOULD be registered with IANA at:

487

http://www.iana.org/assignments/character-sets

488

2.3.2.4

489 490

Each LocalizedString instance MUST have a value attribute that specifies the string value used by that LocalizedString.

491

2.4

492 493

The Identifiable class is the common super class for most classes in the information model. Information model Classes whose instances have a unique identity are descendants of the Identifiable Class.

494

2.4.1

480

Attribute charset

Attribute value

Class Identifiable

Attribute Summary

495

Attribute

Data Type

Required

home

URI

URN

Yes

slots

Set of Slot

Default Value Base URI of local registry

Specified By Client

Mutable

Client or registry Client

Yes

496

2.4.2

Attribute id

497

Each Identifiable instance MUST have a unique identifier which is used to refer to that object.

498 499 500

Note that classes in the information model that do not inherit from Identifiable class do not require a unique id. Examples include classes such as TelephoneNumber, PostalAddress, EmailAddress and PersonName.

501 502

An Identifiable instance MUST have an id that MUST conform to the rules defined in section title “Unique ID Generation” in [ebRS].

503

2.4.3

504 505 506

An Identifiable instance MAY have a home attribute. The home attribute, if present, MUST contain the base URL to the home registry for the RegistryObject instance. The home URL MUST be specified for instances of the Registry class that is defined later in this specification.

Attribute home

May 2, 2005 Page 20 of 78

507

The base URL of a registry is:

508

•

Used as the URL prefix for SOAP and HTTP interface bindings to the registry.

509 510

•

Used to qualify the id of an Identifiable instance by its registry within a federated registry environment.

511

2.4.4

Attribute slots

512 513 514

An Identifiable instance MAY have a Set of zero or more Slot instances that are composed within the Identifiable instance. These Slot instances serve as extensible attributes that MAY be defined for the Identifiable instance.

515

2.5

516

Super Classes: Identifiable

517 518

The RegistryObject class extends the Identifiable class and serves as a common super class for most classes in the information model.

519

2.5.1

Class RegistryObject

Attribute Summary

520

Attribute

Data Type

Required No No No

lid

Set of Classification InternationalString Set of ExternalIdentifier URN

name objectType

InternationalString ObjectRef

status

ObjectRef

versionInfo

VersionInfo

classifications description externalIdentifers

Yes for READs, No for WRITEs. No Yes for READs, No for WRITEs. Yes for READs, No for WRITEs. Yes for READs, No for WRITEs.

Default Value

Specified By Client Client Client

Mutable

Client or registry

Client Client or Registry

Yes No

Registry

Yes

Registry

Yes Yes Yes

521

2.5.2

Composed Object

522 523 524 525 526 527

A RegistryObject instance MAY have instances of other RegistryObjects and other classes composed within it as defined in this specification. In such a relationship the composing object is refered to as the Composite object as defined in section 3.4 of [UML]. The composed object is refered to in this document and other ebXML Registry specification as Composed object. The relationship between the Composite and Composed object is refered as a composition relationship as defined in section 3.4.8 of [UML].

528 529 530

Composition relationship implies that deletes and copies of the Composite object are cascaded to implicitly delete or copy the composed object. In comparison a UML Aggregation implies no such cascading.

531

May 2, 2005 Page 21 of 78

532 533 534

composition relationships. The classes are listed in the order of their being defined in this document. Note that abstract classes are not included in this list since an abstract class cannot have any instances.

535

•

InternationalString

536

•

LocalizedString

537

•

VersionInfo

538

•

Slot

539

•

ExternalIdentifier

540

•

Classification

541

•

PostalAddress

542

•

TelephoneNumber

543

•

EmailAddress

544

•

PersonName

545

•

ServiceBinding

546

•

SpecificationLink

547

•

QueryExpression

548

•

NotifyAction

549 550

2.5.3

Attribute classifications

551 552

Each RegistryObject instance MAY have a Set of zero or more Classification instances that are composed within the RegistryObject. These Classification instances classify the RegistryObject.

553

2.5.4

554 555

Each RegistryObject instance MAY have textual description in a human readable and user-friendly form. This attribute is I18N capable and therefore of type InternationalString.

556

2.5.5

557 558 559

Each RegistryObject instance MAY have a Set of zero or more ExternalIdentifier instances that are composed within the RegistryObject. These ExternalIdentifier instances serve as alternate identifiers for the RegistryObject.

560

2.5.6

Attribute description

Attribute externalIdentifier

Attribute lid

564 565 566 567 568 569

Each RegistryObject instance MUST have a lid (Logical Id) attribute . The lid is used to refer to a logical RegistryObject in a version independent manner. All versions of a RegistryObject MUST have the same value for the lid attribute. Note that this is in contrast with the id attribute that MUST be unique for each version of the same logical RegistryObject. The lid attribute MAY be specified by the submitter when creating the original version of a RegistryObject. If the submitter assigns the lid attribute, she must guarantee that it is a globally unique URN. A registry MUST honor a valid submittersupplied LID. If the submitter does not specify a LID then the registry MUST assign a LID and the value of the LID attribute MUST be identical to the value of the id attribute of the first (originally created) version of the logical RegistryObject.

570 571 572

Note that classes in the information model that do not inherit from RegistryObject class do not require a lid. Examples include Entity classes such as TelephoneNumber, PostalAddress, EmailAddress and PersonName.

561 562 563

May 2, 2005 Page 22 of 78

573

2.5.7

Attribute name

574 575 576

Each RegistryObject instance MAY have a human readable name. The name does not need to be unique with respect to other RegistryObject instances. This attribute is I18N capable and therefore of type InternationalString.

577

2.5.8

578 579 580 581 582

Each RegistryObject instance has an objectType attribute. The value of the objectType attribute MUST be a reference to a ClassificationNode in the canonical ObjectType ClassificationScheme. A Registry MUST support the object types as defined by the ObjectType ClassificationScheme. The canonical ObjectType ClassificationScheme may easily be extended by adding additional ClassificationNodes to the canonical ObjectType ClassificationScheme.

583 584 585 586 587

The objectType for almost all objects in the information model matches the ClassificationNode that corresponds to the name of their class. For example the objectType for a Classification is a reference to the ClassificationNode with code “Classification” in the canonical ObjectType ClassificationScheme. The only exception to this rule is that the objectType for an ExtrinsicObject or an ExternalLink instance MAY be defined by the submitter and indicates the type of content associated with that object.

588 589 590 591

A registry MUST set the correct objectType on a RegistryObject when returning it as a response to a client request. A client MAY set the objectType on a RegistryObject when submitting the object. A client SHOULD set the objectType when the object is an ExternalLink or an ExtrinsicObject since content pointed to or described by these types may be of arbitrary objectType.

592

2.5.9

593 594 595 596 597

Each RegistryObject instance MUST have a life cycle status indicator. The status is assigned by the registry. A registry MUST set the correct status on a RegistryObject when returning it as a response to a client request. A client SHOULD NOT set the status on a RegistryObject when submitting the object as this is the responsibility of the registry. A registry MUST ignore the status on a RegistryObject when it is set by the client during submission or update of the object.

598 599 600 601

The value of the status attribute MUST be a reference to a ClassificationNode in the canonical StatusType ClassificationScheme. A Registry MUST support the status types as defined by the StatusType ClassificationScheme. The canonical StatusType ClassificationScheme MAY easily be extended by adding additional ClassificationNodes to the canonical StatusType ClassificationScheme.

602

2.5.9.1

603

The following table lists pre-defined choices for the RegistryObject status attribute.

Attribute objectType

Attribute status

Pre-defined RegistryObject Status Types

604 605

Name

Description

Approved

Status of a RegistryObject that catalogues content that has been submitted to the registry and has been subsequently approved.

Deprecated

Status of a RegistryObject that catalogues content that has been submitted to the registry and has been subsequently deprecated.

Submitted

Status of a RegistryObject that catalogues content that has been submitted to the registry.

Withdrawn

Status of a RegistryObject that catalogues content that has been withdrawn from the registry. A repository item has been removed but its ExtrinsicObject still exists.

606

May 2, 2005 Page 23 of 78

607

2.5.10

Attribute versionInfo

608 609 610

Each RegistryObject instance MAY have a versionInfo attribute. The value of the versionInfo attribute MUST be of type VersionInfo. The versionInfo attribute provides information about the specific version of a RegistryObject. The versionInfo attribute is set by the registry.

611

2.6

612

VersionInfo class encapsulates information about the specific version of a RegistryObject.

613

The attributes of the VersionInfo class are described below.

614

2.6.1

Class VersionInfo

Attribute Summary

Attribute

Data Type

Required

versionName comment

String16 LongName

Yes No

Default Value 1.1

Specified By Registry Registry

Mutable Yes Yes

615 616

2.6.2

Attribute versionName

617 618 619

Each VersionInfo instance MUST have versionName. This attribute defines the version name identifying the VersionInfo for a specific RegistryObject version. The value for this attribute MUST be automatically generated by the Registry implementation.

620

2.6.3

621 622 623 624 625

Each VersionInfo instance MAY have comment. This attribute defines the comment associated with the VersionInfo for a specific RegistryObject version. The value of the comment attribute is indirectly provided by the client as the value of the comment attribute of the <rim:Request> object. The value for this attribute MUST be set by the Registry implementation based upon the <rim:Request> comment attribute value provided by the client if any.

626

2.7

627

Super Classes: Identifiable

628 629 630

The information model supports the ability for an attribute in an instance of an information model class to reference a RegistryObject instance using an object reference. An object reference is modeled in this specification with the ObjectRef class.

631 632 633

An instance of the ObjectRef class is used to reference a RegistryObject. A RegistryObject MAY be referenced via an ObjectRef instance regardless of its location within a registry or that of the object referring to it.

634

2.7.1

Attribute comment

Class ObjectRef

Attribute Summary

635

Attribute

Data Type

Required

id home

URN URI

Yes No

createReplica

Boolean

Default Value Base URI of local registry false

Specified By

Mutable

Client Client

Yes Yes

Client

Yes

636

May 2, 2005 Page 24 of 78

637

2.7.2

Attribute id

638 639

Every ObjectRef instance MUST have an id attribute. The id attribute MUST contain the value of the id attribute of the RegistryObject being referenced.

640

2.7.3

641 642 643

Every ObjectRef instance MAY optionally have a home attribute specified. The home attribute if present MUST contain the base URI to the home registry for the referenced RegistryObject. The base URI to a registry is described by the REST interface as defined in [ebRS].

644

2.7.3.1

645 646

When the home attribute is specified, and matches the base URI of a remote registry, then ObjectRef is referred to as a remote ObjectRef.

647 648 649

If the home attribute is null then its default value is the base URI to the current registry. When the home attribute is null or matches the base URI of the current registry, then the ObjectRef is referred to as a local ObjectRef.

650

2.7.4

651 652 653

Every ObjectRef instance MAY have a createReplica attribute. The createReplica attribute is a client supplied hint to the registry. When createReplica is true a registry SHOULD create a local replica for the RegistryObject being referenced if it happens to be a remote ObjectRef.

654

2.8

655 656 657

Slot instances provide a dynamic way to add arbitrary attributes to RegistryObject instances. This ability to add attributes dynamically to RegistryObject instances enables extensibility within the information model.

658

A slot is composed of a name, a slotType and a Bag of values.

659

2.8.1

Attribute home

Local Vs. Remote ObjectRefs

Attribute createReplica

Class Slot

Attribute Summary

660

Attribute name slotType values

Data Type

Required

LongName LongName Sequence of LongName

Yes No Yes

Default Value

Specified By Client Client Client

Mutable No No No

661 662

2.8.2

Attribute name

663 664 665

Each Slot instance MUST have a name. The name is the primary means for identifying a Slot instance within a RegistryObject. Consequently, the name of a Slot instance MUST be locally unique within the RegistryObject instance.

666

2.8.3

667 668 669

Each Slot instance MAY have a slotType that allows different slots to be grouped together. The slotType attribute MAY also be used to indicate the data type or value domain for the slot value(s).

Attribute slotType

May 2, 2005 Page 25 of 78

670

2.8.4

Attribute values

671 672 673

A Slot instance MUST have a Sequence of values. The Sequence of values MAY be empty. Since a Slot represent an extensible attribute whose value MAY be a Sequence, therefore a Slot is allowed to have a Sequence of values rather than a single value.

674

2.9

675

Super Classes: RegistryObject

676

The ExtrinsicObject class is the primary metadata class for a RepositoryItem.

677

2.9.1

Class ExtrinsicObject

Attribute Summary

678

Attribute

Data Type

contentVersionI nfo

VersionInfo

isOpaque mimeType

Boolean LongName

Required Yes for READs, No for WRITEs. No No

Default Value

false application/o ctet-stream

Specified By Registry

Client Client

Mutable No

No No

679 680

Note that attributes inherited from super classes are not shown in the table above.

681

2.9.2

682 683 684 685

Each ExtrinsicObject instance MAY have a contentVersionInfo attribute. The value of the contentVersionInfo attribute MUST be of type VersionInfo. The contentVersionInfo attribute provides information about the specific version of the RepositoryItem associated with an ExtrinsicObject. The contentVersionInfo attribute is set by the registry.

686

2.9.3

687 688 689 690

Each ExtrinsicObject instance MAY have an isOpaque attribute defined. This attribute determines whether the content catalogued by this ExtrinsicObject is opaque to (not readable by) the registry. In some situations, a Submitting Organization may submit content that is encrypted and not even readable by the registry.

691

2.9.4

692 693 694

Each ExtrinsicObject instance MAY have a mimeType attribute defined. The mimeType provides information on the type of repository item catalogued by the ExtrinsicObject instance. The value of this attribute SHOULD be a registered MIME media type at http://www.iana.org/assignments/media-types.

695

2.10

696

Super Classes: RegistryObject

697 698

RegistryPackage instances allow for grouping of logically related RegistryObject instances even if individual member objects belong to different Submitting Organizations.

699

2.10.1

700 701

The RegistryPackage class defines no new attributes other than those that are inherited from RegistryObject super class. The inherited attributes are not shown here.

Attribute contentVersionInfo

Attribute isOpaque

Attribute mimeType

Class RegistryPackage

Attribute Summary

May 2, 2005 Page 26 of 78

702

2.11

Class ExternalIdentifier

703

Super Classes: RegistryObject

704 705 706 707 708

ExternalIdentifier instances provide the additional identifier information to RegistryObject such as DUNS number, Social Security Number, or an alias name of the organization. The attribute identificationScheme is used to reference the identification scheme (e.g., “DUNS”, “Social Security #”), and the attribute value contains the actual information (e.g., the DUNS number, the social security number). Each RegistryObject MAY contain 0 or more ExternalIdentifier instances.

709

2.11.1

Attribute Summary

710

Attribute identificationScheme registryObject value

Data Type

Required

ObjectRef ObjectRef LongName

Yes Yes Yes

Default Value

Specified By Client Client Client

Mutable Yes No Yes

711

Note that attributes inherited from the super classes of this class are not shown.

712

2.11.2

713 714 715

Each ExternalIdentifier instance MUST have an identificationScheme attribute that references a ClassificationScheme. This ClassificationScheme defines the namespace within which an identifier is defined using the value attribute for the RegistryObject referenced by the RegistryObject attribute.

716

2.11.3

717 718

Each ExternalIdentifier instance MUST have a registryObject attribute that references the parent RegistryObject for which this is an ExternalIdentifier.

719

2.11.4

720 721

Each ExternalIdentifier instance MUST have a value attribute that provides the identifier value for this ExternalIdentifier (e.g., the actual social security number).

722

2.12

723

Super Classes: RegistryObject

724 725 726

ExternalLinks use URIs to associate content in the registry with content that MAY reside outside the registry. For example, an organization submitting an XML Schema could use an ExternalLink to associate the XML Schema with the organization's home page.

727

2.12.1

Attribute identificationScheme

Attribute registryObject

Attribute value

Class ExternalLink

Attribute Summary

728

Attribute externalURI

Data Type

Required

URI

Yes

Default Value

Specified By Client

Mutable Yes

729 730

2.12.2

Attribute externalURI

731 732 733 734

Each ExternalLink instance MUST have an externalURI attribute defined. The externalURI attribute provides a URI to the external resource pointed to by this ExternalLink instance. If the URI is a URL then a registry MUST validate the URL to be resolvable at the time of submission before accepting an ExternalLink submission to the registry.

May 2, 2005 Page 27 of 78

735

Association Information Model

736 737 738

A RegistryObject instance MAY be associated with zero or more RegistryObject instances. The information model defines the Association class, an instance of which MAY be used to associate any two RegistryObject instances.

739

3.1

740 741 742

One example of such an association is between two ClassificationScheme instances, where one ClassificationScheme supersedes the other ClassificationScheme as shown in Figure 3. This may be the case when a new version of a ClassificationScheme is submitted.

743 744

In Figure 3, we see how an Association is defined between a new version of the NAICS ClassificationScheme and an older version of the NAICS ClassificationScheme.

Example of an Association

745

746 747



Figure 3: Example of RegistryObject Association

748

3.2

Source and Target Objects

749 750 751 752

An Association instance represents an association between a source RegistryObject and a target RegistryObject. These are referred to as sourceObject and targetObject for the Association instance. It is important which object is the sourceObject and which is the targetObject as it determines the directional semantics of an Association.

753 754 755

In the example in Figure 3, it is important to make the newer version of NAICS ClassificationScheme be the sourceObject and the older version of NAICS be the targetObject because the associationType implies that the sourceObject supersedes the targetObject (and not the other way around).

756

3.3

757 758 759

Each Association MUST have an associationType attribute that identifies the type of that association. The value of this attribute MUST be the id of a ClassificationNode under the canonical AssociationType ClassificationScheme.

760

3.4

761 762 763 764 765

A common use case for the Association class is when a User “u” creates an Association “a” between two RegistryObjects “o1” and “o2” where Association “a” and RegistryObjects “o1” and “o2” are objects that were created by the same User “u”. This is the simplest use case, where the Association is between two objects that are owned by the same User that is defining the Association. Such Associations are referred to as intramural Associations.

Association Types

Intramural Association

May 2, 2005 Page 28 of 78

766 767

Figure 4 below, extends the previous example in Figure 3 for the intramural Association case. 



768



769

Figure 4: Example of Intramural Association

770

3.5

Extramural Association

771 772 773

The information model also allows more sophisticated use cases. For example, a User “u1” creates an Association “a” between two RegistryObjects “o1” and “o2” where Association “a” is owned by User “u1”, but RegistryObjects “o1” and “o2” are owned by User “u2” and User “u3” respectively.

774 775 776

In this use case an Association is defined where either or both objects that are being associated are owned by a User different from the User defining the Association. Such Associations are referred to as extramural Associations.

777 778 779 780

Figure 5 below, extends the previous example in Figure 4 for the extramural Association case. Note that it is possible for an extramural Association to have two distinct Users rather than three distinct Users as shown in Figure 5. In such case, one of the two users owns two of the three objects involved (Association, sourceObject and targetObject).

781

May 2, 2005 Page 29 of 78

782 783



Figure 5: Example of Extramural Association

784

3.5.1

Controlling Extramural Associations

785 786 787

The owner of a RegistryObject MAY control who can create extramural associations to that RegistryObject using custom access control policies using the reference access control feature described in section 9.2.4.

788

3.6

Class Association

789

Super Classes: RegistryObject

790 791

Association instances are used to define many-to-many associations among RegistryObjects in the information model.

792 793

An instance of the Association class represents an association between two RegistryObjects.

794

3.6.1

Attribute Summary

795

Attribute associationType sourceObject targetObject

Data Type

Required

ObjectRef ObjectRef ObjectRef

Yes Yes Yes

Default Value

Specified By Client Client Client

Mutable No No No

796

May 2, 2005 Page 30 of 78

797

3.6.2

Attribute associationType

798 799 800 801 802

Each Association MUST have an associationType attribute that identifies the type of that association. The value of the associationType attribute MUST be a reference to a ClassificationNode within the canonical AssociationType ClassificationScheme. While the AssociationType scheme MAY easily be extended, a Registry MUST support the canonical association types as defined by the canonical AssociationType ClassificationScheme.

803

3.6.3

804 805

Each Association MUST have a sourceObject attribute that references the RegistryObject instance that is the source of that Association.

806

3.6.4

807 808

Each Association MUST have a targetObject attribute that references the RegistryObject instance that is the target of that Association.

Attribute sourceObject

Attribute targetObject

May 2, 2005 Page 31 of 78

809

Classification Information Model

810

This section describes how the information model supports Classification of RegistryObject.

811 812 813

A RegistryObject MAY be classified in many ways. For example the RegistryObject for the same Collaboration Protocol Profile (CPP) may be classified by its industry, by the products it sells and by its geographical location.

814 815 816 817 818 819 820 821

A general ClassificationScheme can be viewed as a tree structure. In the example shown in Figure 6, RegistryObject instances representing Collaboration Protocol Profiles are shown as shaded boxes. Each Collaboration Protocol Profile represents an automobile manufacturer. Each Collaboration Protocol Profile is classified by the ClassificationNode named “Automotive” under the ClassificationScheme instance with name “Industry.” Furthermore, the US Automobile manufacturers are classified by the “US” ClassificationNode under the ClassificationScheme with name “Geography.” Similarly, a European automobile manufacturer is classified by the “Europe” ClassificationNode under the ClassificationScheme with name “Geography.”

822 823

The example shows how a RegistryObject may be classified by multiple ClassificationNode instances under multiple ClassificationScheme instances (e.g., Industry, Geography).

824 825

826

Figure 6: Example showing a Classification Tree

827 828 829 830

It is important to point out that the shaded nodes (FortMotorCompnay, GentleMotorsCorporation etc.) are not part of the ClassificationScheme tree. The leaf nodes of the ClassificationScheme tree are Health Care, Automotive, Retail, US and Europe. The shaded nodes are associated with the ClassificationScheme tree via a Classification Instance that is not shown in the picture.

831

May 2, 2005 Page 32 of 78

832

Classifications, the information model defines the classes and relationships shown in Figure 7.

833

Figure 7: Information Model Classification View

834 835 836 837 838

A Classification is somewhat like a specialized form of an Association. Figure 8 shows an example of an ExtrinsicObject Instance for a Collaboration Protocol Profile (CPP) object that is classified by a ClassificationNode representing the Industry that it belongs to.

839

Figure 8: Classification Instance Diagram

840 841 842

4.1

Class ClassificationScheme

843

Super Classes: RegistryObject

844 845 846 847

A ClassificationScheme instance describes a taxonomy. The taxonomy hierarchy may be defined internally to the registry by instances of ClassificationNode, or it may be defined externally to the Registry, in which case the structure and values of the taxonomy elements are not known to the Registry.

848 849

In the first case the classification scheme is said to be internal and in the second case the classification scheme is said to be external.

850

4.1.1

Attribute Summary

851

Attribute

Data Type

Required

Default Value

Specified By

Mutable

May 2, 2005 Page 33 of 78

isInternal nodeType

Boolean ObjectRef

Yes Yes

Client Client

No No

852 853

Note that attributes inherited by a ClassificationScheme class from the RegistryObject class are not shown.

854

4.1.2

855 856 857 858

When submitting a ClassificationScheme instance the submitter MUST declare whether the ClassificationScheme instance represents an internal or an external taxonomy. This allows the registry to validate the subsequent submissions of ClassificationNode and Classification instances in order to maintain the type of ClassificationScheme consistent throughout its lifecycle.

859

4.1.3

860 861 862 863 864 865

When submitting a ClassificationScheme instance the Submitting Organization MUST declare the structure of taxonomy nodes within the ClassificationScheme via the nodeType attribute. The value of the nodeType attribute MUST be a reference to a ClassificationNode within the canonical NodeType ClassificationScheme. A Registry MUST support the node types as defined by the canonical NodeType ClassificationScheme. The canonical NodeType ClassificationScheme MAY easily be extended by adding additional ClassificationNodes to it.

866

The following canonical values are defined for the NodeType ClassificationScheme:

867

UniqueCode: This value indicates that each node of the taxonomy has a unique code assigned to it.

EmbeddedPath: This value indicates that the unique code assigned to each node of the taxonomy also encodes its path. This is the case in the NAICS taxonomy.

NonUniqueCode: In some cases nodes are not unique, and it is necessary to use the full path (from ClassificationScheme to the node of interest) in order to identify the node. For example, in a geography taxonomy Moscow could be under both Russia and the USA, where there are five cities of that name in different states.

870 871

Attribute nodeType

868 869

Attribute isInternal

872 873 874 875 876

4.2

Class ClassificationNode

877

Super Classes: RegistryObject

878 879 880

ClassificationNode instances are used to define tree structures where each node in the tree is a ClassificationNode. Such ClassificationScheme trees are constructed with ClassificationNode instances under a ClassificationScheme instance, and are used to define Classification schemes or ontologies.

881 882

4.2.1

Attribute Summary

883

Attribute

Data Type

Required

Default Value

Specified By

parent code path

ObjectRef LongName String

No No No

885

4.2.2

Attribute parent

886 887 888

Each ClassificationNode MAY have a parent attribute. The parent attribute either references a parent ClassificationNode or a ClassificationScheme instance in case of first level ClassificationNode instances.

Client Client Registry

Mutable No No No

884

May 2, 2005 Page 34 of 78

889

4.2.3

Attribute code

890 891 892 893

Each ClassificationNode MAY have a code attribute. The code attribute contains a code within a standard coding scheme. The code attribute of a ClassificationNode MUST be unique with respect to all sibling ClassificationNodes that are immediate children of the same parent ClassificationNode or ClassificationScheme.

894

4.2.4

895 896 897 898 899 900 901

Each ClassificationNode MAY have a path attribute. A registry MUST set the path attribute for any ClassificationNode that has a non-null code attribute value, when the ClassificationNode is retrieved from the registry. The path attribute MUST be ignored by the registry when it is specified by the client at the time the object is submitted to the registry. The path attribute contains the canonical path from the root ClassificationScheme or ClassificationNode within the hierarchy of this ClassificationNode as defined by the parent attribute. The path attribute of a ClassificationNode MUST be unique within a registry. The path syntax is defined in 4.2.5.

902

4.2.5

903 904 905

The path attribute of the ClassificationNode class contains an absolute path in a canonical representation that uniquely identifies the path leading from the root ClassificationScheme or ClassificationNode to that ClassificationNode.

906

The canonical path representation is defined by the following BNF grammar:

Attribute path

Canonical Path Syntax

907 908 909 910 911 912 913 914

canonicalPath ::= '/' rootSchemeOrNodeId nodePath nodePath ::= '/' nodeCode | '/' nodeCode ( nodePath )?

In the above grammar, rootSchemeOrNodeId is the id attribute of the root ClassificationScheme or ClassificationNode instance, and nodeCode is defined by NCName production as defined by http://www.w3.org/TR/REC-xml-names/#NT-NCName.

915 916

4.2.5.1

Example of Canonical Path Representation

917 918

The following canonical path represents what the path attribute would contain for the ClassificationNode with code “United States” in the sample Geography scheme in section 4.2.5.2.

919 920

/Geography-id/NorthAmerica/UnitedStates

921

4.2.5.2

Sample Geography Scheme

922 923

Note that in the following examples, the id attributes have been chosen for ease of readability and are therefore not valid id values.

924 925 926

927 928 929 930 931

932 933 934

<ClassificationNode id="Asia-id" parent="Geography-id" code="Asia" /> <ClassificationNode id="Japan-id" parent="Asia-id" code="Japan" /> regrep-rim-3.0-os Copyright © OASIS Open 2005. All Rights Reserved.

May 2, 2005 Page 35 of 78

935 936 937 938

4.3

Class Classification

939

Super Classes: RegistryObject

940 941 942 943

A Classification instance classifies a RegistryObject instance by referencing a node defined within a particular ClassificationScheme. An internal Classification will always reference the node directly, by its id, while an external Classification will reference the node indirectly by specifying a representation of its value that is unique within the external classification scheme.

944 945 946

The attributes for the Classification class are intended to allow for representation of both internal and external classifications in order to minimize the need for a submission or a query to distinguish between internal and external classifications.

947 948

In Figure 6, Classification instances are not explicitly shown but are implied as associations between the RegistryObject instances (shaded leaf node) and the associated ClassificationNode.

949

4.3.1

Attribute Summary

950

Attribute

Data Type

classificationScheme

ObjectRef

classificationNode

ObjectRef

classifiedObject nodeRepresentation

ObjectRef LongName

Required for external classifications for internal classifications Yes for external classifications

Default Value null

Specified By Client

Mutable

null

Client

null

Client Client

No No

951

Note that attributes inherited from the super classes of this class are not shown.

952

4.3.2

953 954 955

If the Classification instance represents an external classification, then the classificationScheme attribute is required. The classificationScheme value MUST reference a ClassificationScheme instance.

956

4.3.3

957 958

If the Classification instance represents an internal classification, then the classificationNode attribute is required. The classificationNode value MUST reference a ClassificationNode instance.

959

4.3.4

960 961

For both internal and external classifications, the classifiedObject attribute is required and it references the RegistryObject instance that is classified by this Classification.

962

4.3.5

963 964 965 966 967

If the Classification instance represents an external classification, then the nodeRepresentation attribute is required. It is a representation of a taxonomy element from a classification scheme. It is the responsibility of the registry to distinguish between different types of nodeRepresentation, like between the classification scheme node code and the classification scheme node canonical path. This allows the client to transparently use different syntaxes for nodeRepresentation.

Attribute classificationScheme

Attribute classificationNode

Attribute classifiedObject

Attribute nodeRepresentation

May 2, 2005 Page 36 of 78

968

4.3.6

Context Sensitive Classification

969 970 971 972 973 974 975 976 977

Consider the case depicted in Figure 9 where a Collaboration Protocol Profile for ACME Inc. is classified by the “Japan” ClassificationNode under the “Geography” Classification scheme. In the absence of the context for this Classification its meaning is ambiguous. Does it mean that ACME is located in Japan, or does it mean that ACME ships products to Japan, or does it have some other meaning? To address this ambiguity a Classification MAY optionally be associated with another ClassificationNode (in this example named isLocatedIn) that provides the missing context for the Classification. Another Collaboration Protocol Profile for MyParcelService MAY be classified by the “Japan” ClassificationNode where this Classification is associated with a different ClassificationNode (e.g., named shipsTo) to indicate a different context than the one used by ACME Inc.

978

979 980



Figure 9: Context Sensitive Classification

981 982 983 984

Thus, in order to support the possibility of Classification within multiple contexts, a Classification is itself classified by any number of Classifications that bind the first Classification to ClassificationNodes that provide the missing contexts.

985

In summary, the generalized support for Classification schemes in the information model allows:

986

A RegistryObject to be classified by defining an internal Classification that associates it with a ClassificationNode in a ClassificationScheme.

A RegistryObject to be classified by defining an external Classification that associates it with a value in an external ClassificationScheme.

A RegistryObject to be classified along multiple facets by having multiple Classifications that associate it with multiple ClassificationNodes or value within a ClassificationScheme.

987 988 989 990 991

May 2, 2005 Page 37 of 78

992

993

A Classification defined for a RegistryObject to be qualified by the contexts in which it is being classified.

994

4.4

Example of Classification Schemes

995 996 997 998

The following table lists some examples of possible ClassificationSchemes enabled by the information model. These schemes are based on a subset of contextual concepts identified by the ebXML Business Process and Core Components Project Teams. This list is meant to be illustrative not prescriptive.

999

Classification Scheme Industry Process Product / Services Locale Temporal Role 1000

Usage Example

Standard Classification Schemes NAICS

Find all Parties in Automotive industry Find a ServiceInterface that implements a Process Find a Business that sells a product or offers a UNSPSC service Find a Supplier located in Japan ISO 3166 Find Supplier that can ship with 24 hours Find All Suppliers that have a Role of “Seller” Table 1: Sample Classification Schemes

1001

May 2, 2005 Page 38 of 78

1002

Provenance Information Model

1003 1004

This chapter describes the classes that enable the description of the parties responsible for creating, publishing, or maintaining a RegistryObject or RepositoryItem.

1005 1006 1007 1008

The term provenance in the English language implies the origin and history of ownership of things of value. When applied to the ebXML Registry, provenance implies information about the origin, history of ownership, custodianship, and other relationships between entities such as people and organizations and RegistryObjects.

1009

This includes information about:

1010

•

The registered user that is the submitter of a RegistryObject or RepositoryItem.

1011

•

The organization that is the submitter submitted the object on behalf of (Submitting Organization)

1012 1013

•

The organization that is responsible for the maintainence of the submitted object (Responsible Organization)

1014

•

Any other persons that have some relationship with the submitted object

1015

5.1

1016

Super Classes: RegistryObject

1017

Person instances represent persons or humans.

1018

5.1.1

Class Person

Attribute Summary Attribute

Data Type

Required

addresses emailAddresses personName telephoneNumbers

Set of PostalAddress Set of EmailAddress PersonName Set of TelephoneNumber

No No No No

Default Value

Specified By Client Client Client Client

Mutable Yes Yes No Yes

1019 1020

5.1.2

Attribute addresses

1021 1022 1023

Each Person instance MAY have an attribute addresses that is a Set of PostalAddress instances. Each PostalAddress provides a postal address for that user. A Person SHOULD have at least one PostalAddress.

1024

5.1.3

1025 1026 1027

Each Person instance MAY have an attribute emailAddresses that is a Set of EmailAddress instances. Each EmailAddress provides an email address for that person. A Person SHOULD have at least one EmailAddress.

1028

5.1.4

1029

Each Person instance MAY have a personName attribute that provides the name for that user.

1030

5.1.5

1031 1032 1033

Each Person instance MAY have a telephoneNumbers attribute that contains the Set of TelephoneNumber instances defined for that user. A Person SHOULD have at least one TelephoneNumber.

Attribute emailAddresses

Attribute personName Attribute telephoneNumbers

May 2, 2005 Page 39 of 78

1034

5.2

Class User

1035

Super Classes: Person

1036 1037 1038 1039

User instances represent users that have registered with a registry. User instances are also used in an AuditableEvent to keep track of the identity of the requestor that sent the request that generated the AuditableEvent. User class is a sub-class of Person class that inherits all attributes of the Person class and does not add any new attributes.

1040

5.2.1

1041 1042 1043 1044 1045

A user MAY be affiliated with zero or more organizations. Each such affiliation is modeled in ebRIM using an Association instance between a User instance and an Organization instance. The associationType in such cases SHOULD be either the canonical “AffiliatedWith” associationType or a ClassificationNode that is a descendant of the ClassificationNode representing the canonical “AffiliatedWith” associationType.

Associating Users With Organizations

1046

Figure 10: User Affiliation With Organization Instance Diagram

1047 1048 1049

5.3

Class Organization

1050

Super Classes: RegistryObject

1051 1052

Organization instances provide information on organizations such as a Submitting Organization. Each Organization instance MAY have a reference to a parent Organization.

1053

5.3.1

Attribute Summary

1054

Attribute addresses emailAddresses parent primaryContact

Data Type

Required

Set of PostalAddress Set of EmailAddress ObjectRef ObjectRef

No No No No

Default Value

Specified By Client Client Client Client

Mutable Yes Yes Yes No

May 2, 2005 Page 40 of 78

telephoneNumbers

Set of TelephoneNumber

Client

Yes

1055 1056

5.3.2

Attribute addresses

1057 1058 1059

Each Organization instance MAY have an addresses attribute that is a Set of PostalAddress instances. Each PostalAddress provides a postal address for that organization. An Organization SHOULD have at least one PostalAddress.

1060

5.3.3

1061 1062 1063

Each Organization instance MAY have an attribute emailAddresses that is a Set of EmailAddress instances. Each EmailAddress provides an email address for that Organization. An Organization SHOULD have at least one EmailAddress.

1064

5.3.4

1065 1066

Each Organization instance MAY have a parent attribute that references the parent Organization instance, if any, for that organization.

1067

5.3.5

1068 1069

Each Organization instance SHOULD have a primaryContact attribute that references the Person instance for the person that is the primary contact for that organization.

1070

5.3.6

1071 1072 1073

Each Organization instance MUST have a telephoneNumbers attribute that contains the Set of TelephoneNumber instances defined for that organization. An Organization SHOULD have at least one telephone number.

1074

5.4

1075 1076 1077 1078 1079 1080 1081

An organization MAY be associated with zero or more RegistryObject instances. Each such association is modeled in ebRIM using an Association instance between an Organization instance and a RegistryObject instance. The associationType in such cases MAY be (but is not restricted to) either the canonical “SubmitterOf” associationType or the canonical “ResponsibleFor” associationType. The “SubmitterOf” associationType indicates the organization that submitted the RegistryObject (via a User). The “ResponsibleFor” associationType indicates the organization that is designated as the organization responsible for the ongoing maintenance of the RegistryObject.

1082 1083 1084

Associations between Organizations and RegistryObjects do not entitle organizations to any special privileges with respect to the RegistryObject. Such privileges are defined by the Access Control Policies defined for the RegistryObject as described in chapter 9.

Attribute emailAddresses

Attribute parent

Attribute primaryContact

Attribute telephoneNumbers

Associating Organizations With RegistryObjects

May 2, 2005 Page 41 of 78

1085 1086



Figure 11: Organization to RegistryObject Association Instance Diagram

1087 1088

5.5

Class PostalAddress

1089

PostalAddress defines attributes of a postal address.

1090

5.5.1

Attribute Summary

1091

Attribute city country postalCode slots stateOrProvince street streetNumber

Data Type ShortName ShortName ShortName Set of Slot ShortName ShortName String32

Required No No No No No No No

Default Value

Specified By Client Client Client Client Client Client Client

Mutable Yes Yes Yes Yes Yes Yes Yes

1092 1093

5.5.2

Attribute city

1094

Each PostalAddress MAY have a city attribute identifying the city for that address.

1095

5.5.3

1096

Each PostalAddress MAY have a country attribute identifying the country for that address.

1097

5.5.4

1098 1099

Each PostalAddress MAY have a postalCode attribute identifying the postal code (e.g., zip code) for that address.

Attribute country Attribute postalCode

May 2, 2005 Page 42 of 78

1100

5.5.5

Attribute stateOrProvince

1101 1102

Each PostalAddress MAY have a stateOrProvince attribute identifying the state, province or region for that address.

1103

5.5.6

1104

Each PostalAddress MAY have a street attribute identifying the street name for that address.

1105

5.5.7

1106 1107

Each PostalAddress MAY have a streetNumber attribute identifying the street number (e.g., 65) for the street address.

1108

5.6

1109

This class defines attributes of a telephone number.

1110

5.6.1

Attribute street Attribute streetNumber

Class TelephoneNumber Attribute Summary

1111

Attribute areaCode countryCode extension number phoneType

Data Type String8 String8 String8 String16 ObjectRef

Required No No No No No

Default Value

Specified By Client Client Client Client Client

Mutable Yes Yes Yes Yes Yes

1112 1113

5.6.2

Attribute areaCode

1114 1115

Each TelephoneNumber instance MAY have an areaCode attribute that provides the area code for that telephone number.

1116

5.6.3

1117 1118

Each TelephoneNumber instance MAY have a countryCode attribute that provides the country code for that telephone number.

1119

5.6.4

1120 1121

Each TelephoneNumber instance MAY have an extension attribute that provides the extension number, if any, for that telephone number.

1122

5.6.5

1123 1124

Each TelephoneNumber instance MAY have a number attribute that provides the local number (without area code, country code and extension) for that telephone number.

1125

5.6.6

1126 1127 1128

Each TelephoneNumber instance MAY have a phoneType attribute that provides the type for the TelephoneNumber. The value of the phoneType attribute MUST be a reference to a ClassificationNode in the canonical PhoneType ClassificationScheme.

Attribute countryCode

Attribute extension

Attribute number

Attribute phoneType

May 2, 2005 Page 43 of 78

1129

5.7

Class EmailAddress

1130

This class defines attributes of an email address.

1131

5.7.1

Attribute Summary Attribute

address type

Data Type ShortName ObjectRef

Required

Default Value

Yes No

Specified By Client Client

Mutable Yes Yes

1132

5.7.2

Attribute address

1133

Each EmailAddress instance MUST have an address attribute that provides the actual email address.

1134

5.7.3

1135 1136 1137

Each EmailAddress instance MAY have a type attribute that provides the type for that email address. The value of the type attribute MUST be a reference to a ClassificationNode in the canonical EmailType ClassificationScheme as referenced in appendix .

1138

5.8

1139

This class defines attributes for a person’s name.

1140

5.8.1

Attribute type

Class PersonName Attribute Summary

1141

Attribute firstName lastName middleName

Data Type ShortName ShortName ShortName

Required No No No

Default Value

Specified By Client Client Client

Mutable Yes Yes Yes

1142 1143

5.8.2

Attribute firstName

1144

Each PersonName SHOULD have a firstName attribute that is the first name of the person.

1145

5.8.3

1146

Each PersonName SHOULD have a lastName attribute that is the last name of the person.

1147

5.8.4

1148

Each PersonName SHOULD have a middleName attribute that is the middle name of the person.

Attribute lastName Attribute middleName

May 2, 2005 Page 44 of 78

1149

Service Information Model

1150 1151 1152

This chapter describes the classes in the information model that support the registration of service descriptions. The service information model is flexible and supports the registration of web services as well as other types of services.

1153

Figure 12: Service Information Model

1154 1155

6.1

Class Service

1156

Super Classes: RegistryObject

1157

Service instances describe services, such as web services.

1158

6.1.1

Attribute Summary

1159

Attribute serviceBindings

Data Type

Required

Set of ServiceBinding

Yes, Set may be empty

Default Value

Specified By Client

Mutable Yes

1160 1161

6.1.2

Attribute serviceBindings

1162 1163

A Service MAY have a serviceBindings attribute that defines the service bindings that provide access to that Service.

1164

6.2

1165

Super Classes: RegistryObject

1166 1167 1168

ServiceBinding instances are RegistryObjects that represent technical information on a specific way to access a Service instance. An example is where a ServiceBinding is defined for each protocol that may be used to access the service.

Class ServiceBinding

May 2, 2005 Page 45 of 78

1169

6.2.1

Attribute Summary

1170

Data Type

Required

accessURI service specificationLinks

URI ObjectRef Set of SpecificationLink

targetBinding

ObjectRef

No Yes Yes, Set may be empty No

Attribute

Default Value

Specified By Client Client Client Client

Mutable Yes No Yes Yes

1171

6.2.2

Attribute accessURI

1172 1173 1174 1175

A ServiceBinding MAY have an accessURI attribute that defines the URI to access that ServiceBinding. This attribute is ignored if a targetBinding attribute is specified for the ServiceBinding. If the URI is a URL then a registry MUST validate the URL to be resolvable at the time of submission before accepting a ServiceBinding submission to the registry.

1176

6.2.3

1177

A ServiceBinding MUST have a service attribute whose value MUST be the id of its parent Service.

1178

6.2.4

1179 1180 1181

A ServiceBinding MAY have a specificationLinks attribute defined that is a Set of references to SpecificationLink instances. Each SpecificationLink instance links the ServiceBinding to a particular technical specification that MAY be used to access the Service for the ServiceBinding.

1182

6.2.5

1183 1184 1185

A ServiceBinding MAY have a targetBinding attribute defined that references another ServiceBinding. A targetBinding MAY be specified when a service is being redirected to another service. This allows the rehosting of a service by another service provider.

1186

6.3

1187

Super Classes: RegistryObject

1188 1189 1190 1191

A SpecificationLink provides the linkage between a ServiceBinding and one of its technical specifications that describes how to use the service using the ServiceBinding. For example, a ServiceBinding MAY have SpecificationLink instances that describe how to access the service using a technical specification such as a WSDL document or a CORBA IDL document.

1192

6.3.1

Attribute service Attribute specificationLinks

Attribute targetBinding

Class SpecificationLink

Attribute Summary

1193

Attribute

Data Type

Required

serviceBinding specificationObject usageDescription usageParameters

ObjectRef ObjectRef InternationalString Bag of FreeFormText

Yes Yes No No

Default Value

Specified By Client Client Client Client

Mutable No Yes Yes Yes

1194

May 2, 2005 Page 46 of 78

1195

6.3.2

Attribute serviceBinding

1196 1197

A SpecificationLink instance MUST have a serviceBinding attribute that provides a reference to its parent ServiceBinding instances. It value MUST be the id of the parent ServiceBinding object.

1198

6.3.3

1199 1200 1201 1202 1203

A SpecificationLink instance MUST have a specificationObject attribute that provides a reference to a RegistryObject instance that provides a technical specification for the parent ServiceBinding. Typically, this is an ExtrinsicObject instance representing the technical specification (e.g., a WSDL document). It may also be an ExternalLink object in case the technical specification is a resource that is external to the registry.

1204

6.3.4

1205 1206 1207

A SpecificationLink instance MAY have a usageDescription attribute that provides a textual description of how to use the optional usageParameters attribute described next. The usageDescription is of type InternationalString, thus allowing the description to be in multiple languages.

1208

6.3.5

1209 1210 1211

A SpecificationLink instance MAY have a usageParameters attribute that provides a Bag of Strings representing the instance specific parameters needed to use the technical specification (e.g., a WSDL document) specified by this SpecificationLink object.

Attribute specificationObject

Attribute usageDescription

Attribute usageParameters

1212

May 2, 2005 Page 47 of 78

1213

Event Information Model

1214 1215 1216

This chapter defines the information model classes that support the registry Event Notification feature. These classes include AuditableEvent, Subscription, Selector and Action. They constitute the foundation of the Event Notification information model.

1217 1218 1219 1220 1221

Figure 13 shows how a Subscription may be defined that uses a pre-configured AdhocQuery instance as a selector to select the AuditableEvents of interest to the subscriber and one or more Actions to deliver the selected events to the subscriber. The Action may deliver the events by using its endPoint attribute to invoke a registered ServiceBinding to a registered Service or by sending the events to an email address.

1222 1223

Figure 13: Event Information Model

1224 1225 1226

7.1

Class AuditableEvent

1227

Super Classes: RegistryObject

1228 1229 1230

AuditableEvent instances provide a long-term record of events that effected a change in a RegistryObject. A RegistryObject is associated with an ordered Set of AuditableEvent instances that provide a complete audit trail for that RegistryObject.

1231 1232

AuditableEvents are usually a result of a client-initiated request. AuditableEvent instances are generated by the Registry Service to log such Events.

1233 1234 1235 1236

Often such events effect a change in the life cycle of a RegistryObject. For example a client request could Create, Update, Deprecate or Delete a RegistryObject. An AuditableEvent is typically created when a request creates or alters the content or ownership of a RegistryObject. Read-only requests typically do not generate an AuditableEvent.

1237

7.1.1

Attribute Summary

1238

Attribute eventType affectedObjects requestId timestamp user

Data Type ObjectRef Set of ObjectRef URI dateTime ObjectRef

Required

Default Value

Specified By

Mutable

Yes Yes

Registry Registry

No No

Yes Yes Yes

Registry Registry Registry

No No No

1239

May 2, 2005 Page 48 of 78

1240

7.1.2

Attribute eventType

1241 1242 1243 1244 1245 1246

Each AuditableEvent MUST have an eventType attribute which identifies the type of event recorded by the AuditableEvent. The value of the eventType attribute MUST be a reference to a ClassificationNode in the canonical EventType ClassificationScheme. A Registry MUST support the event types as defined by the canonical EventType ClassificationScheme. The canonical EventType ClassificationScheme MAY easily be extended by adding additional ClassificationNodes to the canonical EventType ClassificationScheme.

1247

7.1.2.1

1248 1249 1250

The following table lists pre-defined auditable event types. A Registry MUST support the event types listed below. A Registry MAY support additional event types as long as they are ClassificationNodes within the canonical EventType ClassificationScheme.

Pre-defined Auditable Event Types

1251

Name

Description

Approved

An Event that marks the approval of a RegistryObject.

Created

An Event that marks the creation of a RegistryObject.

Deleted

An Event that marks the deletion of a RegistryObject.

Deprecated

An Event that marks the deprecation of a RegistryObject.

Downloaded

An Event that marks the downloading of a RegistryObject.

Relocated

An Event that marks the relocation of a RegistryObject.

Undeprecated

An Event that marks the undeprecation of a RegistryObject.

Updated

An Event that that marks the updating of a RegistryObject.

Versioned

An Event that that marks the creation of a new version of a RegistryObject.

1252 1253

7.1.3

Attribute affectedObjects

1254 1255

Each AuditableEvent MUST have an affectedObjects attribute that identifies the Set of RegistryObjects instances that were affected by this event.

1256

7.1.4

1257 1258

Each AuditableEvent MUST have a requestId attribute that identifies the client request instance that affected this event.

1259

7.1.5

1260 1261

Each AuditableEvent MUST have a timestamp attribute that records the date and time that this event occurred.

1262

7.1.6

1263 1264

Each AuditableEvent MUST have a user attribute that identifies the User that sent the request that generated this event affecting the RegistryObject instance.

1265

7.2

1266

Super Classes: RegistryObject

1267 1268

Subscription instances are RegistryObjects that define a User’s interest in certain types of AuditableEvents. A User MAY create a subscription with a registry if he or she wishes to receive

Attribute requestId

Attribute timestamp

Attribute user

Class Subscription

May 2, 2005 Page 49 of 78

1269

notification for a specific type of event.

1270

7.2.1

Attribute Summary

1271

Attribute

Data Type

Required

actions

Set of Action

endTime notificationInterval

dateTime duration

Yes, may be empty No No

selector startTime

ObjectRef dateTime

Yes No

Default Value

P1D day)

Current time

Specified By Client

Mutable Yes

Client Client

Yes No

Client Client

No Yes

1272 1273

7.2.2

Attribute actions

1274 1275 1276

A Subscription instance MUST have an actions attribute that is a Set of zero or more Action instances. An Action instance describes what action the registry must take when an event matching the Subscription transpires. The Action class is described in section 7.5.

1277

7.2.3

1278 1279

This attribute denotes the time after which the subscription expires and is no longer active. If this attribute is missing the subscription never expires.

1280

7.2.4

1281 1282 1283

This attribute denotes the duration that a registry MUST wait between delivering successive notifications to the client. The client specifies this attribute in order to control the frequency of notification communication between registry and client.

1284

7.2.5

1285 1286 1287 1288

This attribute defines the selection criteria that determine which events match this Subscription and are of interest to the User. The selector attribute references a pre-defined query that is stored in the registry as an instance of the AdhocQuery class. This AdhocQuery instance specifies or “selects” events that are of interest to the subscriber. The AdhocQueryClass is described in section 7.3.

1289

7.2.5.1

1290 1291 1292 1293

The selector query MAY be configured as a paremeterized stored query as defined by [ebRS]. A Subscription MUST specify the parameters values for stored parameterized queries as Slots as defined in section title “Specifying Query Invocation Parameters” in [ebRS]. These parameter value Slots if specified MUST be specified on the Subscription object.

1294

7.2.6

1295 1296

This attribute denotes the time at which the subscription becomes active. If this attribute is missing subscription starts immediately.

1297

7.3

1298

Super Classes: RegistryObject

1299

The AdhocQuery class is a container for an ad hoc query expressed in a query syntax that is supported

Attribute endTime

Attribute notificationInterval

Attribute selector

Specifying Selector Query Parameters

Attribute startTime

Class AdhocQuery

May 2, 2005 Page 50 of 78

1300 1301 1302 1303

by an ebXML Registry. Instances of this class MAY be used for discovery of RegistryObjects within the registry. Instances of AdhocQuery MAY be stored in the registry like other RegistryObjects. Such stored AdhocQuery instances are similar in purpose to the concept of stored procedures in relational databases.

1304

7.3.1

Attribute Summary

1305

Attribute

Data Type

Required

queryExpression

QueryExpre ssion

Required when defining a new AdhocQuery. Not required when invoking a stored query.

Default Value

Specified By Client

Mutable No

1306 1307

7.3.2

Attribute queryExpression

1308 1309 1310 1311 1312

Each AdhocQuery instance MAY have a queryExpression attribute that contains the query expression for the AdhocQuery depending upon the use case as follows. When an AdhocQuery is submitted to the registry it MUST contain a queryExpression. When a stored AdhocQuery is included in an AdhocQueryRequest to invoke a stored query as defined by the stored query feature defined in [ebRS] it SHOULD NOT contain a queryExpression.

1313

7.4

1314 1315

The QueryExpression class is an extensible wrapper that can contain a query expression in any supported query syntax such as SQL or Filter Query syntax.

1316

7.4.1

Class QueryExpression

Attribute Summary

1317

Attribute

Data Type

Required

queryLanguage <any>

ObjectRef anyType

Required Required

Default Value

Specified By Client Client

Mutable No No

1318

7.4.2

Attribute queryLanguage

1319 1320 1321 1322 1323 1324

The queryLanguage attribute specifies the query language that the query expression conforms to. The value of this attribute MUST be a reference to a ClassificationNode within the canonical QueryLanguage ClassificationScheme. A Registry MUST support the query languages as defined by the canonical QueryLanguage ClassificationScheme. The canonical QueryLanguage ClassificationScheme MAY easily be extended by adding additional ClassificationNodes to it to allow a registry to support additional query language syntaxes.

1325

7.4.3

1326 1327 1328

This attribute is extensible and therefor MAY be of any type depending upon the queryLanguage specified. For SQL queryLanguage it MUST be an SQL query string. For Filter query it MUST be a FilterQueryType defined by [RR-QUERY-XSD].

1329

7.5

1330 1331

The Action class is an abstract super class that specifies what the registry must do when an event matching the action’s Subscription transpires. A registry uses Actions within a Subscription to

Attribute <any>

Class Action

May 2, 2005 Page 51 of 78

1332

asynchronously deliver event Notifications to the subscriber.

1333 1334 1335

If no Actions are defined within the Subscription it implies that the user does not wish to be notified asynchronously by the registry and instead intends to periodically poll the registry and pull the pending Notifications.

1336

This class does not currently define any attributes.

1337

7.6

1338

Super Classes: Action

1339 1340 1341

The NotifyAction class is a sub-class of Action class. An instance of NotifyAction represents an Action that the registry MUST perform in order to notify the subscriber of a Subscription of the events of interest to that subscriber.

1342

7.6.1

Class NotifyAction

Attribute Summary

1343

Attribute

Data Type

endPoint notificationOption

URI ObjectRef

Required YES No

Default Value Reference to ObjectRefs ClassificationNode

Specified By Client Client

Mutable Yes

1344 1345

7.6.2

Attribute endPoint

1346 1347 1348

This attribute specifies a URI that identifies a service end point that MAY be used by the registry to deliver notifications. Currently this attribute can either be a “mailto” URI (e.g. mailto:[email protected]) or a “urn:uuid” URI.

1349 1350 1351

If endpoint is a “mailto” URI then the registry MUST use the specified email address to deliver the notification via email. Email configuration parameters such as the “from” email address and SMTP server configuration MAY be specified in a registry specific manner.

1352 1353 1354

If endpoint is a “urn:uuid” URI then it MUST be a reference to a ServiceBinding object to a Service that implements the RegistryClient interface as defined by [ebRS]. In this case the registry MUST deliver the notification by web service invocation as defined by the ServiceBinding object.

1355

7.6.3

1356 1357 1358 1359 1360 1361 1362

This attribute controls the specific type of event notification content desired by the subscriber. It is used by the subscriber to control the granularity of event notification content communicated by the registry to the subscriber. The value of the notificationOption attribute MUST be a reference to a ClassificationNode within the canonical NotificationOptionType ClassificationScheme. A Registry MUST support the notificationOption types as defined by the NotificationOptionType ClassificationScheme. The canonical NotificationOptionType ClassificationScheme MAY easily be extended by adding additional ClassificationNodes to it.

1363

7.6.3.1

1364

The following canonical values are defined for the NotificationOptionType ClassificationScheme: Name Description

Attribute notificationOption

Pre-defined notificationOption Values

ObjectRefs

Indicates that the subscriber wants to receive only references to RegistryObjects that match the Subscription within a notification.

Objects

Indicates that the subscriber wants to receive actual RegistryObjects that match the Subscription within a notification.

May 2, 2005 Page 52 of 78

1365 1366

7.7

Class Notification

1367

Super Classes: RegistryObject

1368 1369 1370 1371

The Notification class represents a Notification from the registry regarding an event that matches a Subscription. A registry may uses a Notification instance to notify a client of an event that matches a Subscription they have registered. This is a push model of notification. A client may also pull events from the registry using the AdhocQuery protocol defined by [ebRS].

1372

7.7.1

Attribute Summary

1373

Attribute subscription registryObjectList

Data Type ObjectRef Set of Identifiable

Required YES No

Default Value

Specified By Registry Registry

Mutable No No

1374 1375

7.7.2

Attribute subscription

1376 1377

This attribute specifies a reference to a Subscription instance within the registry. This is the Subscription that matches the event for which this Notification is about.

1378

7.7.3

1379 1380 1381 1382

This attribute specifies a Set of ObjectRefs or a Set of RegistryObject instances that represent the objects that were impacted by the event that matched the Subscription. The registry MUST include ObjectRef or RegistryObject instances as Set elements depending upon the notificationOption specified for the Subscription.

Attribute registryObjectList

May 2, 2005 Page 53 of 78

1383

Cooperating Registries Information Model

1384 1385

This chapter describes the classes in the information model that support the cooperating registries capability defined by [ebRS].

1386

8.1

1387

Super Classes: RegistryObject

1388

Registry instances are used to represent a single physical OASIS ebXML Registry.

1389

8.1.1.1

Class Registry

Attribute Summary

1390

Attribute

Data Type

Required

catalogingLatency

duration

conformanceProfile

String16

operator replicationSyncLatency

ObjectRef duration

Yes No

specificationVersion

Sring8

Yes

Default Value P1D (1 day) “registry Lite” P1D (1 day)

Specified By Registry

Mutable

Registry

Yes

Registry Registry

Yes Yes

Registry

Yes

1391 1392

8.1.2

Attribute catalogingLatency

1393 1394 1395

Each Registry instance MAY have an attribute named catalogingLatency that specifies the maximum latency between the time a submission is made to the registry and the time it gets cataloged by any cataloging services defined for the objects within the submission.

1396

8.1.3

1397 1398 1399

Each Registry instance MAY have an attribute named conformanceProfile that declares the conformance profile that the registry supports. The conformance profiles choices are “registryLite” and “registryFull” as defined by [ebRS].

1400

8.1.4

1401 1402 1403 1404

Each Registry instance MUST have an attribute named operator that is a reference to the Organization instance representing the organization for the registry’s operator. Since the same Organization MAY operate multiple registries, it is possible that the home registry for the Organization referenced by operator may not be the local registry.

1405

8.1.5

1406 1407 1408

Each Registry instance MAY have an attribute named replicationSyncLatency that specifies the maximum latency between the time when an original object changes and the time when its replica object within the registry gets updated to synchronize with the new state of the original object.

1409

8.1.6

1410 1411

Each Registry instance MUST have an attribute named specificationVersion that is the version of the ebXML Registry Services Specification [ebRS].

Attribute conformanceProfile

Attribute operator

Attribute replicationSyncLatency

Attribute specificationVersion

May 2, 2005 Page 54 of 78

1412

8.2

Class Federation

1413

Super Classes: RegistryObject

1414

Federation instances are used to represent a registry federation.

1415

8.2.1.1

Attribute Summary

1416

Attribute replicationSync Latency

Data Type

Required

duration

Default Value P1D (1 day)

Specified By Client

Mutable Yes

1417 1418

8.2.2

1419 1420 1421 1422 1423 1424

Each Federation instance MAY specify a replicationSyncLatency attribute that describes the time duration that is the amount of time within which a member of this Federation MUST synchronize itself with the current state of the Federation. Members of the Federation MAY use this parameter to periodically synchronize the federation metadata they MUST cache locally about the state of the Federation and its members. Such synchronization MAY be based upon the registry event notification capability.

1425

8.2.3

1426 1427 1428 1429 1430

A federation is created by the creation of a Federation instance. Membership of a registry within a federation is established by creating an Association between the Registry instances for the registry seeking membership with the Federation instance. The Association MUST have its associationType be the id of the canonical ClassificationNode “HasFederationMember”, the federation instance as its sourceObject and the Registry instance as its targetObject as shown in Figure 14.

1431 1432

Attribute replicationSyncLatency

Federation Configuration



Figure 14: Federation Information Model

1433 1434

May 2, 2005 Page 55 of 78

1435

May 2, 2005 Page 56 of 78

1436

Access Control Information Model

1437 1438 1439 1440

This chapter defines the Access Control Information Model used by the registry to control access to RegistryObjects and RepositoryItems managed by it. The Access Control features of the registry require that it function as both a Policy Enforcement Point (PEP) and a Policy Decision Point (PDP) as defined in [XACML].

1441 1442

This specification first defines an abstract Access Control Model that enables access control policies to be defined and associated with RegistryObjects.

1443

Next, it defines a normative and required binding of that abstract model to [XACML] .

1444 1445

Finally, it defines how a registry MAY support additional bindings to custom access control technologies.

1446

9.1

1447 1448

The Access Control Model attempts to reuse terms defined by [XACML] wherever possible. The definitions of some key terms are duplicated here from [XACML] for convenience of the reader:

Terminology

1449

Term

Description

Access

Performing an action. An example is a user performing a delete action on a RegistryObject.

Access Control

Controlling access in accordance with a policy. An example is preventing a user from performing a delete action on a RegistryObject that is not owned by that user.

Action

An operation on a resource. An example is the delete action on a RegistryObject.

Attribute

Characteristic of a subject, resource, action. Some examples are: •

id attribute of a subject

•

role attribute of a subject

•

group attribute of a subject

•

id attribute of a RegistryObject resource

Policy

A set of rules. May be a component of a policy set

PolicySet

A set of policies, other policy sets. May be a component of another policy set

Resource

Subject

Data, service or system component. Examples are: •

A RegistryObject resource

•

A RepositoryItem resource

An actor whose attributes may be referenced by within a Policy definition. Example: •

A User instance within the registry

1450 1451

9.2

Use Cases for Access Control Policies

1452

The following are some common use cases for access control policy:

May 2, 2005 Page 57 of 78

1453

9.2.1

Default Access Control Policy

1454 1455 1456

Define a default access control policy that gives read access to any one and access to all actions to owner of the resource and Registry Administrator. This access control policy implicitly applies to any resource that does not explicitly have a custom Access Control Policy defined for it.

1457

9.2.2

1458 1459

Define a custom access control policy to restrict read access to a resource to specified user(s), group(s) and/or role(s).

1460

9.2.3

1461 1462

Define a custom access control policy to grant update and/or delete access to a resource to specified user(s), group(s) and/or role(s).

1463

9.2.4

1464 1465 1466 1467

Define a custom access control policy to restrict reference access to a resource to specified user(s), group(s) and/or role(s). For example a custom access control policy MAY be defined to control who can create an extramural association to a RegistryObject. Another example is to control who can add members to a RegistryPackage.

1468

9.3

1469

A registry MUST control access to the following types of resources:

Restrict Read Access To Specified Subjects

Grant Update and/or Delete Access To Specified Subjects

Reference Access Control

Resources

1470 1471 1472 1473

•

RegistryObject resource is any instance of RegistryObject class or its sub-classes. Each RegistryObject resource references an Access Control Policy that controls all access to that object.

1474 1475

•

RepopositoryItem resource is any instance of RepositoryItem class. By default, access control to a RepositoryItem is managed by the same Access Control Policy as its ExtrinsicObject.

1476 1477

A registry MUST support the following resource attributes.

1478

9.3.1

1479 1480

The owner attribute of a Resource carries the value of id attribute of the User instance within the registry that represents the owner of the resource.

1481

9.3.2

1482 1483 1484

The selector attribute of a Resource carries a string representing a query as define by a sub-type of AdhocQueryType in [ebRS]. The registry MUST use this query is a filter to select the resources that match it.

1485

9.3.3

1486 1487 1488

The resource attribute <attribute> represents any attribute defined by the RegistryObject type or one of its sub-types. For example, it could be the targetObject attribute in case the resource is an Association object.

1489

9.4

1490 1491

A registry MUST support the following actions as operations on RegistryObject and RepositoryItem resources managed by the registry.

Resource Attribute: owner

Resource Attribute: selector

Resource Attribute: <attribute>

Actions

May 2, 2005 Page 58 of 78

1492

9.4.1

Create Action

1493 1494

The create action creates a RegistryObject or a RepositoryItem. A submitObjects operation performed on the LifeCycleManager interface of the registry result in a create action.

1495

9.4.2

1496 1497 1498 1499

The read action reads a RegistryObject or a RepositoryItem without having any impact on its state. An operation performed on the QueryManager interface of the registry result in a read action. A registry MUST first perform the query for the read action and then MUST filter out all resources matching the query for which the client does not have access for the read action.

1500

9.4.3

1501 1502 1503 1504

The update action updates or modifies the state of a RegistryObject or a RepositoryItem. An updateObjects operation performed on the LifeCycleManager interface of the registry result in a update action. A registry MUST evaluate access control policy decision based upon the state of the resource before and not the after performing the update action.

1505

9.4.4

1506 1507

The delete action deletes a RegistryObject or a RepositoryItem. A removeObjects operation performed on the LifeCycleManager interface of the registry results in a delete action.

1508

9.4.5

1509 1510

The approve action approves a RegistryObject. An approveObjects operation performed on the LifeCycleManager interface of the registry result in an approve action.

1511

9.4.6

1512 1513 1514 1515

The reference action creates a reference to a RegistryObject. A submitObjects or updateObjects operation performed on the LifeCycleManager interface of the registry MAY result in a reference action. An example of a reference action is when an Association is created that references a RegistryObject resource as its source or target object.

1516

9.4.7

1517 1518

The deprecate action deprecates a RegistryObject. A deprecateObjects operation performed on the LifeCycleManager interface of the registry result in a deprecate action.

1519

9.4.8

1520 1521

The undeprecate action undeprecates a previously deprecated RegistryObject. An undeprecateObjects operation performed on the LifeCycleManager interface of the registry result in an undeprecate action.

1522

9.4.9

1523 1524

This attribute identifies the specific action being performed by the subject on one or more resources. A Registry MUST support access control for all the types of actions identified in this document above.

1525

9.4.10

1526 1527 1528

This attribute is only relevant to the “Reference” action. This attribute MAY be used to specify the object from which the reference is being made to the resource being protected. The value of this attribute MUST be the value of the id attribute for the object that is the source of the reference.

Read Action

Update Action

Delete Action

Approve Action

Reference Action

Deprecate Action

Undeprecate Action

Action Attribute: action-id

Action Attribute: reference-source

May 2, 2005 Page 59 of 78

1529

9.4.11

Action Attribute: reference-source-attribute

1530 1531 1532 1533

This attribute is only relevant to the “Reference” action. This attribute MAY be used to specify the attribute name within the Class that the reference-source object is an instance of. The value of this attribute MUST be the name of an attribute within the RIM Class that is the Class for the reference source object.

1534 1535 1536 1537 1538

For example, if the reference source object is an Association instance then the reference-sourceattribute MAY be used to specify the values “sourceObject” or “targetObject” to restrict the references to be allowed from only specific attributes of the source object. This enables, for example, a policy to only allow reference to objects under its protection only from the sourceObject attribute of an Association instance.

1539

9.5

1540 1541

A registry MUST support the following Subject attributes within its Access Control Policies. In addition a registry MAY support additional subject attributes.

1542

9.5.1

1543

The identity attribute of a Subject carries the value of id attribute of a User instance within the registry.

1544

9.5.2

1545 1546 1547

The group attribute of a Subject carries the value of the code attribute of a ClassificationNode within the canonical SubjectGroup ClassificationScheme (see appendix ) within the registry. A registry MUST NOT allow anyone but a subject with the canonical RegistryAdministrator role to assign roles to users.

1548

9.5.2.1

1549 1550 1551

Arbitrary groups MAY be defined by extending the canonical SubjectGroup ClassificationScheme. Groups MAY be assigned to registered users by classifying their User instance with a ClassificationNode within the canonical SubjectGroup ClassificationScheme.

1552

9.5.3

1553 1554

The role attribute of a Subject carries the value of the code attribute of a ClassificationNode within the canonical SubjectRole ClassificationScheme (see appendix ) within the registry.

1555

9.5.3.1

1556 1557 1558 1559 1560

Arbitrary roles MAY be defined by extending the canonical SubjectRole ClassificationScheme. Roles MAY be assigned to registered users by classifying their User instance with a ClassificationNode within the canonical SubjectRole ClassificationScheme. A registry MUST NOT allow anyone but a subject with the canonical RegistryAdministrator role to assign roles to users. A registry MAY use registry specific means to assign RegistryAdministrator roles.

1561

9.6

1562 1563 1564 1565 1566 1567 1568

Every RegistryObject is associated with exactly one Access Control Policy that governs “who” is authorized to perform “what” action on that RegistryObject. The abstract Access Control Model allows the Access Control Policy to be defined in any arbitrary format as long as it is represented in the registry as a repositoryItem and its corresponding ExtrinsicObject. The objectType attribute of this ExtrinsicObject MUST reference a descendent of the “xacml” node (e.g. “Policy” or PolicySet”) in the canonical ObjectType ClassificationScheme. This distinguishes XACML “Policy” or PolicySet” Access Control Policy objects from other ExtrinsicObject instances.

Subjects

Attribute id Attribute group

Assigning Groups To Users

Attribute role

Assigning Roles To Users

Abstract Access Control Model

May 2, 2005 Page 60 of 78

1569

9.6.1

Access Control Policy for a RegistryObject

1570 1571 1572 1573

A RegistryObject MAY be associated with an Access Control Policy by a special Association with the canonical associationType of AccessControlPolicyFor. This association has the reference to the ExtrinsicObject representing the Access Control Policy as the value of its sourceObject and has the reference to the RegistryObject as the value of its targetObject attribute.

1574 1575

If a RegistryObject does not have an Access Control Policy explicitly associated with it, then it is implicitly associated with the default Access Control Policy defined for the registry.

1576

1577 1578



Figure 15: Instance Diagram for Abstract Access Control Information Model

1579 1580 1581 1582 1583 1584

Figure 15 shows an instance diagram where an Organization instance org references an ExtrinsicObject instance accessControlPolicy as its Access Control Policy object. The accessControlPolicy object has its objectType attribute referencing a node in the canonical ObjectType ClassificationScheme that represents a supported Access Control Policy format. The accessControlPolicy ExtrinsicObject has a repositoryItem defining its access control policy information in a specific format.

1585

9.6.2

1586 1587 1588 1589 1590 1591

By default, access control to a RepositoryItem is managed by the Access Control Policy associated with its ExtrinsicObject that provides metadata for the RepositoryItem. A RepositoryItem MAY have an Access Control Policy separate from its ExtrinsicObject. In such case, the Access Control Policy for the RepositoryItem is referenced via a Special Slot on its ExtrinsicObject. This special Slot has “repositoryItemACP” as its name and the id of the ExtrinsicObject representing the Access Control Policy for the RepositoryItem as its value.

1592

9.6.3

1593

A registry MUST support the default Access Control Policy.

1594 1595

The default Access Control Policy applies to any RegistryObject that does not explicitly have an Access Control Policy associated with it. • The following list summarizes the default Access Control Policy semantic that a registry

1596 1597 1598

•

Access Control Policy for a RepositoryItem

Default Access Control Policy

SHOULD implement: Only a Registered User is granted access to create actions.

May 2, 2005 Page 61 of 78

1599

•

1600 1601

•

1602 1603 1604

•

An unauthenticated Registry Client is granted access to read actions. The Registry MUST assign the default RegistryGuest role to such Registry Clients. A Registered User has access to all actions on Registry Objects submitted by the Registered User. The Registry Administrator and Registry Authority have access to all actions on all Registry Objects.

1605 1606

A registry MAY have a default access control policy that differs from the above semantics.

1607

9.6.4

1608 1609

A registry SHOULD have a root Access Control Policy that bootstraps the Access Control Model by controlling access to Access Control Policies.

1610 1611

As described in Figure 15, an access control policy is an ExtrinsicObject that contains a pointer to a repository item. The access control policies themselves are created, updated, and deleted.

1612 1613 1614 1615 1616

To define who may create access control policies pertaining to specified resources, it is necessary to have one or more administrative Access Control Policies. Such policies restrict Registry Users from creating access control policies to unauthorized resources. This version of the Registry specifications defines a single Root Access Control Policy that allows all actions on Access Control Policies for a resource under the following conditions:

Root Access Control Policy

1617

•

Subject is the owner of the resource

1618

•

Subject has a role of RegistryAdministrator

1619

9.6.5

Performance Implications

1620 1621 1622 1623

Excessive use of custom Access Control Policies MAY result in slower processing of registry requests in some registry implementations. It is therefor suggested that, whenever possible, a submitter SHOULD reuse an existing Access Control Policy. Submitters SHOULD use good judgement on when to reuse or extend an existing Access Control Policy and when to create a new one.

1624

9.7

1625 1626

A registry MAY support custom access control policies based upon a normative though optional binding of the Access Control Model to [XACML].

1627 1628

This section defines the normative though optional binding of the abstract Access Control Model to [XACML]. This section assumes the reader is familiar with [XACML].

1629 1630

This binding to [XACML] enables a flexible access control mechanism that supports access control policy definition from the simples to the most sophisticated use cases.

1631 1632

In this binding the policyInfo repositoryItem in the abstract Access Control Model MUST be one of the following:

Access Control Model: XACML Binding

1633

•

A PolicySet as defined by [XACML]

1634

•

A Policy as defined by [XACML]

1635

May 2, 2005 Page 62 of 78

1636 1637



Figure 16: Access Control Information Model: [XACML] Binding

1638

9.7.1

Resource Binding

1639 1640

[XACML] defines an element called ResourceAttributeDesignator that identifies the type of resource attribute being specified in a ResourceMatch or Apply element.

1641 1642

The resource attributes defined by the abstract Access Control Model map to the following ResourceAttributeDesignator definitions:

1643

Resource Attribute owner selector <attribute>

AttributeId urn:oasis:names:tc:ebxmlregrep:rim:acp:resource:owner urn:oasis:names:tc:ebxmlregrep:rim:acp:resource:selector urn:oasis:names:tc:ebxmlregrep:rim:acp:resource:<attribute>

DataType http://www.w3.org/2001/XMLSchema #anyURI http://www.w3.org/2001/XMLSchema #string Depends upon the specific attribute.

Table 2: Resource Binding to [XACML]

1644 1645 1646

Data Type Boolean String ObjectRef URI Integer DateTime

XACML Data Type Identifier URI http://www.w3.org/2001/XMLSchema#boolean http://www.w3.org/2001/XMLSchema#string http://www.w3.org/2001/XMLSchema#anyURI http://www.w3.org/2001/XMLSchema#anyURI http://www.w3.org/2001/XMLSchema#integer http://www.w3.org/2001/XMLSchema#dateTime

Description

Used strings of all lengths

1647 1648

9.7.2

Action Binding

1649 1650

[XACML] defines an element called ActionAttributeDesignator that identifies the type of action being specified within in an ActionMatch or Apply element.

1651

May 2, 2005 Page 63 of 78

1652

AttributeValue in the ActionMatch definitions:

1653

Registry Action Create Read Update Delete Approve Reference Deprecate Undeprecate 1654

ActionMatch.ActionAttributeDesignator.AttributeId

AttributeValue

urn:oasis:names:tc:xacml:1.0:action:action-id urn:oasis:names:tc:xacml:1.0:action:action-id urn:oasis:names:tc:xacml:1.0:action:action-id urn:oasis:names:tc:xacml:1.0:action:action-id urn:oasis:names:tc:xacml:1.0:action:action-id urn:oasis:names:tc:xacml:1.0:action:action-id urn:oasis:names:tc:xacml:1.0:action:action-id urn:oasis:names:tc:xacml:1.0:action:action-id Table 3: Action Binding to [XACML]

create read update delete approve reference deprecate undeprecate

1655

Action Attribute

ActionAttributeDesignator.AttributeId

DataType

urn:oasis:names:tc:xacml:1.0:action:a ction-id

http://www.w3.org/2001/XMLSc hema#anyURI

referencesource referencesourceattribute

urn:oasis:names:tc:ebxmlregrep:rim:acp:subject:reference-source

http://www.w3.org/2001/XMLSchema#strin g

urn:oasis:names:tc:ebxml-regrep:rim:acp:subject: reference-source-attribute

http://www.w3.org/2001/XMLSchema#strin g

1656 1657

9.7.3

Subject Binding

1658 1659

[XACML] defines an element called SubjectAttributeDesignator that identifies the type of subject attribute being specified in a SubjectMatch or Apply element.

1660 1661 1662

The subjects defined by the abstract Access Control Model map to the following SubjectAttributeDesignator definitions:

1663

Subject Attribute id roles groups <attribute>

SubjectAttributeDesignator

DataType

urn:oasis:names:tc:xacml:1.0:subj ect:subject-id

http://www.w3.org/2001/XMLSchema #anyURI

urn:oasis:names:tc:ebxmlregrep:rim:acp:subject:roles urn:oasis:names:tc:ebxmlregrep:rim:acp:subject:groups urn:oasis:names:tc:ebxmlregrep:rim:acp:subject:<attribute>

http://www.w3.org/2001/XMLSchema#string http://www.w3.org/2001/XMLSchema#string

As defined by attribute definition. Can be any attribute of the User instance for the subject.

Table 4: Subject Binding to [XACML]

1664 1665

9.7.4

Function classification-node-compare

1666 1667 1668

It is often necessary to test whether a resource matches a specific objectType or its sub-types. A client MAY use the special XACML function named classification-node-compare to perform such comparisons.

1669 1670 1671

A registry MUST support a special XACML function named classification-node-compare whose canonical id is urn:oasis:names:tc:ebxml-regrep:rim:acp:function:classification-node-compare. A client MAY use this function within XACML Access control Policies to perform ClassificationNode

May 2, 2005 Page 64 of 78

1672 1673

comparisons in a taxonomy-aware manner. The following example shows how a ResourceMatch may be specified within an XACML Acccess Control Policy to perform such comparisons.

1674

<ResourceMatch MatchId="urn:oasis:names:tc:ebxmlregrep:rim:acp:function:classification-node-compare"> <!—Specify the id for canonical ClassificationNode for ExtrinsicObject objectType--> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"> urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:ExtrinsicObject </AttributeValue>

1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692

<!—Specify the objectType of resource to compare with objectType ExtrinsicObject --> <ResourceAttributeDesignator DataType = "http://www.w3.org/2001/XMLSchema#string" AttributeId = "urn:oasis:names:tc:ebxmlregrep:rim:acp:resource:objectType"/> </ResourceMatch>

1693 1694

9.7.5

1695 1696

This specification normatively defines the following constraints on the binding of the Access Control Model to [XACML]. These constraints MAY be relaxed in future versions of this specification.

1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725

•

9.7.6

Constraints on XACML Binding

All Policy and PolicySet definitions MUST reside within an ebXML Registry as RepositoryItems.

Example: Default Access Control Policy

The following Policy defines the default access control policy. This Policy MUST implicitly apply to any resource that does not have an explicit Access Control Policy defined. It consists of 3 rules, which in plain English are described as follows: • • •

Any subject can perform read action on any resource A subject may perform any action on a resource for which they are the owner. A subject with role of RegistryAdministrator may perform any action on any resource.

The non-normative listing of the default Access Control Policy follows: <?xml version="1.0" encoding="UTF-8"?> <PolicySet PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policycombining-algorithm:permit-overrides" PolicySetId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:policy:default-access-control-policy" xmlns="urn:oasis:names:tc:xacml:1.0:policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:policy cs-xacmlschema-policy-01.xsd"> <Description>This PolicySet defines the default Access Control Policy for all registry resources.</Description> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/>

May 2, 2005 Page 65 of 78

1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787

</Resources> <Actions> <AnyAction/> </Actions> </Target> <Policy PolicyId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:policy:policyid:permit-anyone-to-read" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combiningalgorithm:permit-overrides"> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <AnyAction/> </Actions> </Target> <Rule Effect="Permit" RuleId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:rule:ruleid:permit-anyone-to-read"> <Description>Any Subject can perform read action on any resource.</Description> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue > <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> </ActionMatch> </Action> </Actions> </Target> </Rule> </Policy> <Policy PolicyId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:policy:policyid:permit-anyone-to-reference" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combiningalgorithm:permit-overrides"> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <AnyAction/> </Actions> </Target>

May 2, 2005 Page 66 of 78

1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850

<Rule Effect="Permit" RuleId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:rule:ruleid:permit-anyone-to-reference"> <Description>Any Subject can perform reference action on any resource as long as it is not deprecated.</Description> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">reference</Attribute Value> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> </ActionMatch> </Action> </Actions> </Target> <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:not"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-one-and-only"> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:resource:status" DataType="http://www.w3.org/2001/XMLSchema#anyURI"/> </Apply>  <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:oasis:names:tc:e bxml-regrep:StatusType:Deprecated</AttributeValue> </Apply> </Condition> </Rule> </Policy> <Policy PolicyId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:policy:policyid:permit-owner-all" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combiningalgorithm:permit-overrides"> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <AnyAction/> </Actions> </Target> <Rule Effect="Permit" RuleId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:rule:ruleid:permit-owner-all"> <Description>A Subject with role of ContenOwner can perform any action on resources owned by them.</Description> regrep-rim-3.0-os Copyright © OASIS Open 2005. All Rights Reserved.

May 2, 2005 Page 67 of 78

1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913

<Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <AnyAction/> </Actions> </Target> <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-one-and-only"> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI"/> </Apply> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-one-and-only"> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:resource:owner" DataType="http://www.w3.org/2001/XMLSchema#anyURI"/> </Apply> </Condition> </Rule> </Policy> <Policy PolicyId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:policy:policyid:permit-registryadministrator-all" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combiningalgorithm:permit-overrides"> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <AnyAction/> </Actions> </Target> <Rule Effect="Permit" RuleId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:rule:ruleid:permit-registryadministrator-all"> <Description>A Subject with role of RegistryAdministrator can perform any action on any resource.</Description> <Target> <Subjects> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/urn:oasis:names:tc: ebxmlregrep:classificationScheme:SubjectRole/RegistryAdministrator</Attribut eValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:ebxml-regrep:3.0:rim:acp:subject:roles" DataType="http://www.w3.org/2001/XMLSchema#string"/> </SubjectMatch> </Subject> regrep-rim-3.0-os Copyright © OASIS Open 2005. All Rights Reserved.

May 2, 2005 Page 68 of 78

</Subjects> <Resources> <AnyResource/> </Resources> <Actions> <AnyAction/> </Actions> </Target> </Rule> </Policy> </PolicySet>

1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941

9.7.7

Example: Custom Access Control Policy

The following Policy defines a custom access control policy to restrict read access to a resource to specified user or role. It also grants update access to specified role. It consists of 3 rules, which in plain English are described as follows: 1.

A subject may perform any action on a resource for which they are the owner. This reuses a Policy by reference from the default Access Control PolicySet. 2. A subject with the role of RegistryAdministrator may perform any action on any resource. This reuses a Policy by reference from the default Access Control PolicySet. 3. A subject with specified id may perform read actions on the resource. This restricts read access to the specified subject. 4. A subject with role of Manager may perform update actions on the resource. This relaxes update access restrictions to the specified subject. The listing of the custom Access Control Policy follows:

1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969

May 2, 2005 Page 69 of 78

1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026

<Policy PolicyId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:policy:permit-delete-access-control-policy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combiningalgorithm:permit-overrides" xmlns="urn:oasis:names:tc:xacml:1.0:policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:policy cs-xacmlschema-policy-01.xsd"> <Description>Allow Subject with specifed id to perform delete action on any resource.</Description> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <AnyAction/> </Actions> </Target> <Rule Effect="Permit" RuleId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:rule:ruleid:permit-delete-rule"> <Description>Allow Subject with specifed id to perform delete action on any resource.</Description> <Target> <Subjects> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:freebxml:registr y:predefinedusers:farrukh</AttributeValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI"/> </SubjectMatch> </Subject> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">delete</AttributeVal ue> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> </ActionMatch> </Action> </Actions> </Target> </Rule> </Policy>

May 2, 2005 Page 70 of 78

2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087

<Policy PolicyId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:policy:permit-update-access-control-policy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combiningalgorithm:permit-overrides" xmlns="urn:oasis:names:tc:xacml:1.0:policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:policy cs-xacmlschema-policy-01.xsd"> <Description>Allow Subjects with ProjectLead role to perform update action on any resource.</Description> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <AnyAction/> </Actions> </Target> <Rule Effect="Permit" RuleId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:rule:ruleid:permit-update-rule"> <Description>Allow Subjects with ProjectLead role to perform read action on any resource.</Description> <Target> <Subjects> <Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/urn:oasis:names:tc: ebxmlregrep:classificationScheme:SubjectRole/ProjectMember/ProjectLead</Attr ibuteValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:ebxml-regrep:3.0:rim:acp:subject:roles" DataType="http://www.w3.org/2001/XMLSchema#string"/> </SubjectMatch> </Subject> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">update</AttributeVal ue> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> </ActionMatch> </Action> </Actions> </Target> </Rule> </Policy> </PolicySet>

May 2, 2005 Page 71 of 78

2088

9.7.8

2089 2090

The following Policy defines an access control policy for controlling who can add members to a RegistryPackge. It makes use of the Reference action.

2091 2092

It consists of 3 rules, which in plain English are described as follows:

2093 2094 2095 2096 2097 2098 2099 2100 2101 2102

Example: Package Membership Access Control

Any subject can perform read action on any resource. Referenced from default access control policy. 2. A subject may perform any action on a resource for which they are the owner. Referenced from default access control policy. 3. A subject with role of RegistryAdministrator may perform any action on any resource. Referenced from default access control policy 4. A subjects with role ProjectLead may perform addmember action on any resource associated with this ACP. The following is a non-normative example listing of this custom Access Control Policy:

2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146

<?xml version="1.0" encoding="UTF-8"?> <PolicySet PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policycombining-algorithm:permit-overrides" PolicySetId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:policy:folderACP1" xmlns="urn:oasis:names:tc:xacml:1.0:policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:policy cs-xacmlschema-policy-01.xsd"> <Description>This PolicySet restricts adding members to RegistryPackage resource to Role ProjectLead</Description> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <AnyAction/> </Actions> </Target> <PolicyIdReference>urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:policy:policyid:permit-anyone-toread</PolicyIdReference> <PolicyIdReference>urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:policy:policyid:permit-owner-all</PolicyIdReference> <PolicyIdReference>urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:policy:policyid:permit-registryadministratorall</PolicyIdReference> <Policy PolicyId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:policy:permit-projectLead-addMember" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combiningalgorithm:permit-overrides" xmlns="urn:oasis:names:tc:xacml:1.0:policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:policy cs-xacmlschema-policy-01.xsd"> <Description>Allow Subjects with ProjectLead role to add members to any resource associated with this ACP.</Description> <Target> <Subjects> <AnySubject/> </Subjects>

May 2, 2005 Page 72 of 78

2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207

<Resources> <AnyResource/> </Resources> <Actions> <AnyAction/> </Actions> </Target> <Rule Effect="Permit" RuleId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:rule:ruleid:permit-projectLead-addMember-rule"> <Description>Allow Subjects with ProjectLead role to add members to any resource.</Description> <Target> <Subjects> <Subject>  <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/urn:oasis:names:tc: ebxmlregrep:classificationScheme:SubjectRole/ProjectMember/ProjectLead</Attr ibuteValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:ebxml-regrep:3.0:rim:acp:subject:roles" DataType="http://www.w3.org/2001/XMLSchema#string"/> </SubjectMatch> </Subject> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <Action>  <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">reference</Attribute Value> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/> </ActionMatch> </Action> </Actions> </Target> <!-Match condition where all the following are true: 1. reference is being made via the attribute sourceObject (from an Association instance) 2. The associationType attribute of the Association matches the id for associationType HasMameber Above is equivalent to saying Match any HasMember associations where the resource (the RegistryPackage) is the sourceObject. --> <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

May 2, 2005 Page 73 of 78

<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">SourceObject</Attrib uteValue> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only"> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:action:reference-source-attribute" DataType="http://www.w3.org/2001/XMLSchema#string"/> </Apply> </Apply> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:oasis:names:tc:e bxml-regrep:AssociationType:HasMember</AttributeValue> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:anyURI-one-and-only"> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:ebxmlregrep:3.0:rim:acp:action:reference-source-attributefilter:associationType" DataType="http://www.w3.org/2001/XMLSchema#anyURI"/> </Apply> </Apply> </Condition> </Rule> </Policy> </PolicySet>

2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238

9.7.9

Resolving Policy References

2239 2240 2241 2242 2243 2244

An XACML PolicySet MAY reference XACML Policy objects defined outside the repository item containing the XACML PolicySet. A registry implementation MUST be able to resolve such references. To resolve such references efficiently a registry SHOULD be able to find the repository item containing the referenced Policy without having to load and search all Access Control Policies in the repository. This section describes the normative behavior that enables a registry to resolve policy references efficiently.

2245 2246 2247 2248

A registry SHOULD define a Content Cataloging Service for the canonical XACML PolicySet objectType. The PolicySet cataloging service MUST automatically catalog every PolicySet upon submission to contain a special Slot with name ComposedPolicies. The value of this Slot MUST be a Set where each element in the Set is the id for a Policy object that is composed within the PolicySet.

2249 2250

Thus a registry is able to use an ad hoc query to find the repositoryItem representing an XACML PolicySet that contains the Policy that is being referenced by another PolicySet.

2251

9.7.10

2252 2253

So far we have defined how ebXML registries MAY use [XACML] to define Access Control Policies to control access to RegistryObject and RepositoryItem resources.

2254 2255 2256

An important side effect of the normative binding of the Access Control Model to [XACML] is that enterprises MAY also use ebXML Registry as a [XACML] Policy store to manage Policies for protecting resources outside the registry.

2257 2258 2259

In this use case, enterprises may submit [XACML] Policies and PolicySets as ExtrinsicObjectRepositoryItem pairs. These Policies may be accessed or referenced by their URL as defined by the HTTP binding of the ebXML Registry Services interface in [ebRS].

ebXML Registry as a XACML Policy Store

May 2, 2005 Page 74 of 78

2260

9.8

Access Control Model: Custom Binding

2261 2262 2263 2264

A registry MAY support bindings to policies describes in formats other than [XACML]. The use of such policies sacrifices interoperability and is therefore discouraged. In such cases the RepositoryItem for the policy information MAY be in any format supported by the registry in an implementation specific manner.

May 2, 2005 Page 75 of 78

2265

References

2266

10.1

Normative References

2267 2268

[RFC2119]

2269

[ebRS]

2270 2271 2272

[UUID]

2273 2274 2275

[RFC 3066]

2276

[XPATH]

2277 2278

[XACML]

2279 2280 2281

[NCName]

2282 2283

10.2

2284 2285 2286

[ISO]

2287

[UML]

2288 2289

S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997, http://www.ietf.org/rfc/rfc2119.txt. ebXML Registry Services Specification Version 3.0 http://www.oasis-open.org/committees/regrep/documents/3.0/specs/regrep-rs3.0-cs-01.pdf DCE 128 bit Universal Unique Identifier http://www.opengroup.org/onlinepubs/009629399/apdxa.htm#tagcjh_20 H. Alvestrand, ed. RFC 3066: Tags for the Identification of Languages 1995. http://www.ietf.org/rfc/rfc3066.txt XML Path Language (XPath) Version 1.0 http://www.w3.org/TR/xpath OASIS eXtensible Access Control Markup Language (XACML) Version 1.0 http://www.oasis-open.org/committees/xacml/repository/cs-xacml-specification01.pdf Namespaces in XML 19990114 http://www.w3.org/TR/REC-xml-names/#NT-NCName

Informative References ISO 11179 Information Model http://208.226.167.205/SC32/jtc1sc32.nsf/576871ad2f11bba785256621005419 d7/b83fc7816a6064c68525690e0065f913?OpenDocument Unified Modeling Language http://www.uml.org http://www.omg.org/cgi-bin/doc?formal/03-03-01

May 2, 2005 Page 76 of 78

2290

A. Acknowledgments

2291 2292 2293

The editors would like to acknowledge the contributions of the OASIS ebXML Registry Technical Committee, whose voting members at the time of publication are listed as contributors on the title page of this document.

2294 2295

Finally, the editors wish to acknowledge the following people for their contributions of material used as input to the OASIS ebXML Registry specifications:

2296

Name Aziz Abouelfoutouh Ed Buchinski Asuman Dogac Michael Kass Richard Lessard Evan Wallace David Webber

Affiliation Government of Canada Government of Canada Middle East Technical University, Ankara Turkey NIST Government of Canada NIST Individual

2297

May 2, 2005 Page 77 of 78

2298

B. Notices

2299 2300 2301 2302 2303 2304 2305 2306

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

2307 2308 2309

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

2310

2311 2312 2313 2314 2315 2316 2317 2318

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

2319 2320

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

2321 2322 2323 2324 2325

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

May 2, 2005 Page 78 of 78

ebXML Registry Information Model (RIM) v3.0 (2005-05-01)

Related documents