Skip to content

Allow existing relative DID document references - #13

Closed
jonathanhefner wants to merge 2 commits into
agent/define-did-web-entry-signaturesfrom
agent/allow-relative-did-references
Closed

Allow existing relative DID document references#13
jonathanhefner wants to merge 2 commits into
agent/define-did-web-entry-signaturesfrom
agent/allow-relative-did-references

Conversation

@jonathanhefner

Copy link
Copy Markdown
Owner

The did:web publisher profile already describes resolving relative DID URLs, but also requires did:web document validation, whose absolute-only rule can reject those documents before key selection. This change makes the compatibility exception explicit so publishers can reuse DID documents containing references such as #release-signing-key.

DID Core's relative-reference rules take precedence wherever they permit shorthand, including during resolver validation. References resolve against the validated issuer DID, never the HTTPS retrieval URL. The signature's kid remains absolute, and the existing issuer, controller, assertion authorization, and in-document key-selection requirements remain in place. ADR-0027 records the adoption rationale, and the trust guide illustrates the matching references.

This PR targets agent/define-did-web-entry-signatures for review alongside upstream Agent-Card#110. It does not choose a verification-method type.

Validation:

  • Specification HTML build passed.
  • Strict MkDocs build passed.
  • Nine relevant tests passed in the separate throwaway SDK experiment, covering relative and inline methods and invalid DID authorization. These are prototype tests, not a test suite added to this repository or proof of compatibility with every resolver.
  • git diff --check passed.

References: DID Core relative DID URLs, did:web document-handling rules.

AI usage disclosure: This PR was prepared with AI assistance under the requester's direction for human review.

Make the did:web publisher profile explicitly accept relative DID URLs
wherever DID Core permits them, including during resolver validation.
Publishers can reuse existing DID documents while Trust Manifest
signatures retain absolute `kid` values.

Resolve references against the validated issuer DID, retain exact issuer
and controller checks, and confine key selection to that DID document.
Explain the did:web exception in ADR-0027 and illustrate it in the trust
guide.
Comment thread adr/0027-did-web-entry-signature-profile.md Outdated
Comment thread adr/0027-did-web-entry-signature-profile.md Outdated
Comment thread docs/guides/adding-trust.md Outdated
Group signature-header rationale and key-selection rationale in the ADR,
explain shorthand within the guide retrieval flow, and express the
normative exception alongside document validation and key selection.

Remove duplicated procedure and constraints, match unwrapped guide
prose, and format `did:web` consistently. Preserve the compatibility
rule and issuer authorization requirements.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant