Minutes IETF120: oauth: Tue 22:30
minutes-120-oauth-202407232230-00

Meeting Minutes Web Authorization Protocol (oauth) WG
Date and time 2024-07-23 22:30
Title Minutes IETF120: oauth: Tue 22:30
State Active
Other versions markdown
Last updated 2024-07-31

minutes-120-oauth-202407232230-00

IETF 120 - OAUTH 22-07-2024 1300

Agenda

  • Chairs update
  • SD-JWT
  • SD-JWT-VD
  • Transaction Token
  • OAuth for First party apps
  • Client ID Metadata
  • Encrypted Authorize Response

Minutes

Chairs

Rifaat:
Notewell and background, meeting tips, etc.

SD-JWT

Speaker: Yasuda

Overview & Refresher

Quick poll for any any new people? (none 😮)

Selective disclosure of claims via signing of salted hashes
Assumes 3 party model (Issuer, Holder, Verifier)

Trying to keep things simple

(illustration of an SD-JWT)

Notes that ~ is the separator at the end of a normal JWT

Payload is setup as array of strings with a special property _sd that
is an array of the claims (salted and hashed)

Thanks R. Barnes for improvement to terminology:
SD-JWT the think that is issued
SD-JWT+KB is the thing that is presented with key binding which shows
possession of key

Since last IETF

  • Clear distinguising of issued vs presented
  • better structure for JSON serialization to align with JAdES for
    EIDAS
  • better explanation of salts in disclosuers
  • mandated use of cnf for key binding

What's new in -10

Clarifications around recursive claims as well as editorial

What's next

Editorial fixes to respond to a few issues

Ask if we are ready for last call?

Chairs: ask for how many have reviewed -10 (around 5 by show of hands)
Chairs: ask for when issues will be resolved?

Brian: all open issues are editorial in nature, hoped to consider them
as a part of last call feedback

Chairs: think we should start last call, request additional reviews and
merging of editorial - should start that next week

Watson Ladd: Think that this work is actively harmful to end user
privacy - posits that sum total of information that has ever been
accumulated is shown

Chairs: any other comments, questions, concerns

John Bradley: This is far more privacy preserving than other options and
is here today - ZKPs are a way out from any practical use

Chairs: WG Last call next week

SD-JWT Verifiable Credentials (VCs)

Speaker: Brian Campbell

Intro and Background

Actually at IETF 120, and notes that taller than Kristina

Describing the data format and processing rules to express verifiable
credentials both with and without selective disclosure

Does not use the W3C VC Data Model (now with less RDF)

Example showing person identification data, including a hypothetical URI
(vct) that shows the type and structure of the credential

Example showing selective disclosure that shows that age is equal or
over certain thresholds with no other PII
Notes that cnf is in the clear since that is required for key
possession demonstration

Example breaking our clams, salts, encoding, etc. followed by an encoded
SD-JWT that only discloses nationality and age over as well as a key
binding JWT that shows possession of private key that was used

Example showing after validation what is available to the verifier

Changes since IETF 119

  • Published -04
  • Added a ref to status list doc
  • Introduced type metadata
  • Including schema type metadata
  • Clarify that digital signatures are "one way" of securing things,
    since some one might want strange constructions using ECDH + a MAC
    without violating the draft
  • Reworked validation rules for x5c so that it is cleaner and better
    to understand

Anticipate that metadata will evolve in future drafts

Open Issues

Many and out of hand - needs work and clarity

Chairs: Ask if there is a favorite issue

Brian: Pass

Current Work in progress

Current open pull request around claim and display metadata so that any
party can evaluate independently and make decisions around user display
of information

Going with a approach that uses an array of string values that map to
order of claims

Locale should be a map or subproperty still being determined

Questions

