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 Notice Copyright (C) The Internet Society (2006).
AbstractThis 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. 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
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. RFC2119]. All schema definitions are provided using [RFC2252] descriptions, and are line-wrapped for readability only.
information about a business or entity. Service descriptions and technical information are expressed within a businessEntity by a containment relationship. 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. 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.
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. 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.
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. tModel's definition is given in Section 5. Section 5. A mandatory attribute, uddiUUID, contains the unique identifier for a given instance of a publisherAssertion. publisherAssertion's definition is given in Section 5.
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. 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. ( 188.8.131.52.184.108.40.206 NAME 'uddiBusinessKey' DESC 'businessEntity unique identifier' EQUALITY caseIgnoreMatch SYNTAX 220.127.116.11.4.1.1418.104.22.168.15 SINGLE-VALUE )
metadata associated with core data structures. ( 22.214.171.124.126.96.36.199 NAME 'uddiAuthorizedName' DESC 'businessEntity publisher name' EQUALITY distinguishedNameMatch SYNTAX 188.8.131.52.4.1.14184.108.40.206.12 SINGLE-VALUE )
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. ( 220.127.116.11.18.104.22.168 NAME 'uddiName' DESC 'human readable name' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 22.214.171.124.4.1.14126.96.36.199.15 ) The xml:lang value precedes the name value, with the "#" character used as the separator. 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
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. ( 188.8.131.52.184.108.40.206 NAME 'uddiDiscoveryURLs' DESC 'URL to retrieve a businessEntity instance' EQUALITY caseIgnoreMatch SYNTAX 220.127.116.11.4.1.1418.104.22.168.15 ) The useType value precedes the URL value, with the "#" character used as the separator.
With UDDIv3, the sortCode attribute is deprecated because of the guarantee of preserving the document Order.
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. ( 22.214.171.124.126.96.36.199 NAME 'uddiAddressLine' DESC 'address' EQUALITY caseIgnoreMatch SYNTAX 188.8.131.52.4.1.14184.108.40.206.15 ) The keyName, keyValue, and addressData of this attribute are separated by "#" (e.g., "#"<keyName>"#"<keyValue>"#"<addressData>). The addressData is the only required portion of the attribute. 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]. ( 220.127.116.11.18.104.22.168 NAME 'uddiIdentifierBag' DESC 'identification information' EQUALITY caseIgnoreMatch SYNTAX 22.214.171.124.4.1.14126.96.36.199.15 ) 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.
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]. ( 188.8.131.52.184.108.40.206 NAME 'uddiCategoryBag' DESC 'categorization information' EQUALITY caseIgnoreMatch SYNTAX 220.127.116.11.4.1.1418.104.22.168.15 ) 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, uddiBindingTemplates also supports the uddiCategoryBag element and they can also be categorized according to any of several available taxonomy-based classification schemes.
(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. ( 22.214.171.124.126.96.36.199 NAME 'uddiHostingRedirector' DESC 'designates a pointer to another bindingTemplate' EQUALITY caseIgnoreMatch SYNTAX 188.8.131.52.4.1.14184.108.40.206.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.
uddiBindingTemplate entry. The uddiBindingTemplate entry MAY also include the uddiv3BindingKey, the explicit v3 form key, which can be 255 characters long. ( 220.127.116.11.18.104.22.168 NAME 'uddiv3BindingKey' DESC 'UDDIv3 BindingTemplate unique identifier' EQUALITY caseIgnoreMatch SYNTAX 22.214.171.124.4.1.14126.96.36.199.15 SINGLE-VALUE ) http://www.w3.org/TR/xmldsig-core/). ..businessEntity ..businessService ..bindingTemplate ..tModel ..publisherAssertion
This uddiv3DigitalSignature attribute holds the digital signature for the corresponding UDDI entity. ( 188.8.131.52.184.108.40.206 NAME 'uddiv3DigitalSignature' DESC 'UDDIv3 entity digital signature' EQUALITY caseExactMatch SYNTAX 220.127.116.11.4.1.1418.104.22.168.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.
Section 6. The OIDs for the structure rules in this document have been registered by the IANA.
Section 6. Note that rule identifiers defined here show the relationship between structure rules. Implementations may use different identifiers but must follow the same hierarchical model.
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. RFC 3383, "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)" [RFC3383].
NAME Type OID -------------- ---- ------------ uddiIdentifierBag A 22.214.171.124.126.96.36.199 uddiCategoryBag A 188.8.131.52.184.108.40.206 uddiKeyedReference A 220.127.116.11.18.104.22.168 uddiServiceKey A 22.214.171.124.126.96.36.199 uddiBindingKey A 188.8.131.52.184.108.40.206 uddiAccessPoint A 220.127.116.11.18.104.22.168 uddiHostingRedirector A 22.214.171.124.126.96.36.199 uddiInstanceDescription A 188.8.131.52.184.108.40.206 uddiInstanceParms A 220.127.116.11.18.104.22.168 uddiOverviewDescription A 22.214.171.124.126.96.36.199 uddiOverviewURL A 188.8.131.52.184.108.40.206 uddiFromKey A 220.127.116.11.18.104.22.168 uddiToKey A 22.214.171.124.126.96.36.199 uddiUUID A 188.8.131.52.184.108.40.206 uddiIsHidden A 220.127.116.11.18.104.22.168 uddiIsProjection A 22.214.171.124.126.96.36.199 uddiLang A 188.8.131.52.184.108.40.206 uddiv3BusinessKey A 220.127.116.11.18.104.22.168 uddiv3ServiceKey A 22.214.171.124.126.96.36.199 uddiv3BindingKey A 188.8.131.52.184.108.40.206 uddiv3TmodelKey A 220.127.116.11.18.104.22.168 uddiv3DigitalSignature A 22.214.171.124.126.96.36.199 uddiv3NodeId A 188.8.131.52.184.108.40.206 uddiv3EntityModificationTime A 220.127.116.11.18.104.22.168 uddiv3SubscriptionKey A 22.214.171.124.126.96.36.199 uddiv3SubscriptionFilter A 188.8.131.52.184.108.40.206 uddiv3NotificationInterval A 220.127.116.11.18.104.22.168 uddiv3MaxEntities A 22.214.171.124.126.96.36.199 uddiv3ExpiresAfter A 188.8.131.52.184.108.40.206 uddiv3BriefResponse A 220.127.116.11.18.104.22.168 uddiv3EntityKey A 22.214.171.124.126.96.36.199 uddiv3EntityCreationTime A 188.8.131.52.184.108.40.206 uddiv3EntityDeletionTime A 220.127.116.11.18.104.22.168 uddiBusinessEntity O 22.214.171.124.126.96.36.199 uddiContact O 188.8.131.52.184.108.40.206 uddiAddress O 220.127.116.11.18.104.22.168 uddiBusinessService O 22.214.171.124.126.96.36.199 uddiBindingTemplate O 188.8.131.52.184.108.40.206 uddiTModelInstanceInfo O 220.127.116.11.18.104.22.168 uddiTModel O 22.214.171.124.126.96.36.199 uddiPublisherAssertion O 188.8.131.52.184.108.40.206 uddiv3Subscription O 220.127.116.11.18.104.22.168 uddiv3EntityObituary O 22.214.171.124.126.96.36.199 uddiBusinessEntityNameForm N 188.8.131.52.184.108.40.206 uddiContactNameForm N 220.127.116.11.18.104.22.168 uddiAddressNameForm N 22.214.171.124.126.96.36.199
NAME Type OID -------------- ---- ------------ uddiBusinessServiceNameForm N 188.8.131.52.184.108.40.206 uddiBindingTemplateNameForm N 220.127.116.11.18.104.22.168 uddiTModelInstanceInfoNameForm N 22.214.171.124.126.96.36.199 uddiTModelNameForm N 188.8.131.52.184.108.40.206 uddiPublisherAssertionNameForm N 220.127.116.11.18.104.22.168 uddiv3SubscriptionNameForm N 22.214.171.124.126.96.36.199 uddiv3EntityObituaryNameForm N 188.8.131.52.184.108.40.206 where Type A is Attribute, Type O is ObjectClass, Type N is NameForm These assignments have been recorded in the following registry: http://www.iana.org/assignments/ldap-parameters [LDAPv3] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [UDDIdsr] UDDI.ORG, "UDDI version 2.03 Data Structure Reference," http://uddi.org/pubs/DataStructure-V2.03-Published- 20020719.htm [UDDIapi] "UDDI Version 2.04 API Specification", http://uddi.org/pubs/ProgrammersAPI-V2.04-Published- 20020719.htm [UDDIv3] UDDI Version 3.0, Published Specification, 19 July 2002 http://uddi.org/pubs/uddi-v3.00-published-20020719.htm [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000. [RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002. [XML] Extensible Markup Language (XML) 1.0 (Second Edition) W3C Recommendation 6 October 2000 http://www.w3.org/TR/REC-xml [URL] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
Full Copyright Statement Copyright (C) The Internet Society (2006). 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. Intellectual Property 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. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).