Allow existing relative DID document references

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

@@ -93,17 +93,23 @@ is authorized to speak for the publisher namespace.
 
 The normative profile specifies the detached JWS construction, protected
 headers, key representation, DID resolution, verification-method selection,
-and verification result. The important application choices are that `alg` is
-`ES256`, `kid` identifies one method under the exact issuer DID, and that method
-must be authorized by `assertionMethod`. Merely listing a key under
-`verificationMethod`, `authentication`, or `keyAgreement` is insufficient.
+and verification result. The signature uses `ES256`, and its absolute `kid`
+identifies one verification method under the exact issuer DID.
 
 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
 a separate profile rather than adding a marker without a demonstrated
 ambiguity.
 
+The selected key must be authorized by the DID document's `assertionMethod`
+relationship; merely listing it under `verificationMethod`, `authentication`,
+or `keyAgreement` is insufficient. To let publishers reuse existing DID
+documents, the profile accepts references using DID Core's relative-URL rules
+in place of the `did:web` method's absolute-only restriction. This preserves
+the publisher's existing key descriptions while retaining an absolute `kid`
+and exact issuer authorization.
+
 A Trust Manifest is verified only after the issuer, signature, signed subject,
 Catalog Entry, and artifact all satisfy their respective checks. Failure does
 not require rejecting the entire catalog, but the consumer cannot rely on the

docs/guides/adding-trust.md

@@ -188,7 +188,9 @@ The `signature` field holds a detached JWS (RFC 7515):
 
 The signature is computed over the Trust Manifest content using JCS (RFC 8785) canonicalization. The stored value is a detached compact JWS with a protected `alg` header of `ES256` and an absolute DID URL in `kid`, such as `did:web:acme-corp.com#release-signing-key`.
 
-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.
+The verifier retrieves the current DID document from `https://acme-corp.com/.well-known/did.json` and confirms that its `id` matches the issuer, `did:web:acme-corp.com`. Under the profile's [DID-document processing rules](https://agent-card.github.io/ai-catalog/spec/#did-document-resolution-and-key-selection), the document can retain relative method IDs and references. For example, a method's `id` and its reference in `assertionMethod` can both be `#release-signing-key`; resolving them against the document's DID produces the absolute `kid` shown above.
+
+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.
 
 Clients verifying signatures should:
 

specification/ai-catalog.md

@@ -985,18 +985,25 @@ DID or an external key document.
 #### DID Document Resolution and Key Selection
 
 The verifier MUST resolve `identity` according to the `did:web` method
-[[DIDWEB]] and process the result as a DID document according to DID Core
-[[DIDCORE]]. The resolution MUST satisfy the safe-fetching requirements in
-[Safe Fetching](#safe-fetching). Resolution fails under the `did:web` Publisher
-Profile if the DID document cannot be retrieved and validated or if its `id` is
-not exactly equal to `identity`.
+[[DIDWEB]], observing the safe-fetching requirements in
+[Safe Fetching](#safe-fetching), and process the result as a DID document
+according to DID Core [[DIDCORE]]. To accommodate existing DID documents,
+validation MUST accept relative DID URLs wherever DID Core permits them,
+including verification-method IDs and verification-relationship references.
+This rule takes precedence over the absolute-URL-only requirement in
+[[DIDWEB]] and applies whether validation is performed by the verifier or its
+resolver. Resolution fails if the document cannot be retrieved and validated
+or if its `id` is not exactly equal to `identity`.
 
 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`.
+reference a method in the top-level `verificationMethod` collection. Consumers
+MUST resolve relative DID URLs using DID Core's rules with the validated
+DID document's `id` as the base, never the HTTPS retrieval URL, and select
+exactly one verification method whose resolved `id` exactly equals the
+absolute `kid`. Selection is confined to the issuer's DID document; consumers
+MUST NOT retrieve an external verification method to satisfy `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