John B: Metadata is interesting - nothing in metadata is disclosed to
verifier?
Brian: intended for holder, but could be used by verifier - not secret
and is retrievable
John B: Might leak what claims are availabile - might be some reasons
not to disclose to the verifier
John B: Should disucss policies for wallets, etc? e.g. Some gov may only
want to permit disclosure or presentation to approved parties - if we
want interop we should consider issuer to wallet policies - could
metadata help with this?
Question - is metadata a way of annotating policy type info?
Brian: metadata could be, but debate around this and it is yet to be
determined
John B: we should figure this out
Brian: agree
John B: we should have an answer around privacy and consider it
especially in regards to metadata

Yaron: in the same area, "I have a VC, i use it to verify my age for the
scotch bof", do i have a protocol to see what info is requested or
required depending on the jursidication age requirements
Kristina: we do have some protocols on the OIDC side
Brian: This work is just token format related - that is out of scope for
this item and currently this group
Kristina: Some of this is available but protocols and query languages
are still being definied - trying to align these things with metadata,
etc.

Media types

Term VC defined and or popularized at W3C
For a variety or reasons there is desire to simplify and do related work
at IETF

W3C Started with potential rules that cascaded processing rules via
media types and structured suffixes

There was some disagreement at mediaman regarding multiple suffixes and
whether or not that is ok - most recent conclusion is that that is not
ok

Current statue for W3C media types:

  • application/vc
  • application/vp
  • application/vc+jwt
  • application/vp+jwt

some collision possible on

  • application/vc+sd-jwt and related

Orie: as ART AD I am ready to assit in the exploration of media types
and what they can mean - session is this afternoon. If you show up at
mediaman it can be discussed

Transaction Tokens

Speakers

  • George Fletcher
  • Atul Tulshibagwale

Update since 119

See list of PR here.

  • in PR #73 added text to clarify that trust domain only has one
    logical transaction token service - a transaction token only makes
    sense within one trust domain, so this text helps clarify

recap aside: additional service on top of server to server auth, etc

  • in PR #86 added privacy considerations to ensure no PI or PII in
    logging, etc
  • in PR #87 clarified responsibilities of servies to not modify sub
    or aud
  • in PR #89 clarified aud must uniquely identify trust domain, also
    that sub is in the context of the audience
  • in PR #90 added text to require that transaction tokens create self
    signed JWTs in cases when no appropriate token exists - definition
    of those claims is out of scope for the spec
  • in PR #92/#103 clarified fields and claims and cleaned up IANA items
    for registry
  • PR #100 clarifies scope and processing logic on cases where scope
    might change

Brian: Question on name / auth details and that claim name is the same
as another - maybe there is another name that would not conflict
George: Intentionally same name as RAR (sp) because you are defining
what is specific and should be immutable, and this is supposed to be a
container to hold the immutable items of the transaction, used because
semantics were similar
Brian: maybe i need to look again, but feels like it should reuse claim
directly or define a new name
Justin R: similar concerns on alignment, if similar enough should just
reuse, if not, another name (that might be related) might be better -
requests a common place for these items

  • PR #101 makes clear that txn should be unique and even though it
    is required you can in edge cases use a fixed value of "N_A"

Justin R: isn't this just null or optional with extra steps?
George: from a processing perspective I prefer values
Justin R: a naive processor will just group fields by N_A
George: if feedback is switch to something else, will incorporate it
Justin R: looks like a valid value with semantics in the value that
require knowledge to process properly

argument over optionality proceeds

Hannes: suggest a non-colliding random 128 bit value or similar if a
value must be there
Brian: token exchange did this becuase there was no option for optional
- don't do that here
George: prefers a value there, open to options

Topic: should internal use cases require a self signed JWT

e.g. if you have an inbound SMTP request, should you get a transaction
token to identify the delivery and lock transaction to delivery only

current spec is to use a self signed JWT

or should this be out of scope?

Joseph: does this have to be a self-signed JWT or could it come from
someone else?
George: could leave out of scope to be defined elsewhere (with some
detailing of options that would clarify that it is out of scope) - a JWT
gets some level of integrity
Joseph: seems like it could be useful to have self-signed vs other paths

Issues without time

