trbouma
commented
5 months ago Most likely a did:web will be resolved at a subdomain leve having its own did. That is what I am experimenting with in the prototype, e.g.,
did:web:trustroot.ca, did:web:credentials.trustroot.ca, and did:web:community.trustroot.ca all resolve to different dids.
As well, I am experimenting with did:web that have a local part - e.g., did:web:trbouma@credentials.trustroot.ca - resolves to a did that is specific to a user.
These comments are from reading the document draft-ietf-high-assurance-dids-with-dns.md. The links in the README.md did not resolve — at least for me.
The examples in the specification could use additional detail. Notably — what do the values in the URI and TLSA records mean? I was not clear on the relationship between the DIDs in the example, and those DNS records — particularly for the TLSA records.
The spec. reads (at least to me) as if the “usual case” will be for the DIDDocs to be at the domain level — e.g. with the did:web referencing the domain, and thus, the DIDDoc in the .well-known path. I think that the common case will be that the DIDDoc will be in a sub-domain or path, and that having the DIDDoc at the domain level will be a rare case. An organization will have multiple — perhaps many — DIDs (especially if there are employee level DIDs as discussed in some of the issues in this repo), and so the common case will be that the DIDs are not at the domain level. I think should be reflected in the specification.