Skip to content

bind the proof to the full request target #28

@Hendler

Description

@Hendler

I maintain JACS and am reviewing the DIDWba initial-request authentication flow in the tentative protocol draft.

Relevant section:

Problem

The current draft describes a proof over:

  • nonce
  • timestamp
  • service
  • did

That is a useful start, but it does not appear to bind the proof to the full request target.

As written, a valid proof may be replayable across multiple endpoints on the same service within the allowed freshness window if:

  • permissions are broad
  • the same service host is used
  • the server does not separately bind the proof to path/method/body

In particular, the proof does not appear to cover:

  • HTTP method
  • request path
  • query string
  • body digest / content hash

Request

Please strengthen the authentication proof so that it is bound to the actual request being authorized.

Proposed change

At minimum, include these fields in the signed canonical input:

  • method
  • service
  • path
  • timestamp
  • nonce
  • did
  • verification_method

For requests with bodies, also include:

  • content_digest (or equivalent body hash)

Optionally include:

  • canonical query representation

Why this matters

This reduces the risk of:

  • replay across endpoints on the same origin
  • body substitution for POST/PUT/PATCH-style requests
  • ambiguity about what exactly the client authorized

It also makes the scheme easier to implement safely in existing middleware, because the verifier can construct a canonical request object rather than verifying a detached identity proof with no request binding.

Alternative direction

If the group wants to keep a custom scheme, it would still help to define a canonical “request proof” object explicitly.

Alternatively, the group could consider whether alignment with existing HTTP request-signing conventions would reduce ambiguity and implementation risk.

Specific question

Would the group be open to changing the signed input from:

  • identity + freshness only

to:

  • identity + freshness + request binding

before more implementations build against the current shape?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions