section on Identifier Resolvability

[bertvannuffelen]

Impacted sections

-https://uncefact.github.io/spec-untp/docs/specification/IdentityResolver#resolvability

Issue Description

I see that in the section, in the first paragraph, DIDs are discussed and then ISO/IEC (FDIS) 18975.

However I would like to point out that the general practice, implemented by just HTTP URIs is the vast majority practice. One does not need a specific protocol like DID for that. Persistent URIs maintained by any organisation with a strong data governance do not need the additional DID protocol. Of-course, the main drawback is that one cannot spot from the identifier representation whether this is resolveable and if it a maintained identifier. Therefore it is a good practice to document your organisation choices in a PURI guideline (e.g. Belgian government https://github.com/belgif/thematic/blob/master/URI/iceg_uri_standard.md)

But in the end, it is just the application of the very basic HTTP standard. That is what I like to stress: the section gives the feeling that either DIDs of ISO/IEC 18975 are to be used, while resolution can be done without these.

[onthebreeze]

I think the section needs to specify how to resolve identifiers. And should not dictate a single method but rather establish patterns.

1. You have a simple ID and you need to find the URL to get a DPP - use ISO 18975 and ask the registry that owns the ID
2. You already have a URL that encodes the ID just call the URL (basic http as @bertvannuffelen says)
3. You have a DID and you need to find the URL to get a DPP - look to the DID document service end point(s).

In all cases, we might want to specify that the return set from the URL should be an IETF linkset that lists all available object types - including a DPP.

I think this kind of approach allows considerable flexibility but also accomodates the existing world of non-URL IDs (eg a barcode on a product), the rapidly emerging world of URL IDs (ie QR Codes on products), and the decentralised world of DIDs. But in all three cases we can be pretty precise about how to resolve and what to expect as a response. So that interoperability is simple.

It is important that the response is a set of links because manufacturers just want to put one barcode or QR code on their product rather than dozens of them. Let the smart client pick which link the verifying user or system needs.

[philarcher]

Hi @bertvannuffelen - small world and all that.

It's not just about using URIs as IDs. There are any number of ID schemes in use around the world. What 18975 does is provide two methods for encoding identifiers that already exist in their own right into an HTTP URI structure. That way, you can just treat it like any other URL or you can process it to make use of the included identifiers. A recent video by yours truly sets out how and why we're doing this at GS1. That video doesn't go into the issue of what UNTP calls an Identity Resolver but that's also part of 18975. The key thing being that when you resolve, you get back a list of links (as defined by RFC 9264). The URL is just a lookup mechanism for the identifier(s) within it. The internet domain name itself is not part of the identification. This will all sound very familiar to anyone working with DOIs and DOIs are in fact conformant with 18975, but the resolution piece/linkset is not part of the DOI metadata structure (which is much more loosely defined).

There are other differences with DOIs too. Firstly, when you resolve a DOI you always get to the same thing. Not true with identity resolvers. You can resolve the same identifier in multiple places and get back different info. I always liken this to looking up the same subject in different reference books.

I'd happily send you a copy of 18975 (I wrote it) but ISO rules prohibit me from doing so, much to my frustration.

DIDs are a slightly different case. There are now over 200 different methods for creating DIDs but the key feature is that, when resolved, you get back a DID Document that incldues the public key associated withthat identifier and ... a list of service endpoints. That is, a set of links associated with the identified entity.

We're likely to want to make it clearer in the section on resolvability that these different approaches are all equally valid in the context of UNTP but hopefully this answers your issue. I have always been and remain, of the view that URI persistence is actually pretty easy to achieve - you just have to decide you want to do it. Heck, I literally wrote the GS1 policy on the matter :-) However, there are cases where URIs are not the best kind of identifier to use and so we need a way to bridge various gaps.

[bertvannuffelen]

Hi @bertvannuffelen - small world and all that.

yep it is ;-)

We're likely to want to make it clearer in the section on resolvability that these different approaches are all equally valid in the context of UNTP but hopefully this answers your issue. I have always been and remain, of the view that URI persistence is actually pretty easy to achieve - you just have to decide you want to do it. Heck, I literally wrote the GS1 policy on the matter :-) However, there are cases where URIs are not the best kind of identifier to use and so we need a way to bridge various gaps.

When reading @onthebreeze had suggested, and your response here above, satisfies my comment. The current phrasing of the section is not clear in its intentions: whether is was on describing resolving identifiers in general and then 2 specific implementations, or suggesting one of the two specific ones should be used over a self implementation or what UNTP view is on this topic w.r.t. the different approaches.