OAuth WG

IETF119

Wednesday

Note-taker: Justin Richer, Pieter Kasselman

SD-JWT

Presentation:
https://datatracker.ietf.org/meeting/119/materials/slides-119-oauth-sessb-sd-jwt/

Brian gave an overview of the SD-JWT mechanisms

it's a hash-based mechanism for selective disclosure

aims to be easy to use for familiar algorithms

structure:

• regular old JWt with a bunch of tildes afterwards
• payload has salted hashes of disclosures
• can't brute force hashes to get values

to reveal:

• take original JWT, keep only one disclosure (signature does not
  cover disclosures on the end)

also a key-binding JWT (KB-JWT)

• can add a whole extra JWT to the end that proves posession of the
  key encoded in the JWT

new since last time:

• See ful list on slides - highlights below
• Added info on salt entropy - random number genretation is hard.
• improved references and registrations and examples
• KB-JWT claim name change
• edge cases for tilde~separated formats
• Improved unlinakbility considerations
• removed explicit prohibition of HMAC

Open Issues:
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues

• Redesign JSON serialization
• JSON serialixzation not binding cover key binding: Intentionally
  remoed in a previous draft
• Seperate token and presentaiton format - will be discussed in detail
  later
• Recursive reduction
  • Richard Barnes - may not be editorial only

Discussion items

• PR394: SD-JWT has different security properties depending on whether
  KB is present or not.

  • Kristina in chat: tl;dr for this most important PR:
    https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/394
    terminology is changing: now issuer-signed JWT + Disclosures are
    called SD-JWT and adding KB JWT to that will be called "SD-JWT
    and KB JWT" (SD-JWT~KB for short)

• PR 414 Revisiting JSON serialization (again)

Next Steps:

• Brian: Not ready for WG-LC (but probably close)

Peter Liu: use cases for comparing age to threshold; is there an
algebraic formula for disclosure?

• from chat, "no", you need a new claim

Brian: no, you can expose the whole birthday or add new claims like
age_over_21 and disclose only that

Richard: thanks to the authors, have pushed a ton of issues and they've
been great

Use of extra time:

1. Mike - suggests not distinguising between SD-JWT and SD-JWT+KB.
   Richard asserts that it is required because security properties are
   different. Brian suggest clarification. Richard - guard against
   mistakes by implementors, make it hard to get confused. Mike - it is
   more than terminology. Using a different media type does not mean
   that there is a ky binding. The verification still has to be done
   seperately. Argument is that a media type does not guarunette
   correct implementation. Brian - media type is not intended to have
   security proerties or help with binding. John Bradly - it is
   dangerous to have the media type suggest a security property.
   Richard - Need to guide to different implementations because they
   have different security proeprties. John Bradly - talk anout them as
   seperate things makes snese. Different media types may not help.

OAuth 2.0 Protected Resource Metadata

Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-oauth-oauth-20-protected-resource-metadata/

Presenter: Mike Jones

What is this for? See the last presentation from IETF118

Change ssince 118:

• now compliant with .well-known path construction (in the middle)
• changed to returning resource_metadata instead of resource
  identifier

All known issues are addressed

Time for WG Last Call?

Chairs: Will start WGLC after meeting

Kristina: how much implementation experience?

Mike: All OID Fed use it

Kristina: it's mandatory?
Mike: yes

Atul: This is useful in the context of SSF as well; this makes it
possible for RS to get a token far more capable than what it needs

Hannes: will you review during WGLC?

• atul, pieter, monty, philip

Browser-Based Apps BCP

Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-oauth-sessb-browser-based-apps-bcp/

Presenter: Aaron Parecki

What is it?

• include recommendations for in-browser-execution, or SPA, both with
  and without backend component

Major re-structuring (main changes)

• list of threats/attacks, and what happensn if those attacks are
  successful

• then going through patterns and how they solve attacks

  • BFF, TMI, fully in-browser

• clarifications on cookie encryption

• postmessage considerations

Next Steps:

