1. Generalizing Metadata Services URLs Dale Moberg

2. Metadata Services Parts L,M, and N of PEPPOL describe a solution for finding out about capabilities and endpoints for final recipients while within the central “cloud” of a four-corner connection “topology.” Focus today: can the discovery of endpoints be generalized in useful ways? It can be generalized. Some uses will be mentioned. Only one direction (“NAPTR”) for generalization will be considered

3. Current URL Template “The sender constructs the address for the service metadata for a given recipient participant identifier using a standard format, as follows: http://.. / /services/ “The sender uses this URL in an HTTP GET operation which returns the metadata relating to that recipient and the specific document type (see SMP]). The sender can obtain the information necessary to transmit a message containing that document type to that recipient from the returned metadata. “Note that the sender is required to know 2 pieces of information about the recipient - the recipient's participant ID and the ID of the Scheme of the participant ID (i.e. the format or type of the participant ID).

4. Generalizing ULR format “parts” ● Can the scheme part (“http:”) be generalized; can it be “https”? ● Can the hostname part convention (. ) be altered? ● Can there be many different SMP domains? ● Can different communities use different paths? ● Can query parameters be added to the URL?

5. One way beyond fixed templates. ● There are standards defining “Dynamic Delegation Discovery Systems” that have been used (SIP VOIP, ONS/FONS, ENUM) to produce an open DNS approach to flexible URI publication and retrieval. ● One special part of this system is called the NAPTR, with a “u” flag declaring that the record defines a URI/URL. (RFC 3404)

6. What records might look like... $ORIGIN purchasing.example.com. [declares what DNS name is the “key” for the records ] ;; order pref flag service regexp replacement IN NAPTR 100 10 "u" "meta+loc" "!^.*$!https://m.example.com/recipId/schemeId/?query=Orders!i". Order “100” indicates the sequence of using the record Pref 10 indicates which record preferred at a given sequence position Flag indicates a defined processing mode Regexp maps any query value ( ^.*$ ) to Result ( https://m.example.com/recipId/schemeId/?query=Orders) Case-insensitive matching ( i)

7. Initial Comments ● The scheme, hostname, domain, path elements, and query parameters are all customizable to meet specific use case requirements. ● Various communities of interest could define registered values for use in metadata service locations. ● REST style queries supported.

8. Security ● HTTPS scheme is usable with the canonical name of the host that is the metadata server. ● The remote “server” authentication function of TLS/SSL can assure a client who is providing the metadata service. ● The ability to find the URL using the domain DNS identity of the final recipient is compatible with on-premise, hosted, or cloud metatdata service providers.

9. Advanced Security Futures ● Compatible with the nearly completed TLSA specification from the DANE WG. ● Can use DNS PKI exclusively or in combination with tradional CA PKI. ● NAPTR itself can be signed using DNSSEC.

10. Backwards Compatible with SML format ● Although SML does not need NAPTR as currently deployed, the SML format could be used in a NAPTR within the SML Domain or within the final recipient domain or both. ● Need comparison on how federation ( interconnects) are to be made for current SML domains or NAPTR based federation.

11. Standardization Options ● If NAPTR (plus other DNS RRs) are used, still need: ● Enumerations of values for schemes, hostnames, paths, query parameters. ● Conventions for query parameter use ?key=value&key1& … – Defaults, post-processing? ● Much more TBD based on use cases.