OAuth @ IETF124

Monday 11/3/2025

Chairs update – 15 min

4 drafts nearing completion

token status - in IESG LC

browser based apps - waiting for cookies

SDJWT - with RFCEd

Cross-device - waiting for writeup (hannes writing up now)
Pieter: outstanding pieces are waiting for confirmation, just arrived at
mailing list 20 minutes ago.

ID Chaining - in WGLC, waiting for shepherds
Riffat: we'll pick it up after

SD-JWT VC - Brian (20 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/

• Uses SD JWT, established JWT content, and extensibility to represent
  VC/DC
• type data allows for description of the document itself, how to
  display and other informational fields - especially on a smart
  phone, for use of user-friendly rendering, mandatory attributes etc

• Two drafts since Madrid (-11, -12)

  • added type structure (and extensions)
  • added privacy considerations
  • added ties to status list via status claim
  • definition of vct is now a string (not a string-or-uri)
  • No more JSON schema in type metadata (does not preclude usage
    but does simplify)
  • new optional mandatory property
  • Unknown claims no longer have to be explicitly ignored
  • improved terminology
  • vct now required in type metadata
  • Introduction cleaned up - no repetitive discussion on state
  • additional guidance on vct and integrity
  • additional security considertations re: type metadata
  • x5c header now required in protected header very clearly
  • better examples (pid, type metadata)
  • Zero issues in issue tracker (for ~10 seconds)

• EU is interested in relying on this doc, stable versions are
  important

  • but it is a balance
  • hoping to get something soon

• Brian believes this doc is ready for WGLC consideration

Question/comments

Hannes: Who has read the most recent version? (lots of changes, is this
a rewrite?)

• Raised hands: not too many (4 online hands* )
• Volunteers: nat, dan, tim

Identity Assertion Authorization Grant - Aaron/Brian (20 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/

• profile of chaining across domains
• applying identity chaining in enterprise contexts

• When apps want to talk to each other eg, wiki embedding something
  prettier than a long URL (or AI for example)

  • Today there is an oauth flow with a consent screen. IdP only
    sees the first app in the chain, don't know that there is a
    downstream issuance. Data sharing between apps is not visible.

• Goal is to extend SSO to API access between apps

  • also better UX and security, and enterprise control

• Moves control inside the enterprise IdP

• The draft defines the claims in the ID-JAG

• Changes (-01)

  • restructuring of doc itself for clarity
  • role names now closer to the OAuth standard
  • explicit references to IDtoken claims that are closer to the SSO
    moment (eg auth_time)

• Changes for the next version (-02)

  • identifiers (it's tricky)
  • Refresh tokens (discussion coming)
  • POP binding
  • Multi-tenancy
    • How do I know what applications should even be accessible by
      this method - is that question in scope?

Refresh Tokens:

• See issue #58 - what happens if the user logged in ages ago?
  • If that AT expires, the ID-JAG can be used to get a new one, if
    not, the IDtoken is used. If neither, refresh token can be used
    to get IDToken
  • proposal: short-circuit to get an ID-JAG from the refresh token
    (no ID Token in the middle)
  • Conceptually refresh is designed to represent over a longer
    period of time, which makes it seem ok

Jeff: when you refresh, you don't necessarily get an ID Token; you might
not expect an ID-JAG
To consider ID token and ID-JAG as equivalent?
Aaron: consider IDT and RT as equivalent, then need to get a new ID-JAG.
Today, RT used to get IDT then ID-JAG. Goal is to replace step 3

Justin: Not a universal pattern, with offline access maybe we can signal
I want this refresh token to have this behavior - getting into scopes, a
little crazy but as crazy as expecting everyone to return RT on every
response.
Aaron: this is a strong reason to include the RT
Justin: We didn't think of this in OAuth2 but maybe if we could define a
semantic way to carry in the request, perhaps this draft can tackle it.

Brian: This is fishy but good - RT in step 3 would be as a token
exchange request so semantics are different from normal RT
request/response.
Justin: that gives a cleaner place for the semantics, thanks

Arndt: there will be many was to get what we want, complexity results,
can we just make RT the goto method, wil be more clear
Aaron: confirming you want RT to be the main mechanism
Arndt: yes

Atul: arrows 1&2 are for ID Token, 3&4 are for JAG - are they supposed
to be the same AS?
Aaron: that is core to the model (security) - that is the restriction
that this draft adds, if you are talking about different relationships,
Identity Chaining draft might be better
Atul: what are you trying to solve in Enterprise Use Case?
Aaron: the thing that issues the IDtoken becomes the thing that is
issuing for API access across domains

Vanshaj: If I am the client and I make an oauth request, how does
redirect happen?
Aaron: it does not redirect, will do instead of a redirect proactively

Mohibul: what breaks today if we would like to use normal token
exchange? why do we need this on top?
Aaron: the quick answer: the token in token exchange issued by IDP but
you could have case where Resource server accepts, but no scenario where
no resource server will accept tokens issued by the other IDP. Lets RS
use their access tokens in their domain in response to something that
happened in another domain.

PoP Binding

proposal for adding dpop to everything, mostly existing building blocks,
will talk about new thing on friday

multi-tenancy

need a way to point to which install of a given app we're talking about
within the flow

• need a name for what to refer to these things as

Updates to Audience Values for OAuth 2.0 Authorization Servers - Brian (10 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-rfc7523bis/

• started at OSW 2025 (iceland)

• analysis of OID Fed

  • discovered obscure but real vuln around metadata and private key
    JWT
  • see: audience injection attacks

• Filip working on updates to the document that closes the gap from
  what was discussed in Dublin

• we're very close to something that's in good shape

• targeted set of fixes that break fewer things

  • Updating JWT-based client authN requiring a construct that
    didn't exist but now gives a signal that the client is doing the
    right thing.
  • More targeted advice for the JAGs to be used in non-problematic
    ways, preventing misuse

• Drafts since Madrid (-03)

  • Registry updates so that security update is pointed to in case
    anyone looks
  • Aud can be an array with single member (text was overreaching)
  • Puts onus on client to prevent problems with extra guidance
  • Extensive example of JWT client auth makes understanding easier
  • Abbreviated title is updated (Justin is mad)

• Is it time to consider WGLC? Brian says yes

Rifaat: anyone against WGLC? (crickets)
Hannes: yes, put it forward

OAuth 2.1 - Aaron (15 min)

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

• Long-running effort to update OAuth 2.0 - now on draft 14
• OAuth 2.0 has additions, removals, security BCP etc
• Browser Apps BCP held up (waiting for cookies)

• This doc becomes a new baseline.

  • Takes existing RFCs, points to different practices
  • No new behavior

• Need to push to finish

• In Draft (-12)

  • Reference changes in 9700
  • RFC7591 client_secret_post & client_secret_basic
  • Native apps: most contents apply to mobile not desktop - added
    text to make the mobile context clear

• Many open issues on github, many have discussions, some just need to
  get worked up but have a conclusion

  • Please review

Colliding URI Query Parameters (#171)

• if a uri includes state or any other fragment expected to be
  appended, what to do?

Suggestion: forbid any registered query parameter names
Filip: no concerns, this is still a valid url,
Justin: makes sense, debatable if it is a MUST or SHOULD, if a client
steps into this space they must be expected to be able to handle it. The
behavior of multiple params of th esmae name could be interprested in
many ways, and could be handled by any part of your processing stack. We
encountered - solution was to say if you do this, you are on your own.
For anyone who needs Anchors for where this language is defined; if you
need them ping him
Aaron: So call this out as client's responsibility
Justin: yes, not a normative change but also not particularly present in
the wild

Invalid client and HTTPAuth (#162)

• response can indicate support for auth methods but there's no where
  defined how to do that
• most comments have coalesced around - this isn't useful to return
  anyway because what clients choose their AuthN method dynamically
  anyway

Filip: if the MAY is not present, everyone who returns 401 today would
not be compliant, fallback is 400.
Aaron: can we leave the rest of the 401 but get rid of it for AuthN
schemes? If so would that be acceptable?
Justin: I think that we can because it is the interpretation of the
error msg that we are trying to narrow down.
Aaron: Additionl methodsare in WWW-Authenticate response
Filip: but private_key_jwt is not listed
Justin: can we ignore?
Aaron: want to but need a path to return the 401 part of error but
remove the Auth method challenge bits
Filip: WWW-Authenticate needs a scheme
Aaron: we are stuck
Jeff: can we do an addendum to define an auth method for private key
jwt?
Aaron: Yes but nobody uses it anyway.
Brian: the Auth scheme meant to be a challenge/response, there is an
impedance mismatch. Mutual TLS would be another one you could fail but
you are required to have 401 in WWW-authenticate. Basic is the only one,
could you just say that without getting into supported schemes?
Aaron: seems the sense is we don't want to make current servers
non-compliant but we also don't want to define this mechanism, need to
find a way to slice this
Arndt: maybe just be pragmatic and put our dilemma into the spec for
consideration

Version Upgrade Support / signaling

Aaron: long discussion is on list with no conclusion. How to support 2.0
and 2.1 with opt-in to new behavior wihtout breaking old behavior is not
conclusive.

• anyone wanting to help with language, please help

Filip: you can have a client with 2.0, 2.1 don't need any
discoverability (will be taken offline)

Browser-swapping attacks - Jonas (20 min)

https://openid.net/specs/fapi-security-profile-2_0-final.html#name-browser-swapping-attacks

• while doing pen tests on OAuth, realized we need to talk about
  browser swapping attacks

• CSRF attack is possible if authorization response is injected during
  authz code flow, attacker is then logged in as user

• Solution: Client includes a state parameter in the authorization
  response, then compares the state to know if an injection has
  happened

• Question, what happens with the authorization code? It remains valid
  and can be used (potentially by an attacker that finds it)

  • Attack ends up happening in an earlier step of the flow, with
    code used to fetch a token in a different CSRF attack (attacker
    can see/inject state parameter)

• AuthZ code can be leaked in many ways

  • eg - code could be in an amazon leak passed when sharing
    shopping links
  • lack of referrer-policy means code could be sent in referer
    header of related request (images etc)
  • analytics
  • logging

• doesn't PKCE solve it?

  • Nope

• challenge method can be defined by attacker (and comes from session
  of attacker)

• response_mode=fragment helps, because not sent to backend of
  browser, restricts attack surface to client
• Fragment parameters only good for front-end apps (SPA, mobile)
• Backend reco: response_mode:form_post
• Both recomendations can be downgraded to response_mode=query

Filip: a cient will usually be written with response mode in mind, if it
expects a param it won't expect form post etc
Jonas: Method not implemented error as a query parameter won't be
handled,attacker can still then take the parameter and go elsewhere

• Recommend to circumvent: way for client to invalidate authz codes
  (eg CSRF detected). authz code would be unusable that way

  • No way for the client to invalidate today, the only way is to
    send a token request.
  • It depends on AS implementation, no redirect_uri in token
    request might be an option, but there were examples where that
    didn't do the job.

• For OAuth 2.1: do we still need response_mode=query?

• (crowd (ok Justin & Brian) says yes)

• Jonas: the other options seem to work well, response_mode query is
  just legacy, should not deprecate but we should say it is mandatory
  for AS to provide client implementers the opportunity to enforce a
  specific response mode.

  • This removes downgrade attacks

• We should also include how to invalidate an authz code

Aaron: this is deep, and important - agree this is a real attack
scenario. Don't think it is realistic to deprecate, especially since
other response modes are OIDC specified not OAuth-specified. Third reco
could be worth an extension, probably too new for Oauth 2.1. Effort to
fix has relatively low value compared to bearer token theft, as well as
OAuth phishing (protocol works but user is tricked). Those feel higher
priority. Want to minimize churn
Filip: For point #2 in FAPI 2 message signing spec we introduced a plan
to do this, the client is required to use a specific response mode,
cannot be downgraded. Fapi 2.0 has defined a model that uses standard
query response mode & PKCE. Does that spec not cover it?
Jonas: My impression is standard expectation is to keep code secret, you
are right
Justin: Agree 100% with suggestions, these suggestions help prevent
leakage not mitigate. We should be focusing on mitigation, close one
leak another opens. Good security advice exists for sanitizing
parameters on each page before serving to user. (Implicit flow with a
backend)
Rifaat: do we need an interim to hash this out?
Aaron: enough concrete proposals to go ahead with text. Let's start
there first.

Application-Agnostic Demonstration Proof of Possession (DPoP) Framework - Suhas/Cullen (15 min)

https://datatracker.ietf.org/doc/draft-nandakumar-oauth-dpop-proof/

• Current DPoP draft specific to HTTP but we wanted to open up to more
  protocols
• Endpoints in Media over QUIC send data corresponding to resources
  and identified by ??
• CAT - common access token needs to be extended for POP

• Approach #1 HTTP verbs mapped to MOQ (but isn't easy)

  • There are not 1:1 equivalents

• Approach #2: adding generic authorization context object that
  contains a type to identify a transport

• Eg: using authz context for type MOQ - object contains action, tns,
  tn attributes
• actx object keeps things more flexible keeps properties available
  for evolving needs
• TL;DR:
  • Want to adopt the doc
  • Need feedback - for generic transport direction
    • Experts here specifically are asked

Justin: clarification: is request for adoption in OAuth WG or in MOQ
community/
Suhas: right now the doc adoption is hoped for here, so that more
experts can see
Justin: right now DPoP already doesn't cover much of HTTP, this may not
be a perfectly clean mapping unless you are also hopping to extend for
HTTPS as well - goal or non-goal
Suhas: not sure, right now we are just defining for MOQ but if people
want to have that conversation it can be had
Brian: offhand, it may be more appropriate in MOQ - the DPOP/HTTP
binding was intentional, wonder if it is better not to try to be
transport agnostic (and then adding MOQ). We tried this and had a tough
time, could be more work this way. Consider getting away with using just
audience rather than full context binding. (justin +1 off-mic)
Suhas: we tried but it felt like more of a hack. Can be more
MOQ-specific but other protocol owners wanted to support things other
than MOQ as well - we are open though
Yaroslav: generalizing DPoP is a good direction, there are other places
where it could help (see Friday presentation). Maybe bring to DISPATCH
and see if there is more guidance
Cullen: My take was the only WG chartered to make DPoP changes was this
one. We could do it in MOQ but it isn't chartered for that. DISPATCH
remains good advice
Hannes: we have had efforts with other WGs eg: ACE. There is history but
both groups need to work together no matter where the work happens. Will
discuss with AD and WG chairs
Aaron: this is recurring theme - not clear where that work should
happen, not necessarily good for it to be good to happen outside of
OAuth WG
Rifaat: yes is early days (way too early to adopt doc) we will think
more

Delegated Authorization - Ruochen (5 min)

https://datatracker.ietf.org/doc/draft-li-oauth-delegated-authorization/

• Downscoping of AT is not possible unless a mechanism is used like
  token exchange. Client is not able to generate an AT or make changes
  to the AT.

• This framework defines a dt (delegation token) that can be retrieved
  instead of an AT

  • After receiving a DT the client is able to retrieve its own AT,
    authorized through the application itself

• digital sig linked token chain is used. Only delegated AT (DAT) is
  accepted by RS, DT alone is not accepted

• Client is able to perform downscoping on its own
• Claims of DAT is downscoped from DT
• Delegation key included in DT which is public key used in DAT
• will support traditional oauth grants incl refresh tokens, can
  support RAR

• need a new header (delegated authz header)

  • may need to include two tokens

• Also has a metadata discovery claim

Aaron: Don't fully understand, but I see similarities with Identity
Assertion Grant, I will talk again on Friday. Can you read that draft
and see if it works, and say what is missing otherwise?
Ruochen: I will write something about similarities with different works.

Peter Liu: this has a slight advantage, you RS might be in your local
domain. When you exchange with the full key present, you don't need a
roundtrip ... can validate signature at the RS.

Friday 11/7/2025

Chairs update – 5 min

Attestation-based Client Authentication - Paul (20 min)

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

• Current status of draft: got a lot of feedback from IETF 123,
  incorporated most
• 2-3 major open topics, all other open issues are mostly editorial
• Have also discussed at IIW
• Intend to reach WGLC if possible before next IETF plenary

• Issue 1: Using the draft outside client authentication

  • OAuth only allws 1 type of client auth
  • Some want to use this as an additional/complimentary signal
  • Proposed: define client attestation as a generic mechanism
  • Eg: Renaming to "Key-bound Client Attestation"

• Issue 2: Client ID - matches instance or class?

  • Could be part of a bigger client solution
  • client_id is defined as a wallet solution (ie class) in
    OPenID4VCI

  • Does it make more sense to make Client ID individual or keep it
    as a class?

    • Or remain in current state?

  • Could bind to public key if using individual client instance

Comments:
Aaron P: may be unpopular opinion: if you look at direction this is
going, feels like client ID references family rather than individual,
other things like DPoP key can indicate individual. CIMD is like that.
Justin also submitted a draft to add the concept of client instances
into OAuth. Aaron also has a proposal but Justin's may be a better
direction.
Paul: should we make it explicit in our draft?
Aaron:

Rifaat: is that captured anywhere that we expect client ID to be a
family
Aaron: I don't know if that is written anywhere
Rifaat: should that be in OAuth 2.1?
Aaron: will go look
Brian: last time I read this draft I thought this was well written and
solved. Aaron is right, this draft is not the right place to fix the
instance/class problem, it is too narrow a scope
Filip S: I agree the draft is clear today, I don't think we need to make
it more explicit. Would not appreciate it if htere was language that
could exclude the option to use client id as one option or the other.
Filip S: in the last slide (issue #1) when it comes to using resources,
a number of things would change, including target audience.
Paul: would you be in favor?
Filip: yes
Arndt: Glad you brought this up (client id issue) I will be bringing up
a draft later, we have the same problem. Think we as a working group
should work on this problem somewhere.
Jeff L: don't define here, this is for client auth so finalize that, if
you need another extension just do an additional draft to add on the
side (issue #1). We have issue #2's problem in WIMSE too
Atul T: I think this spec can be neutral as to instance vs. class,
Wondering if CIMD would allow instances for client IDs.
(many people nod "No")
Mike J: We have been talking about this at least since we made DCR. We
explicitly took the position that we are not going to take a position.
That has been the position ever since.
Justin R: yes we said that back then but the world has changed. The
reality is that most often client id is a class but DCR is explicitly
instances. I also put forward a draft to say that with PAR you don't
need a client ID.

Issue #3: Client Attestation with DPoP

• Optimization where those two things are present.

Arndt: why would it be necessary to do both?
Paul: You could use client attestion without DpoP but not the other way.

Paul: if the key is in a remote HSM it gets expensive to do both

Client ID Metadata Document - Aaron (15 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/

• Clients publish their own metadata at a URL which becomes their
  client ID in a metadata request

  • Useful when pre-registration is not possible.
  • MCP clients that allow connections to arbitrary MCP servers

• good feedback in the adoption process

• Have held back on incorporating
• MCP community will be referencing in this month's update

• Context for use cases:

  • Concern for fetching external data
    • Some value comes even if you don't fetch. Client ID can be
      just checked against doc location.
    • Client impersonation:
      • web: jws uri can be published
      • ios/android: use attestation based client attestation
      • desktop: no standardized patterns for app attestation on
        desktop apps
      • Could use MDM to push data around to do it, Maybe we
        could try to convince vendors to adopt an app
        attestation pattern

• Feedback received: (see slides)

  • Client ID Reputation
    • Could be more explicit about incrementally trusting more
      metadata properties over time
    • All of this is AS implementation decision
    • AS can do client health checks (for typos etc)

Justin: we have implemented - users were surprised by it, support
investigating

• New Client ID URL recognition

  • could incrementally lower guards on consent screens
  • could rate limit access tokens

• Planned updates

  • SSRF mitigations

    • Will add more

  • Restrict URI properties to HTTPS

    • PR #50

  • security considerations for changes

    • PR #47
    • AS might choose to invalidate grants etc if metadata changes
      are detected

  • Prohibit following redirects when fetching

    • PR #46

  • Other issues on github

Bryan N: no concerns, we implemented at Bluesky, has been working well.
Have hundreds of unique client IDs
Max G: also have implemented, we like it, running into trouble with
preview environments, this has a unique domain now and as a result a
unique client id
Emilia: in the previous meeting we had text about ... (sorry the scribe
did not understand hopefully somebody can put the right description in)

DPoP for the Device Authorization Grant and JWT Authorization Grant - Aaron (15 min)

https://datatracker.ietf.org/doc/draft-parecki-oauth-dpop-device-flow/
https://datatracker.ietf.org/doc/draft-parecki-oauth-jwt-dpop-grant/

• Clients using device code grant are likely public clients

  • Flow can be used for large-scale token theft

• DPoP alone doesn't solve that but combining DPoP with app
  attestation, a dent can be made

  • This was always possible, now it is written down

Filip: nothing prevents existing AS's from already doing this but
because it wasn't written down, some AS's took different routes. If we
are writing things down, options from already existing deployments
shouyld be added
Aaron: Not a fan of optionality
Brian: There is already a request parameter, PAR is a passthrough of the
request parameters, the conceptual jump to adding here could be a
too-large jump.
Brian: it's already there, if we document it and it does nothing, it's
weird. Either acknowledge or don't, fine either way
Aaron: this is not an adopted draft. First question may be, should this
be adopted

• DPoP for JWT authZ grant - another document

  • What if the JWT is obtained via JWT bearer

• Aaron cares because of identity chaining

  • gives end-to-end DPoP binding

• Atul asked: does IDP have to also be the issuer of the ID-JAG?

  • Aaron thinks the answer could be no
  • If so, DPoP would be bound for SSO, AT is used for token
    exchange which would be already covered for DPoP

• Lets us differentiate between who does login and who guarantees
  token exchange

Yaron: we support this draft, have a slightly different use case - want
to bind a bearer token issued by a dufferent service, this draft helps
Filip: JWT bearer grant includes token type that is unfortunate. If we
add another type of binding we need another authz grant. If I'm getting
the JWT from a place I don't know I don't know if it is bound with DPoP
or not, don't know if I should use jwt-bearer or jwt-dpop. in identity
chaining you don't know which grant type was used, or if the token has
been bound.
Aaron: ack
Arndt: situation: what if one domain supports DPoP the other doesn't? If
that AS doesn't know it will just issue a JWT, this represents a
downgrade attack
Jeff: on Monday ID-JAG was exchabnge of ID token for access token (maybe
with RT in the middle) what part of that was Atul's question?
Aaron: Atul's q was at the end. Audience of ID token is IDP, don't want
IDT to be sent to other things but AT can be audienced to other things,
so that might mean ID-JAG works
Justin: I disagree with Filip, devils in details
Aaron: much discussion spurred, we need to talk more on the list

Browserless app2app - Yaron Zehavi (15 min)

https://datatracker.ietf.org/doc/draft-zehavi-oauth-app2app-browserless/

• Basically oauth federation for mobile

• Challenge: 2020 app2app draft written

  • two apps redirecting to each other

• In a federation use case some AS's need to use a sub-optimal flow
  (more friction)

  • eg we have 11 subsidiaries

• Client app acts as its own user agent

  • Proposal for a native_authorization endpoint

  • Accepts a native_callback_uri (pre-registered)

    • Could return a federated response
    • Easier to process from a native client

    • Might say it needs more routing info

      • Will ask for an email for example

    • client traverses responses until it has enough data

      • invokes native_callback_uri with redirect_uri as
        parameter

• One problem was how to bind to a user agent (thanks George Fletcher)

  • mitigate authz code theft (uses cookies)
  • looking for better way

• PKCE recommended, made it mandatory

• feedback to recommend PAR
• Next steps: asking for additional review
• Would like to go for adoption in IETF 125

Roberta: I had a few issues with native apps have you seen the
sandboxing side of native browser usage? Could there be a collaboration
there?
Yaron: are you talking about not providing the wrong client the
information? Yes, there is consideration about not rendering in a web
view, only caveat is in use cases where input is needed to guide. We are
restricted to very non-sensitive input.
Aaron: have you seen the 3rd party apps draft, is that a similar thing?
Recognize it doesn't define everything you have but it was intended to
be a framework, didn't it work?
Yaron: we looked at it but the domains involved are totally different,
the issue is the indirect relationships between apps on left & right of
the swimlane. These are not challenges we want to serve.
Aaron: I will take a look, one of the challenges for that draft is that
it is designed to directly present challenges, broader pattern is also
stuff that can be done with the draft, coudl deploy without using
sensitive challenges.
Yaron: happy to talk
Paul: in OpenID4vci had a similar trajectory but also decided the 1st
party apps draft did not fit.
Leif: for discovery flows you may want to look at the seamlessaccess
project it is SAML but there is a lot of learnings there

Refresh Token and Consent Expiration - Nick Watson (15 min)

https://datatracker.ietf.org/doc/draft-watson-oauth-refresh-token-expiration/

• Two concepts: authorization expiration, credential expiration

• RT expiration

  • authz expiration - clients may want to remind users while user
    is active
  • cred expiration - clients need to know how often an RT must be
    used

• Since Madrid

  • new draft
  • consent renamed to "authorization"
  • rotation of RT moved to informative section

  • more considerations for client behavior

    • eg prompt=consent

  • two new token endpoint response params

    • refresh_tokentimeout
    • authorization_expires_in

• Looking for reviewers

George: feels like authorization_expires_in is a one-to-many
relationship, you would need to bind to which authorization expires when

Nick: yes, in some deployments four scopes could be authorized for
different times, that could get out of control quickly. Could add
language to advise implementers what to do (ie returning min value)
Aaron: great changes, like the concept. let's do an adoption call
Justin: simple on the surface but points a bright light at lifetime
relationship between all artifacts (grant management api was a noble
swing). This spirals out quickly beyond 'when is my RT going to expire'.
Usually OAuth tokens are not smart. They use stuff until they stop
working and then reset. Is there a need for additional stuff?
Nick: I expect if this is implemented, 90% wouldn't do anything with it,
big partners though.., Google is limiting access to email to certain
times, that is some of the use case, don't want to overcomplicate. Open
to a per-scope authorization, but seems better to pick a sane default
Justin: viable if there is clear guidance
Paul: RT expiration is a valid scenario that is useful to communicate to
users. Don't understand why there is 2 different things or why RT times
out instead of expiring
Nick: difference is who is responsible. RT timeout is AS policy, other
timeout is user/policy.
Aaron: very important and good design feature of OAuth that clients are
"stupid". Don't want to boil the oceanm, what you have done with the
minimal definitions does let the client stay dumb and I don't want to go
farther than that. This is a good level to shoot for, recommend do not
complicate the draft further
Arndt: I support this work and +1 to Aaron
Bryan: one motivating use case - clients only talking to a couple
providers, your software may talk to wildly different AS's with
different token lifetimes. If you know you want to take an action in a
week it is good to know that the RT won't last that long
Rifaat: can we get a few reviewers?
Brian: I did review, you clarified a lot of what I was worried about in
the previous draft
Rifaat: Justin you had reservations before, would you be opposedto
asking for adoption?
Justin: if this is scoped and simple it can make sense. There is a
deeper discussion to be had, this draft needs to be eyes open, that can
happen post-adoption. If it doesn't spiral it could be a reasonable
addition
Rifaat: getting ense of room, will be official ask on the mailing list.

(nobody jumped up to argue)

Separating DPoP Bindings for Access and Refresh Tokens - Yaroslav (15 min)

https://datatracker.ietf.org/doc/draft-rosomakho-oauth-dpop-rt/

• designed to solve a practical security problem

  • Loren (also at Zscaler) looking at situation where many bearer
    tokens were floating around after a compromise, makes. it scary
    if you are a company that uses other peoples tokens to access
    things
  • what happens if somebody gets hold of tokens? DPoP is a good way
    to tie tokens down
  • then found out DPoP has a good feature, if a token is bound, any
    derived token will be bound by the same key (eg: RTs) Not a lot
    of features that allow destruction of tokens on compromise
    unless you are the actual user.
  • If you tie your DPoP to an HSM, if you cut off the HSM the AT
    will burn out and the RT will not be exercisable anymore.
  • Have a scaling problem with HSM
  • Tracking RT separately from AT so that core system handles keys
    and edge systems do the scanning

• Trying to find a way to contain leaked refresh tokens and still able
  to run efficiently at scale

• Mention of another option on the list, a different PoP like MTLS.
  That boils down to the normal public PKI protecting JWKS
  distribution (if that cert is compromised, you could get an illicit
  token or cert). Takes a while to revoke those
• Differentiation for DPoP is speed, DPoP RT means you can cut the
  legs off of RT by cutting legs off HSM, can do that fast

• Proposal

  • separate DPoP AT and DPoP RT
  • new header for DPoP RT
  • Optional RT nonce mechanism
  • Minimizing blast radius of potential compromise

• Outcome: edge workloads only has AT DPoP, core workloads have RT
  DPoP

Arndt: to get AT you have to have access to both RT and AT, doesn't mean
at least one workload has to see both?
Yaroslav: yes, but how that is done is implementation detail
Arndt: agree - as long as this is optional I am for this
Brian: we talked a bit, the original DPoP was intentional about not
doing this to reduce complexity. Caveat was, in confidential client use
cases, the key is bound to the confidential client. It is designed to
bind RT to client with access to TPM or HSM. The case where you only get
one thing bound is public client, argument for more flexibility is fair,
but this is different than the use case you discuss. Worry about
introducting complexity in a use case I am not convinced is not
addressed already
Yaroslav: clear - in practice "sender constraints" are the constraints
for all artifacts - if credential is compromised it is compromised for
all. public client is unfortunately more common. Confidential is lower
potential level that you can fall, DPoP gives certain guarantees
Brian: there are public client drafts that could be used instead
Joseph: (no audio boo)
Loren: the alternatives all seem to be backed by PKI, which seems a bit
slower
Brian: there is one variant based on PKI, should step back to look at
existing alternatives

Joseph (from chat): When I first saw the slides (which have since changed) I was going to say something like Brian said, but I think they did a good job of explaining that there can be use for this

I was concerned about introducing multiple dpop nonces, it's a lot
of annoyance and I don't see why a single nonce isn't good enough to
get freshness.

OAuth SPIFFE Client Authentication - Arndt (10 min)

https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-spiffe-client-auth/

• Current situation: workloads talk to other workloads via SPIFFE.
  Problem starts when workloads need to authenticate clients
• No point in bringing user auth into SPIFFE because OAuth already
  does this
• Client ID / Secret exists but is a management nightmare
• Goal: workloads use their SPIFFE ID to authenticate to authorization
  servers. Goal is to use existing drafts
• RFC 8705 and 7521 can be used.

• Want to put it together to profile the pattern

  • Vanilla 8705/7521 don't work, for specific reasons

• Had an interim after IETF 123, we are one year in,

• Question - is this a SPIFFE output or an OAuth output, I believe
  OAuth
  • SPIFFE ID vs. Client ID

Flemming: I like work, makes sense, infra already does cred mgmt, would
like to take advantage. Want more security consideratings for SVIDs,
alluded to Wimse identity tokens would like to see that too
Arndt: we have a chicken/egg problem with wimse identity tokens
Jeff: I support, we will be doing things. Adding more high assurance
mechanisms is better
Justin: this makes as much sense as everything else. I worry that we are
cramming many things with different semantics into client id, we will
need to be very clear about how we differentiate. This may step on CIMD,
but we can work on that. Seconding question about WIPs etc - better to
not just be SPIFFE if that makes sense. Will you take dependency on
WIMSE?
Arndt: I had it in but took it out
Brian: don't think this is about putting things into client id, but
about how to associate them. We have had convos about tangental OAuth
stuff, this is probably the right place, compared to DPoP Moq stuff
where that seems to be happening outside
Pieter: wrt clientid metadata, there is an opportunity to get the
discovery elegance and combine it.
Rifaat: get the feeling there is interest, any issues with calling for
adoption - nobody in queue

Transaction Tokens - Atul (10 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/

• two known implementations

• progress since 123:

  • changed name from purp(ose) to scope
  • type discussion
  • flow diagram for internal token flow

• open issues

  • should request context be validated?

    • Atul doesn't think so

  • concerns over TraT should be replaced

    • some uses might require lifetime to be extend
    • Atul prefers possibility of extension, should be able to
      modify tctx

Arndt: not a fan of the replacement process, would question if it would
be better to move it to a separate draft after implementations exist
George: useful feedback, no strong feeling
Pieter: can remove, people will probably do it anyway without guidance
Atul: I like the idea of guidance in a different draft
RECORD SHOWS THAT PIETER SHRUGGED
Justin: this might be semantics. Really creating a new tx token in the
context of a tx token. Reason most likely is to get a new view, but as
token exchange does, add considerations for creating a new one in
context of original one, this isn't really a new thing just guidance
Pieter: this could just be security considerations. Justin's point about
introducting a semantic
RECORD SHOWS THAT BRIAN AGREED
Peter: Can you give more specific example of what specific situation
results in context modified
Atul: if a fraud service does a thing and adds more stuff
Peter: there could be a context rot problem
Rifaat: will take to the list
Pieter: maybe when it is appropriate could also be added to security
considerations
Jeff: there is a force for the replacement which is crossing security
domains
Atul: that is not what we intend
Rifaat: will take to list
Jeff: was discussion what the BFF should do to with the backend resource

Mike: there is a JWT BCP RFC 8725 listing things that people could do
wront with JWT, people did more stuff wrong, we did a BIS version, have
updated draft, have now explained all the additional things wrong, ready
for WGLC. Slides are in the agenda. Want to see this proceed.
Reviewers? None because it published 2 hours ago
Arndt, Filip are reviewers (Filip already did it)
Brian: WGLC after no action from not addressing previous comments might
be premature
Mike: please send items to list