• WG Last call?
• Justin - not objecting, just some comments
  • It is a strong and needed document
  • Lots of comment on the text structure
  • All about clarification
  • Editorial debries - no objection to going to last call.
  • Expressed full support for document

Chairs will issue WG LC
- Justin (already done, not doing it again), Tim Cappalli, Andy

Transaction Tokens

Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-oauth-sessb-transaction-tokens/

Presenter: George Fletcher

what is it?

• goal is "how do you manage authz & transaction immutability w/in
  boundary"
• talked in detail at WIMSE on monday
• subject, context, authz details
• Supports least privelage/zero trust architectures

changes:

• moved away from sub_id and back to straight "sub" claim
• sub is bound to "aud" not "iss"

• workload identifiers

  • each time you request one, append to array
  • explicitly not a path
  • should do path outside of tx token

• token request

  • can be both internal and external
  • is a profile of oauth token exchange

• request processing at TTS

• creating replacement tokens

  • additional processing rules for sub/aud and workload identifier

• added section on passing tokens between servers

  • Question - should we have a new HTTP Header for passing
    TxN-Token for HTTP requests
  • hand-waved about this in draft

• updated security considerations

  • authentication is out of scope

Issues https://github.com/oauth-wg/oauth-transaction-tokens/issues

• How to us txn-token in long running batch request

• Shold we separate transaction tokens from other formats than JWT

  • WIMSE, protobufs, how to use with SPIFFE

  • Justin: Initial motivation - architectural cleanliness. Format
    and data model for th token, format and protocl for exchanging
    token. All is rolled together. Are we tying it together out of
    convenience, or do we need abstractionpoints. . Combines format,
    data model and binding.

    • WIMSE discussions have been ongoing. Can this be re-used in
      WIMSE environment. Is transactiontokens an instance of this
      etc?
    • There is a design team working on this. Justin invited
      George to join the design team. (reply to post on
      wimse@ietf.org list)
    • Goes beyond OAuth and Acces tokens. Efficiency may be one of
      them.

  • Dean

    • Consider Macaroons for downscoping. Text needs to cleared up
      around changing the purpose of the token.
    • George: Needs to be more specific about the processing
      rules.
    • Dean - Perhaps only ever downscope - seems like a logical
      choice
    • george: if you change the purpose, what is the integrity of
      that token is you move through?
    • would love to see real-world examples on the list

chairs:

• drop a note to the WIMSE list to review doc
• doc is in much better shape than it was, please review
  • yaron, joe

Brian: you do declare a header, you need to to through the process

• george: is it necessary to define that mechanism? if not then we
  don't need to go through process (pull it all out)
• in the half state, known to be a half-state
• feedback on list would be great

Atul: on header, good to decide, increase interop
Justin - Ask for early review from HTTP directorate. Can use
authorization header or custome header. George - May want to use it as
seperate header as authroization header is used for other purposes.

AJ Stein: Heads up to its authors, very minor thing: the transaction
tokens I-D in datatrack doesn't have the GitHub metadata on the page to
find the repo for this draft, so it could help to save me 1-2 Google
searches like the others (I lurk and getting my legs, not a frequent
OAUTH contributor yet or would have guessed the GH repo org).

https://github.com/oauth-wg/oauth-transaction-tokens/issues/72

Identity Chaining

Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-oauth-oauth-identity-and-authorization-chaining-across-domains-00

Presenter: Kelly

• Kelly provided introuction/overview.

background:

• sometiems an RS need to access another RS in a different domain
• need to consider needs of services in second domain
• need to consider when second domain is its own OAuth protected
  service

solution:

• uses token exchange and assertion framework

  • client has token in TD1, exchanges token in TD1 for grant in D2
  • exchanges grant in TD2 for token in TD2

• variations

  • RS as client
  • AS (1) as client

claims transcription

• needs to be relationship between AS's
• when final AS recieves token, knows how to process it

changes

• renamed to add "authorization"
• limited to using JWTs only
• additional use cases