azd, rctx and do we need a full registry or otherwise?
Reuqest for thoughts

Question around metadata and discovery, or is it too deployment specific
(so that additional metadata specification is not requrired)

Yaron: think self-signed JWTs are a foot gun (the popular term of the
day award goes to this), simple JSON object should suffice

OAuth for First Party apps

Speaker: Aaron

Overview

developers want a better UX for first party apps

Today, peopler ignore RFC8252 and come up with terrifying workarounds
that ignore security best practices

this draft is intended to fit in with exising OAuth models and building
blocks

(diagram showing auth server to app flow that is noted by the presenter
to be missing time)

Authorization Challenge Endpoint is new endpoint that takes items that
would be on query string, takes POST, and handles things like erros and
redirection. Not intended to be end all be all

Since 119

Updates around DPoP including removal of ash claim

Enabled PAR for redirect to web

Clarified ability to include PKCE code challenges and that follow up
requests do not need to be form encoded

Required that auth_session is bound to a device

In progress implementations

  • MS
  • Yahoo
  • Auth0 (in progress w/ no public docs yet)
  • WS02

Interest from keycloak

Next steps

Ready for adoption?

Create an extension for passkeys (some in progress work there via Tim
Cappalli)

Chairs: Call for adoption poll
....

Chairs: looks great (23 for, 10 no opinion) - strong support, will be
followed up on list (with clarification from Deb)

Kristina: has emerged as ways of handling presentation of a credential
during credential issuance - useful for that use case?
Aaron: intended only for first party, not 3rd party with good
description as to why - that case would be better as a separate draft
due to security considerations

George: nuance is that when you think about presenting credentials,
those are things that you would only want to show very specifically - if
credential itself is protected maybe that would be different

Tony Nadlin: maybe a quesiton more for Tim....

Tim: maybe we should look at these use cases together

Client ID Metadata

Speaker: Aaron

Intro

Totally new, co-authored with Emilia Smith

OAuth Clients need to register with server for things like redirect,
scopes, logo, etc

Currently happens out of band or it is not possible to do in cases where
developer may not have relationship with server (e.g. federated services
like mastodon)

Dynamic Client Registration (RFC7591) doesn't tend to work in practice,
becase it is an NxN sized problem

Previously proposed looker-client-discovery for .well-known actually has
issues around multi-tenancy and then things become super mess

Proposed approch says you define a url that has your client id and has a
json doc with the metadata discovery

AS can fetch metata, can include redirect uris

Q&A

David: just getting a json file on a web server shouldn't be sufficient
to trust - point of .well-known is that it can have process, etc.
Aaron: this is a risk because of the way it is

Brian: I follow, but get real worried as an open vector since it is open
internet, etc. need to be very serious guiance at a minimum on what,
where, how to access, etc. might undermine trust since might not be on
the the same TLD, etc.
Aaron: once concern is whether or not URL is on same "host" - that could
be specified. Can't get around that anyone can spin up a web server and
host whatever they want
Brian: TLS and things help
Aaron: client id must be in doc - should not be able to create a doc -
best we can do in this world
Brian: also issue of anyone showing up with bad data or other attack
vectors
Aaron: some normal web guidance on not trusting arbitrary data. What
about dev clients, local and local, etc.
Mike: I put links in the chat, Orie had some metadata discovery stuff,
pages are up in SPICE on that topic, very close to what we deal with -
system to system for supply chain credentials -- similar use cases,
multiple parties exchyanging creds, need to know where do I go. We have
utilized did:web extensively but it has issues. Some issues have been
addressed by other folks, eg how to bind back into DNSSec so there may
not be a perfect solution but the closest I've seen is what is happening
in SPICE on Thursday, maybe we can join forces

Justin R: SSRF and other things are key and may be in doc already. There
is a bunch of half backed stuff like "structured client ids" and there
are also things like open id federation that are bringing semantics to
client ids. there are dragons here (he did say foot-gun) since now
layers of semantics are being applied to something intended to be opaque

