A mechanism for the identification of business partners in business documents based on XML (or other structured formats) and message headers using URN-based identifier types is required in many electronic business exchanges. This specification specifies a formal URN-based mechanism for referencing party types from the ISO 6523, ISO 9735 and ISO 20022 identification scheme catalogs using the oasis URN namespace. Sample applications include (but are not limited to): ebXML message headers; ebXML collaboration protocol profiles and agreements; UBL, UN/CEFACT and OAGIS XML business documents; the UN/CEFACT SBDH; and XBRL documents.

Status:

This document was last revised or approved by the OASIS ebXML Core (ebCore) TC on the above date. The level of approval is also listed above. Check the "Latest Version" or "Latest Approved Version" location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ebcore.

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 Technical Committee web page (http://www.oasis-open.org/committees/ebcore/ipr.php).

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/ebcore/.

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

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 section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

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

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 OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

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' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on 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 implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

Table of Contents

1 Introduction

1.1 Terminology

1.2 Normative References

1.3 Non-normative References

OASIS ebCore PartyId Type

2.1 URN Syntax for PartyId Type

2.2 ISO 6523

2.3 ISO 9735

2.4 ISO 20022

2.5 Unregistered

2.6 Compatibility URN ebxml-cppa:partyid-type

2.7 Party Identification

3 Sample Applications

3.1 ebXML Collaboration Protocol Profiles and Agreements (CPPA)

3.2 ebXML Messaging (ebMS)

3.3 Universal Business Language (UBL)

3.4 UN/CEFACT XML Schemas and OAGIS

3.5 UN/CEFACT Standard Business Document Header (SBDH)

3.6 Extensible Business Reporting Language (XBRL)

4 Conformance

Appendix A.Acknowledgments

Appendix B.Revision History

1 Introduction

Several schemes exist for naming identifier domains. For example, the GS1 organizations assign Global Location Numbers ([GLN]) to identify physical locations and legal entities to improve the efficiency of communication with the supply-chain. The GLN is the basis for the Global GS1 Electronic Party Information Registry [GEPIR]. Other well-known directories include D-U-N-S (Data Universal Numbering System from Dun & Bradstreet), national Chamber of Commerce registries, and financial industry identification schemes.

ISO 6523, ISO 9735 and ISO 20022 serve as "catalogs" of schemes for naming identifier domains; processes exist by which additional domains can be identified through the Registration Authorities (RA):

•.The British Standards Institute (BSI): ISO 6523
•.ISO/TC154-UN/CEFACT Joint Syntax Working Group (JSWG): ISO 9735
•.ISO 20022 RA: ISO 20022

These three identification schemes are not based on Universal Resource Names (URNs). A requirement in many electronic business communities is to have a mechanism for identification of business partners in business documents in XML or other structured formats, document headers and message headers using URNs. This specification specifies a formal mechanism for referencing party type identification schemes using a formal URN notation that leverages these three identification scheme catalogs. This allows these existing schemes to be reused using an alternative URN-based syntax, without duplication of Registration Authorities. The references to OASIS and to the ebCore Technical Committee just serve to support the formation of URN-based identifiers and do not establish OASIS or the ebCore TC themselves as PartyId Registration Authorities. This specification also provides a fourth formal URN prefix for unregistered (mutually agreed) party identification and a URN for backwards compatibility with a previous draft version of this specification developed in the former ebXML CPP/CPA TC, which is used in some business communities.

With the exception of the ISO 6523 scheme (which allows some other notations for compatibility) and the CPP/CPA backwards compatibility format, the general format of the proposed URN is:

urn:oasis:tc:ebcore:partyid-type:catalog-identifier:scheme-in-catalog

Future revisions of this specification may recognize catalog-identifier identifiers for catalogs other than ISO 6523, ISO 9735 and ISO 20022. For flexibility, this specification already offers unlimited extensibility through the unregistered scheme (defined in 2.5 ).

The URN format can also be used as format that combines the party ID type and the value in the referenced party ID system, using the format (defined in 2.7 ):

urn:oasis:tc:ebcore:partyid-type:catalog-identifier:scheme-in-catalog:scheme-specific-identifier

As an illustration, this specification also contains a non-normative section that describes some sample applications:

•.ebXML version 2.0 or 3.0 message headers (ebMS);
•.ebXML version 2.0 collaboration protocol profiles and agreements (CPP/CPA);
•.Universal Business Language (UBL) version 2.0 documents;
•.UN/CEFACT XML business documents, such as the Cross Industry Invoice (CII);
•.OAGIS 9 XML business documents;
•.The UN/CEFACT Standard Business Document Header (SBDH).
•.Extensible Business Reporting Language 1.2 (XBRL).

1.1 Terminology

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119 [RFC 2119].

1.2 Normative References

[URN-NS] IANA. Uniform Resource Names (URN) Namespaces.
http://www.iana.org/assignments/urn-namespaces/

[ISO 6523-1] ISO/IEC 6523-1:1998. Information technology -- Structure for the identification of organizations and organization parts -- Part 1: Identification of organization identification schemes.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=25773

[ISO 9362] ISO 9362:2009. Banking -- Banking telecommunication messages -- Business identifier code (BIC).
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52017

[ISO 9735] ISO 9735:1988. Electronic data interchange for administration, commerce and transport (EDIFACT) -- Application level syntax rules.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=17592

[ISO 10383] ISO 10383:2003. Securities and related financial instruments -- Codes for exchanges and market identification (MIC)
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=33444

[ISO 20022-2] ISO 20022-2:2007 Financial services -- UNIversal Financial Industry message scheme -- Part 2: Roles and responsibilities of the registration bodies
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=44898

[ISO 20022-DSS] ISO 20022 External Code Lists, Data Source Schemes (DSS) and Supplementary Data.
http://www.iso20022.org/External_Code_Lists_and_DSS.page

[ISO 20022-OID] OrganisationId Business Component Details.
http://www.iso20022.org/standardsrepository/index.cfm?fuseaction=display&Instance=2&ssrid=xbda83e07fcfe4160dcff43d10ce30fa3

[RFC 2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Internet Engineering Task Force (IETF) RFC 2119, March 1997.
http://www.ietf.org/rfc/rfc2119.txt

[RFC 2141] URN Syntax, Internet Engineering Task Force (IETF) RFC 2141, May 1997.
http://www.ietf.org/rfc/rfc2141.txt

[RFC 2396] Uniform Resource Identifiers (URI): Generic Syntax, Internet Engineering Task Force (IETF) RFC 2396, August 1998.
http://www.ietf.org/rfc/rfc2396.txt

[RFC 3121] K. Best. A URN Namespace for OASIS.
http://www.ietf.org/rfc/rfc3121.txt

[RFC 3406] L. Daigle. Uniform Resource Names (URN) Namespace Definition Mechanisms. Oktober 2002.
http://www.ietf.org/rfc/rfc3406.txt

1.3 Non-normative References

[CWA16036] Cyber-Identity - Unique Identification Systems For Organizations and Parts Thereof. CEN Workshop Agreement 16036. November 2009.
ftp://cenftp1.cenorm.be/PUBLIC/CWAs/Cyber_Identity/CWA_CyberIdentity.pdf

[DUNS] Dun & Bradstreet D-U-N-S Number.
http://www.dnb.com/us/

[ebCPPA] OASIS Standard, “Collaboration-Protocol Profile and Agreement Specification Version 2.0”, November 2002.
http://www.oasis-open.org/committees/download.php/204/ebcpp-2.0.pdf

[EBMS2] OASIS Standard, “Message Service Specification Version 2.0”, August 2002.
http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0.pdf

[EBMS3CORE] OASIS Standard,”OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features”, October 2007.
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.pdf

[GEPIR] The Global GS1 Electronic Party Information Registry.
http://gepir.gs1.org/

[GLN] GS1 Global Location Number (GLN).
http://www.gs1.org/barcodes/technical/idkeys/gln

[OAGIS] Open Applications Group. Integration Specification 9.4 (OAGIS).
http://www.oagi.org/

[SBDH] UN/CEFACT ATG. “Standard Business Document Header (SBDH)”. http://www.gs1.org/gsmp/kc/ecom/xml/xml_sbdh

[UBL2] OASIS Standard, “Universal Business Language v2.0”, December 2006.
http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html

[UNCEFACT] UN/CEFACT XML Schemas, release D09A.
http://www.unece.org/cefact/xml_schemas/index.htm#2009A

[XBRL 2.1] Extensible Business Reporting Language (XBRL) 2.1. RECOMMENDATION - 2003-12-31 + Corrected Errata – 2008-07-02.
http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.rtf

2 OASIS ebCore PartyId Type

This section defines the ebCore PartyId Type.

2.1 URN Syntax for PartyId Type

The concept of Universal Resource Identifier (URI) and Universal Resource Name (URN) are defined in the Internet Engineering Task Force (IETF) [RFC 2396] and [RFC 2141] specifications. General definitions of, and mechanisms for, establishing Uniform Resource Names (URN) "namespaces" are specified in [RFC 3406]. The Internet Assigned Names Authority (IANA) acts as Registration Authority for URN namespaces. IANA supports a process for assigning formal Namespace IDs (NIDs) based on the IETF consensus process. NID application is made via publication of an RFC through standard IETF processes. A list of currently assigned NIDs is published on [URN-NS]. The assigned oasis NID is described in [RFC 3121].

This specification uses the assigned oasis NID to establish formal URN-based references to party identification schemes based on the prefix:

urn:oasis:names:tc:ebcore:partyid-type:

This prefix is the basis for a standard mechanism for constructing URNs from the OASIS namespace ID that reference identifier schemes in identifier scheme catalogs. Specific support is provided for the ISO 6523, ISO 9735 and ISO 20022 catalogs. This specification does not replace or compete with any existing identification scheme authority. Rather, its purpose is to provide a valid formal URN prefix that allows the use of established standards for identification of parties in contexts where URN (or more generally URI) values are required.

This specification is based on previous work in the ebXML CPP/CPA Technical Committee. That work was based on user requirements and has since been deployed by e-business user communities. Section 2.6 of this specification provides a compatibility mode that supports this existing practice. For additional background and context on party identification schemes, also see [CWA16036].

Section 2.7 extends the party identification type identifier to a party identifier, to support situations where no separate type identifier attribute or element is available to qualify the party identifier.

2.2 ISO 6523

Several schemes exist for naming identifier domains. [ISO 6523-1] enumerates values for many domains: the domain is identified by a four-digit numeric sequence for International Code Designators (ICDs). For example:

•.ISO 6523 ICD 0060 identifies the Dun & Bradstreet domain [DUNS].
•.ISO 6523 ICD 0088 identifies the GS1 Global Location Number (GLN) [GLN].

This section specifies a method to construct a URN to identify an identification scheme registered in [ISO 6523-1].

If an abbreviated name is described in the item titled “Name of Coding System” within the ICD list, a type attribute can be constructed by prepending: urn:oasis:names:tc:ebcore:partyid-type: to the abbreviated name and appending a colon “:” followed by the ICD value. For example:

•.Abbreviated Name: “D-U-N-S Number”
•.ICD value of D-U-N-S Number: 0060
•.Upper-camel-case resultant string: “D-U-N-SNumber”

Value of the URN:

urn:oasis:names:tc:ebcore:partyid-type:D-U-N-SNumber:0060

Because an abbreviated name may be omitted from the ICD list, the type attribute can always contain the string derived from “Name of Coding System” expressed in upper-camel-case. A value can always be constructed by pre-pending urn:oasis:names:tc:ebcore:partyid-type: to the upper-camel-case name and appending a colon “:” followed by the ICD value. For example, using the formal name of the Name of Coding System: “Data Universal Numbering System”:

Transformed Camel-case: “DataUniversalNumberingSystem”

Value of the URN:

urn:oasis:names:tc:ebcore:partyid-type:DataUniversalNumberingSystem:0060

Punctuation marks in these formal names (such as, “/”, “-“ or “’” ) should be included unless they are not allowed in URNs [RFC 2141]. If the punctuation characters are not allowed in URNs, then the hexadecimal escaping convention explained in [RFC 2141] should be followed for characters not allowed in URNs. However, spaces are not allowed in URNs and should be consumed during the production of an upper-camel-case string, rather than preserved in an escaped form. Words in names that are all upper-case should remain so when converted to an upper-camel-case string.

The ICD value should be appended as the last field of the URN so that any collision between formal or abbreviated names is avoided.

Another example of the above schema is:

urn:oasis:names:tc:ebcore:partyid-type:StandardCompanyCode:0147

This example designates a partner identification code which is registered with the Japan Information Processing Development Corporation / Electronic Commerce Promotion Center (JIPDEC/ECPC).

Because an abbreviated name may be omitted from the ICD list, the URN value can always contain a string derived from “Name of Coding System” expressed in upper-camel-case. If this string is considered too lengthy, the string constant “iso6523” can be used instead. A value for the URN can then always be constructed by prepending urn:oasis:names:tc:ebcore:partyid-type: to either the string constant or the upper-camel-case name and appending a colon “:” followed by the ICD value.

For example, the identifier for “Data Universal Numbering System” can be transformed in either:

•.urn:oasis:names:tc:ebcore:partyid-type:DataUniversalNumberingSystem:0060
•.urn:oasis:names:tc:ebcore:partyid-type:iso6523:0060

2.3 ISO 9735

Alternatively, the code list for ISO 9735 (UN/EDIFACT syntax) D.3 Service simple data element 0007 (Identification Code qualifier) can be used to name identifier domains [ISO 9735]. The URN will be constructed using the prefix urn:oasis:names:tc:ebcore:partyid-type: followed by iso9735: followed by the specified code value. Since the value for GLN in this code list is 14, the constructed URN has the syntax:

urn:oasis:names:tc:ebcore:partyid-type:iso9735:14

Similarly, the D-U-N-S scheme has the value 1 in this code list, so it would be represented as:

urn:oasis:names:tc:ebcore:partyid-type:iso9735:1

The envisaged application of this scheme is the exchange of EDIFACT documents using an XML-based B2B message protocol, like ebXML Messaging.

2.4 ISO 20022

The ISO 20022 Registration Authority (RA) is the operating authority responsible for the registration and maintenance of the ISO 20022 Repository. Its responsibilities are defined in [ISO 20022-2]. The ISO 20022 repository defines a type to identify organizations [ISO 20022-OID]. The ebCore identifier for the ISO 20022 catalog is:

urn:oasis:names:tc:ebcore:partyid-type:iso20022:

The schemes in the 20022 catalog are identified by appending the business element names from the ISO 20022 organisation id business component to the ebCore ISO 20022 catalog identifier. For instance, the following type qualifies a reference to a bank using its Bank Identifier Code [ISO 9362] and to a financial market using its Market Identifier Code [ISO 10383].

urn:oasis:names:tc:ebcore:partyid-type:iso20022:BIC

urn:oasis:names:tc:ebcore:partyid-type:iso20022:MIC

In the ISO 20022 organization id component, the element ProprietaryIdentification is used for identification of organizations using proprietary schemes. Data Source Schemes (DSS) are proprietary code lists that are neither owned nor managed by ISO 20022, and that replace a standard code list in specific ISO 20022 Message Components, where the use of such DSS has been approved. The current list of Data Source Schemes is available online [ISO 20022-DSS]. Data source issuers are identified using four character codes. For instance, XLON identifies the issuer “London Stock Exchange” and XETR identifies “Deutsche Boerse AG: XETRA (exchange electronic trading)”. The URN for an approved data source schema is constructed using the following pattern:

urn:oasis:names:tc:ebcore:partyid-type:iso20022:ProprietaryIdentification:dss-issued-scheme

The dss-issued-scheme is identical to the issuer code, if the issuer issues only a single code. If the issuer maintains multiple schemes, dss-issued-scheme is the concatenation of the issuer code and scheme. An example identification scheme indentifier would be:

urn:oasis:names:tc:ebcore:partyid-type:iso20022:ProprietaryIdentification:xlon

The ebCore ISO 20022 PartyId Type is not relevant in the specific context of schemas defined in the ISO 20022 registry, as the message schema and context will already indicate that such codes are to be interpreted as referring to approved ISO 20022 DSS schemes. In other contexts, the ebCore Party ID allows URN identification strings for ISO 20022 defined party types to be constructed and interpreted in an unambiguous manner.

2.5 Unregistered

To support situations where there is a requirement to use a valid formal URN as partner identifier, but only an informal, mutually agreed or proprietary identification scheme is used, the following type is provided as a prefix.

urn:oasis:names:tc:ebcore:partyid-type:unregistered:

The unregistered scheme can be used as an extension element for Party Identification schemes that are not registered in the three catalogs recognized in this specification, for example:

urn:oasis:names:tc:ebcore:partyid-type:unregistered:myscheme

It can also be used to identify scheme catalogs other than the three catalogs and a scheme in such a catalog, for example:

urn:oasis:names:tc:ebcore:partyid-type:unregistered:mycatalog:myscheme

Presence of the substring unregistered: in this example clearly distinguishes unregistered catalogs like mycatalog from the established iso6523, iso9735 and iso20022 scheme catalogs, while offering unlimited extensibility.

2.6 Compatibility URN ebxml-cppa:partyid-type

This specification is based on draft revisions of the 2.0 specification of ebXML Collaboration Protocols and Agreements and a draft revision of version 3.0. Recognizing that several implementations of the proposed mechanism exist in production use, which anticipated the standardization process, implementations SHOULD also support the following prefix, which was used in these draft documents:

urn:oasis:names:tc:ebxml-cppa:partyid-type:

Implementations MUST process these values as if the following prefix, defined in this specification, had been used:

urn:oasis:names:tc:ebcore:partyid-type:

Furthermore, to be consistent with version 2.0 of CPP/A, the value that follows SHOULD be accepted as a valid type party identification scheme URN:

urn:oasis:names:tc:ebxml-cppa:partyid-type:duns.

This value is equivalent to:

urn:oasis:names:tc:ebcore:partyid-type:iso6523:0060

and

urn:oasis:names:tc:ebcore:partyid-type:iso9735:1

2.7 Party Identification

In some applications, it is not possible to reference the identification scheme in a scheme catalog separately from the scheme-specific identifier. In these applications, there is a need to combine the party identification type value and the party identifier in a single value. This specification extends the ebCore PartyId type to support this requirement using the following pattern:

urn:oasis:tc:ebcore:partyid-type:catalog-identifier:scheme-in-catalog:scheme-specific-identifier

In the pattern, catalog-identifier is one of iso6523, iso9735, iso20022, iso20022:ProprietaryIdentification or unregistered . The scheme-in-catalog is the value of the scheme within the catalog, and scheme-specific-identifier is the identification code in the scheme, with characters escaped (where needed to meet the syntax of [RFC 2141]) and white space removed, as described in section 2.2 .

This longer format supports situations where the content of an XML element that identifies a party is of type anyURI and there is no attribute or element that can qualify the identifier, or where the URN is used as a sender or recipient address in an HTTP header value.

3 Sample Applications

This non-normative section describes some applications of the PartyId-Type URN.

3.1 ebXML Collaboration Protocol Profiles and Agreements (CPPA)

The ebXML Collaboration Protocol Profiles and Agreements ([ebCPPA]) specification can use the proposed URN party identification type scheme. In a CPA, the PartyId specifies the identification of a party in the agreement. The @type attribute of this element has a type URI and defines a namespace for the value or content of the PartyId element. The type attribute can therefore use the URN-based identification of the identification system in which the party identification is to be interpreted. The following example shows a fragment of a CPA that involves an entity identified using the code 4035811991021 in the GLN system.

<cpa2:PartyInfo tns:partyName="Example company"

cpa2:defaultMshChannelId="P1_channel_"

cpa2:defaultMshPackageId="DefaultPackage">

<cpa2:PartyId

cpa2:type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"

>4035811991021</cpa2:PartyId>

<cpa2:PartyRef xlink:href="http://www.example.com/"/>

<cpa2:CollaborationRole>
...

3.2 ebXML Messaging (ebMS)

The OASIS ebXML Messaging ([EBMS2], [EBMS3CORE]) specifications can similarly use the ebCore PartyId type. In an ebXML message, both the sender and recipient of the message are identified using the PartyId element and @type attribute. The following is an excerpt from an ebMS 3.0 message:

<eb3:PartyInfo>

<eb3:From>

<eb3:PartyId

type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"

>4035811991021</eb3:PartyId>

<eb3:Role>Buyer</eb3:Role>

</eb3:From>

<eb3:To>

</eb3:To>

</eb3:PartyInfo>

3.3 Universal Business Language (UBL)

The Universal Business Language 2.0 OASIS Standard [UBL2] defines a number of XML document schemas to support electronic business. These documents contain elements referring to parties in various roles. For example, an Order document has BuyerCustomerParty and SellerSupplierParty elements. These elements contain a common Party group that has an optional PartyIdentification element. The ID element in this element has an optional @schemeID element that could use the proposed URN as a standard identification mechanism. The content of the ID element contains the identifier in the referenced identification scheme.

<cac:BuyerCustomerParty>

<cac:Party>

<cac:PartyIdentification>

<cbc:ID

schemeID="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"

>4035811991021</cbc:ID>

</cac:PartyIdentification>

</cac:Party>

</cac:BuyerCustomerParty>

<cac:SellerSupplierParty>

<cac:Party>

<cac:PartyIdentification>

<cbc:ID

schemeID="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"

>4035811991014</cbc:ID>

</cac:PartyIdentification>

</cac:Party>

</cac:SellerSupplierParty>

3.4 UN/CEFACT XML Schemas and OAGIS

The @schemeID attribute also occurs in two other e-business libraries:

•.UN/CEFACT D09A XML schemas contain an ID element with the same semantics as in UBL. The approach of using the ebCore PartyId URN as value for @schemeID therefore also supports party identification in business documents in this set of schemas, such as IssuerCITradeParty in the Cross Industry Invoice (CII).
•.OAG Integration Specification [OAGIS] business documents contain a generic ApplicationArea structure, which has sub-elements like Sender and Receiver, which in turn have a sub-element LogicalID that has the @schemeID attribute.

3.5 UN/CEFACT Standard Business Document Header (SBDH)

The Standard Business Document Header specification [SBDH] is a result of a work project of the UN/CEFACT Applied Technology Group (ATG). It provides a consistent interface between applications and provides the semantic information needed for the routing, processing and business domain context of documents, regardless of the data format of the document. The schema contains Sender and Receiver groups, containing an Identifier element with an @Authority attribute that serves a similar role to the @type attribute in ebXML CPPA and messaging, and to @schemeID in UBL.

<sh:StandardBusinessDocument

xmlns:sh="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">

<sh:StandardBusinessDocumentHeader>

<sh:HeaderVersion>2.2</sh:HeaderVersion>

<sh:Sender>

<sh:Identifier

Authority="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"

>2203148000007</sh:Identifier>

</sh:Sender>

<sh:Receiver>

<sh:Identifier

Authority="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"

>6903148000007</sh:Identifier>

</sh:Receiver>

3.6 Extensible Business Reporting Language (XBRL)

XBRL is the specification for the eXtensible Business Reporting Language [XBRL 2.1]. XBRL allows communities to enhance the creation, exchange, and comparison of business reporting information. Business reporting includes, but is not limited to, financial statements, financial information, non-financial information, general ledger transactions and regulatory filings, such as annual and quarterly reports. In XBRL, the entity element describes the reporting entity. An identifier element specifies a scheme for identifying business entities. The required scheme attribute contains the namespace URI of the identification scheme, providing a framework for referencing naming authorities. The value of scheme is a non-empty value of type anyURI. The following sample references a company registered in the Netherlands Chambre of Commerce registry.

<xbrli:xbrl

xmlns:xbrli="http://www.xbrl.org/2003/instance"

xmlns:link="http://www.xbrl.org/2003/linkbase"

xmlns:xlink="http://www.w3.org/1999/xlink"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"

xlink:href="http://..."/>

<xbrli:context id="cd0">

<xbrli:entity>

<xbrli:identifier

scheme="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0106"

>800029562</xbrli:identifier>

</xbrli:entity>

<xbrli:period>

<xbrli:startDate>2009-07-01</xbrli:startDate>

<xbrli:endDate>2010-06-30</xbrli:endDate>

</xbrli:period>

...

</xbrli:context>

...

</xbrli:xbrl>

4 Conformance

Conformance targets for this specification include:

•.schemas for XML business document types;
•.libraries of re-usable XML structures and types for use in such schemas;
•.Message Implementation Guidelines (MIGs) or profiles that define constraints on business documents for use in specific contexts;
•.XML-based B2B messaging protocols that have header elements or attributes for party identification types;
•.XML-based languages that define policies or agreements about B2B message exchanges between identified business partners;
•.XML processing software

and

•.any XML documents that instantiate and conform to these schemes, libraries, profiles, message protocols, policy or agreement languages;

For any of these artifacts to claim conformance to this specification, any element or attribute that:

1.provides typing information for party identification
2.has a anyURI (or more general, e.g. string) type
3.and has any of the following strings as a prefix of its value:
urn:oasis:names:tc:ebcore:partyid-type

urn:oasis:names:tc:ebxml-cppa:partyid-type

MUST satisfy all the MUST and REQUIRED level requirements defined in this specification.

Furthermore, for any of these artifacts to claim conformance to this specification, any element or attribute that meets requirements (1) and (2):

4.MAY use the compatibility URN defined in section 2.6 in situations where backward compatibility is required. It SHOULD NOT be used in new applications.
5.SHOULD set the party identification type value as specified in section 2.2 if the party ID type is registered in the ISO 6523 registry.
6.MAY specify the party identification type as specified as in section 2.3 in the context of exchange of EDIFACT messages.
7.SHOULD set the party identification type value as specified in section 2.4 if the party ID type is a registered ISO 20022 party ID type.
8.SHOULD use the “unregistered” scheme of section 2.5 in all other situations.

Appendix A.Acknowledgments

The editors would like to acknowledge the contributions of the completed OASIS ebXML Collaboration Protocol Profile and Agreement (CPPA) Technical Committee, which contributed its uncompleted documents to the OASIS ebXML Core (ebCore) Technical Committee.

The editors would also like to acknowledge the contributions of the OASIS ebXML Core (ebCore) Technical Committee, whose voting members at the time of publication were:

•Kathryn Breininger, The Boeing Company (Chair)
•Pim van der Eijk, Sonnenglanz Consulting.
•Sander Fieten, Individual member.
•Bahareh Heravi, Brunel University.
•Dale Moberg, Axway (Chair)
•Farrukh Najmi, Individual member.
•David Webber, Individual member.

Appendix B.Revision History

Revision	Date	Editor	Changes Made
CD 001	19/03/10	Dale Moberg (for the CPPA input) Pim van der Eijk	First version based on CPPA TC input and ebCore extensions and amendments.
CD 002, PRD 001	13/04/10	Pim van der Eijk	Public Review Draft, based on TC Admin feedback.
Working Draft	19/06/10	Pim van der Eijk	Public Review Feedback in new section 2.7 ; ISO 20022 coverage improved; XBRL example
CD 003	09/07/10	Pim van der Eijk	Document voted CD 003