1 of 10

Confused Deputy

A PROBLEM WITH DID URLS AND RESOLUTION

2 of 10

Agenda

  • What is a Confused Deputy
  • DID URL Parameter Injection
    • Spec Today
    • General Framing
    • Specific Example
  • Options
  • Discussion

3 of 10

What is a Confused Deputy

  • A trusted, highly privileged program (the "deputy") is tricked by a lower-privileged entity into misusing its authority.
    • Low-privilege software is configured to compromise a naïve high-privilege app
  • Example: Folder Access by Group
    • Permissions get changed independent of group membership

4 of 10

DID URL Parameter Injection

  • Spec Today*
    • Resolve(did/didUrl, options)
      • Dissent about passing path & query part directly
    • All query parameters become options
      • Client replaces query parameter values to override
    • #fragment not passed to resolve

5 of 10

DID URL Parameter Injection

  • Incoming DID URLs are commonly a low-privilege interface
    • DID URL author may be unknown
    • DID URL may be modified in transit
  • Manipulated DID URL parameters can compromise resolution when promoted without consideration.

6 of 10

DID URL Parameter Injection : DID Auth

  • Scenario
    • #key-1 is compromised May 1
    • rotation replaces #key-1 June 1
    • DID URL Author manipulates versionTime to trick DID Auth June 10
    • did:example:abc?versionTime=2026-05-10T17:00:00Z
  • Naïve resolver client passes all query parameters
    • It should have omitted versionTime
  • Resolver returns DID Doc with compromised key instead of current doc

{

"id": "did:example:abc",

"verificationMethod": [{

"id":"did:example:abc#key-1",

…}],

"authentication":

["did:example:abc#key-1"]}

}

​

7 of 10

DID URL Parameter Injection�Situations

  • DID Authentication
    • versionTime should be NOW()
    • versionId should be ignored
  • Validating DID authentication logs
    • versionTime should be time of authentication, per log
    • versionId should be ignored
  • VC issuance date mismatch with versionTime
    • If versionTime is different than ValidFrom, issuer could be using rotated keys while pretending to be published at a different date
    • VersionTime should based verifier's belief about issuance time

8 of 10

Only the resolution client knows which versionTime would be apprpriate.��Not the DID URL Author

versionTime should only be promoted explicitly, when client knows it is proper

​

9 of 10

Options Proposed

  • Resolve(did, options) Current Spec
    • All query parameters promoted into same set as client selected options
  • Resolve(didUrl, options) Current Resolution: Pass Full DID URL
    • Options override DID URL parameters
  • Resolve(did, options) No promotion
    • All options are client-selected (no promotion without explicit choice)
  • Resolve(did, options, parameters) Separate Bucket
    • Query parameters passed in separate value
    • Options override

10 of 10

Discussion

​