Kristina: real like experince with this in VC world, which is why
original draft was there. What we have seen people do is sign the
requests, etc. Would absolutely like to see an aligned solution to this.
For security purposes, becuase the client id gets passed around you also
see different uri resolution approaches, etc. namespaces come up. this
is something that is being looked at in a lot of areas
Aaron: federation trust cert doesn't work. closest model is DNS.

Orie: there was a slide with .well-known and multi-tenancy - there are
other drafts that approach this problem, including disclosing keys. Is
this a universal solution, I want to see relationships....
Aaron: could put keys via jwks uri....
Aaron: handful of related implementations, solid, bluesky, etc

Chairs: clearly see a lot of interest with giant security holes.
concerning when there are big holes and early implementations are
already starting.

Encrypted Authorize Response

Speaker: Peter

Intro

Challenge is that while Authorization code flow with PKCE is great, it
requires and extra roundtrip which has impacts on cost at scale as well
as latency

What if we encrypt the authorize response .... neato
Key material to auth server on request, then auth server encrypts and
returns with that material

looking for feedback and noting that there are a bunch of security
concerns, especially around credential leakage, access token injection,
sender constraints / DPoP, refresh tokens, redirect uri validation

feel obvious, likely others have tried similar things, why or why
not....?

Filip: Do you envision this as a part of Authorization response
Peter: yes
Filip: done via JWT auth response mode (JARM)
Peter: will take a look, thanks

Brian: Filip is right as usual, however only difference is that this is
ephemeral rather than pre-registered keys. Naive analysis is that this
might not get the security properties you are after. Subtle bad things
emerge always, unfortunately
Peter: thanks!

Next steps

Digging in and looking further (especially at JARM)

AOB

Chairs: any other business? (seeing none) Thanks all, see you tomorrow!

IETF 120 - OAUTH 23-07-2024 1530

Agenda

Identity Assertion Authorization flow

Extend the SSO experience to API Access
AS will control the data shared in between the services through OAuth2
needs Token Exchange and JWT Authorization bearer token
The out of scope was how to get the token, in this case it will be
addressed in this draft. The initial token is obtained via an SSO flow.
The client goes to an Identity provider that then it provides a JWT
Authorization Grant oken with defined claims.

The custom JWT Authorization Grant token can be used to get an access
token, which may be too powerful. They are trying to make the JWT human
readable and simple, and the user id is small. There is no reason that
user id must be consistent between calls. The client then uses it in a
JWT Assertion Authorization Grant. The Token Response from the Resource
App's Authorization Server the same token as before.
The implementation status, Okta has a developer branch that people can
request access to. Atlassian also has a implementation prototype.
Additional companies are also under discussions.

From the enterprise view is where we tend to strive to outline, but
there are others. For example the client workflow becomes cleaner.

Atul: Pretty cool stuff. You would bind the JWT authorization request to
the client so that the IDP knows that the right requester was serviced.
The client is going to request different scopes for different workloads.

Yes there are multiple access tokens in scope and our recommenadations
are to only request the minimum permissions needed and not worry about
future requests.

George: If the subject identifier was given to lets say Slack or
whatever. The identifier collisions are then possible.

The JWT, which is a user ID in it is a user ID bound to the issuer.

George: Since it is not an ID token, we should update the draft to say
that.

George: If I can mint one of these authorizations granges, I'm going to
get SSI.

Justin: Asking to clarify the workflow. Why don't we hand back an access
token directly.

There are different trust zones.

None of the policy is not part of the spec, but it is a deeper
discussion.

OAuth Profile for Open Public Clients

The Problem: The IETF has spent a lot of effort over the years to refine
standard protocols. The problem is the authentication. At the moment it
is username and passport. That is not acceptible for 2024

Currently it hard-coded in most e-mail client. So last year Fastmail
organized a proposal off oAuth profile.

First we get an authorization server metadata, that issue is
untrustable.

So they are mandated Pixie using SHA-256 hashing of the code challenge.

