§11.6 signed responses... time to revisit?

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.

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.