§ DID URL Resolution
-A did:tdw resolver SHOULD resolve DID URLs in addition to resolve simple
-DIDs, since failure to do so requires the resolver clients to implement their
-own DID URL resolution. The DID URL resolution process MUST support the
-resolution of DID URL fragments, DID URL query parameters, DID URL paths. The
-following sections document the specific DID URL patterns that all
-did:tdw implementations MUST implement.
+The did:tdw DID Method embraces the power and usefulness of DID URLs, along with the semantic simplicity
+of using them in a web-based DID method. Specifically, a did:tdw implementation
+MUST:
+
+- Resolve the
/whois DID URL path using a [[spec:LINKED-VP]] service, whether or not it exists in the did:tdw DIDDoc, returning a Verifiable Presentation, if published by the DID Controller, found at the web location whois.vp beside where the didlog.txt file is found.
+
+- For example,
did:tdw:{SCID}.example.com/whois returns the verifiable presentation https://{SCID}.example.com/.well-known/whois.vp
+
+
+- Resolve any
did:tdw DID URL using a [DID-CORE] relativeRef DID paraemeters, whether or not a supporting service exists in the did:tdw DIDDoc, returning the file, if published by the DID Controller, found at the web location relative to where the didlog.txt file is found.
+
+- For example,
did:tdw:{SCID}.example.com/governance/issuers.vc returns the file https://{SCID}.example.com/.well-known/governance/issuer.vc
+
+
+
+In both cases, a DID Controller MAY define services in the DIDDoc that override the default services that MUST be resolved by the did:tdw DID Method.
+The sections below formalize the services that exist by default in did:tdw and how a DID Controller can override them.
§ whois LinkedVP Service
-This service enables those that receive a did:tdw DID to retrieve and verify a
-verifiable presentation (and embedded Verifiable Credentials) the DID controller
-has decided to publish about itself. The intention is that anyone interested in
-a particular did:tdw DID can see if there is a #whois Verifiable
-Presentation, and if so, if it contains any useful (to the resolver) Verifiable
-Credentials that might help in learning more about who is the controller of the
-DID and if they should be trusted. It is up to the DID Controller to decide to
-publish a whois verifiable presentation and if so, which Verifiable
-Credentials to put into the verifiable presentation.
-A did:tdw DIDDoc SHOULD include a whois service endpoint with the
-following definition based on the Linked Verifiable
-Presentation
+The #whois service enables those that receive a did:tdw DID to retrieve and
+verify a VCDM Presentation (and embedded
+VCDM Credentials) the DID Controller has decided to
+publish about itself. The intention is that anyone interested in a particular
+did:tdw DID can resolve the a <did>/whois DID URL, and if returned, if it
+contains any useful (to the resolver) Verifiable Credentials that might help in
+learning more about who is the controller of the DID and if they should be
+trusted. It is up to the DID Controller to decide to publish a whois.vp
+verifiable presentation and if so, which verifiable credentials to put into the
+verifiable presentation.
+did:tdw DIDs automatically supports a #whois service endpoint with the
+following definition based on the Linked VP Specification, with the serviceEndpoint
+matching the did:tdw DID-to-HTTPS DIDDoc transformation and didlog.txt
+changed to whois.vp.
{
+ "@context": "https://identity.foundation/linked-vp/contexts/v1",
"id": `#whois`,
"type": "LinkedVerifiablePresentation",
"serviceEndpoint": `https:
}
-A DID Controller that adds to their DIDDoc a did:tdw service with the
-"id": "#whois" MUST have a serviceEndpoint that MUST be an HTTP URL
-that SHOULD be found in the same web location as the did:tdw DID, and that MUST return a Verifiable Presentation.
-To resolve the DID URL <did:tdw DID>#whois, the resolver MUST:
+A DID Controller MAY explicitly add to their DIDDoc a did:tdw service with the
+"id": "#whois". Such an entry MUST override the implicit service above.
+To resolve the DID URL <did:tdw DID>/whois, the resolver MUST:
- Resolve the given
did:tdw DID by retrieving, processing, and verifying the DID log for the did:tdw as defined in this specification.
-- Find the DIDDoc
service with the id #whois, if any.
+ - Find the DIDDoc
service with the id #whois, if any, or use the implicit service (above).
+- Resolve the
serviceEndpoint URL, if possible, and return the document found.
-- If none, return an error
404 Not Found.
+- If the
serviceEndpoint URL can’t be resolved by the resolver (such as if the URL protocol is not supported by the resolver), the error Error XXX: YYY MUST be returned.
+- If the file at the defined
serviceEndpoint is not found, return Error 404: Not Found MUST be returned.
-- Resolve the
serviceEndpoint HTTP address, and return the document found.
§ The whois Use Case
This section is informative.
-The following is a use case for the whois capability. Consider an example of the
-did:tdw controller being an educational institution that issues “degree”
-verifiable credentials to its graduate students. A graduate from the school
-submits as part of their job application to a company a Verifiable derived from the verifiable credential they received from the
-school. The company receiving the presentation can verify the cryptography of
-the presentation, but can they trust the the usefulness of a degree from the school that issued the verifiable
-credential? If the school issued the verifiable credential using its did:tdw
-DID, the company can resolve the DID. It can also resolve the DID’s #whois DID
-URL where it might find VCs from issuers it trusts with the did:tdw DID as
-the subject. For example:
+The following is a use case for the whois capability. Consider an example of the did:tdw controller being an educational institution that issues “degree” verifiable credentials to its graduate students. A graduate from the school submits as part of their job application to a company a Verifiable Presentation derived from the verifiable credential they received from the school. The company receiving the presentation can verify the cryptography of the presentation, but can they trust the the usefulness of a degree from the school that issued the verifiable credential? If the school issued the verifiable credential using its did:tdw DID, the company can resolve the DID. It can also resolve the DID’s /whois DID URL Path where it might find VCs from issuers it trusts with the did:tdw DID as the subject. For example:
-- A verifiable credential issued by the Legal Entity Registrar for the
-jurisdiction in which the school is headquartered.
+
- A verifiable credential issued by the Legal Entity Registrar for the jurisdiction in which the school is headquartered.
-- Since the company knows about the Legal Entity Registrar, they can automate
-this lookup to get more information about the school from the verifiable
-credential – its legal name, when it was registered, contact information,
-etc.
+- Since the company knows about the Legal Entity Registrar, they can automate this lookup to get more information about the school from the verifiable credential – its legal name, when it was registered, contact information, etc.
-- A verifiable credential issued by the “Association of Colleges and
-Universities” for the jurisdiction of the school.
+
- A verifiable credential issued by the “Association of Colleges and Universities” for the jurisdiction of the school.
-- Perhaps the company does not know about the Association for that
-jurisdiction. The company can repeat the
whois resolution process for the
-issuer of that credential. The company might (for example), resolve and
-verify the did:tdw DID for the Association, and then resolve the #whois
-DID URL to find a verifiable credential issued by the government of the
-jurisdiction. The company recognizes and trusts that government’s authority,
-and so can decide to recognize and trust the Association.
+- Perhaps the company does not know about the Association for that jurisdiction. The company can repeat the
whois resolution process for the issuer of that credential. The company might (for example), resolve and verify the did:tdw DID for the Association, and then resolve the /whois DID URL to find a verifiable credential issued by the government of the jurisdiction. The company recognizes and trusts that government’s authority, and so can decide to recognize and trust the Association.
-- A verifiable credential issued by US News magazine about the school’s
-placement on the US News Rankings of Colleges and Universities.
+- A verifiable credential issued by US News magazine about the school’s placement on the US News Rankings of Colleges and Universities.
-Such checks can all be done with a handful of HTTPS requests and the processing
-of the DIDs and verifiable presentations. The result is an efficient,
-verifiable, credential-based, decentralized, multi-domain trust registry.
+Such checks can all be done with a handful of HTTPS requests and the processing of the DIDs and verifiable presentations. The result is an efficient, verifiable, credential-based, decentralized, multi-domain trust registry.
§ DID URL Path Resolution Service
+The automatic resolution of did:tdw DID URL paths follows the [DID-CORE] relativeRef specification, as follows:
+
+- a DID path, such as example 2 in [section 3.2 DID URL Syntax] gives the example:
did:example:123456/resume.pdf
+- In turn, that can be treated as the following, as shown in example 8 in the same section:
did:example:123456?service=files&relativeRef=/resume.pdf
+- The
#files service defined below then defines the serviceEndpoint for the relativeRef.
+
+- For
did:tdw, that service is implicitly defined, with the
+serviceEndpoint matching the did:tdw DID-to-HTTPS DIDDoc transformation
+and didlog.txt replaced by the DID URL Path.
+
+
+
+Thus, the implicit service for DID did:tdw:example.com:dids:<scid> is:
+{
+ "id": `#files`,
+ "type": "relativeRef",
+ "serviceEndpoint": `https:
+}
+
+A DID Controller MAY explicitly add to their DIDDoc a service with the
+"id": "#files". Such an entry MUST override the implicit service defined above.
+To resolve the DID URL <did:tdw DID>/path/to/file, the resolver MUST:
+
+- Resolve the given
did:tdw DID by retrieving, processing, and verifying the DID log for the did:tdw as defined in this specification.
+- Find the DIDDoc
service with the id #files, if any, or use the implicit service (above).
+- Resolve the
serviceEndpoint URL with the DID URL Path appended, if possible, and return the document found at that location.
+
+- If the
serviceEndpoint URL can’t be resolved by the resolver (such as if the URL protocol is not supported by the resolver), the error Error XXX: YYY MUST be returned.
+- If the file at the path appended to the defined
serviceEndpoint is not found, the error Error 404: Not Found MUST be returned.
+
+
+
§ Implementors Guide
§ Using Pre-Rotation Keys
Using Pre-Rotation Keys
Best practices are that the DID Controller generates the active key for the DIDDoc where it can be used for “production” purposes, and generates the “next key” in an isolated location from production
-TODOComplete this section, covering guidance on where to hold pre-rotation keys and post-quantum key rotations.
+
TODOComplete this section, covering guidance on where to hold pre-rotation keys and post-quantum key rotations.
§ Definitions
@@ -960,8 +988,8 @@ § F
["xkuu1nwynw5ymfv4f1np2xbmg21k4vn1rrvg3ngpdmx482c2ce20",1,"2024-04-03T03:47:51Z",{"method":"did:tdw:1","scid":"ke465curdwjzrrp5x5ut92te"},{"value":{"@context":["https://www.w3.org/ns/did/v1","https://w3id.org/security/multikey/v1"],"id":"did:tdw:example.com:ke465curdwjzrrp5x5ut92te","controller":"did:tdw:example.com:ke465curdwjzrrp5x5ut92te","authentication":["did:tdw:example.com:ke465curdwjzrrp5x5ut92te#FFhXVfsx"],"assertionMethod":["did:tdw:example.com:ke465curdwjzrrp5x5ut92te#CPixwJ8x"],"verificationMethod":[{"id":"did:tdw:example.com:ke465curdwjzrrp5x5ut92te#FFhXVfsx","controller":"did:tdw:example.com:ke465curdwjzrrp5x5ut92te","type":"Multikey","publicKeyMultibase":"z6MkkXKMSiE7mXvGcR2KUpeJXwT7MPXZSBC6HZw9FFhXVfsx"},{"id":"did:tdw:example.com:ke465curdwjzrrp5x5ut92te#CPixwJ8x","controller":"did:tdw:example.com:ke465curdwjzrrp5x5ut92te","type":"Multikey","publicKeyMultibase":"z6Mkg8FdKNRt4NLXm5YSUZVGWzK8vvS3DJByxAqHCPixwJ8x"}]}},{"type":"DataIntegrityProof","created":"2024-04-03T03:47:51Z","verificationMethod":"did:tdw:example.com:ke465curdwjzrrp5x5ut92te#FFhXVfsx","cryptosuite":"eddsa-2022","proofPurpose":"authentication","challenge":"xkuu1nwynw5ymfv4f1np2xbmg21k4vn1rrvg3ngpdmx482c2ce20","proofValue":"zK7pASjX3ou7t2bDuU43sWzG4E8B3TTDFgmY8AiFLahPaLzXn4fGrXksKbWr6o2RLr7rCTT2VRAgc8F9LQKLEJkg"}]
§ did:web Version of DIDDoc
-
As noted in the publishing a parallel did:web
-version(#publishing-a-parallel-didweb-did) of the DIDDoc section of this
+
As noted in the publishing a parallel did:web
+version of the DIDDoc section of this
specification, here is what the did:web DIDDoc looks like for the did:tdw
above.
{
@@ -1309,10 +1337,10 @@
+ 