open issues
https://github.com/oauth-wg/oauth-identity-chaining/issues

• Main issues highlighted
  • add sender constrained tokens - significant work, but needed
  • how the AS knows to generate a JWT Authorization grant

Aaron: curious about send-constraining mechanism; is there anything
that's unique to this?

• kelly: think there will be challenges across domains, like MTLS
  propagation
• aaron: would be usful to say anthing unique for sender constraints

brian: there's a lot of variations, depending on who's calling who and
chaining what that make constraining really difficult

• talking about it in any logical way gets hard

Pieter: we need to write down the scenarios and work through them one by
one; sometimes it's impossible and we need to be explicit why not

Identity Assertion Authorization Grant

Presenter: Aaron Parecki
Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-oauth-sessb-identity-assertion-authorization-grant-00

Profile of identity chaining across domains

• but you might be surprised to hear that given the use case

context/problem:

• enterprise SSO: user has single account to get to all applications
• API access between applications is a giant mess
• idp isn't a part of that workflow
• UX impact
  • embedded links in wiki page, can't fetch until user connects
    accounts between apps
  • lots of oauth consent dialogs, all look different
  • lots of friction
  • Goal: Extend single sign-on to API access

Building blocks:

• made up of two RFCs: token exchange and authz grant
• exchange assertion for authorization grant for access token

Why bother profiling?

• initial token is out of scope there, needs to be set as assertion
  here
• only identity tokens accepted
• needs more detail for interop

not imposing any new restrictions to final access token response

• assuming people already have some framework for oauth down at the
  end

status

• in dev @ okta
• deployed for live testing

George: sounds like we're bootstrapping on the id token to identify the
token and creating an access token off of that; in the sense of
accessing APIs

• George: do we need to add sender constraining? is there an
  impersonation scenario that would allow me to get tokens for other
  things?
• Aaron: clients are already registered with different AS's, can use
  the same sender constraining
• Aaron: sender constraining beyond security considerations would be
  useful
• Aaron: b/c there's existing relationships, that info is meant to be
  embedded into the grant; can't steal it b/c you need to use the
  client's credentials

Atul: could this be a profile of identity chaining and not a separate
spec?

• Aaron: it's meant to be
• Atul: thought it was different
• aaron: it was reworked; if you implement this, you're implementing
  the other one (100% within) with restrictions

Pieter: we may see additional profiles, keeping it as a separate
document makes sense; I think we will see 2-3 more

• Atul: Was not suggesting that it all be one doc
• Aaron: wanted to make it fit w/in the specs

Kristina: naming of the draft is confusing; aligning to make it more
clear

• Aaron: naming is hard

Atul: can this work also with SAML?

• Aaron: yes
• JWT only restriction is the assertion. Any token can be exchanged
  (including SAML)

What are next steps for WG adoption?

Chairs: let this cook a little bit, expect more reviews for other
document; if you find people who are interested outside Okta, that would
be a good indication for call for adoption

• Aaron: have two already, hopefully will report more in July

SD-JWTs Part 2

Mike Jones: read the PR and commented on it; in my mind, an SD-JWT with
or without KB is an SD-JWT, not a new media type

Richard: in some degree it's an optional feature, but it gives you
different security features; we need to make sure that the verifier
knows what properties they're getting

Hannes: wouldn't an attacker just change the media type? similar to
attack in LAMPS; from LAMPS, couldn't we incorporate something in key
derivation?

• something that relates to key derivation, or
• punt it, needs to be negotiated

richard: much like alg:none, if you arrange your policy you won't be
vulnerable, but people in practice don't arrange their policies

• make it more difficult to get wrong, make it difficult to confuse

Mike: it's not just terminology, there's a different media type, and
it's extraneous; media type doesn't add security properties

John Bradley: SDJWT has a confirmation method, receiver has to verify;
that's what drives whether or not it's key-bound SDJWT

• if there's a confirmation, you're supposed to check the confirmation
  method

Brian: media type isn't meant to be validatation

