Network Working Group B. Bergeson Request for Comments: 4403 K. Boogert Category: Informational Novell, Inc. V. Nanjundaswamy Oracle India Pvt. Ltd. February 2006
Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3)
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2006).
This document defines the Lightweight Directory Access Protocol (LDAPv3) schema for representing Universal Description, Discovery, and Integration (UDDI) data types in an LDAP directory. It defines the LDAP object class and attribute definitions and containment rules to model UDDI entities, defined in the UDDI version 3 information model, in an LDAPv3-compliant directory.
Table of Contents
1. Introduction ....................................................2 2. Conventions Used in This Document ...............................2 3. Representation of UDDI Data Structures ..........................2 4. Attribute Type Definitions ......................................6 5. Object Class Definitions .......................................28 6. Name Forms .....................................................32 7. DIT Structure Rules ............................................35 8. Security Considerations ........................................37 9. IANA Considerations ............................................37 10. Normative References ..........................................40
This document defines the Lightweight Directory Access Protocol [LDAPv3] schema elements to represent the core data structures identified in the Universal Description, Discovery, and Integration version 3 [UDDIv3] information model. This includes a businessEntity, a businessService, a bindingTemplate, a tModel, a publisherAssertion, and a Subscription. Portions of [UDDIv3] are repeated here for clarity.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
All schema definitions are provided using [RFC2252] descriptions, and are line-wrapped for readability only.
The information that makes up a registration in a UDDI registry consists of these data structure types. This division by information type provides simple partitions to assist in the rapid location and understanding of the different information that makes up a registration.
The individual instance data managed by a UDDI registry is sensitive to the parent/child relationships found in the schema. A businessEntity object contains one or more unique businessService objects. Similarly, individual businessService objects contain specific instances of bindingTemplate, which in turn contains information that includes pointers to specific instances of tModel objects.
It is important to note that no single instance of a core schema type is ever "contained" by more than one parent instance. This means that only one specific businessEntity object (identified by its unique key value) will ever contain or be used to express information about a specific instance of a businessService object (also identified by its own unique key value).
The businessEntity object represents all known information about a business or entity that publishes descriptive information about the entity as well as the services that it offers. The businessEntity is the top-level container that accommodates holding descriptive
Bergeson, et al. Informational [Page 2]
RFC 4403 LDAP Schema for UDDIv3 February 2006
information about a business or entity. Service descriptions and technical information are expressed within a businessEntity by a containment relationship.
A businessEntity is represented in the directory by the attributes uddiBusinessKey, uddiAuthorizedName, uddiOperator, uddiDiscoveryURLs, uddiName, uddiDescription, uddiIdentifierBag, uddiCategoryBag, and uddiv3DigitalSignature, along with corresponding v3 keys viz. uddiv3BusinessKey, as defined in Section 4. A businessEntity may contain zero or more instances of uddiContact and uddiBusinessService.
A mandatory attribute, uddiBusinessKey, contains the unique identifier for a given instance of a businessEntity.
businessEntity's definition is given in Section 5.
The businessService instances represent a logical business service. Each businessService object is the logical child of a single businessEntity object. Each businessService element contains descriptive information in business terms outlining the type of technical services found within each businessService instance.
In some cases, businesses would like to share or reuse services, e.g., when a large enterprise publishes separate businessEntity structures. This can be established by using the businessService instance as a projection to an already published businessService.
A businessService is represented in the directory by the attributes uddiBusinessKey, uddiServiceKey, uddiName, uddiDescription, uddiCategoryBag, uddiIsProjection, and uddiv3DigitalSignature, along with corresponding v3 keys viz. uddiv3BusinessKey, and uddiv3ServiceKey, as defined in Section 4. A businessService may contain zero or more instances of uddiBindingTemplate.
The mandatory attribute, uddiServiceKey, contains the unique identifier for a given instance of a businessService.
businessService's definition is given in Section 5.
Technical descriptions of Web services are accommodated via individual contained instances of bindingTemplate objects. These instances provide support for determining a technical entry point or optionally support remotely hosted services, as well as a lightweight facility for describing unique technical characteristics of a given implementation. Support for technology and application specific parameters and settings files are also supported.
Since UDDI's main purpose is to enable description and discovery of Web service information, it is the bindingTemplate that provides the most interesting technical data. With UDDIv3, bindingTemplates also can have categorization information.
Each bindingTemplate instance has a single logical businessService parent, which in turn has a single logical businessEntity parent.
A bindingTemplate is represented in the directory by the attributes uddiBindingKey, uddiServiceKey, uddiDescription, uddiAccessPoint, uddiHostingRedirector, uddiCategoryBag, and uddiv3DigitalSignature, along with corresponding v3 keys viz. uddiv3ServiceKey and uddiv3BindingKey, as defined in Section 4. A bindingTemplate may contain zero or more instances of uddiTModelInstanceDetails.
The mandatory attribute, uddiBindingKey, contains the unique identifier for a given instance of a bindingTemplate.
BindingTemplate's definition is given in Section 5.
The tModel object takes the form of keyed metadata (data about data). In a general sense, the purpose of a tModel within the UDDI registry is to provide a reference system based on abstraction. Thus, the kind of data that a tModel represents is pretty nebulous. In other words, a tModel registration can define just about anything, but in the current revision, two conventions have been applied for using tModels: as sources for determining compatibility and as keyed namespace references.
The information that makes up a tModel is quite simple. There are a key, a name, an optional description, and a Uniform Resource Locator [URL] that points somewhere--presumably somewhere where the curious can go to find out more about the actual concept represented by the metadata in the tModel itself.
A tModel is represented in the directory by the attributes uddiTModelKey, uddiAuthorizedName, uddiOperator, uddiName, uddiDescription, uddiOverviewDescription, uddiOverviewURL, uddiIdentifierBag, uddiCategoryBag, uddiIsHidden, and uddiv3DigitalSignature, along with the corresponding v3 key viz. uddiv3tModelKey, as defined in Section 4. A tModel may also contain a uddiHidden to logically delete a tModel.
A mandatory attribute, uddiTModelKey, contains the unique identifier for a given instance of a tModel.
Many businesses, such as large enterprises or marketplaces, are not effectively represented by a single businessEntity, since their description and discovery are likely to be diverse. As a consequence, several businessEntity instances can be published, representing individual subsidiaries of a large enterprise or individual participants of a marketplace. Nevertheless, they still represent a more or less coupled community and would like to make some of their relationships visible in their UDDI registrations.
With UDDIv3, the operational information associated with the core UDDI data structures is maintained in a separate OperationalInfo structure, so that the digital signature specified by the publisher remains valid.
The operationalInfo structure is used to convey the operational information for the UDDIv3 core data structures, that is, the businessEntity, businessService, bindingTemplate, and tModel
Bergeson, et al. Informational [Page 5]
RFC 4403 LDAP Schema for UDDIv3 February 2006
structures. UDDIv3 OperationalInfo consists of 5 elements: created, Modified, modifiedIncludingChildren, nodeId, and authorizedName.
Depending on the specific UDDIv3 core data structure, the operationalInformation is represented in the directory as a combination of implicit LDAP Standard Operational attributes: createTimestamp and modifyTimestamp, and the following explicit attributes: uddiAuthorizedName, uddiv3EntityCreationTime, uddiv3EntityModificationTime, and uddiv3NodeId.
This is used in uddiBusinessEntity and uddiBusinessService.
The uddiBusinessKey is the unique identifier for a given instance of a uddiBusinessEntity. The attribute is optional for businessService instances contained within a fully expressed parent that already contains a businessKey value.
If the businessService instance is rendered into the Extensible Markup Language [XML] and has no containing parent that has within its data a businessKey, the value of the businessKey that is the parent of the businessService is required to be provided. This behavior supports the ability to browse through the parent-child relationships given any of the core elements as a starting point. The businessKey may differ from the publishing businessEntity's businessKey to allow service projections.
The uddiAuthorizedName is the recorded name of the individual who published the uddiBusinessEntity or uddiTModel data. This data is generated by the controlling operator and should not be supplied within save_business operations.
With UDDIv3, this attribute is part of the "operationalInformation"
The uddiOperator is the certified name of the UDDI registry site operator that manages the master copy of the uddiBusinessEntity or uddiTModel. The controlling operator records this data at the time data is saved. This data is generated and should not be supplied within save_business or save_tModel operations.
With UDDIv3, this field is no longer used -- it is replaced by the nodeId (uddiv3NodeId) attribute that is part of the "operationalInformation" metadata.
( 126.96.36.199.188.8.131.52 NAME 'uddiOperator' DESC 'registry site operator of businessEntitys master copy' EQUALITY caseIgnoreMatch SYNTAX 184.108.40.206.4.1.14220.127.116.11.15 SINGLE-VALUE )
This is used in uddiBusinessEntity, uddiBusinessService, and uddiTModel.
These are the human-readable names recorded for the uddiBusinessEntity, uddiBusinessService, or uddiTModel, adorned with a unique xml:lang value to signify the language that they are expressed in. Name search is provided via find_business, find_service, or find_tModel calls.
The publishing of several names, e.g., for romanization purposes, is supported. In order to signify the language that the names are expressed in, they carry unique xml:lang values. Not more than one name element may omit specifying its language. Names passed in this way will be assigned the default language code of the registering party. This default language code is established at the time that publishing credentials are established with an individual Operator
Bergeson, et al. Informational [Page 7]
RFC 4403 LDAP Schema for UDDIv3 February 2006
Site. If no default language is provisioned at the time a publisher signs up, the operator can adopt an appropriate default language code.
With UDDIv3, multiple values with the same language code are permitted.
The uddiDescription is an optional repeating element of one or more descriptions. One description is allowed per national language code supplied. With UDDIv3, there is no restriction on the number of descriptions or on what xml:lang value that they may have.
This is a list of Uniform Resource Locators (URLs) that point to alternate, file-based service discovery mechanisms. Each recorded uddiBusinessEntity structure is automatically assigned a URL that returns the individual uddiBusinessEntity structure. A URL search is provided via find_business call.
The uddiDiscoveryURLs attribute is used to hold pointers to URL- addressable discovery documents. The expected retrieval mechanism for URLs referenced in the data within this structure is via the Hypertext Transfer Protocol [HTTP] HTTP-GET operation. The expected return document is not defined. Rather, a framework for establishing conventions is provided, and two such conventions are defined within
Bergeson, et al. Informational [Page 8]
RFC 4403 LDAP Schema for UDDIv3 February 2006
UDDI behaviors. It is hoped that other conventions come about and use this structure to accommodate alternate means of discovery. With UDDIv3, a new convention is defined with useType as "homepage". Further, a UDDIv3 server need not generate/add a discoveryURL itself, since this can invalidate the digital signature of signed the Business Entity saved by publishers.
( 18.104.22.168.22.214.171.124 NAME 'uddiDiscoveryURLs' DESC 'URL to retrieve a businessEntity instance' EQUALITY caseIgnoreMatch SYNTAX 126.96.36.199.4.1.14188.8.131.52.15 )
The useType value precedes the URL value, with the "#" character used as the separator.
The uddiUseType is used to describe the type of contact or address in freeform text. Suggested examples for contact include "technical questions", "technical contact", "establish account", "sales contact", etc. Suggested examples for address include "headquarters", "sales office", "billing department", etc.
( 184.108.40.206.220.127.116.11 NAME 'uddiUseType' DESC 'name of convention the referenced document follows' EQUALITY caseIgnoreMatch SYNTAX 18.104.22.168.4.1.1422.214.171.124.15 SINGLE-VALUE )
This is used to hold telephone numbers for the contact. This element can be adorned with an optional uddiUseType attribute for descriptive purposes. If more than one phone element is saved, uddiUseType attributes are required on each.
( 126.96.36.199.188.8.131.52 NAME 'uddiPhone' DESC 'telephone number for contact' EQUALITY caseIgnoreMatch SYNTAX 184.108.40.206.4.1.14220.127.116.11.15 )
The useType precedes the telephone number by a separating '#' (e.g., "Work Number#123 456-7890") .
This is used to hold email addresses for the contact. This element can be adorned with an optional uddiUseType attribute for descriptive purposes. If more than one email element is saved, uddiUseType attributes are required on each.
( 18.104.22.168.22.214.171.124 NAME 'uddiEMail' DESC 'e-mail address for contact' EQUALITY caseIgnoreMatch SYNTAX 126.96.36.199.4.1.14188.8.131.52.15 )
The useType precedes the email address by a separating '#' (e.g., "President of the United States #firstname.lastname@example.org").
The uddiSortCode is used to drive the behavior of external display mechanisms that sort addresses. The suggested values for uddiSortCode include numeric ordering values (e.g., 1, 2, 3), alphabetic character ordering values (e.g., a, b, c), or the first n positions of relevant data within the address.
( 184.108.40.206.220.127.116.11 NAME 'uddiSortCode' DESC 'specifies an external display mechanism' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 18.104.22.168.4.1.1422.214.171.124.15 SINGLE-VALUE )
Bergeson, et al. Informational [Page 10]
RFC 4403 LDAP Schema for UDDIv3 February 2006
With UDDIv3, the sortCode attribute is deprecated because of the guarantee of preserving the document Order.
The uddiTModelKey is the unique identifier for a given instance of an uddiTModel.
It is also used in a KeyedReference and in Address structures. When used with a keyed reference, this is the unique key to identify a value set and implies that the keyName keyValue pair in a uddiIdentifier or uddiCategory Bag are to be interpreted by the value set referenced by the tModelKey.
When used with Addressline elements, it implies that the keyName keyValue pair given by subsequent uddiAddressLine elements are to be interpreted by the address structure associated with the tModel that is referenced.
The uddiAddressLine contains the actual address in freeform text. If the address element contains a uddiTModelKey, these uddiAddressLine elements are to be adorned, each with an optional keyName keyValue attribute pair. Together with the uddiTModelKey, keyName and keyValue qualify the uddiAddressLine in order to describe its meaning.
The uddiAddressLine elements contain string data with a line length limit of 80 character positions. Each uddiAddressLine element can be adorned with two optional descriptive attributes, keyName and keyValue. Both attributes must be present in each address line if a uddiTModelKey is assigned to the address structure. By doing this, the otherwise arbitrary use of address lines becomes structured. Together with the address' uddiTModelKey, keyName and keyValue virtually build a uddiKeyedReference that represents an address line qualifier, given by the referenced uddiTModel.
When no uddiTModelKey is provided for the address structure, the keyName and keyValue attributes can be used without restrictions, for example, to provide descriptive information for each uddiAddressLine
Bergeson, et al. Informational [Page 11]
RFC 4403 LDAP Schema for UDDIv3 February 2006
by using the keyName attribute. Since both the keyName and the keyValue attributes are optional, address line order is significant and will always be returned by the UDDI-compliant registry in the order originally provided during a call to save_business.
The uddiIdentifierBag element allows uddiBusinessEntity or uddiTModel structures to include information about common forms of identification such as D-U-N-S_ numbers, tax identifiers, etc. This data can be used to signify the identity of the uddiBusinessEntity or can be used to signify the identity of the publishing party. Including data of this sort is optional, but when used greatly enhances the search behaviors exposed via the find_xx messages defined in the UDDI Version 2.0 API Specification [UDDIapi]. For a full description of the structures involved in establishing an identity, see UDDI Version 2.0 Data Structure Specification - Appendix A: Using Identifiers [UDDIdsr].
The uddiCategoryBag element allows uddiBusinessEntity, uddiBusinessService, and uddiTModel structures to be categorized according to any of several available taxonomy-based classification schemes. Operator Sites automatically provide validated categorization support for three taxonomies that cover industry codes (via NAICS), product and service classifications (via UNSPC), and geography (via ISO 3166). Including data of this sort is optional,
Bergeson, et al. Informational [Page 12]
RFC 4403 LDAP Schema for UDDIv3 February 2006
but when used, it greatly enhances the search behaviors exposed by the find_xx messages defined in the UDDI Version 2.0 API Specification [UDDIapi]. For a full description of structures involved in establishing categorization information, see UDDI Version 2.03 Data Structure Specification--Appendix B: Using Categorization [UDDIdsr].
The tModel, keyName, and keyValue of this attribute are separated by "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the only required portion of the attribute. With UDDIv3, the tModelKey also becomes a mandatory part of the attribute.
Also, UDDIv3 defines KeyedReferenceGroups for CategoryBags. A keyedReferenceGroup contains a tModelKey and a simple list of KeyedReference structures. The uddiKeyedReference attribute will support KeyedReferenceGroups by suffixing the tModelKey for KeyedReferenceGroup to each of the keyedReference values associated with the group.
For example, to represent a keyedReference group containing a list of 2 keyed references, the attribute will hold the following 2 strings as its values:
This is the unique key for a given uddiBusinessService. When saving a new uddiBusinessService structure, pass an empty uddiServiceKey value. This signifies that a UUID value is to be generated. To update an existing uddiBusinessService structure, pass the UUID value that corresponds to the existing service. If a uddiServiceKey is received via an inquiry operation, the key values may not be blank. When saving a new or updated service projection, pass the uddiServiceKey of the referenced uddiBusinessService structure.
This attribute is optional when the uddiBindingTemplate data is contained within a fully expressed parent that already contains a uddiServiceKey value. If the uddiBindingTemplate data is rendered into XML and has no containing parent that has within its data a uddiServiceKey, the value of the uddiServiceKey that is the ultimate containing parent of the uddiBindingTemplate is required to be provided. This behavior supports the ability to browse through the parent-child relationships given any of the core elements as a starting point.
This is the unique key for a given uddiBindingTemplate. When saving a new uddiBindingTemplate structure, pass an empty uddiBindingKey value. This signifies that a UUID value is to be generated. To update an existing uddiBindingTemplate, pass the UUID value that corresponds to the existing uddiBindingTemplate instance. If a uddiBindingKey is received via an inquiry operation, the key values may not be blank.
The uddiAccessPoint element is an attribute-qualified pointer to a service entry point. The notion of service at the metadata level seen here is fairly abstract and many types of entry points are accommodated. A single attribute is provided named URLType.
Required attribute-qualified element8: This element is a text field that is used to convey the entry point address suitable for calling a particular Web service. This may be a URL, an electronic mail address, or even a telephone number. No assumptions about the type of data in this field can be made without first understanding the technical requirements associated with the Web service.
( 126.96.36.199.188.8.131.52 NAME 'uddiAccessPoint' DESC 'entry point address to call a web service' EQUALITY caseIgnoreMatch SYNTAX 184.108.40.206.4.1.14220.127.116.11.15 SINGLE-VALUE )
The URLType value precedes the accessPoint value by a separating '#'.
With UDDIv3, the "URLType" attribute is replaced by a "UseType" attribute. Using this UseType attribute, the accessPoint attribute can model a hostingRedirector or support indirection to indicate that the accesspoint is specified within a remotely hosted WSDL document.
For a UDDIv3 registry that needs to support UDDIv2 clients, the attribute must allow the representation of URLType and UseType values independently.
The UDDIv3 spec specifies the following logic for mapping values between URLType and UseType: If an entity is saved with the v3 namespace and a v2 inquiry is made, the URLType will be returned as "other". In the case when a v3 inquiry is made on an entity published with the v2 namespace, the v3 useType attribute will be returned as "endPoint".
For implementations that need to explicitly model both forms, the recommended format is as follows: v2URLType#v3UseType#Address
The uddiHostingRedirector element is used to designate that a uddiBindingTemplate entry is a pointer to a different uddiBindingTemplate entry. The value in providing this facility is seen when a business or entity wants to expose a service description
Bergeson, et al. Informational [Page 15]
RFC 4403 LDAP Schema for UDDIv3 February 2006
(e.g., advertise that it has a service available that suits a specific purpose) that is actually a service described in a separate uddiBindingTemplate record. This might occur when a service is remotely hosted (hence the name of this element), or when many service descriptions could benefit from a single service description.
The uddiHostingRedirector element has a single attribute and no element content. The attribute is a uddiBindingKey value that is suitable within the same UDDI registry instance for querying and obtaining the uddiBindingDetail data that is to be used.
More on the uddiHostingRedirector can be found in the appendices for the UDDI Version 2.0 API Specification [UDDIapi].
Required element if uddiAccessPoint is not provided: This element is adorned with a uddiBindingKey attribute, giving the redirected reference to a different uddiBindingTemplate. If you query a uddiBindingTemplate and find a uddiHostingRedirector value, you should retrieve that uddiBindingTemplate and use it in place of the one containing the uddiHostingRedirector data.
( 18.104.22.168.22.214.171.124 NAME 'uddiHostingRedirector' DESC 'designates a pointer to another bindingTemplate' EQUALITY caseIgnoreMatch SYNTAX 126.96.36.199.4.1.14188.8.131.52.15 SINGLE-VALUE )
With UDDIv3, the hostingRedirector is a deprecated element, since its functionality is now covered by the accessPoint. For backward- compatibility, it can still be used, but it is not recommended.
The uddiInstanceParms is an optional element of the uddiInstance. It is used to contain settings parameters or a URL reference to a file that contains settings or parameters required to use a specific facet of a uddiBindingTemplate description. If used to house the parameters themselves, the suggested content is a namespace-qualified XML string using a namespace outside of the UDDI schema. If used to house a URL pointer to a file, the suggested format is a URL that is suitable for retrieving the settings or parameters via HTTP-GET.
( 184.108.40.206.220.127.116.11 NAME 'uddiInstanceParms' DESC 'URL reference to required settings' EQUALITY caseIgnoreMatch SYNTAX 18.104.22.168.4.1.1422.214.171.124.15 SINGLE-VALUE )
This is an optional element. This string data element is to be used to hold a URL reference to a long form of an overview document that covers the way a particular uddiTModel specific reference is used as a component of an overall Web service description. The recommended format for the overviewURL is a URI that is suitable for retrieving the actual overview document with an HTTP-GET operation, for example, via a Web browser.
( 126.96.36.199.188.8.131.52 NAME 'uddiOverviewURL' DESC 'URL reference to overview document' EQUALITY caseIgnoreMatch SYNTAX 184.108.40.206.4.1.14220.127.116.11.15 SINGLE-VALUE )
With UDDIv3, uddiOverviewURL becomes multi-valued to allow the representation of multiple OverviewDocs within a single InstanceDetail element.
Modeling multiple OverviewDocs within an InstanceDetail element:
In UDDIv3, the InstanceDetails element in TmodelInstanceInfo can have multiple OverviewDoc's. In UDDIv2, we could have only 1 OverviewDoc. To retain the grouping between a set of overviewDescriptions and overviewURL, we can make both OverviewDoc and OverviewURL multi- valued, and have a "group ID" Prefix to each value (to group OverviewDescriptions and OverviewURL).
This implies that OverviewDoc1 has 3 overview descriptions and an overviewURL. OverviewDoc2 has only an overviewURL. OverviewDoc3 has only 2 overviewDescriptions. OverviewDoc4 also has 1 overview description and an overviewURL.
This is used to model the xml:lang value for the Address structure in UDDIv3.
( 18.104.22.168.22.214.171.124 NAME 'uddiLang' DESC 'xml:lang value in v3 Address structure' EQUALITY caseIgnoreMatch SYNTAX 126.96.36.199.4.1.14188.8.131.52.15 SINGLE-VALUE )
The following are attribute definitions to model new elements/fields in UDDIv3 information model. These attribute definitions have the "uddiv3" prefix to indicate that these attributes represent UDDI information model elements unique to UDDIv3.
This is the unique UDDIv3 identifier for a given instance of uddiBusinessEntity. It is used in uddiBusinessEntity and uddiBusinessService.
A uddiBusinessEntity will include the uddiBusinessKey (the v2 form) for unique identification by UDDIv2 clients. The uddiBusinessKey (36-char) will also be the LDAP naming attribute for the uddiBusinessEntity. The uddiBusinessEntity entry MAY also include the uddiv3BusinessKey, the explicit v3 form key, which can be 255 characters long.
This is the unique UDDIv3 identifier for a given instance of uddiBusinessService. It is used in uddiBusinessService and uddiBindingTemplate.
A uddiBusinessService will include the uddiServiceKey (the v2 form) for unique identification by UDDIv2 clients. The uddiServiceKey (36-char) will also be the LDAP naming attribute for the uddiBusinessService entry. The uddiBusinessService entry MAY also include the uddiv3ServiceKey, the explicit v3 form key, which can be 255 characters long.
This is the unique UDDIv3 identifier for a given instance of a uddiTModel.
A uddiTModel will include the uddiTModelKey (the v2 form) for unique identification by UDDIv2 clients. The uddiTModelKey (41-char) will also be the LDAP naming attribute for the uddiTModel entry. The uddiTModel entry MAY also include the uddiv3TModelKey, the explicit v3 form key, which can be 255 characters long.
The tModelKey is also used in a KeyedReference and in Address structures. In all instances where a tModelKey is used as a reference to tModel, the v3 form of the tModel key (viz. uddiv3TModelKey) will be the form used, since using the v2 form key will require translating it to the v3 key by the UDDI Server, which may invalidate the digital signature of the entity.
This uddiv3DigitalSignature attribute holds the digital signature for the corresponding UDDI entity.
( 184.108.40.206.220.127.116.11 NAME 'uddiv3DigitalSignature' DESC 'UDDIv3 entity digital signature' EQUALITY caseExactMatch SYNTAX 18.104.22.168.4.1.1422.214.171.124.15 )
A Signature element SHOULD be generated according to the required steps of "Core Generation" in XML-Signature Syntax and Processing. The signature should be calculated on the top-level element that will be stored by the registry as a result of the Publication API call. This element, referred to as the data object in the XML-Signature and Syntax specification, is the businessEntity element for save_business API calls, the businessService element for save_service API calls, the bindingTemplate for save_binding API calls, the tModel for save_tModel API calls, and the publisherAssertion for set_publisherAssertions and add_publisherAssertion API calls.
The signature should be generated on the elements before they are added to the body of an API call. Also, according to the signature generation, all children of the element being signed are included in the generation of the signature unless first excluded by application of a transform. Due to the containment of service projections as businessService elements within a businessEntity element, this also means that changes to the projected service will render a signature of the businessEntity containing the projection invalid, unless a businessService element representing a service projection is excluded using a transform.
Due to the location of the sequence of Signature elements within an element that is to be signed, the signature is "enveloped". As a result of the enveloping of the signature, it is necessary to apply at least one transformation on the signed entity to exclude the signature or signature(s). The transformation selected by a publisher or the XML-Signature tool is specified in a Transform element inside the Signature element.
This attribute is used to maintain the last modification time for a UDDI entity. It is needed in the context of maintaining the modifiedIncludingChildren element. When a child entity (e.g., uddiBindingTemplate) is updated, the parent entity (e.g., uddiBusinessService) LDAP timestamp also gets updated. The uddiv3EntityModificationTime attribute saves the last modification time of the parent entity (uddiBusinessService in this case).
( 126.96.36.199.188.8.131.52 NAME 'uddiv3EntityModificationTime' DESC 'UDDIv3 Last Modified Time for Entity' EQUALITY generalizedTimeMatch SYNTAX 184.108.40.206.4.1.14220.127.116.11.24 SINGLE-VALUE )
The following attribute definitions define attributes related to the modeling of UDDIv3 subscription-related entities in the LDAP directory.
Subscription provides clients, known as subscribers, with the ability to register their interest in receiving information concerning changes made in a UDDI registry. These changes can be scoped based on preferences provided with the request. The uddiv3Subscription object class is used to model registered UDDIv3 subscriptions.
This attribute contains the UDDIv3 Subscription Filter, specified as part of the save_subscription API, i.e., the Inquiry API specified as filtering criteria with a registered subscription. The filtering criteria limits the scope of a subscription to a subset of registry records. The get_xx and find_xx APIs are all valid choices for use as a subscriptionFilter. Only one of these can be chosen for each subscription.
This attribute contains the maximum number of entities to be returned as part of a subscription notification. It is an integer and specifies the maximum number of entities in a notification returned to a subscription listener.
This attribute is a Boolean flag for Brief Response associated with a subscription entity. It controls the level of detail returned to a subscription listener. The default is "false" when omitted. When set to "true", it indicates that the subscription results are to be returned to the subscriber in the form of a keyBag, listing all of the entities that matched the subscriptionFilter.
This is the unique UDDIv3 identifier for a given instance of a core UDDI data structure that is to be logged as an Obituary entry uddiv3EntityObituary. When a core UDDIv3 Entity is deleted and there is an active subscription registered against this UDDI Entity, an Obituary entry is created, in which the v3 key of the deleted entry is logged as part of the uddiv3EntityKey attribute.
This attribute is used to log the original Creation Time for a UDDI Entity that is deleted in the uddiv3EntityObituary entry.
It is also used in uddiBusinessService and uddiBindingTemplate. A Move BS operation needs to delete and recreate BT sub-tree due to lack of support for moving a sub-tree in many LDAPv3 servers. This attribute is used to save the original creation time of the BT during a Move BS.
This structural object class represents a publisherAssertion.
( 18.104.22.168.22.214.171.124 NAME 'uddiPublisherAssertion' SUP top STRUCTURAL MUST ( uddiFromKey $ uddiToKey $ uddiKeyedReference $ uddiUUID ) MAY ( uddiv3DigitalSignature $ uddiv3NodeId) )
The following are object class definitions to model new data structures needed to implement the UDDIv3 information model. These object class definitions have the "uddiv3" prefix to indicate that these attributes represent UDDI information model elements unique to UDDIv3.
Storing UDDI data into the directory enables the data to be examined and used outside the environment in which it was originally created. The directory entry containing the UDDI data could be read and modified within the constraints imposed by the access control mechanisms of the directory. With UDDIv3 [UDDIv3], publishers can digitally sign UDDI Entities enabling registry clients to validate the integrity of entries read from the UDDIv3 registry by verifying the digital signature.
Each UDDI Entity has a uddiAuthorizedName attribute that contains an LDAP DN identifying the publisher/owner. The referenced LDAP object can provide the public key of the signer to a registry client for integrity validation of the UDDI Entity.
Other general LDAP [LDAPv3] security considerations apply. Some of the UDDI attributes such as AccessPoints for services may contain sensitive information. Use of strong authentication mechanisms and data integrity/confidentiality services [RFC2829][RFC2830] is advised.
The IANA has registered an LDAP Object Identifier for use in this technical specification, according to the following template:
Subject: Request for LDAP OID Registration Person & email address to contact for further information: Bruce Bergeson (email@example.com) Specification: RFC 4403 Author/Change Controller: IESG Comments: The assigned OID (10) will be used as a base for identifying a number of UDDI schema elements defined in this document.
The IANA has registered the LDAP Descriptors used in this technical specification as detailed in the following template:
Subject: Request for LDAP Descriptor Registration Update Descriptor (short name): see table Object Identifier: see table Person & email address to contact for further information: Bruce Bergeson (firstname.lastname@example.org) Usage: see table Specification: RFC 4403 Author/Change Controller: IESG Table:
The following descriptors have been added:
NAME Type OID -------------- ---- ------------ uddiBusinessKey A 126.96.36.199.188.8.131.52 uddiAuthorizedName A 184.108.40.206.220.127.116.11 uddiOperator A 18.104.22.168.22.214.171.124 uddiName A 126.96.36.199.188.8.131.52 uddiDescription A 184.108.40.206.220.127.116.11 uddiDiscoveryURLs A 18.104.22.168.22.214.171.124 uddiUseType A 126.96.36.199.188.8.131.52 uddiPersonName A 184.108.40.206.220.127.116.11 uddiPhone A 18.104.22.168.22.214.171.124 uddiEMail A 126.96.36.199.188.8.131.52 uddiSortCode A 184.108.40.206.220.127.116.11 uddiTModelKey A 18.104.22.168.22.214.171.124 uddiAddressLine A 126.96.36.199.188.8.131.52
Bergeson, et al. Informational [Page 38]
RFC 4403 LDAP Schema for UDDIv3 February 2006
NAME Type OID -------------- ---- ------------ uddiIdentifierBag A 184.108.40.206.220.127.116.11 uddiCategoryBag A 18.104.22.168.22.214.171.124 uddiKeyedReference A 126.96.36.199.188.8.131.52 uddiServiceKey A 184.108.40.206.220.127.116.11 uddiBindingKey A 18.104.22.168.22.214.171.124 uddiAccessPoint A 126.96.36.199.188.8.131.52 uddiHostingRedirector A 184.108.40.206.220.127.116.11 uddiInstanceDescription A 18.104.22.168.22.214.171.124 uddiInstanceParms A 126.96.36.199.188.8.131.52 uddiOverviewDescription A 184.108.40.206.220.127.116.11 uddiOverviewURL A 18.104.22.168.22.214.171.124 uddiFromKey A 126.96.36.199.188.8.131.52 uddiToKey A 184.108.40.206.220.127.116.11 uddiUUID A 18.104.22.168.22.214.171.124 uddiIsHidden A 126.96.36.199.188.8.131.52 uddiIsProjection A 184.108.40.206.220.127.116.11 uddiLang A 18.104.22.168.22.214.171.124 uddiv3BusinessKey A 126.96.36.199.188.8.131.52 uddiv3ServiceKey A 184.108.40.206.220.127.116.11 uddiv3BindingKey A 18.104.22.168.22.214.171.124 uddiv3TmodelKey A 126.96.36.199.188.8.131.52 uddiv3DigitalSignature A 184.108.40.206.220.127.116.11 uddiv3NodeId A 18.104.22.168.22.214.171.124 uddiv3EntityModificationTime A 126.96.36.199.188.8.131.52 uddiv3SubscriptionKey A 184.108.40.206.220.127.116.11 uddiv3SubscriptionFilter A 18.104.22.168.22.214.171.124 uddiv3NotificationInterval A 126.96.36.199.188.8.131.52 uddiv3MaxEntities A 184.108.40.206.220.127.116.11 uddiv3ExpiresAfter A 18.104.22.168.22.214.171.124 uddiv3BriefResponse A 126.96.36.199.188.8.131.52 uddiv3EntityKey A 184.108.40.206.220.127.116.11 uddiv3EntityCreationTime A 18.104.22.168.22.214.171.124 uddiv3EntityDeletionTime A 126.96.36.199.188.8.131.52 uddiBusinessEntity O 184.108.40.206.220.127.116.11 uddiContact O 18.104.22.168.22.214.171.124 uddiAddress O 126.96.36.199.188.8.131.52 uddiBusinessService O 184.108.40.206.220.127.116.11 uddiBindingTemplate O 18.104.22.168.22.214.171.124 uddiTModelInstanceInfo O 126.96.36.199.188.8.131.52 uddiTModel O 184.108.40.206.220.127.116.11 uddiPublisherAssertion O 18.104.22.168.22.214.171.124 uddiv3Subscription O 126.96.36.199.188.8.131.52 uddiv3EntityObituary O 184.108.40.206.220.127.116.11 uddiBusinessEntityNameForm N 18.104.22.168.22.214.171.124 uddiContactNameForm N 126.96.36.199.188.8.131.52 uddiAddressNameForm N 184.108.40.206.220.127.116.11
Bergeson, et al. Informational [Page 39]
RFC 4403 LDAP Schema for UDDIv3 February 2006
NAME Type OID -------------- ---- ------------ uddiBusinessServiceNameForm N 18.104.22.168.22.214.171.124 uddiBindingTemplateNameForm N 126.96.36.199.188.8.131.52 uddiTModelInstanceInfoNameForm N 184.108.40.206.220.127.116.11 uddiTModelNameForm N 18.104.22.168.22.214.171.124 uddiPublisherAssertionNameForm N 126.96.36.199.188.8.131.52 uddiv3SubscriptionNameForm N 184.108.40.206.220.127.116.11 uddiv3EntityObituaryNameForm N 18.104.22.168.22.214.171.124
where Type A is Attribute, Type O is ObjectClass, Type N is NameForm
These assignments have been recorded in the following registry:
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).