This is predicated on autodiscovery and define scopes. The scopes using
J-Map capabilities, because that covers things like access to mail or
whatever.

This then flows into iPam or J-Map or whatever.

Kristina: We have prior experience in this space and defining one
profile led to a prolification of others. What was the criteria did you
come up with and why?

It is specifically for native clients as D-Pop is not mandeated because
it is only defined to work with HTTP.

Kristina: The actual details I am looking for is the level of security
that you are asking for, versus web or native applications.

Ben: I am for this subject but has huge reservation about dynmaic client
registartions on multiple levels. I'm trying to register with Google and
Microsoft and it has been impossible. There is a lot of red flags here
as well, as the need an access token requires dynamic registration which
is a catch22. I would rather call for OPEA which is simpler. then we are
bsically on the same level with IMAP, when we lock down username and
passwords.

Its simple transition if you look at it as a profile is very restricted
and basically may choose to ignore that.

Ben: Still not clear what clear why this is important, nor the value. It
is overly complex. My object is to make it more reliable.

Hannes: It looks like we need to look deeper into the implementation. If
the dynamic client registartion is like you request something and you a
token based on nothing.

Some of this is more not only is it simpler for the client, but whether
the server can leverage it at a finer grain to lock down or deny
activity.

Aaron: We are going to see more and more of this type of want. Where is
the best place for this activity to happen? Should it be in the OAuth?

Hannes: The answer has varied over time, but depending on the current
appetite may be within OAuth. This is worth an interim discussion for
the group.

OAuth Status Assertions

The status check can be done to the identity of the wallet, instead of
the identity of the individual. It can also flow into short-lived
credentials

The holder can request a status Assertion. You are basically presenting
a hash over the credential and the issuer can respond with a status. The
status format was nebulous but there is some clarity happening. Getting
status assertions can be multiple per a set of hashes and communication
is between the Holder and the status service.

There is an open issue regarding the use of D-POP and proof of
possession.
There are two type of responses, error and status. This a little bit of
ambiguity around when to use error and something they want to clarify.

Mahmoud: You are working on two workitems one regarding multiple
statuses at the same time?

Asked to comment on PR 61. The confusion that can arise with that can be
confused.

Mahmoud: Can I check the the status after the consuming?

Orie: When you get these status assertions come with addition metadata
which can include the Time To Live etc. Each status assertion has a
validity period.

Kristina: Not happy with the wallet fetches the status list, but knowing
the authors I have given up on the trying the persuade them. I suggest
that them outline in the same document a section that clearly outlines
when to use with each approach and that compines multiple mechanims. She
would not be in favor of keeping them separate.

The example of CRL and OCSP both exists that ship may of sailed.

Giuseppe: We designed a way to monitor status of credentials over time,
even outside of the scope of the user. There are good reasons for having
this as a status list, and may get too big.

John Bradley: Is skepticism of this approach. Most of the verifiers will
want this information stapled someway. Is it going to be done in this
draft or another.

Opinion is that this should be in this draft.

John: This is going to limit us to SDJW.

Atul: Is there a way for the requester to be authenticated.

This should be in the draft.

Justin Richer: Both of these violation the core privacy tenants that are
promoised by the SSI folks. We need to be very clear with the security
and privacy properties that they give.

There are different elements of picking your poison, and there is a good
privacy consideration section and everybody should review that.

Giuseppe: The first one is the status of the serach prove to the wallet.
We have also implemented this in Italy.

Richard: It is fair that this is re-inventing PKI. We have a better
handle on privacy than PKK ever did.

Hannes: We should reference previous related work. Specifically those we
are replicating.

OAuth Identity and Authorization Chaining Across Domains

Describes a Mechanism to perserve identity information and federate
authorization across Trust Domains that use the OAuth 2.0 Framework.

We describe a token client exchange in the first domain which returns an
authorization grant JWT. This is then presented to the Authorization
Server in the second domain. This then returns an access token for that
domain which can be presented to access a protected resource.