John: stronger argument for media type is for requesting, than for
requiring checking confirmation

Richard: we should never have an interface that you should shove either
SD-JWT and SD-JWT-KB

Brian: confirmation claim isn't the only way to express it, not the only
way to drive checking KB, can also be on policy

John: both types will be received over the same flow by the verifier

Richard: it needs to

john: but it doesn't right now

Kristina: don't want to solely discuss on media types

• first part is clarity, splitting makes it clearer
• agree w/richard, good to separate from privacy perspective
• disagree w/john, verifier needs to distinguish
• KB becomes one of the means

Joe: being able to differentiate makes it clearer how to apply policy,
seems like a good idea

Mike: fine with clarity, don't need explicit syntax for it b/c you have
to check it

Kristina: then why do you need JWT types?

Mike: 'typ' value is part of the signed structure, but recipient only
gets value from it by checking it at runtime for checking it

• kristina's right, its' exactly parallel

Brian: media type is just naming to signal this

Kristina: specific example uses same value

Chairs Summary

Hope we have spare time to continue this!

Thursday

Notetaker: George Fletcher, Pieter Kasselman, Yaroslav Rosomakho

Interim OAuth WG meetings

• Interim working group meeting being planned. Watch the list for
  updates. FedCM group to present Federated Credentials Management API
  and solicit feedback
• 2.nd International workshop on Trends in digital identity (10-11
  April - Rome, Italy)

SD-JWT VC

https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-oauth-sessc-sd-jwt-vc

• Daniel Fett presenting
• Reviewed new additions for 02/03

• What's next

  • EU Digital Identity Wallet - Architecture Reference FRamework
    (ARF)
  • Requires VCs (W3C VCDM 1.1) and SD-JWT
  • Needs to resolve these two requirements (best of both worlds)
  • JSON-LD may not always be needed.

  • SD-JWT VC as the proposed solution

    • SD-JWT VC (small changes) with Type Metadata
    • Open world modeling
    • VCDM 2.0 compatible
    • JSON LD supported, but not required

  • Defines set of required and optional claims

• How to get there

  • Uptates to SD-JWT VC (metadata, extension points), SD-JWT (JAdES
    compatibility) and ETSI JAdES (profiles)

Hannes: Where is the proposal? Daniel to share. Type metadata.

• https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/220

Questions:

• Mike Jones: generally we take approach of ignoring things that you
  don't understand - how would this work for SD JWT VC.

  • Daniel - idea is to give flexibility and options

• Hannes: How to ensure use cases outside of the EU are covered?

  • Daniel - have website with proposal. Other use cases need to be
    considered. Call to the working group to review and ensure other
    use cases are covered as well.
    • https://github.com/danielfett/sd-jwt-vc-dm

Token Status List - Tobias/Paul/Christian (30 min)

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

• All three authors presenting
• Christian provided overview of the problem and architecture
• Changes include support for unsigned status list, ttl claim to
  support caching and addition of COSE/CWT/CBOR encodings

• Unsigned status list support

  • Delegate protection to TLS
  • Similar to OAuth metatdata
  • Enables status list repudiation

• Discussion: Provide all StatusLists

  • load all status lists at the beginning of the data to enable
    offline verification throughout the day

• Discussion: Identifier list?

  • Increased demand for a simple CRL-like mechanism
  • Add to status list draft or start a new draft?
  • Seeking WG feedback on this topic

• Discussion: status IANA registration?

  • Separate registries for JWTs and CWTs?

• Comparison of status mechanisms

  • Maybe a separate information RFC for this?

Questions:

• Orie Steel - Header vs payload discussion is interesting

  • may want to look at head to determine status first which may
    allow for ignoring the payload
  • should we have an ordered processing mechanism?
  • Tobias: leaving it open as to where the underlying claim may
    exist
  • likes the potential of CWT claims in header
  • Brian: JWT is not that flexible for putting claims in headers

