Define Client Challenge Type for Authorization Evidence

[ju-cu]

The appendix contains an example for a client challenge that provides evidence of the client having the authorization/mandate for the access that the requested access token implies/would imply. Define a formal type for that authorization evidence and propose a registration of the identifier for the Client Challenge Type registry.

[MohamadKhalilYossif]

Following up on the registry question. I would propose the first registered authorization_requirement.type be an action-authorization evidence type, since that is the case Appendix A already describes and the one with no home elsewhere in the WG. Client-provenance material is covered by attestation-based-client-auth and the attestation-authz-native-app draft. Evidence of human execution authority over a specific action is not.
Proposed identifier: action_authorization_evidence.
Semantics: the AS challenges a specific action by carrying a canonical representation (or digest) of the action parameters in the challenge. The client returns evidence that a human decision authorized that specific action. Four normative requirements define the type:
Binding. Evidence MUST be cryptographically bound to the canonical action parameters carried in the challenge. Evidence bound only to the session, the client, or the access token, but not to the action parameters, MUST be rejected. This is what separates the type from client attestation.
Freshness. Evidence MUST carry a freshness assertion evaluated against the intended execution time of the action, not the issuance time of any token or session. The type profile MUST define a maximum freshness window appropriate to the risk class.
Producer and verification. Evidence MUST be produced by a party distinct from the requesting client acting alone, and MUST be verifiable by the relying party against a key or authority held outside the requesting client's control. Evidence a client can both produce and verify under its own control is recorded, not proven, and does not satisfy this type. Without this property the evidence is forgeable by the same party it is meant to constrain.
Single use. Evidence MUST be bound to a single execution of the action and MUST NOT be replayable to a second execution. A relying party MUST reject re-presentation of the same evidence. This is distinct from the freshness window: fresh evidence can still be replayed within its window absent a single-use constraint.
In the framework: the challenge carries the action descriptor, challenge_session SHOULD be sender-bound per the binding discussion, and the response carries the evidence object.
The type is mechanism-neutral. A Verifiable Intent presentation as in Appendix A, the EMILIA protocol, and the device-bound action attestation in draft-yossif-psea can each serve as a producer without any change to the framework. Any producer that satisfies binding, freshness, producer/verification, and single-use requirements is conformant. I would keep the registry policy specification-required so additional producers can register cleanly.
Happy to turn this into Appendix A text in whatever shape works for your revision.

[ju-cu]

While I think, the action-authorization-evidence type is a good first type to define for the reasons you list, I do not agree with all of your proposed semantics.

Binding

Evidence MUST be cryptographically bound to the canonical action parameters carried in the challenge. Evidence bound only to the session, the client, or the access token, but not to the action parameters, MUST be rejected. This is what separates the type from client attestation.

I agree. Whatever the client presents as an evidence to resolve the challenge MUST be cryptographically bound to the challenge request. In the action-authorization-evidence use case, the challenge request from the authorization server conveys action parameters. A compliant evidence is bound to the challenge request and consequently to the action parameters as well.

Freshness

Evidence MUST carry a freshness assertion evaluated against the intended execution time of the action, not the issuance time of any token or session. The type profile MUST define a maximum freshness window appropriate to the risk class.

I'm not sure the authorization server can determine the "intended execution time of the action". Execution (e.g. token request) happens at the very moment and this is what the authorization server can validate the freshness of the presented evidence against. It is part of validating the evidence. Imo, the authorization server may validate a token or session as well, but that is separate or in addition to the evidence.

Risks are very individual and change over time. Therefore, I think you should not standardize risk classes for an evidence or derived mitigation controls such as freshness windows.

Producer and verification

Evidence MUST be produced by a party distinct from the requesting client acting alone, and MUST be verifiable by the relying party against a key or authority held outside the requesting client's control. Evidence a client can both produce and verify under its own control is recorded, not proven, and does not satisfy this type. Without this property the evidence is forgeable by the same party it is meant to constrain.

Disagree. Or, it depends what you mean by "evidence". Evidence for me is whatever the client sends to solve a challenge. The client produces at least (part of) the evidence (e.g., a proof-of-possession artifact). If you think of the evidence as a verifiable presentation where the client is the subject and holder, the client is the producer of that presentation and the evidence. If you think of the evidence as the underlying credential, the producer is a trusted party. I agree that the trusted party is crucial in that case.

Single use

Evidence MUST be bound to a single execution of the action and MUST NOT be replayable to a second execution. A relying party MUST reject re-presentation of the same evidence. This is distinct from the freshness window: fresh evidence can still be replayed within its window absent a single-use constraint.

The relying party is the authorization server. Agree on single use otherwise.

In the framework

The challenge carries the action descriptor, challenge_session SHOULD be sender-bound per the binding discussion, and the response carries the evidence object.

Yep!

The type is mechanism-neutral

Don't agree. I don't intend the authorization_requirement.type to be neutral. It is a pointer to the mechanism the client MUST use to fulfill the requirements. While there are some common requirements, such as the binding and freshness, I believe, each mechanism has different means of fulfilling them.