Minutes interim-2026-oauth-01: Mon 17:00
minutes-interim-2026-oauth-01-202605041700-00

OAuth 2.0 Attestation-Based Client Authentication

https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/

• Normal IETF Notewell
• We have two more interims,
  https://datatracker.ietf.org/wg/oauth/meetings/
  • May 11th Refresh Token and Authorization Expiration

Update since IETF 124, we're talking about the changes in -08 on
datatracker and the editors draft.

For -08, goal was to remove things that didn't fit anymore, and
restructuring for readability.

For -09, the current editors draft, made more readability changes, and
added Combined DPoP presentation mode, which we want feedback on.
Please review.

The goal of Combined DPoP is to simplify the PoP headers and only use
the DPoP header, instead of having two PoP headers, adds new
token_endpoint_auth_methods:

• attest_jwt_client_auth_dpop
• attest_jwt_client_auth

Feedback:

• Attester and Attestation terms are not clear. What is the frontend
  and the backend is not clear. Authorization server should put the
  characteristic of the application in the credential without
  disclosing the identity of the application.
  • Denis: Attestation acts as authentication as main mode, second
    mode where attestation is presented to the resource server is a
    statement at that point of time, not a statement about what
    was presented to the resource server
  • Denis: If you do the protocol for AS and RS, you can't use the
    same attestation
  • The RS could trust the AS has validated the attestation.
  • Transitive trust model is preferred by all
  • Paul: Client attester may put additional data into attestation
    for specific usecases, this is not handled by the draft. Should
    be profiled by a specific usecase.
  • Denis: Too vague for me, otherwise you're doubling the number of
    attestions.
  • Paul: Interesting use case, but already profiling the draft to a
    specific use-case. Draft is for use in many things, which are
    not wallets, this is an OAuth draft. TEEs and other specifics do
    not make sense for this draft.
  • Paul: This draft is higher level, and delegates the specifics of
    attestation to a service that can assert certain properties
    about the client.

Path forward

• Needs volunteers to review the document and the recent changes.

  • Call for reviewers received two people

• Need to resolve open issues on GitHub. 17 open, ~6 clear todos or
  ready for PR, some open questions

#56, #114: bind to other OAuth artefacts?

• Paul: For example the authorization code, CIBA, we want to find all
  auth artefacts that should be bound to this client instance.
• Filip: The one thing I'd like to preempt and to avoid another draft
  down the road, is how this interacts with other documents down the
  road, so things like PAR or CIBA or Device Code I think makes sense.
• Filip: We have an individal draft to describe how DPoP works with
  Device Flow because we didn't cover it in the original DPoP draft.
  Don't want to repeat that here as well.
• Filip: If we bind this to public clients, they become confidential
  clients. Codes are meant for a single device, not a group of
  clients.
• Paul: We could use some help here. There are a lot of OAuth
  extensions that need to be addressed.
• Brian: Let's be careful not to bind everything, and actually be
  intentional with what we do and do not bind. e.g., Auth Code is
  already covered via DPoP and PKCE.
• Should we do a short call for this topic?
• Rifaat: Maybe take it to the mailing list?

#61: Relationship to DCR? Should this explicitly be mentioned?

• After last update, we explicit said this may be used as client
  authentication, but it doesn't need to, you can use the header to
  make additional statements about the client instance.
• Will raise on mailing list, otherwise close the issue.
• Filip: What about if we swap DCR with CIMD? Would then we have any
  comments.
• Aaron: I was planning on connecting the dots at some point. Can be
  in this draft, separate draft, or in CIMD draft itself.
• Confirmed need to discuss as relates to CIMD, not DCR
• Pieter (in chat): Do it in CIMD rather than this draft
• Brian: I do think CIMD is useful to discuss, but it's not just a
  simple swap in. This work fits CIMD better than DCR. Agree with
  Filip but not in the framing.
• Aaron: I'd be happy to take a look

#107: Should we provide more guidance for other usecases

• This is about the way the client attestor gets information about the
  client instance, we deliberately left this open.
• In the use case of wallets or smartphones, there's native mobile
  attestation methods, but we left those out as other use-cases have
  other signals.
• Is it better to keep this out of scope, or should we give more
  guidance for client attestors?
• Want example of one more ecosystem other than wallets where it is
  worth it to give examples