• Pieter - add security considerations for not signing status list

  • Christian: comparison of revovation mechanisms - informational
    RFC?
    • favoring a new draft to define a more CRL like mechanism

• Kristina - would like it to be the same draft

  • if an extension of the same mechanism would prefer not to have
    two different drafts

• Nick - similar concept in the W3C

  • concerns around malicious status list providers
  • are there mitigations that can be deployed?

  • verifiers and probably not detect if interacting with a malicous
    status list provider

    • need to be clear about the complexity we are expecting the
      verifiers to implement to protect against these sorts of
      "attacks"

  • Paul: addressed some in the Privacy Consideration section

  • Tobias: can describe recommendations for verifiers for how to
    detect
  • additional work required by the working group

• Ray -

  • no error correction detection mechanisms
  • get the indexs off by one could be problematic
  • Hannes: digital signatures are a good error detection mechanism

• Reviewers for the document

  • Nick Doty

Attestation-based Client Authentication - Tobias/Paul (20 min)

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

Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-oauth-attestation-based-client-authentication

• both authors are presenting
• support for "public" clients where pre-registration is problematic

• two proposal

  • use DPoP for the PoP syntax
  • support a header based syntax
    • enabling use in other contexts

• Is there an option to make better use of DPoP

  • under consideration and exploration

• Use of attestations outside of client authentication

  • at the RS
  • as part of Dynamic Client Registration (DCR)

• Discussion:

  • DPoP key and client instance key MUST be the same
  • do these keys need to be different or is that unneeded
    complexity?
  • time sensitive as an interop event is planned for April

• Questions:

  • Muhammad - related to work in RaTS working group

    • Paul - terminalogy is very different from the RaTS working
      group
    • Hannes - attesation result
    • would be good to get terminology synchronized

  • Justin - client attestation is NOT client authentication

    • need to be clear
    • the separate header proposal would help address concerns
    • use of squigglies [tilde (~)] to combine JWTs may intrduce
      security or interoperability risks.
    • DPoP keys are intended to be "instance" keys, some concerns
      with using DPoP for generic PoP use cases

  • Brian - DPoP is intended for proof of an instance key, and this
    is such a case

    • better off to just define the headers and not reuse the
      client assertion framework
    • Justin: is this an instance key in the same way?

  • Aaron - likes the header approach

    • also would like to avoid tidles (~)
    • if it's not a DPoP key probably shouldn't use a DPoP header

  • Hannes

    • Caution against viewing this a greenfield, there are
      existing atteestation work already that can be used.

  • Kristina -

    • plus one to what Justin & Aaaron are saying (only use DPoP
      header if the instance key is a DPoP)
    • there are other use cases where using a DPoP header doesn't
      make sense

  • Tim (in chat)
    Putting question in chat since I don't think we're going to
    have time.

    Using Play Integrity as an example, those statements are only
    available to app owner, and aren't intended to (and in some
    cases can't) be shared across party lines.

    WebAuthn addresses this with a set of predefined attestation
    formats that are intended to be shared between multiple parties.
    These attestation semantics also address the concerns around
    sharing identifiers across parties.

    So how does this work in practice while preventing a user from
    being tracked across parties?

    Is there another document that talks about the actual use of
    these attestations and defines the contents of the JWT?

Nonce Endpoint – Orie (20 min)

https://datatracker.ietf.org/doc/draft-demarco-oauth-nonce-endpoint/
Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-oauth-sessc-nonce-endpoint-status-attestations

• Both authors are presenting
• What is the Nonce and why it is important
• Examples of /nonce endpoint

• intended for use beyond OAuth and JSON

