You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Then the question becomes, what should we expect in the id field for the resulting DID Document. One possibility is this:
"id": "did:web:example.com"
... but another possibility is this:
"id": "did:web:example.com/.well-known/did.json"
What if someone specified this as their DID: did:web:example.com/alice.json, but their DID Document states:
"id": "did:web:example.com/alice"
Is this DID did:web:example.com equivalent to this DID did:web:example.com/?
The current specification does not have an answer to any of these questions, which can be summarized as: What is the canonical URL for a DID Web identifier, if any?
Therefore, if the proposal to use absolute URLs is rejected #52 ... then it raises the question around what a canonical DID Web ID is.
At present, there might be an assumption that there is a canonical URL for a DID Web ID, that is, these are canonical URLs for the examples above:
did:web:example.com
did:web:example.com/alice
If that's the case, then it holds that we have to have at least two special cases when determining if a DID Web ID is valid based on the DID Document we receive:
A DID for a domain DID Web ID is found at DOMAIN/.well-known/did.json but the id field in the DID Document MUST be did:web:DOMAIN.
A DID for a non-domain DID Web ID is found at DOMAIN/ARBITRARY_PATH/FILE.EXTENSION but the id field in the DID Document MUST be did:web:DOMAIN/ARBITRARY_PATH/FILE (without the extension).
Extra rules will be needed if we support re-directs, where you have to remember the initial HTTP GET you did AND there are security concerns if you're sent off of the original domain.
Are there any other special cases we need to consider?
The text was updated successfully, but these errors were encountered:
msporny
changed the title
Canonical URL for did:web id field
Canonical URL algorithm needed for did:web id field
Dec 17, 2021
Canonical URLs as described in RFC 6596 exist so one of several identical resources can be identified as representative of the entire group. The DID meets that need.
What is the canonical URL for a did:web
id
field. At present, one variation of the future looks like this:did:web:example.com -> HTTP GET https://example.com/.well-known/did.json
Then the question becomes, what should we expect in the
id
field for the resulting DID Document. One possibility is this:... but another possibility is this:
What if someone specified this as their DID:
did:web:example.com/alice.json
, but their DID Document states:Is this DID
did:web:example.com
equivalent to this DIDdid:web:example.com/
?The current specification does not have an answer to any of these questions, which can be summarized as: What is the canonical URL for a DID Web identifier, if any?
Therefore, if the proposal to use absolute URLs is rejected #52 ... then it raises the question around what a canonical DID Web ID is.
At present, there might be an assumption that there is a canonical URL for a DID Web ID, that is, these are canonical URLs for the examples above:
If that's the case, then it holds that we have to have at least two special cases when determining if a DID Web ID is valid based on the DID Document we receive:
id
field in the DID Document MUST bedid:web:DOMAIN
.id
field in the DID Document MUST bedid:web:DOMAIN/ARBITRARY_PATH/FILE
(without the extension).Are there any other special cases we need to consider?
The text was updated successfully, but these errors were encountered: