Allow existing relative DID document references

adr/0027-did-web-entry-signature-profile.md

@@ -98,6 +98,16 @@ and verification result. The important application choices are that `alg` is
 must be authorized by `assertionMethod`. Merely listing a key under
 `verificationMethod`, `authentication`, or `keyAgreement` is insufficient.
 
+Existing DID documents can use relative method IDs and verification-relationship
+references such as `#release-signing-key`. The profile explicitly applies DID
+Core's relative-URL rules to those documents despite did:web's absolute-only
+requirement, so adopting AI Catalog does not require publishers to rewrite
+otherwise usable DID documents. References resolve against the validated issuer
+DID, never the HTTPS retrieval URL. The signature's `kid` stays absolute, and
+key selection must remain unambiguous within the issuer's document. Resolver
+validation must honor the exception before returning the document to the
+verifier; resolving shorthand after a resolver has rejected it is insufficient.
+
 No `typ` header is required. The signature appears in a specifically defined
 Trust Manifest field, so the containing data model supplies the application
 context. A future need for cross-protocol token separation can be addressed by

docs/guides/adding-trust.md

@@ -190,6 +190,17 @@ The signature is computed over the Trust Manifest content using JCS (RFC 8785) c
 
 The verifier retrieves the current DID document from `https://acme-corp.com/.well-known/did.json`. The key selected by `kid` must be an ES256 P-256 JWK authorized by the DID document's `assertionMethod` relationship. A key listed only for authentication or key agreement cannot sign an AI Catalog Trust Manifest.
 
+An existing DID document can use shorthand for its key references. For example,
+a document with `id` equal to `did:web:acme-corp.com` can give a verification
+method the `id` `#release-signing-key` and list `#release-signing-key` in
+`assertionMethod`. Both resolve to the absolute signature `kid`
+`did:web:acme-corp.com#release-signing-key`. Publishers do not need to expand
+these DID Core references to adopt this profile. Verifiers, including their
+DID resolvers, must support the profile's relative-reference exception to
+did:web's absolute-only rule, using the document's validated DID as the base.
+References in other verification relationships may also use shorthand; those
+relationships do not authorize a Trust Manifest signature.
+
 Clients verifying signatures should:
 
 1. Extract the `signature` field and remove it from the object

specification/ai-catalog.md

@@ -991,12 +991,28 @@ The verifier MUST resolve `identity` according to the `did:web` method
 Profile if the DID document cannot be retrieved and validated or if its `id` is
 not exactly equal to `identity`.
 
+For compatibility with existing DID documents, this profile permits relative
+DID URLs wherever DID Core permits them, including verification-method IDs
+and references in verification relationships. For these values, DID Core's
+relative-DID-URL rules take precedence over the absolute-URL-only requirement
+in [[DIDWEB]]. Consumers MUST NOT reject an otherwise valid DID document solely
+because it contains such relative DID URLs. This exception applies during DID
+document validation, including validation performed by a resolver.
+
+Consumers MUST resolve these relative DID URLs against the DID document's
+`id`, after confirming that it exactly equals `identity`, using the rules in
+DID Core. The HTTPS retrieval URL MUST NOT be used as the base. This does not
+relax the absolute `kid` requirement or the exact issuer and controller
+requirements. Selection remains confined to verification methods in the
+issuer's DID document; consumers MUST NOT retrieve an external verification
+method to satisfy `kid`.
+
 The verification method selected by `kid` MUST be authorized by the DID
 document's `assertionMethod` verification relationship. An
 `assertionMethod` entry can contain the verification method directly or can
 reference a method in the top-level `verificationMethod` collection. After
 resolving relative DID URLs as defined by DID Core, the verifier MUST select
-exactly one verification method whose `id` exactly equals `kid`.
+exactly one verification method whose resolved `id` exactly equals `kid`.
 
 A key's presence in the top-level `verificationMethod` collection does not by
 itself authorize the key to sign a Trust Manifest. A key used only for another