This was presented to the WIMSE working group. There is a lot of overlap
on concepts between the two. In draft 2 that stated not to use RFC8693's
request_token_type. Just trivial changes.

Open Issues & Requests were in the single digits. Like: sender
constraining mechanisms, allowing identity chaining with DPoP tokens.

The group spent a lot of time on sender constrained. DPoP and the burden
of proof. Getting to concensus is a difficult.

Checking the binding on inbound token of Token Exchange request. No
standard has been defined. It might be even feasible or make sense
depending on the deployment. The RS acting as the client doesn't have
access to the bound key. No solution proposed.

The binding of the token returned from Token Exchange could be MTLS or
have a DPoP header, which is implied by the standard, but not explicitly
written down.

The recieving of the access token request, also leaves a lot to the
imagination. The presense of the cnf claim might be sufficient to say
the thing is bound and suggest\require checking it.

On the access token request to the Authorizaton Server in the second
domain, implies that it should\could be bound.

In another scenario that is not covered is when the first Resource
Server itself acts as a proxy to the second domain for the client. The
text in the specification becomes unclear. Whether we want to do this,
raises the question of using the assertion that basically states trust
me.

Justin: The AS acting as client throws several wrenches into the works,
but we have seend this before with token binding.

IETF 120 - OAUTH 26-07-2024 1300

Note takers: Heather Flanagan, Justin Richer, George Fletcher

Chairs update – Rifaat Shekh-Yusef/Hannes Tschofenig (5 min)

Hannes took a picture. Brian's was better, but Brian says Hannes took a
good picture. 📸

Attestation-based Client Authentication - Paul (20 min)

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

Focuses on how a client can push an attestation as to its authenticity
to an Issuer in the Issuer-Holder-Verifier model

In scope, the syntax and structure of the attestation and
proof-of-posession attestation

Out of scope is the protocol between the client instance and the client
backend service

Desire to avoid Dynamic Client Registration with the AS

  • single client software would have many instances

Changes since IETF 119

  • add text on the inability to rotate the Client Instance Key
  • no longer using RFC7521 and client_assertion and moved to using
    new HTTP headers
    ** allows conveyance of the attestation/PoP-attestation to
    endpoints other than the /token endpoint

new syntax removes squigglies!

DPoP Optimization - The DPoP Key and the Client Instance Key MUST be the
same

  • the optimization would allow a DPoP proof header in place of the
    Client Attestation PoP (based on some rules)
  • discussing the pros and cons on the list

Also concerns over naming (use of the term 'attestation') from the RaTS
working group

  • alternate proposal-> Key-bound JWT Client Authentication
  • add comments to issue #71

Discussion

Pieter: DPoP Optimization

  • dangerous precedent to use the same key for client authentication
    and proof of possession
  • basically, the same key is being used for two distinct purposes

Brian: DPoP Optimization

  • is ok with the optimization
  • this feature is optional and doesn't need to be implemented

Chairs: DPoP Optimization

  • do we have any security proof of this change
  • answer: no, not really

Kristina: DPoP Optimization

  • feels it does make sense for simplification / optimization
  • in the German wallet effort there are lots of keys
  • in the work with the EU wallet effort, no concerns have been raised

Filip: DPoP Optimization

  • likes the optimization
  • has concerns about the optionality of the feature which may cause
    issues in implementations
  • can we make the optimization manditory

Justin: DPoP Optimization

  • feels like this could go sideways
  • hasn't identified a concrete way for it to go sideways
  • recommendation to approve the optimization and then define a
    concerns in Security Considerations

John: DPoP Optimization

  • likes the optimization
  • probably should reduce the optionality of implementation options
  • more keys doesn't always mean better security
  • in this context fewer signatures is better

Chairs: DPoP Optimization

  • is the DPoP key in the hardware security module? or elsewhere?
  • there is a cost to doing signatures from hardware stored keys

Tobias: DPoP Optimization

  • <>

John: DPoP Optimization

  • want the same level of security for all keys

Filip: DPoP Optimization

  • would prefer to not support the optionality

