OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Business Identifiers -- was RE: [bdxr] Groups - Service Discovery Generalization with NAPTR(u) uploaded


Hi Kenneth,  I will respond to your:


Question: How do you see the use of business identifiers? Can existing business identifiers (GLN, VAT etc.) fit into this scheme?


Let me first review what the generalization (and its illustration with NAPTR-“u” implementation) is to allow. The goal is to find a backwards compatible approach that allows the URL for a metadata service to be retrieved from the DNS, rather than always constructed from filling in a template. The service location discovery is now done by a query to DNS for NAPTR records. These queries (which can be explored with a tool like “dig” in a linux system (that is configured to make use of some decent DNS servers!) ) can then use a fully qualified host name or a domain name or, in fact any DNS admissible query string)


So instead of requiring what SML domain is relevant to a metadata service, it becomes possible to simply use a company’s registered DNS name, for example, in the query. DNS names are one kind of company identifier. And this permits a company to run its own metadata service, if it wants to. Or even if it wants to outsource either its DNS or its metadata service, one could still find that service entry point by querying for its NAPTR at  big-financial-institution.com, and the value could be for a metadata service provider hostname (outside big-financial-institution.com) at meta-cloud-systems.tld, for example. The HTTPS schema could then know what hostname to look for, and the remote endpoint could be identified by its certificate (or TLSA record or combination thereof) as the intended service host.  By using TLS, we can use some of the “lightweight” authorization approaches needed for Roger Bass’s use case); these include OAuth using Bearer tokens in the Authorization header as well as ordinary Basic Auth (username/password). [These approaches assume and should require protection by TLS (IMO).]  Roger’s use case raises an additional question about registration with the server, and this raises a question about registration service discovery. I have not yet found much (official) standardization in the registration service discovery area. Most of these are browser-based and you discover them by a little control marked “Register” ! But let’s move beyond the preliminaries, and ask: well how does the metadata discovery service “know” whose metadata you are interested in? I think this is the question that is of interest to you; if not, please ask again!


Roger has also asked how to query the URL found during metadata service location discovery. And here we can make use of the parts of a URL after the hostname—that is, after scheme://example.com/path/parts/as/needed?queryp0=value&morequery=othervalue& as needed.


These parts of the URL are URI-escapable, or the SML implementation of hashing names and naming-authority schemes, can also be used in the path components. It makes sense to me to put them in the path components, because certainly that will be a crucial “key” for the metadata values that are to be retrieved. I suppose they could be put into the query parameters (keys, or key-value pairs) also. Those choices are TBD. For example, if ebXML were to use this device, we would probably want to arrive at enumerations of supported values and parameters that would enable CPPs to be retrieved, or parts of CPPs, and so on. [Also there would need to be room for a RegRep metadata service, and what is needed there is really TBD in collaboration with that TC.]  In addition,because the NAPTR system is backwards compatible with SML/SMP, the NAPTR values can contain the same URLs as now used.  For CPP, we have over the years built up a mapping of ISO identified naming authorities and values within those naming authority systems that can be leveraged directly or with abbreviations that could fit into URL path components or into URI-escaped query value fields. Pim is the ebXML expert on the current state of these enumerated values, and ebCore is a discussion area for the work in that specification. So I will let Pim speak on any specifics about that specification about business identifiers. If there is something that we missed in the business identifier area, it is probably because it has emerged recently or was not added to the ISO base codes.






You are right in your comment on slide 3 that in the PEPPOL model, senders are required to know two pieces of information about the receiver: The literal business identifier, and what type of business identifier is being used. So if you want to send a document to a Danish company as example, you will have to know that they are registered in the public records as (for example) DK12345678 and that this number refers to a Danish VAT scheme. This makes a lot of sense for PEPPOL because existing business identifiers can be reused rather than having to reinvent and coordinate. There may also be a certain level of confidence in using some trusted source of identification rather than "my-trading-partner@some-service.some-network". How can this fit into the NAPTR generalization scheme?


I think I have addressed this question in the above. The NAPTR can contain the “filled-out SML template” (In this use case, you would also need to know the domain part for a given metadata service provider arena.)  If you, however, know the filled-out URL, the NAPTR is arguably a little redundant (and this is deliberate so that backwards compatibility is possible.) Where the generalization starts to show its value, is for future systems that might involve a federation of SML/SMP systems across many domains or different naming systems, for systems that make use of different metadata formats (such as CPP or WS-Policy/WSDL or whatever is next) , or have different metadata service access requirements. And there are also some security features that allow emerging security approaches (DANE, TLSA, DNSSEC signatures over NAPTRs, etc.) to be utilized a little more cleanly. Currently some of these security approaches are awkward when the service hostname is a CNAME, for example.  


I hope this helps clarify the naming problems involved both with DNS names (a core naming identifier system when internet is involved) as well as the business naming authority names (like GLNs, DUNS, ISO 20222, etc. etc.) that are needed in the query to the metadata service.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]