Skip to content

fix using use_attestation_challenge error parameter code for missing … #132

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion draft-ietf-oauth-attestation-based-client-auth.md
Original file line number Diff line number Diff line change
Expand Up @@ -325,7 +325,7 @@ To validate an HTTP request which contains the client attestation headers, the r
2. There is precisely one OAuth-Client-Attestation-PoP HTTP request header field, where its value is a single well-formed JWT conforming to the syntax outlined in [](#client-attestation-pop-jwt).
3. The signature of the Client Attestation PoP JWT obtained from the OAuth-Client-Attestation-PoP HTTP header verifies with the Client Instance Key contained in the `cnf` claim of the Client Attestation JWT obtained from the OAuth-Client-Attestation HTTP header.

An error parameter according to Section 3 of {{RFC6750}} SHOULD be included to indicate why a request was declined. If the Client Attestation is absent or not using an expected server-provided challenge, the value `use_attestation_challenge` can be used to indicate that an attestation with a server-provided challenge was expected. If the attestation and proof of possession was present but could not be successfully verified, the value `invalid_client_attestation` is used.
An error parameter according to Section 3 of {{RFC6750}} SHOULD be included to indicate why a request was declined. If the Client Attestation is not using an expected server-provided challenge, the value `use_attestation_challenge` can be used to indicate that an attestation with a server-provided challenge was expected. If the attestation and proof of possession was present but could not be successfully verified, the value `invalid_client_attestation` is used.
Copy link
Member

@panva panva Jul 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
An error parameter according to Section 3 of {{RFC6750}} SHOULD be included to indicate why a request was declined. If the Client Attestation is not using an expected server-provided challenge, the value `use_attestation_challenge` can be used to indicate that an attestation with a server-provided challenge was expected. If the attestation and proof of possession was present but could not be successfully verified, the value `invalid_client_attestation` is used.
When validation errors are encountered the following error codes are defined for use in either Authorization Server authenticated endpoint error responses or Resource Server error responses.
- `use_attestation_challenge` MUST be used when the Client Attestation PoP JWT is not using an expected server-provided challenge. When used this error code MUST be accompanied by the `OAuth-Client-Attestation-Challenge` HTTP header field parameter (as described in [](#challenge-header)).
- `invalid_client_attestation` MAY be used if the attestation or its proof of possession could not be successfully verified.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And change

## Providing Challenges on Previous Responses

to

## Providing Challenges on Previous Responses {#challenge-header}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am making this suggestion because a) this section is referenced from Token and PAR endpoint sections and linking 6750 error handling is invalid.

Making use_attestation_challenge a MUST use when challenge validations fail just makes sense and having to have it accompanied by OAuth-Client-Attestation-Challenge as well. I don't mind defining invalid_client_attestation but only as a MAY because on the AS authenticated endpoints the convention is already invalid_client for client authentication failures.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've opened #135 as an alternative to this PR with all suggestions applied.


## Client Attestation at the Token Endpoint {#token-endpoint}

Expand Down Expand Up @@ -625,6 +625,8 @@ This section requests registration of the following scheme in the "Hypertext Tra
--- back

# Document History
-07
* do not use error response `use_attestation_challenge` on absent client attestation

-06

Expand Down Expand Up @@ -692,6 +694,7 @@ Filip Skokan,
Francesco Marino,
Guiseppe De Marco,
Kristina Yasuda,
Micha Kraus,
Michael B. Jones,
Takahiko Kawasaki
and
Expand Down