Nick, Jeff, Yaron, Max G, and Meiling are willing to review the OAuth
2.1 specification
Browser-based Apps in RFC Editor Queue
Massive number of proposals, this will continue from the views of the
chairs. If you want to propose something you need to have discussions on
the mailling list. There is need to have discussions there to
demonstrate interest
This is not a conference to present stuff, we need to make sure it
progresses
No standing questions
https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/
Goes beyond the just this proposal, already extended through other
Drafts
Bind Token Exchange and JWT Authorization Grant
Multiple implementations already Closed and Open Source
Not limited to Enterprise use cases
-02 is adding SAML Assertion elements representation in the ID-JAG
2 elements to work on:
Authors looking for feedback on the directions of those 2 elements,
options are:
Yaron:
Justin: Because this uses 2 similar processes, it can be troubling to
know which mechanism is happening first and second. Support the work
Arndt: The AS and IDP might have a different understanding of claims
including scopes
Aaron: They will have to have the same understanding
Max: JIT Provisionning is important to us
Paul: We adopted that in MCP. 1/ Need more granular Error Code 2/
Ability to expose the capability
2 new draft:
Rachid: How the AS establish trust with the other partys?
Aaron: Assume it already happen
Pieter: The key binding is important, need to be clear about what you
mean by the E2E key binding. You might to write that this is the Client
ID all the way
Tony: Whath will you do with NameID unspecified
Aaron: We will apply the same
https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/
Thanks to Justin for a lot of feedback. Split in two sections: the
document content and how to fetch it
Issue #88: Mix-up attacks are more real, therefore requires to return
iss claim even if 2.0
Emelia: Other protection mechanism, we have a JSON extension on the URL
Issue #78: doc might have to adapt to some AS expectation through one
document. Identify through QSP or Header
Justin: this is good but I hate it. It start to create an enumeration
attack
Aaron: Migth consider just using a header
Nick: Like that, we need flexibility from Day 0. Be careful to no
invalidate your client id
Emilia: I would be against a QSP, would prefer a header
Paul: I use that for Private_key JWT support, and progressive rollout
Arndt: +1 to Emelia. We also clearly need to descrive on clear rules on
when to use it
Joseph: I can see the need for this in some cases, but also feels
dangerous. There's existing solutions (developed by OpenID federation)
for some use cases like allowing the client to say it supports multiple
authentication methods. It adds a lot of complexity that might hurt
interoperatibility in the longer term.
Client versions
Justin: Software version is already there does it not solve it?
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics-update/
Hannes (off chair): on the Shared Consent, is there a place for a broker
in the first place?
Emelia: has seen some implementation with various success
Hannes (off chair): For Javascript, we could have said how to do it for
Javascript, client side. Instead we said don't do it
Justin: From the client perspective, the Broker is the AS in this
scenario. I woudl support guidance on this. AS definition can be
different in different case. They can have more elements in the chain.
Deb: it is BCP240
Arndt: I see this pattern being used. It does not stop at the consent
Rachid Bouziane - questions about Threat statement (Hannes answered) -
this isn't complete.....
Emelia: this is the same type of attacjs for CIMD. We might want to
explore the mitigations of one on the other
https://datatracker.ietf.org/doc/draft-ietf-oauth-spiffe-client-auth/
Hannes: in other space we have matching rules that are evaluated to find
match but this can lead to confusion
Aaron: Generally it works. There are a lot of discussion o Client
instance ID and Client ID
Hannes: There are problem with star matching and other risks
Arndt: Spiffe is clear and narrowly defined.
Chris: we need it for workload and agent, it keeps comings
Arndt: This won't be your CIMD
Paul: we see the same problem with the Wallet, we did not wanted to
solve it for the whole OAuth. We need to distinguish the client id from
the client instance id.
Frederik: The problem is not that you do it in SPIFFE but that you have
to look into other specifications as well.
George: There are other complexitities that you have to keep in sync.
Arndt: Recognize that things are implemented differently
Pam: If you decide to use this SPIFFE ID across domains that might be
problematic since you introduce the enumeration attack. An attacker
could use the structure to find information about the deployment of a
cloud provider.
Arndt: If you put it in your CIMD there might be a privacy problem
Andrew: don't have a strong feeling about the how, but we need to do
something
https://datatracker.ietf.org/doc/draft-rosomakho-oauth-txn-challenge/
Peter: Why initiated from the RS and not the Agent?
Yaroslav: cause the RS challenge it
Peter: Can it be initiated from the Agent side? to access the protected
request?
Yaroslav: If the Agent has no token, then yes It can still acquire it
through the native mechanism
https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/
https://datatracker.ietf.org/doc/draft-skyfire-oauth-kyapay-token/
Max: How can we do the authentication of the user in the first place
Mike:
Rifaat (chair): we do not need to go in details yet
Max:
https://datatracker.ietf.org/doc/draft-chen-oauth-agent-authz-use-cases/
Jonathan mentioned his use case:
https://datatracker.ietf.org/doc/draft-rosenberg-aiproto-cheq/
Pieter - Use case on batch / intent authorization
Rachid -
Altanai - User preferences (context)
Yaron - Consent negotiation
https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/
Comments:
Arndt: do want different typs, expecting many platforms
Justin: client id assumptions are not always correct. does not
necessarily need to be a static value. client id could be
Joseph: client id is used in tokens returned so need to be careful. re:
refresh tokens,
Filip: if we change typ, change method name.
Paul: only change on pop? Arndt: not concerned
https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-01.html
Kathleen: Many questions, can we have a deep-dive interim? (lots of
nodding)
Filip: double encoding the JWK is wasteful, httpsig already carries the
algorithm which points to a key type, we can just send over the public
portion of the key ({x}, {x||y}, {pub}, etc)
https://datatracker.ietf.org/doc/draft-zehavi-oauth-rar-metadata/
Nick Watson: insufficient_authorization is excellent (would like to
combine w/ Yaroslav's draft). Can a $150 grant allow a $100 grant, or is
it very specific? might be better in that case for the LLM to draft its
own RAR.
Yaron Zehavi: had layering meeting
Arndt: +1 on problem space, need to debate solution
Justin Richer: Agreed a gap in RAR, decided not to in RAR draft in order
to not try to solve the ecosystem. Re: the earlier point, the AS can
make sense of subsuming a $100 claim for $150
Call for adoption? Yes
https://datatracker.ietf.org/doc/html/draft-kahrer-oauth-client-challenge-protocol
Comments:
Aaron Parecki: Client has been authorized by the user, but current token
doesn't have that scope? (yes) Can be done with a higher scoped refresh
token that you use to get a higher scoped token, RFC 6749.
Yaron Zehavi: related problem of RAR draft, DTR, RFC 9728 can be helpful
Pam Dingle: how are the 2 tokens different if both have same scope?
(scope was request param)
https://datatracker.ietf.org/doc/draft-gerber-oauth-deferred-token-response/
Yaron: important draft, has many use cases
Nick: +1 to deployment considerations
Paul Carleton: +1 to this, like flexibility
Arndt: +1,
Dapeng Liu: +1 to this,
Justin Richer: +1, consider past UMA in GNAP, CIBA as referenced. also
please consider PAR and device flow.
George Fletcher: sender constrain the deferred code
Gareth: +1, had to do custom thing for this, would love 1st class
support
https://datatracker.ietf.org/doc/draft-ambekar-oauth-epop/
Paul Bastian: Seems out of scope for OAuth. Do like DPoP replacement,
prefer HTTPSig mechanism
Justin Richer: Reminiscent of SOAP issues, by trying to be transport
agnostic it reinvents things the transports provide. Don't think it
should be in here. OAuth is HTTP-based. Also check out WIMSE
Antoine: Nested tokens for privacy could be a useful reference.
https://datatracker.ietf.org/doc/draft-gco-oauth-delegate-sd-jwt/
Antoine: what's the added order for additionally added disclosures?
Frederic: +1 have many use cases for this, please adopt or we need
proprietary solutions
Christian: +1, e.g. delegating to accountant
Ni: every entity in chain needs to sign it... so verifier needs public
keys for all things in the chain.
Gareth: Thankfully don't need to fetch keys! public keys are endorsed
throughout the chain, so the verifier just needs the 1 anchor.
(support in chat)
Arndt: Desire to defer evaluation?
Jeff: No specific draft here, stance here is do NOT put policy in the
token (except in rare edge cases)
Daniel: Support expression of policies, so user can be in the loop
George: User defined constraints may want to be expressed
Jeff: Yes, just not specifying policy provisioning
Dapeng:
Antoine: Downscope in the envelope?
Jeff: Sometimes you don't want to downscope, so you want to discover the
schema
Yaron Sheffer:
Comments:
Deb: Agree w/ approach, being systematic. Where to document the
categories? How about the wiki?
Hannes: Excited about the excitement.
Deb: Have received pressure to open additional agentic authorization
working groups, which Deb has rejected. If you think that is wrong, talk
to me, it seems bad to silo.
Aaron: We do not have an "AI" category! We want to find the needs.
Deb: I don't see the gaps between OAuth and WIMSE for agent things, so
will continue to push back.
Pam Dingle: This is about how the WG triages, but for other folks
consuming these, could we use that as well? We send them numbers
Aaron: Haven't looked at that, but wiki would help.
Jeff: Agree on more onus on authors, a shepherding piece may be helpful.