1. Description

eDelivery uses the e-SENS profile of the Business Document Metadata Service Location Version 1.0 OASIS Standard [BDX-Location-v1.0], usually referred to as the "BDX Location" (BDXL) specification, as its technical specification for Service Location. BDX Location specifies a method to query DNS resource records to retrieve a URL for metadata services. The result of a query is a full URI, which can use HTTPS and supports server (and optionally client) authentication.

The e-SENS BDX Location profile is intended to be used in conjunction with the e-SENS SMP profile [PR-SMP]. The retrieved URL is a URL for an SMP XML document that can be obtained using the SMP HTTP binding. This process is visualized in the following diagram:

OASIS BDX Location is similar to the PEPPOL SML [SML], but is based on a type of DNS resource records called URI-enabled Naming Authority Pointer records [U_NAPTR]. U-NAPTR is designed to support Dynamic Delegation Discovery Services (DDDS). This profile of BDX Location provides a superset of the functionality of SML.

2. Base Specification

This specification is based on the following OASIS Standard:

• [BDX-Location-v1.0] Business Document Metadata Service Location Version 1.0. OASIS Standard, 01 August 2017. http://docs.oasis-open.org/bdxr/BDX-Location/v1.0/  

3. Implementation Guidelines

Client and server components implementing this specification MUST comply with the OASIS Business Document Metadata Service Location Version 1.0 standard.

Server deployments of e-SENS BDX Location MUST use the "Service Provider Domains" option, defined in section 2.3.2 of [BDX-Location-v1.0].  This is because the IETF BCP 3405 is not currently implemented on the Internet. The value of the provider domain suffix MAY differ for different sectors or communities and MUST also encode the communication environment, to separate "production" from "test" environments.

In the DNS query, the DNS query string MUST be created as follows: 

1. The party identifier and type is encoded in the partner identifier format defined in section 2.7 of [PARTYIDTYPE] and following the eDelivery ebCore Party Identifier profiling [PR-EBCORE]. This format concatenates the urn:oasis:tc:ebcore:partyid-type:<<catalog-identifier>>:<<scheme-incatalog>> value, a single colon, and the <<scheme specific identifier>>.
   For example, the GS1 Global Location Number (GLN) scheme [GLN] is registered in the ISO 6523 catalog under the "0088" code. The ebCore Party Id type prefix for GLN “urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088” can be combined with a GLN scheme specific identifier “4035811991021” into the canonical ebCore Party identifier “urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088:4035811991021”.
2. The canonical party identifier is processed using the SHA256 algorithm.
3. The digest obtained in (2) is BASE32 encoded.
4. Any trailing '=' padding characters added in (3) in the encoded digest are removed.
   For the example, this results in the following value: “I3QYB36CTAYRFGTHBYCQZDTOJFHGAZJEGLFOOE7727EGVDWRK5QQ”
5. If the BDXL service provider provides resource records for separate environments, a label identifying the applicable environment MUST be used in combination with value obtained in (4) for all environments other than production. For example, the service provider may provide resource records for the environments “acceptance” and “production”. In this case, a label MUST be added to records that are to be looked up in the “acceptance” environment.
6. The values obtained in (4) and (5) are used as parameters in a service provider-specific formatting function that adds produces the final query domain string. Details of the formatting function are left to the service provider. For example, the service provider could adopt a simple concatenation of the values. For the “bdxl.example.com” and the “acceptance” environment, the resulting query domain could then have the value:
   “I3QYB36CTAYRFGTHBYCQZDTOJFHGAZJEGLFOOE7727EGVDWRK5QQ.acceptance.bdxl.example.com”
   In the production environment, the resulting domain could have the value:
   “I3QYB36CTAYRFGTHBYCQZDTOJFHGAZJEGLFOOE7727EGVDWRK5QQ.bdxl.example.com”
   However, the service provider MAY also use different formatting conventions. Furthermore, the service provider MAY also include other parameters (such as parameters to group the records for business domains, or for use with particular services) in the format.    

Note that the query string does not include a B- prefix, unlike the convention specified in [SML].

BDX Location servers MUST set the type field of U-NAPTR records that link to metadata services based on the OASIS SMP to the value "meta:smp".  BDX Location clients that retrieve SMP-based metadata MUST restrict record searches to U-NAPTR records of this type.

URI values stored in BDX records MUST use the secure HTTP URL scheme ("https"). For coexistence with the legacy SML format and the OASIS SMP HTTP binding, URI records MUST be limited to the "authority" part, i.e. not include any path, query or fragment parts.

4. Ownership

The BDX Location technical specification is Copyright © OASIS Open 2017. All Rights Reserved.

The BDX Location technical specification is created by the OASIS BDXR Technical Committee which operates under the Non-Assertion Mode of the OASIS IPR Policy. OASIS is not aware of any statements or declarations regarding IPR related to the work of this technical committee.

This specification was originally created in the former EU e-SENS project. The EU e-SENS project formally transferred ownership of its specifications to the European Commission, which accepted it for further maintenance in the context of the CEF Programme. Information on governance and procedures for eDelivery is available from Governance and Procedures.

5. References

[BDX-Location-v1.0] Business Document Metadata Service Location Version 1.0. OASIS Standard, 01 August 2017. http://docs.oasis-open.org/bdxr/BDX-Location/v1.0/  

[GLN] Global Location Number https://www.gs1.org/gln

[PARTYIDTYPE] OASIS ebCore Party ID Type Technical Specification. September 2010. http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/PartyIdType-1.0.pdf.

[PR-EBCORE] e-SENS ebCore Party Id 1.3.

[PR-SMP] e-SENS SMP - 1.9.0.

[SML] Service Metadata Locator. https://peppol.eu/downloads/the-peppol-edelivery-network-specifications/

[SMP-v1.0] Service Metadata Publishing (SMP) Version 1.0. OASIS Standard, 01 August 2017. http://docs.oasis-open.org/bdxr/bdx-smp/v1.0/.

[U_NAPTR] IETF RFC 4848. Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS). https://tools.ietf.org/html/rfc4848. 

6. Contributors

The eDelivery team is in charge of maintaining the current version of the e-SENS BDX Location specification.

Details about contributors of previous versions can be consulted on the e-SENS website.

7. History

Details about previous versions of the specifications can be consulted on the e-SENS website.