IETF122 - OAuth WG Agenda - Tuesday (120 min)

Note takers: Dean/Hannes

Chairs update – Rifaat/Hannes (10 min)

https://datatracker.ietf.org/meeting/122/materials/slides-122-oauth-chairs-slides-01

Rifaat welcomes the group and goes through his slides.

• Note well has been well noted.

• Published:

  • RFC9700 Security BCP
  • RFC9701 - JWT Response for Token Introspection

• Editor Queue:

  • Protected resource metadata

• Publication Requested:

  • Browser Based Apps - IESG Telecthat on 24 April 2025
  • SD-JWT

• Notes from Chairs

  • OAuth Sec Workshop - participation encouraged, not an IETF event
  • WGLC - can be used to push people to review docs. WGLC does not
    mean a doc is complete, it can move back into the WG if needed

Token Status List - Paul (20 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/
https://datatracker.ietf.org/meeting/122/materials/slides-122-oauth-token-status-list-00

• Paul and Christian go through their slide deck describing the
  changes to the draft.

• Scalable revocation mechanism w/ similar properties to a CRL but
  uses JSON/CBOR encoding

• Usable by diffent kinds of tokens - SD-JWT, ISO 18013-5 mDoc
• Named in the EIDAS ARF1.4, on the roadmap as the primary revocation
  mechanism

• Extension point registered in IANA for status mechanism

• Architecture

  • Status list describes the status of many referenced tokens that
    were issued by a service
  • cryptographically protected
  • When the referenced token is presented by the holder to a
    relying party, the relying party can check the status in the
    status list

• Key changes since interim on 25/1/2025

  • added recommendations for key resolution & trust management
  • added extended key usage extension for x509
  • added more test vectors
  • added new privacy considerations for "suspend" status
  • fixed naming confusion in -08/-09 for status list definitions
  • breaking change to fix cwt type value to full media type

• Remaining issue - status list for x.509 certs

  • current position: Do not include in the draft, but do not
    prevent its usage
  • a separate draft could occur in a different WG if needed
  • Hannes: Have the authors spoken to LAMPS?
  • Christian/Paul - Dennis (??) reached out to LAMPS editors, no
    response.
  • Hannes: I reached out early last year and no interest was there.
    LAMPS is the right community for this extension
  • Rifaat: extension is likely out of scope for OAuth - open for
    discussion
  • Brian Campbell - out of scope in his opinion
  • Pieter Kasselman - concurs with Brian
  • Rifaat - no argument for this in the room.
  • Chairs: Work with LAMPS, out of scope here
  • Christian: LAMPS or ETSI in the EU ecosystem are possible places
    to work on the extension
  • Orie: Do you plan to register a CoAP content format for the COSE
    /CWT related media type?
    (It is smaller. Just something to consider)
  • Christian - we didn't intend to register a content format, space
    savings is immaterial
  • Henk - content format registration is a no brainer, low cost,
    high benefit

• Rifaat - we should be able to start a WGLC.

• Christian: New size comparison PR added yesterday, next step is to
  ask for WGLC
• Rifaat - reasonable to do WGLC

Attestation-based Client Authentication - Paul (15 min)

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

• Christian

  • Motivation - backend vs. frontend channel authN

    • classic OAuth model requires the backend channel
    • wallets use the front channel, e.g. OpenID4VCI
    • need to establish a mechanism for backend attested client
      authN through the front channel
    • establish assurance about security of the client

  • Architecture:

    • client backend attests a client instance w/ Client Instance
      Key and provide a key-bound client attestation WT
    • security checks are undefined - out of scope
    • client instance generates PoP used to authenticate to the AS

  • Changes since 121

    • added a nonce endpoint
    • improved intro
    • there are still terminology challenges with RATS on attester
      terminology

• Paul

  • New intro to explain rationale

    • the draft is focused on client authentication, not key
      attestation
    • description for how platform native apps can attest further
      properties

  • Nonce fetching

    • needed a mechanism for preventing replay attacks
    • freshness guaranteed by providing a nonce from the AS
    • client instance needs to be able to explicitly request a
      nonce
    • final option uses HTTP OPTIONS to request the nonce from AS
      or RS
    • new header attestation-nonce-request
    • HTTP response has an empty body, nonce in the headers
      attestation-nonce

  • Filip - we don't want to define an AS error for not having the
    nonce. Needs text that clients must support this mechanism.
    Document doesn't identify whether the nonce is for freshness or
    one time use

    • Paul - we can more clearly describe

  • Filip - OPTIONS is similar to CORS preflight. From a browser
    perspective this could be 4 http requests

    • Christian: Initially looked at header fields, Brian C.
      proposed to use HEAD instead of OPTION.
    • Filip: This may be cumbersome to hook into CORS handlers to
      add this

  • Brian - idea for OPTIONS was to avoid a new endpoint to get
    this, didn't consider preflight. Hard time imagining this in a
    JS client. Need to consider this more

  • Brian - worried about metadata endpoint, premature optimization?
    Adds a list of URLs to check before you make the call

    • Rifaat - needs more consideration
    • Brian - yes

  • Filip - More on CORS. If this is deployed in a browser the CORS
    implementation will be there regardless.

  • Hannes - this is more generic than the wallet use case
  • Henk - client needs nonce, requires nonce for request, nonce
    must be fresh, nonce used to prevent replay.
  • Paul - this is correct
  • Henk - the client cannot create a nonce
  • Paul - from the server only
  • Rifaat - take comments to mailing list due to time
  • Paul - authZ server signals via metadata that it offers nonces
  • Paul - need more time, nonces are last major feature to work on
  • Hannes - Reviewers? Pieter, Tim, Monty
  • Pieter - should we wait for nonces to be resolved?
  • Hannes - no, review current draft in the next 3 weeks

OAuth 2.1 - Aaron (25 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/

• Aaron

  • OAuth 2.1 is supposed to clean up the messiness of OAuth
  • capture the best practices of OAuth 2.0, consolidate content
    from many docs
  • no new behavior defined in 2.1!

  • Docs that this was waiting on are published as RFC9700 and
    browser based apps, which is nearing publication

    • IESG telechat on April 24 for browser based apps

  • Treating the doc as "done" as an editor

    • Rifaat - expect reviews
    • Aaron recognizes that reviews will induce further changes.

  • Changes since -11

    • added DPoP and Step Up Auth
    • new language on client registration
    • non-normative change for client_id moved to individual
      grant types
    • added bEaReR as case insensitive example for clarity
    • Justin: Thank you. <3

  • Handful of open issues to close

    • Issue 201 - should 2.1 be updated to be less strict about
      HTTP binding? RFC9200 defined a non-HTTP transport for oauth
    • Can we be less restrictive? u
    • Discussion
      • Justin - I don't like this. ACE has to take parts of
        OAuth and apply it to a specific space, had to define
        the specific connections. Hard to draw this out into the
        core OAuth specs, likely to miss the mark, likely to be
        unbound. Written as an HTTP based protocol, that was a
        strength. Keep this as HTTP based.
      • Brian - agrees with Justin. These changes would be
        antithetical to the simplification goals.
      • Mike Jones - Agree, keep it as is using HTTP transports
      • Aaron - strong agreement, we'll keep it as HTTP

  • Aaron: minor issues to still review, hope to go to WGLC before
    IETF123

OAuth First-Party Apps - Aaron (20 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-first-party-apps/

• Aaron

  • Only use this draft if you know what you're doing...
  • devs want a better UX
  • devs are finding workarounds to avoid RFC8252
  • First Party Apps enable the authz code flow through the native
    app UX
  • the draft mirrors the authorization code flow, adds new bits at
    the beginning/end

  • new endpoint

    • accepts POST requests from client to start and continue
      authZ
    • response is auth code, error, redirect_to_web, or custom
    • additional user interactions can happen at custom endpoints
      if desired (e.g. passkey authN)

  • some implementations exist

    • WSO2
    • MSFT
    • Yahoo
    • Auth0
    • Keycloak

  • Tim started PR for passkey support, needs to be pulled into a
    separate doc

    • Rifaat - why?
    • Aaron - not everyone wants to use passkeys

  • Open Questions:

    • should this be defined as a PAR extension?

      • will this affect implementation plans?
      • pros/cons?

    • Aaron says the draft is 80% of the way to PAR with slightly
      different names...

    • main difference is the redirect_to_web is the exception
      case, PAR this is the happy path
    • if extending PAR, this error goes away in favor of PAR
      request_uri
    • Aaron reviews pros/cons (see slide 10)
    • Brian - Not just the happy path for PAR, the only path.
      Thinks of PAR as a distinct mechanism to transport an authZ
      request. Conflating the two concerns me. Against pulling
      them together.
    • Justin - disagree with Brian. If the interest is FiPA,
      you're probably not interested in PAR. Both are intent
      registration. Defines a new happy path in paralell to the
      PAR happy path. If response includes a request URI, no need
      to start over again, then this is a diff PAR-like response
      to solve a different use case. Different processing on the
      server side between FiPA and PAR.
    • Nick Watson - agrees with Justin, this is intent
      registration.
    • Filip - implementation reuses parts from the AS already.
      Don't think this makes sense to make this as an extension of
      PAR. Doesn't see value in a PAR extension.
    • Matthieu Sieben - adding this as a PAR extension makes a lot
      of sense.
    • Brian - Doubling down on conflating 1st/3rd party apps.
    • Aaron - would defining this as a PAR extension impact
      implementation plans?
    • George Fletcher - Needs more work around implementation
      requirements vs PAR, checking for first partyness of the
      app. Would need to restructure the draft to call this out.
      1st party app check would only be for some PAR-oriented
      flows. Extension would explicitly change what PAR does/says.
      Changes behavior for the FiPA case. No strong preference
      either way
    • Justin - agree w/ George's precaution. Token endpoint is
      open to 1st/3rd party apps. Code path switching would be
      checking client authN/identification/attestations first. 3rd
      party apps unlikely to trigger this code path.

  • Aaron - need to move discussion to the list for feedback

Client ID Scheme - Aaron (20 min)

https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-scheme/

• Aaron

  • different but related draft at IETF121, client id scheme
    discussed at interim in January 2025
  • client published metadata at a URL
  • URL is used as a client id in the authZ request

  • Why?

    • preregistration of clients may not always be possible, e.g.
      open source chat apps

  • Problem

    • Many ways for an AS to interpret a URL as a client id
    • this is an issue for a generic server that supports
      everything, server can't know what a URL means until it's
      resolved

  • Why not add a new param?

    • &client_id_scheme - creates more issues than it solves.
      See WG discussion

  • New param per type, e.g. client_url, did, etc

    • breaks compatability with OAuth tooling

  • OpenID4VP introduces a namespace for client ids

    • see slides 9/10 for visual description
    • HTTPS and did will change to a new client id scheme in
      OpenID4VP PR#401
      • No scheme recognized falls back to a default scheme,
        e.g. plain URLs

  • Proposal

    • take the client id scheme, pull it into the draft, enables
      OpenID Federation, OpenID4VP, Client Metadata docs

  • Discussion

    • George Fletcher - are you planning to define a new ID scheme
      value for the metadata context?
    • Aaron - good point, missing in the chart on slide 11. See
      statement at bottom of slide 11 for context

    • Mike Jones - OpenID Federation PR 401 hasn't reached
      consensus, may not be merged as is. Doesn't align with
      existing practice.

      • Aaron - the PR says "looks great, let's merge"
      • Mike - 3 people requesting changes to the PR - don't
        want to have the debate here, rather inform that it
        needs to be aligned with OpenID4VP which does not use
        the prefix
      • Aaron - my understanding is was moving to prefix with a
        fallback
      • Mike - let's have this discussion in DCP WG
      • Aaron - trying to define a non-conflicting mechanism

    • Joseph Heenan - clarify previous point. Conclusion in OIDF
      was due to a misunderstanding of where the https scheme was
      in use. People have live systems that we need to not break.
      Need to find a resolution across the working groups.

    • Brian - trying to prohibit it here is probably not the right
      choice. We should not take requirements here from work in
      OIDF
    • Matthieu Sieben: https and did prefixing would not help in
      any way.

  • Aaron - not an adopted draft. Intent is to try to reach
    conclusion so we can adopt. Ensure no conflict with existing
    uses.

  • Mike Jones - DCP WG has stated their intention to go to review
    for final status within a few weeks. By then, it will be clear
    which way that group is going. Suggests waiting for review
    period to make a decision on this draft if you want to
    coordinate.

Updating Security BCP - Pedram Hosseyni (10 min)

No draft available at this time.

• Pedram

  • We do formal analysis of identity protocols
  • Why update the BCP?
  • Two attacks since publication requested: audience injection
    attack, AS mixed up attack
  • Review of audience injection attack enabling client
    impersonation

  • Review of the mix up attack described at OSW

    • authors proposed countermeasures already

  • question: What's the best process to update RFC9700?

  • Brian - procedural question. Can a BCP have multiple docs listed
    under it, allowing a new doc to augment the BCP? Avoids having
    to rewrite RFC 9700

    • Rifaat - chairs can figure that out

  • Justin - do what Brian said. By the time you publish a BCP, it's
    not current any longer. We can move tightly scoped docs through
    IETF faster than many years. Recommends writing a small doc
    describing the attacks and mitigations. Go fast.

    • Hannes - we wanted to accumulate data first before
      publishing
    • Justin - but then we'll hold again on publishing as new
      attacks come out
    • Hannes - do we want to collect everything in one place or
      not?
    • Justin - we want a small focused doc, collect multiple rfcs
      under the BCP. eventually get Aaron to write BCP 2.1 (lol)
    • Aaron - agree, keep it small, focused, and publish. Can we
      theme the BCP around a client interacting with multiple AS
      instead of general OAuth?
    • Mike - Thanks Tim & Pedram. The draft we adopted for RFC7523
      bis and friends does not describe the attack.
    • Dean - go fast, publish, don't delay

  • Pedram - discussion was helpful.

  • Rifaat - start work on the doc asap.

Friday

Chairs update – Rifaat/Hannes (5 min)

SD-JWT – Brian (10 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

https://datatracker.ietf.org/meeting/122/materials/slides-122-oauth-sessb-sd-jwt-02

Brian goes through his slide deck giving a status update.

Rohan: Wrote a intro section for 1.3

Brian: Some introductory text was a bit repetitive, then the examples
were more verbose than what I wanted in that section. Some other text
was about areas where there was previously some misunderstanding. It may
have introduced additional confusion. If others believe it would be
worthwhile we can look into it.

SD-JWT VC - Brian (20 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
https://datatracker.ietf.org/meeting/122/materials/slides-122-oauth-sessb-sd-jwt-vc-00

Brian presents slides

Rohan: Re: optional issuer, was the intention to make it more efficient?

Brian: It was to avoid the previous situation where you always had an
issuer, even with x5c, and there were rules about matching to the
content of certificates. If you were only wanting to do certificate
based trust, so including the issuer implied that verifiers would go
pull keys from the web, risking domain takeovers etc

Brian: I wanted to have the semantic that the issuer field is there but
there is no requirement to go out and fetch the keys.

Rifaat: What is your sense of how far along this is?

Brian: These two are the most pressing issues, but there are a lot in
the repository, but many are not super substantial.

JWT Profile for Client Authentication and Authorization Grants - Mike & Brian (25 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-rfc7523bis/
https://datatracker.ietf.org/meeting/122/materials/slides-122-oauth-sessb-updating-jwt-profile-for-oauth-20-client-authentication-and-authorization-grants-00

Mike presents slides

Detailed description of the vulnerability available at
https://openid.net/notice-of-a-security-vulnerability/

Brian presents slides

Poll: Did you read the draft?
Yes: 13
No: 24
No Opinion: 3

Poll: Do you understand the difference between the two proposals?
Yes: 20
No: 10
No Opinion: 5

Poll: Are you in favor of Brian's version?
Yes: 23
No: 4
No Opinion: 10

Transaction Token - Pieter (15 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/
https://datatracker.ietf.org/meeting/122/materials/slides-122-oauth-sessb-transaction-tokens-00

Pieter presents slides

Aaron: I am nervous about relaxing the lifetime of the access token. I
tell people that it is more important to know for what the access token
was valid at the time when the call chain was started. This is a
different way of phrasing the problem.

Pieter: This is a good way to phrase the problem.

Brian agrees with Aaron.

Justin: What you are trying to say: is it in a context in which it
should be processing right now?
It is important to capture initiation: The transaction token must not be
used to initiate a transaction in the way the access token does.

Dean also agress with Aaron and Justin.

George agrees with Justin. There is probably better wording we can put
into the draft.

Rohan: I like what Justin said about the expiration time. You still want
to check revocation or status lists.

Arndt: If we bind the lifetime of the transaction tokens and the access
tokens then I have to put restrictions on the access tokens. This is
something we want to avoid.

Dean: The iat claim and the entire "chain" needs to be carried along to
keep the context.

Atul points Dean to the text in Section 7.5.1 regarding the lifetime.

Pieter: This is the last open issue and once this issue is resolved we
can move on to WGLC.

OAuth Identity Chaining - Brian (15 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/
https://datatracker.ietf.org/meeting/122/materials/slides-122-oauth-sessb-oauth-identity-and-authorization-chaining-across-domains-01

Brian presents slides

• The goal of this spec is to provide clarity around this pattern, not
  describe new functionality.
• The idea of layering sender constrained tokens adds additional
  complexities

Hannes: This pattern is similar to Kerberos, so we could borrow from
that

Brian: Specific pointers would be helpful

Hannes will post a mail to the OAuth mailing list with pointers.

Rifaat asks for reviewers: Dean, Justin, Joe

Deferred Key Binding for OAuth - Justin (10 min)

https://datatracker.ietf.org/doc/html/draft-richer-oauth-tmb-claim
https://datatracker.ietf.org/meeting/122/materials/slides-122-oauth-sessb-deferred-key-binding-for-oauth-tokens-01

Justin presents slides

Rifaat asks whether we should schedule an interim meeting on this topic.

Justin believes that this would be helpful.

Token Exchange extensions - Nick Watson (20 min)

No draft available at this time.
https://datatracker.ietf.org/meeting/122/materials/slides-122-oauth-oauth-token-exchange-extensions-00

Nick presents slides

Nick talks about returning errors:

Brian: Have you looked at the existing error uri parameter

Nick: I understood that the existing uri is for the developer rather
than the user.

Brian: I got a lot of negative feedback on the use of URIs for error
feedback

Second topic: Refresh token expiration

There are two topics: consent expiration and token expiration

Clients would like to know consent / refresh token expiration.

Justin: The response of the token endpoint puts all information
together. People have made various assumptions about the fields
returned. Adding further fields would potentially add further complexity
to existing deployments.

There are practical aspects we could do. For example, the AS could
return the old token if the AS is not ready to rotate a token fast
enough.

Aaron: There are dynamic access token mechanisms. Refresh token schedule
does not mean fixed token schedule. I like that your goal is to allow
the client to let the user do something. I think we should focus on this
aspect: How do we let the client indicate that the user can take some
action? Not get stuck in the weeds about defining every subtle aspect
about expiration.

Darin Mcadams: We at AWS are interested in this in the context of VPN
tunnels. When the token expire in our scenario then it has a lot of
impact.

Jonathan Hoyland: With proposal 2 (proposal with URL) you have to think
carefully about cross site request forgery.

Ben Brucksch: I am having the same issues in the email client space. I
need to the error information to attempt to recover in different ways.
Currently, I cannot differentiate the various scenarios. Happy to work
with you. Would more error codes help? Would a descriptive error message
for end user help?

Nick: One more error code would be helpful. (I noticed access denied is
not a valid error code.)

Fillip: We typically do not want to give information to the client. You
need to take this into account.

Nick: Absolutely and there are ways to do this.