• Questions:

  • Hannes - concept of scope and aud are OAuth specific

    • other uses have other requirements for nonces (e.g. size of
      the nonce)
    • as is, it's not useful for RaTS
    • Orie: scope and aud are concepts rather than the specifics
      as it relates to OAuth

  • Ray - looks a lot like the NIST randomness beacon

    • difficult to design - non-trivial effort
    • recommendation to review

    • link:

      • NIST random beacons:
        https://csrc.nist.gov/pubs/ir/8213/ipd

    • My opinion is that a nonce must be generated at a very low
      level and locally and not obtained from a server.

  • Pieter - how to use in the context of a transaction

    • may be a benefit to document how to design a good quality
      nonce
    • Orie: primary object is to give that guidance on generating
      good nonces
      • secondary - provide an implementation/end point.

  • Brian - provisioning-by-error

    • in OAuth this is convenient as part of the challenge
      response flow
    • provisioning-by-error can be useful

  • Justin - concern with the value of the spec

    • nonces are useful within a specific context
    • concern that by separating the nonce from the context
      creates confusion for protocols and implementations

  • Mike - responding to a comment by Brian

    • when doing OpenID Connect the relying party provides an
      nonce value
    • used to prevent substitution attacks

  • Aaron - I just wanted to point out the massive difference
    between client-generated nonce like OpenID Connect and
    server-generated nonce like DPoP

  • Refer to meeting chat for more comments/feedback on proposal.

Status Attestation – Orie (20 min)

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

Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-oauth-sessc-nonce-endpoint-status-attestations

• Orie is presenting

• What is the Status Attestation, its purposes and benefits

• Questions:

  • Hannes - restandardizing PKIX mechansisms ?

    • Is this something the working group wants to take on
      (in-charter)?

  • Monty - terminology

    • don't overload the term attestation
    • need to resolve terminology (especially between OAuth and
      RaTS)

  • John - likes validity stapling

    • concerns around colluding Verifiers and Issuers

  • George

    • Is this a problem (colluding parties) we really need to
      solve?
      • I'm concerned with the complexity pushed into the
        overall solution

• Working group encouraged to read the document and provide feedback
  on the list

JSON Fine Grained Access - Jiangcheng (10 min)

https://datatracker.ietf.org/doc/draft-zhang-jose-json-fine-grained-access/

Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-oauth-json-fine-grained-access

• Jinling presenting remotely

• Hannes provided a link that may be similar to this proposal
  (RFC9237)

• Related docs:

  • https://datatracker.ietf.org/doc/rfc9237/
  • https://openid.net/wg/authzen/
  • https://ucan.xyz/
  • https://datatracker.ietf.org/doc/html/rfc9396

• Questions:

  • Ray - how does this work relate to the RAR specification?
  • Atul - broad proposal
    • the AuthZen in the OpenID Foundation is also working in this
      space: https://openid.net/wg/authzen/
    • proposal may be too broard

Friday

Notetaker: Mike Jones, Yaron Sheffer

Cross-Device Security

Pieter Kasselman presented about
https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/

Pieter summarized the problem being solved
Gave the example of QR-code based flows
Described attackers tricking the user
-05 added actionable guidance to implementers
(See the "How to use the draft" slide)
Top recommendation is to find a way to establish proximity
The draft enumerates formal methods evaluations on the topic
We need reviewers
Hannes asked whether we should start WGLC to elicit reviews
Pieter said that the purpose is to get feedback
Monty, Dean, Roy, Ralph, Hannes volunteered to review
Pieter plans to publish an update before the WGLC starts

OAuth 2.1

Aaron Parecki presented about
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/

Aaron summarized changes since IETF 117
Aaron discussed confused implementations of ClientID+ClientSecret
encoding
He asked whether we should restrict the client_id and client_secret
syntax to alphanumerics only to avoid this mess completely
Filip Skokan said that implementations faithfully implementing RFC 6749
won't interoperate with Google
Yaron said that allowing characters beyond alphanumerics would be useful
for discovery of secrets in logs and code
George Fletcher asked about migration
Justin Richer said that even if we changed the alphabet, Google would
still be noncompliant
... It doesn't bite you until it does
... Using the Authorization Basic header lets people get away with
different things
... :shrug:

