search

uncefact / spec-untp

UN Transparency Protocol
https://uncefact.github.io/spec-untp/
GNU General Public License v3.0
10 stars 9 forks source link

Need to get verifiable identity “who is” data about all participants, especially issuers #56

Closed swcurran closed 4 days ago

swcurran commented 2 months ago

Given the UNTP architecture of recursively using identifiers to discover verifiable data about products, it is important that there be an easy way to discover verifiable identity data about the issuers of the product data. For example, when a producer issues and publishes a Digital Product Passport (DPP) about their product, the consumers of that DPP need to verify who is the producer of the DPP.

Since issuers sign signed their VCs, they must have published their public key some how, and we would like them to use a DID for that. Ideally, that DID can be used to find details about the identlty of the DID Controller — e.g. the issuer. Ideally the approach will be a generalized mechanism that will work easily for all DIDs.

swcurran commented 2 months ago

While the idea of having an easy way to find if an issuer can be trusted by seeing the VCs with the DID as the subject is appealing, it is likely the biggest challenge is going to getting trusted authorities to issue foundational credentials where the DID is the subject. The most important is the issuance of a "Legal Entity" credential to bind a DID to a Legal Name. This likely needs to be done at the Jurisdictional level. It is something that GLEIF is trying to implement via their "vLEI" concept -- although their choice of tech stack may prove challenging.

It is a chicken and egg issue a Legal Entity having the capability to hold/use a DID (which is fundamental to UNTP, so we'll have to solve this) and for the Legal Entity Registration Authority being willing to do a sufficient Identity Proofing of the Legal Entity and their DID so as to be willing to issue a Verifiable Credential to bind the Legal Entity's DID to the Legal Entity's Registration Identifier and Legal Name. The more we can do to help Legal Entity Registration Authority accomplish that step, the better.

I imagine the process that GLEIF uses for issuing an LEI is quite similar. Presumably, they are using documentation from the jurisdictional Legal Entity Registration Authority to determine the identity of the Legal Entity such that they are willing to issue an LEI.

mxshea commented 2 months ago

Another potential implementation candidate would be the work that CIRA has been doing High Assurance DIDs with DNS (HIADID) https://www.ietf.org/archive/id/draft-carter-high-assurance-dids-with-dns-03.html

That said, I do agree with the intent that @swcurran has outlined here, but do have concerns about including specific implementation details within the body.

swcurran commented 2 months ago

Removed from the issue topic and added as a comment.

The DID Core compatible solution that we propose is the application of the Linked-VP specification, combined with its use by convention that all DIDs (or at least UNTP ones…) SHOULD define a service that enables a <did>/whois DID URL Path that, when resolved, returns a Verifiable Presentation signed by the <did>, containing Verifiable Credentials where the <did> is the credentialSubject. The Verifiable Presentation contains any verifiable credentials that the DID Controller wants to publish about itself, and, presumably, anyone resolving <did>/whois likely has some context to understand at least some of the published credentials. The process is applied recursively — each of the verifiable credentials in the /whois verifiable presentation, has been issued by an issuer (presumably, an authority), and so the resolver can in turn, resolve their <did>/whois DID URL until they either find an authority they trust, or all of the information is organized (into a graph) and provided to a human who can use the evidence to make a trust decision — do we trust the issuer of the original VC we retrieved? Presumably, as human decisions are made, they are converted to business rules that can be applied automatically.

We proposed this convention as part of did:tdw — a DID Method to complement did:web that addresses a number of limitations with did:web — especially the need for a verifiable history of a DID, with evidence of authorized (by the DID Controller) of changes to the DID.

References:

onthebreeze commented 4 days ago

does the proposed Digital Identity Abchor close this issue? https://jargon.sh/user/unece/DigitalIdentityAnchor/v/working/artefacts/readme/render#digitalidentityanchor-domain

swcurran commented 4 days ago

Yes, I think so.