Paul: DPoP Optimization

  • there is an explicit request to use the headers with other endpoints

Filip: DPoP Optimization

  • only wants the optimization when DPoP is in use

Brian: DPoP Optimization

  • has been told there are real world use cases for wallets that want
    to use a less secure key for DPoP proofs over the client attestation
    key

Orie: Attestation term

  • just use the term assertion instead to remove conflict with RaTS
    working group

John: Attestation term

  • RaTS didn't invent the term attestation
  • ask the AD if it's ok to have a different interpretation of the term

Kathleen:

  • there may be less concern about definition of the term over the use
    of the term in general
  • outside the crypto community, attestation has a different meaning
    (auditor process)
  • probably ok to use the term, but realize there may be other
    misunderstandings with the use of the term

Token Status List - Paul (20 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/

Mechanism for managing token status across a distributed set of clients

how it works: status list bit array returned from server, provides an
index into the compressed array

Changes since IETF 119

  • lots of editorial changes
  • added validation rules
  • status list aggregation mechanism
    • allow the client to do caching of status lists

Unsigned Option

  • considering removing the unsigned option

Targetting IETF 121 for WGLC

No plan to merge with status assertion

Discussion

Brian:

  • recommend to only support the 'unsigned option'
  • doesn't see a need for these lists to be signed
  • if signed option is required do it in the CBOR effort

Roy:

  • is there still an option to control the life time? <-- yes

Jeff:

  • concerned with complexity of the solution and the requirement to
    manage large arrays that don't have value to the client
  • Solving CBOR and JSON in the same RFC brings complexity - reemphased
    by Kristina. Is the CBOR community even interested into that?

Richard:

  • believes we should absolutely sign these lists
  • avoid runtime dependencies

FedCM Profile for OAuth - Aaron (20 min)

No draft at this time

Problem

  • lots of different ways to track users via web browsers
  • two in scope are third party cookies and link decoration
  • OpenID Connect uses both these features
    • form response mode, iframe silent refresh, ...
    • OpenID Connect, OAuth and SAML all use link decoration

Two groups within the W3C to address tracking and federated identity

  • Federated Identity Communbity Group
  • Federated Identity Group

FedCM

  • protocol being standardized in the Federated Identity Group
  • primarily developed by Google Chrome
  • makes the browser a trusted actor in the identity flow
  • FedCM implementation examples (IDPro webinar, 10 July 2024):
    https://youtu.be/0OjdqldRvXo?si=O9UIU1VKK4G3lkWS

Cross-Site Cookie Access Credential

  • much smaller surface area of an API
  • primarily developed by Mozilla; should be in a beta version of
    Firefox real soon now

OAuth Profile for FedCM (not ready for an I-D)

  • https://gitub.com/aaronpk/oauth-fedcm-profile
  • treat it as an authorization endpoint that returns an
    authorization_code
  • allows for support of confidential clients and OAuth features like
    PAR
  • Put OAuth parameters in the params parameter
  • Returned "token" is an authorization_code
  • Browser then makes a normal JS call to the /token endpoint to get
    tokens
  • Filip: can use any response_mode allowing protocols like FAPI

What is the best way for the "params" object to work in FedCM?

  • feedback requested by the Federated Identity Working Group
    • issue #556

See slides for other important issues in FedCM related to OAuth

Discussion

Dick: how relevant is this going to be given chrome is not going to
deprecate 3rd party cookies

  • Aaron: can change the priority of the effort
  • Aaron: can improve the user experience and work will likely continue
  • Doesn't seem like

Tim:

  • file an issue
  • Dick: has already filed an issue
  • FedCM may be more important as the browser behavior will be based on
    user consent

Heather:

Kristina:

  • very similar to work done in OpenID4VP for the Digital Credentials
    API
  • similar to the last option

Proof of Issuer Key Authority (PIKA) - Richard Barnes (20 min)

https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/

Problem

  • not all use cases have consistent internet connectivity
  • JWT lifecycle can sometimes be problematic
  • containers need to know about the state of the signing keys in the
    past

PIKA Chain of Trust

  • JWT containing keys and signed by the X509 cert (with chain?)

There was a call for adoption post IETF 119. Feedback from the list

  • Issue 1: general movement away from X509; this proposal cuts against
    this trend
  • Issue 2: Security considerations using Web PKI certificates for PIKA
    signing

Call for adoption: Official request will be on the mailing list

  • Vote: 11 yes, 3 no, 9 no opinion

Discussion

Roy: why wouldn't SCITT (https://datatracker.ietf.org/group/scitt) and
counter signatures work here?

  • Richard: not familiar with that technology

Leif:

Filip:

  • concerns regarding the ability for implementation
  • Richard: introduces implementation challenges
    • would need additional work from verifiers

Atul: is this a "certificate" for the JWT issuer key(s)

  • Richard: basically, yes
  • how to revoke the PIKA "certificate"
  • Richard: nothing in the draft... maybe status list? needs to be
    addressed
  • Not sure we need a new certificate format
  • Richard: this is extending x509 into the application domain

Pieter:

  • this is a problem that needs to be solved
  • appreciate on the security updates to the draft
  • happy to work with Richard on the draft

AuthZEN Profile of OAuth RAR - David Brossard (15 min)

https://datatracker.ietf.org/doc/draft-brossard-oauth-rar-authzen/

Not related to the RAR discussion at IETF 119 (re: CEDAR profile for
RAR)

AuthZen is under OpenID Foundation (OIDF)

  • protocol between the Policy Enforcement Point (PEP) and the Policy
    Decision Point (PDP)
  • 12 implementation of the protcol with completed interop between the
    participants

Is there room for an AuthZEN Request/Response Profile in RARs?

Looking potential relationships with Transaction Tokens and other OAuth
options

Discussion

Darin: You can pass in AuthZEN content when requesting a token. Most RAR
profiles represent scoped down permissions; that doesn't seem to be
represented in the spec. Unclear how it would solve certain problems?

  • David: may not entirely understand the RAR spec.

Darin: then there's a slippery slope in the policy. Will take this to
the list.

Justin: interesting work, primary use case of RAR is the client having
more expressive way to define what it wants access to... a more
expressive way to deal with scopes

  • however, the introspection endpoint was about how to add context to
    the results of the token
  • probably space for both the cedar proposal (return executable
    policy) in addition to this proposal
  • there are lots of dragons down this path but also value

Jeff:

  • RAR is full of open banking examples
  • SMART on FHIR has added a RAR profile as an experiment

Atul:

  • slide 9 -- associated with RAR
  • David: no, this was just a possible architecture that would include
    a PDP
  • David: the use of the profile would be between the client and the AS

ALFA 2.0 Authorization Policy Language - David Brossard (15 min)

https://datatracker.ietf.org/meeting/120/materials/agenda-120-oauth-05

Long history of authorization techniques

ALFA - Abbreviated Language for Authorization

  • implements RBAC, ABAC, ReBAC

Why ALFA 2.0?

  • get rid of baggage
  • make a proper authorization policy language within a standards body
  • promote re-use for authorization policy

Next Steps

  • live in its own working group? part of OAuth?

Discussion

Justin: it might make sense in another working group within the IETF, it
definitely doesn't live in OAuth

  • when you bring an existing technology to the IETF it will be changed
    significantly in the working group

Jeff: Cedar is not an AWS technology and is not restricted to the AWS
infrastructure

Richard: +1 to Justin's comments

Darin: (works on Cedar) will this new policy end up being a full
"programming language"... will this solve anything or just be another
language

Yuan: What's the relationship with AuthZEN? Is it working in parallel?
How does it connect to oauth?

  • AuthZEN is not orthogonal; it's parallel. They don't dictate model
    (graph, RBAC, ACL), just interface. AuthZEN does not deal with the
    policy; it does not want to be in the middle of standardizing
    policy.
  • Next step: go to DISPATCH