§11.6 signed responses... time to revisit?

Open
  • Is something wrong?
#656 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Domain
authorization, cryptography, security

Research direction

Start by reading §11.6 of the Authorization API specification, then compare its signed-response text with the ARAP references in §6 and §21.1.4 and the conformance work in #611. Done would require a decided direction on whether an optional profile is needed for verification beyond the immediate PEP, with its scope and relationship to existing artifacts recorded.

Written by the indexing model from the issue text.

Description

authorization-api

In 2025, this group discussed signing authorization responses (#55). The discussion on the 21 August 2025 call went against adding a signing mechanism, and what was adopted instead was #361 ... the advisory text now at §11.6, which permits a PDP to sign its authorization response and specifies no format. That text went through public review and was approved with the Final Specification in January 2026. I read that as a settled outcome, not unfinished work.

I would like to ask about one case that has become more visible since...

The base evaluation exchange is a PDP and a PEP that already trust each other, and §11.4 states that relationship directly; for that topology a signature adds little beyond what transport protection already gives. The case where it might matter is narrower: a party other than the immediate PEP needing to verify a decision independently of that PEP.

That topology already exists inside the family.

ARAP, added in June 2026, exists because an independent Access Request Service must verify PDP-issued state without shared storage. It therefore requires a PDP that issues signed values to publish a jwks_uri in PDP metadata (§6), registers that member in the PDP Metadata Registry (§23.1), and defines a deterministic digest over the evaluated subject, resource, action and context that independent implementations are required to compute identically (§21.1.4), with conformance vectors in progress in #611. I am not arguing those artifacts should be reused as they stand, since they are scoped to ARAP's own workflow; only that if such cases were judged to warrant a profile, some of the machinery already exists.

It also appears outside the family.

The Logius Authorization Decision Log (draft, 24 August 2026) builds its log record on the AuthZEN information model, is aimed at accountability within and across organisations, and requires the record interface to be consistent across organisations — while its §2.2 lists ensuring integrity and non-repudiation among the things the specification does not define, and §5.3 offers hash chains and periodic sealing only as non-normative suggestions. That is one concrete use case, not evidence of broader demand, and I offer it as a data point.

So, just one question:

Given those developments, is there now interest in defining the optional signed-response profile contemplated by §11.6 for cases where a PDP decision needs to be verified beyond the immediate PEP, or does the group still consider those cases deployment-specific?

Disclosure: I build a product in this space (an authorization gateway that retains signed decision records), so I have an interest in the outcome.

Dominant language
TypeScript
Stars
170
Forks
46
Avg merge
18h 5m
Merged PRs (30d)
43

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openid/authzen

All issues in openid/authzen

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.