Identity Resolver page updates #254
Conversation
address feedback on draft spec.
Co-authored-by: Ashley Harwood <[email protected]> Signed-off-by: Steven Capell <[email protected]>
Co-authored-by: Ashley Harwood <[email protected]> Signed-off-by: Steven Capell <[email protected]>
Co-authored-by: Ashley Harwood <[email protected]> Signed-off-by: Steven Capell <[email protected]>
Co-authored-by: Ashley Harwood <[email protected]> Signed-off-by: Steven Capell <[email protected]>
Co-authored-by: Ashley Harwood <[email protected]> Signed-off-by: Steven Capell <[email protected]>
Signed-off-by: Steven Capell <[email protected]>
onthebreeze
force-pushed
the
DAC-Updates
branch
from
f9b2596 to
80b90d0
Compare
|
Significant amount of work here - impressive! I've found a few areas that I think can be sharpened/improved. Didn't want to create a new fork... I suggest a slight improvement/simplification of the third sentence in the overview, "...without precluding the use of..." is a complex sentence structure. How about "...allows for the use of...."? The column heading "Name" in the table in the requirements section (https://github.com/uncefact/spec-untp/blob/DAC-Updates/website/docs/specification/IdentityResolver.md#requirements) doesn't seem to match the content. "Leverage existing carriers" sounds like a purpose/summary or something, not a name - or am I misunderstanding this? Are the first two columns meant to be concatenated? The section "Linked Data Needs" has a typo ("consistnet" should be "consistent") and I think the last sentence (starting "In this section") should start with "To address these challenges, in this section..." since the previous text is describing the problems with identifiers and the subsequent sections offer the way that UNTP addresses them. Section "Decentralised Identifiers (DID)" - Given that the DID community is reviewing DID Methods and looking for simplification/improvement, I this section could be enriched a little but that can wait until we have a draft published. Section "Creating the IDR Query URL" refers to the conceptual model and the process to derive an IDR query as having two steps. The diagram doesn't have a clear mapping to the two steps that are introduced. Section "From a URN to IDR Linkset" is a heading level below where it should be. Section "From a DID to IDR Linset", "a DID resolved to a DID document" should be "a DID resolves to a DID document" (my emphasis). There is some move away from DID:web as a DID method, looking for more security and separation from reliance on CA hierarchies, but that can be addressed in an further update. Section "LinkSet (sp?) Response Variations", "SHIULD" should be "SHOULD" General comment - many of the subsections after the requirements table seek to address the requirements - should we reference the requirement in the explanatory text where this is the case? |
| * examples: | ||
| * `https://products.sample-company.com/1234567` | ||
| * `https://facilities-register.com/ABC123456` | ||
| * `https://example.com%2F01/733240226591` |
There was a problem hiding this comment.
example.com%F01 is an invalid DNS name. We should not allow it
Signed-off-by: Phil Archer <[email protected]>
…nto DAC-Updates
| 1. Each item in an inbound shipment of supplies to a manufacturing facility is barcoded - using the same well known barcode scheme that has been in use for many years (so nothing special for UNTP). A barcode reader captures the identifier of an item - eg `1234567`. | ||
| 2. The scanner system may already know how to construct a URL from the ID (eg following ISO/IEC 18975) or may lookup the scheme in a local copy of the UN global register of schemes. A resolver template such as `https://resolver.example/{id}` can be used to replace `{id}` with the actual identifier to get `https://resolver.example/1234567`. | ||
| 3. Calling the URL `https://resolver.example/1234567` returns an [IETF link-set](https://datatracker.ietf.org/doc/rfc9264/) that includes one or more links (also URLs). Each link is annotated so that the type of information provided by the link is declared. **Link types** may include things like product safety data sheet, instruction manual, brand homepage, a digital product passport (DPP), and a digital conformity credential (DCC). Further annotations are used to declare things like the format of the linked information (HTML, PDF, JSON etc.). This is achieved using [IANA-registed Media Types](https://www.iana.org/assignments/media-types/media-types.xhtml). | ||
| 4. A link typed of `dpp` with a format declaration of `[application/vc](https://www.w3.org/TR/vc-data-model-2.0/#vc-ld-media-type)` is a hint that the target URL will yield a UNTP DPP credential which is verified to confirm integrity. The DPP includes several sustainability claims including the emissions footprint of the product, which the manufacturing facility can use to calculate the contribution of the received item to their scope 3 total. Following the DCC link type yields a conformity credential issued by a third party certifier that attests to the carbon intensity of the product. |
There was a problem hiding this comment.
A link typed of
dppwith a format declaration of `[application/vc]
Since we require implementors to envelop their credentials, should we use application/vc+jwt instead?
|
|
||
| Link resolver services SHOULD define DEFAULT link type for each `anchor` which defines the `href` target to which a client will be redirected when no `linkType` is specified in the matching query URL. In the previous [IDR example](#identity-resolver-example), calling the resolver URL without a `linkType` parameter; | ||
|
|
||
| `https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=linkset` |
There was a problem hiding this comment.
This should be https://resolver.sample-register.example/products/ABCD9876/items/1234, right?
| * a context describes what the links are about using the `anchor` property. Often there is only one `anchor` that represents the requested `identifier`. But as described in the [resolver workflow](#resolver-service-workflow), a resolver may return links about related entities. For example a query about a specific serialised item may return some links about the item, and some links about the product class, and even some links about the manufacturer or brand that sells the product. | ||
| * a target describes a specific link identified with the `href` property together with other properties that provide useful meta-data about the link. | ||
|
|
||
| A typical response the the sample query `https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=linkset` might be as shown in the snippet below. |
There was a problem hiding this comment.
| A typical response the the sample query `https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=linkset` might be as shown in the snippet below. | |
| A typical response to the sample query `https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=linkset` might be as shown in the snippet below. |
| ### Related Links | ||
| * The DID document `service.id` property is the same as the linkset `anchor` property with the optional `#fragment` suffix to ensure that `service.id`is unique. | ||
| * The DID document `service.type` property is the same as the linkset linkType value. | ||
| * The DID document `service.serviceEndpoint` property is exactly the same as the the linkset `target` object. |
There was a problem hiding this comment.
| * The DID document `service.serviceEndpoint` property is exactly the same as the the linkset `target` object. | |
| * The DID document `service.serviceEndpoint` property is exactly the same as the linkset `target` object. |
Added some overview of a generic process from data carrier to UNTP credentials. Also generalising to multiple identifier types. Also conventions about URI structure so that identifers are the same thing can be consistently matched across different data sources.