• Denis: I want an example with digital wallets to prove out that the
  document works for that usecase
• Paul: I can show you some documentation for wallet providers in
  Europe (Germany?) and show how this is going to work with those
• Denis: I will provide some comments on the terminology used
• We aligned with RATS
• Denis: I believe the terminology in RATS is wrong
• Rifaat: Can you open issues there then?
• Paul in chat: There is a clear translation to RATS:
  https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-08#name-relation-to-rats
• Paul: Terminology varies, we may call it attestations or verifiable
  credentials, or something else. We could have a terminology section
  that explains this, and how this maps to the RATS ecosystem.
• Denis: Wants definitions to be improved, relationship to RATS
  questionable, will send comments to the mailing list.
• Christian: We decided to not have very concrete examples in this
  draft, or do you believe it should be in the draft?
• Paul: Mechanisms can evolve over time - e.g. Android SafetyNet was
  replaced by Google Play Integrity
• Pieter: if someone has a very specific usecase, creating a profile
  or some guidance document is better. Don't want to over-constrain
  the spec. Focus on the higher-level abstraction, protocol level,
  etc. See if someone else has the energy to create a profile.
• Tim C in chat: FWIW, we regret including platform-specific
  mechanisms in the WebAuthn spec.
• Emelia: In the document, don't describe a specific profile, but an
  abstract scenario instead? Non-normative examples of what someone
  could build here if they wanted to.
• Paul: So desribe what is happening in the world ecosystem without
  mentioning any names?
• Emelia: Yes, give step-by-step examples of how someone could
  implement an attestor if they wanted to & provides the foundations
  for what is going on in a high level
• Christian: We tried to do that in the introduction
• Paul: We can have a look to see if it makes sense to give some
  non-normative examples without actually mentioning specific
  technology. WebAuthn regrets mentioning platform-specific
  mechanisms.
• Brian: I would generally avoid providing speculative guidance around
  speculative use-cases

• Paul: Will write a short summary to mailing list to give others the
  opportunity
  #### #170: Does Client metadata make sense here? {#170-does-client-metadata-make-sense-here}

  This is about client's presenting information about
  client_attestation_signing_alg_values_supported and
  client_attestation_pop_signing_alg_values_supported.

• It was asked to provide metadata from the Client about the
  signatures that the attestor and client instance are providing.

• We think it makes sense to have metadata at the AS level, we were
  looking to reuse token_endpoint_auth_method for this.
• Client presents metadata as to which algorithm for the client
  attestation key, the client reads AS metadata and makes the
  negotiation.
• Does anyone see a usecase where it is beneficial for the client to
  publish what algorithms it supports?
• Aaron: Big change with CIMD - supports clients sharing what they can
  do with an AS they haven't seen before. Quickly ramping up adoption
  right now. Need to think through specifics but it would be
  reasonable for clients to do that.
• Paul: Can you look at the issue?
• Aaron: Yes
• Filip: You mentioned reusing the algs from AS metadata registry,
  specifically with CIMD. The AS may actually support multiple token
  endpoint auth methods. There could be HS/ES/RS, then for attestation
  you have a different set of algos. Makes the water kind of muddy to
  combine them all.
• Paul: Are other OAuth methods reusing the existing token endpoint
  ath methods? is there precedent for this?
• Filip: Both private key JWT and ??? are using this, but we can make
  a clear distinction there because now we will have two things using
  asymettric methods
• Christian: Would it be better to have a clear separation?
• Filip: Can offer my time to look at this in more detail
• Paul: On the AS, this is just verification. Does the AS have a
  codepath for a certain algo or not? I don't think it makes sense to
  differentiate between the algs supported for the attestation JWT and
  the attestation POP JWT? I don't think so. I can only think of
  separating these if there are different libraries supporting the
  underlying functionality. Very realistic for both to be backed by
  the same library. Open to hear more - if this makes sense to split
  we will split.
• Emelia: In the spec it mentions client attestation alg values
  supported & client attestation pop alg values supported. Based on
  this convo those should be the same values? Should we collapse those
  down?
• Paul: Yes - continuing that argument should we collapse down further
  to token_endpoint_auth_signing_alg_values_supported?
• Emelia: If they're just the same thing as the
  token_endpoint_auth_signing_alg_values_supported then we
  should just reuse them rather than defining new properties.