Mike J.: My former employers' client IDs include special characters and
they're unlikely to change that.
... Also, we kinda committed not to change the protocol is 2.1.
... The fact that people implement the spec incorrectly is orthogonal to
what the spec says.
Brian Campbell: people are prefixing their secrets. Also, people using
URIs as client ID.
... I am skeptical of this change.
Michael Fraser: In Open Banking Brazil, the Client ID is the base URI
for the Federation.
Filip: learned about prefixing of secrets. Most interoperable is to
encode everything except some set of chars. LEt's continue the
discussion on GH.
Mike J.: OpenId Fedederation also uses HTTPS URLs as Client IDs
... We need to keep the full character set
Aaron: more discussion to be had.
... Presented a proposed timeline, WGLC by IETF-121.
... Expects lots more work resolving open issues
... A lot of work remains
Hannes proposes a virtual interim in June. Aaron concurs.

Cedar Profile for RAR

Dean Saxe presented about
https://datatracker.ietf.org/doc/draft-cecchetti-oauth-rar-cedar/

Individual draft proposing a RAR profile for the Cedar authorization
language
Usama: please say more on formal methods. Sarah: this is on GH.

Sarah C.: Repository online at github.com/cedar-rust
Dean: Primary use case to standardize a Cedar policy set
... Presented a set of open questions
... This is the first profile on RAR
Yaron: It doesn't need to work for Open Banking
... At the high level, the draft needs to say to which areas this is
going to be applicable
George Fletcher: One possibility is to embed the Cedar syntax in my
access token.
... Take the RAR input and transform it into Cedar policies.
Ralph Bragg: ISO standardized a format for financial services
transactions.
... I can't see them updating these to adopt Cedar.
... In most cases the RS and AS are owned by the same domain.
... The Access Token is opaque to the RS.
... Introspection for a RS versus an RP is different.
... This can add complexity.
Brian: The whole idea of RAR was to provide a bucket that you can put
stuff in. What it is is indicated by a type field.
... Use cedar-policy.com as the type value
Justin Richer: The idea behind type in RAR is to specify what's in the
RAR data structure.
... I believe this is just syntactic massaging of what you already have.

Brian: Less syntactic is whether this makes sense.
... You can put Cedar policies in your Access Tokens without RAR.
... The idea behind RAR was to give the client a rich language to
express what it's requesting authorization for.
... I don't know that the client needs to be exposed to Cedar policies.

(There was back-and-forth between Dean and Brian about the nature of the
interactions between the components.)
Sarah: The client may not know what it has access to.
Brian: I'm still not clear on the need for the Client to express Cedar
policies. It feels like there's a disconnect. It's profiling the wrong
building block provided by OAuth.
... You don't need RAR to embed policies in the Access Token.
Brian: It feels more like an Access Token profile - maybe with a broader
scope.
... Enabling a flow between the AS and the RS.
Michael F: (Talked quickly about translating between things) Cedar is
probably too complex to use near the end user, and translate the Cedar
policy into UI. Reiterates that this is more appropriate inside of the
access token.
Pieter: This graph shouldn't be extensible to other policy languages.
... Are you planning to bring Cedar into the IETF to standardize here?
Dean: An open question is how to normatively refer to Cedar when it's
not standardized by an SDO.
Hannes: to be investigated.
Dima: The client doesn't need to know the policies. There is some
utility to sharing this information in a closed ecosystem.
... A bit of "why" could help.
Atul T: Policies can be longer lived.
Dean: As you know from the AuthZen WG, there's a lot of work on
externalizing authorization.
Hannes: This has triggered a good discussion. I suspect you have enough
information to update the document. We'll be coming back to this.

First-Party Apps

George Fletcher presented about
https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-apps/

George described what is happening today.
Described flows, goals, and reusing existing things.
Proposes a new Authorization Challenge Endpoint.
.. Accepts parameters that would have been in the query string to the
Authorization Endpoint.
... Described why a new endpoint. PAR is very specific about how it's
used.
... Expected to be executed in a Web context.
... Described changes since IETF 118
Sent a message to the list about a generic OAuth POST request framework

... Didn't see any interest
Feel like spec is good enough to ask for WG adoption
... Could also describe how to use PassKeys for authentication
Hannes: I'll do a poll on who has read the draft.
... Yes: 5, No: 12, no opinion: 1
Hannes: Maybe we can recruit more reviewers, then do a call for adoption
on the mailing list.
Yaron: Are there specific implementations?
George: I don't know of specific implementations.
Yaron, Filip, and Ralph offered to review
Hannes: I'm reluctant to pull the trigger on adoption during the last
session, given low attendance and tired participants.
Brian: It feels like there's not a lot of reviewers and low energy, so a
call for adoption seems unwarranted.
Hannes: This feels like one of a series of recommendations for a
specific environment.
Brian: This is a whole new protocol. The other things like Browser-based
Apps were codifying existing practices.
... I did read the prior draft and my feedback has been largely
addressed.
... So I am involved.
Ralph: The industry is very lacking in guidance on first-party
applications. If anything, the need is getting more and more pressing.
... A standard to facilitate adoption would be great.
... There are four markets going live in the Middle East.
Roman: I'd like to see this problem solved. That said, I'd like it go
further before we do a call for adoption.
George: That's super helpful.

Global Token Revocation

Aaron Parecki presented about
https://datatracker.ietf.org/doc/draft-parecki-oauth-global-token-revocation/

He described apps and app backends
... This adds a new endpoint at the AS
The goal is a lightweight revocation endpoint
... There's no negotiation and no wiggle room
He did a survey of existing token revocation/logout standareds
... There's no standard doing what this is trying to achieve
Input to Global Token Revocation required to be authenticated
... Uses SecEvent subject representation
Outcome is that refresh tokens and access tokens are revokved
He enumerated changes made since IETF 118
There are implementations in progress
... He can only name Okta's at the moment
Aaron asked if it's time for working group adoption
Atul T: Can this be expressed as a profile of Shared Signals Framework
(SSF)?
Aaron: The main concern with that is that SSF has subtleties, versus
whereas this is started to be a clear signal causing a specific action.

... Signals from SSF could be part of the input to the decision engine
causing this command to be used.
Hannes: Only two people have read the document
.. It would be good to have people chime in the list about why they
think this is useful work

Signed JWKs

Richard Barnes presented about
https://github.com/bifurcation/redistributable-jwks/blob/main/draft-barnes-oauth-redistributable-jwks.md

He described the normal JWT lifecycle
... Relies on Web PKI
... Used by OpenID Connect
Seeing new patterns for Verifiable Creentials
What if the JWK Set is not available?
... It could be offline
... The key might not still be in the JWK Set
Stick an x5c in the header
Then can reason about whether the JWT is still valid
... No validate-time dependency
Mike Jones helpfully pointed out that OpenID Federation uses Signed JWTs

... The only difference is the x5c
... Redistributable proof of authority
It maps to a lot of use cases
It's super-early stuff
... It's in a repot - no published draft yet
Roy: There's a lot of overlap with what's being done by SCITT
... How do you do revocation in this model?
Richard: This is using an intermediate certification
... And you can do certificate-based revocation

Justin: What's the difference between just using the certificate and
using the signed JWK Set?
Richard: There's a discussion of this in the document
... We want to not perturb the JWTs that are already out there
Justin: So the x5c is effectiely the CA? RB: yes.
Mike J.: I've read the draft and agree with parts of it
... People have been using signed JWK for at least 8 years
... The Signed JWK Sets are similar to those in OpenID Federation
... The draft title should highlight that the innovation is that it
defines a way to validate a JWT issuer using a PKIX cert but not TLS
Rohan: I've been thinking about writing a draft like this for a while.
... In response to the revocation question, the cert could contain a CRL
revocation point, which you would check in the normal way
... The most important thing that we're dancing around is "Why do you
want to unlink the identity from the WebPKI?"
... What's done in the OAuth WG is provide a way to do authorization
using WebPKI
... I think it's useful