OAuth IETF 121 Monday

Notetakers:

• Justin Richer
• Aaron Parecki
• Joseph Heenan

Chair Updates

OAuth Security Workshop 2025

Reykjavik Iceland
Feb 26-28 2025
https://oauth.secworkshop.events/osw2025

Draft Updates

Waiting for shepherd writeups on browser-based and cross-device apps

PR metadata in RFC Editor's Queue

Token Status List

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

problem: enable the issuer of a token to communicate dynamic status for
longer lived tokens

similar to CRL, but more scalable and aimed at tokens

has been tested and interopped, various implementations

Security/privacy considerations notably updated since last IETF

big changes since last time:

• allow symmetric keys
• support of historical requests

drop the unsigned option? makes spec significantly cleaner

Justin: Architecturally cleaner to seperate content/delivery format.
Probably fine to drop unsigned option. But do add security
considerations that it's expected to be in a secured container.

Aaron: My use case doesn't require a signed JWT but I'm not planning on
using it immediately; would be good to be able to expand it to these use
cases later

Brian: suggestion to keep unsigned option was to keep only the unsigned
option; if signed is needed then simplify to just signed

Hannes (chair hat off): Do we really need JOSE and CBOR? Wouldn't it be
simpler to have just one.
- paul: people are looking to use this in existing ecosystems that are
already based on JOSE/COSE; want to avoid bringing in more dependencies

• tobias: mDL exclusively uses CBOR/COSE, adding in JOSE is a big lift

Brian: why don't ISO/mDL define their own mechanisms?
- Hannes: we can't answer that
- Tobias: ISO already relies on IETF documents already, COSE is the
base of mDOC

Joseph: there's a lot of developers that have to develop across ISO mDL
and SD-JWT, it simplifies to keep things aligned

Hannes: Task for the chairs to reach out to ISO -- no we don't want to
do that

Brian: There's already an entire fork of things that are different. I
can see we're gonna keep it but it's odd

Tobias: mDOC is just as general purpose as SD-JWT, not just driving
licenses

Tony: we (ISO) did look at using other things, but this work was natural
to use

Other compression algorithms

Justin: It's fine for a RFC to update an existing registry to add new
columns, just have to be approved by relevant experts. There are some
general purposes registries for hash algs etc already, would be better
to reuse rather than reinvent, having a lot of overlapping registries is
confusing / results in slightly dight be pmaren urevalues.

Hannes: do we want to add options? last slide we were removing options
for simplicity

Brian: building out options to support extensibility in this structure
seems like a bad idea, particularly you have a construct of making this
whole thing extensible at another layer. Don't do it.

Paul: the whole idea is that compression is really important. Compared
to CRL we include every issued credential. more about having "none" as
compression alg. Mifferent optimizations

joseph: problem with single nonce point is the same semantics for all
the nonces, shouldn't use the same thing for everything in oauth

hannes: and we aren't going to change dpop, it's in the past

pieter: not about expense, it's a risk decision and willing to pay the
price

hannes: also issue of who creates the signature. in dpop it's software,
in this it is very low level hardware

Justin: nonces exist in context, another disadvantage of a single nonce
endpoint is you lose that context. Specific protocol/crypto
mechanism/particular exchange. Yes, we're reinventing, but the context
gives the nonce a purpose/use.

hannes: will find a time slot, beginning of december

Attestation Basic Client Authentication

get attestation from backend to present with client frontend

changes since last ietf:

• restructure

key attestation vs. client attestation

• better to split up
• key attestation removed from spec (draft is only about client
  attestation)
• could still be used together
• key attestations moved to openid4vci

nonce fetching:

• reviewed dpop mechanisms
• added nonce endpoint to openid4vci
• probably will use nonces provided by headers

dpop optimization:

• use dpop header as client attestation pop
• can use the same key as client attestation
• don't have a concrete proposal yet

george: can we just have a common nonce solution?

paul: nonce endpoint was proposed here but rejected

george: it seems like we're leveraging nonce a lot to address
time/freshness aspects; having a generic way to do this would be good
instead of tweaking it every time

christian: it's reoccuring but there are different optimizations

joseph: problem with single nonce point is the same semantics for all
the nonces, shouldn't use the same thing for everything in oauth

hannes: and we aren't going to change dpop, it's in the past

pieter: not about expense, it's a risk decision and willing to pay the
price

hannes: also issue of who creates the signature. in dpop it's software,
in this it is very low level hardware

Justin: nonces exist in context, another disadvantage of a single nonce
endpoint is you lose that context. Specific protocol/crypto
mechanism/particular exchange. Yes, we're reinventing, but the context
gives the nonce a purpose/use.

hannes: sounds like we need to work more on this

Transaction Tokens

goal is to look at transactions w/in multi-workload environment as a
whole instead of series of api invocations

updates from last time

• semantic discusisons
• subject type processing
• privacy considerations

discovery

• is there a need to discover transaction token service?
• would be interested in specifics of what those would be

hannes: what would be input to discovery?

george: that's a good question, i don't know how you'd do that without
binding it into some other document that's already known

arndt: ability to find correct transaction token server, do you imagine
that for the gateway or all the way through the domain?

george: it's relatively easy to define in some circumstances, but there
is an issue here; have come up with three likely models

1) embedded in AS or gateway
2) truly centralized, logical single entity, externalized from AS or
gateway
3) distributed set of services that form a logical single unit

hannes: should this be asked in WIMSE?

justin: drop a note to the WIMSE list

dean: related to token translation, bring the conversation there

joe: we want to update and include more on transaction and context.
quesiton on 3rd mechanism, would you see all distributed services as
equivalent?

george: generally thinking they're equivalent, it's a performance
mechanism. at the end of the day, transaction token service is
performing an authorization: can this client do something on this
transaction. if they perform slightly different functions, creates
question of whether they're different services. spec says there's one
logical service per trust domain. would that change?

batch processing:

• core principle is transaction token is very short-lived
• don't want to have to deal with revocation

• we don't have atomic transactions

  • revoking a transaciton mid-stream can cause problems

• batch processes are different from the core use cases

  • running autonomously over a period of time

hannes: have you looked at kerberos mechanism for dealing with
long-running batch jobs?

Yaron: this is even more of a WIMSE question. very much in the context
of how workloads are authenticated and authorized, suggest going to
WIMSE list. let's not have transaction tokens as access tokens, keep
them as context, but we need to have that discussion.

arndt: also to keep it out of scope. transaction tokens can be safely
forwarded, batch job means "allow-*", anything in the chain can act on
behalf of user

george: agree with concerns, would lean more towards special token. It's
weird for transaction token service to issue something that's not a
transaction token.

RAR:

• we agreed that we would not call context "azd" because it overloaded
  RAR
• talk of embedding RAR within that context

Justin: authorization details lives at the top level of the transaction
token

George: what does top level mean?

Justin: I meant where George had said. But claim name & internal syntax
should come straight from RAR. Additional things transaction spec
defines for context adds valuable things RAR isn't talking about and
have them both along aside each other semantically makes sense.

George: If authz request came with RAR environment, and AS issues token
in context of RAR objects, in some cases RAR is in the access token and
can just be copied into transaction token. Exactly how we do that
depends on best practice, we don't have that kind of guidance for scopes
either.

Hannes: Does RAR syntax give a rich enough capability or do we need more
powerful policy languages like discussed at previous IETF.

Justin: If there's a place we can decide where policy languages fit
inside, we define a claim/place for it and transaction tokens can use
it.

Client ID Hint for AS Metadata Requests

no ID to present, goal is to figure out if there should be one

AS discovery always sends the same thing back

can be expanded via registry, always say "if omitted, default is..."

metadata chances CAN break existing integrations

• mostly related to bad client behaviors and implementations

AS metadata does not support migration

AS server metadata with a client hint

• add ?client_id= to URL

does not replace or deprecate RFC8414

some servers already accomodate this discovery mechanism, some started
giving errors

Justin: Seems like great idea. Emphasis on "seems". Lesson from past is
failure of webfinger, I wanted it to be real, but in practice getting a
dynamic service up at the root domain of a system (i.e. .well-known at
origin) is very difficult in a lot of systems on a lot of domains. In
practice in many deployments I was involved with web finger ignored all
the parameters & served a static document. It wouldn't hurt to do this
but I don't have high hopes for this really sticking in the system
because of those .well-known constrains.

Filip: So would be useful, but deployment often doesn't accomodate it?

Justin: Yes. Related issue of very strict path mapping to the static
files, something with a ? will often go to a 404. Just a lot of issues
with making this work on the deployment side. There are some
security/privacy consideration, but conceptually I don't see problems
but deployment I do.

Filip: Will that stop us defining the mechanism?

Justin: WG has great history of defining things that don't get deployed.
Web finger was fabulous and solved a key need but never took off. We can
still define it but we can't make people use it. We need to go in with
our eyes open, maybe we can't avoid them, maybe we can do better this
time.

Aaron: Agree with most of what Justin says. deployment issues around top
level domain can be challenging. In the scenarios where this is needed
the top level domain is under control of oauth anyway. For a sub-domain
under control of particular customer this is okay and works. As long as
it's not required it's probably fine. If this was required for
everything it'd be a problem but this is just an upgrade for certain
thing. Privacy issues similar to those being discussed in FedCM, but
probably this won't be used with FedCM.

Filip: Our discovery endpoint isn't being used with FedCM

Aaron: Yes, but there is an endpoint where FedCM fetches metadata, but
it's done without the cookie. In general a good idea and useful.

Arndt: dont' think we should do this to mitigate misbehaving clients.
it's not going to end and it adds chaos to the system if clients behave
differently. It's good for gradual rollout of changes.

George: dealt with trying to implement webfinger @ aol/aim, agree in
this context that AS often doesn't run at ETLD, usually a separate
domain. There's opportunity for some security principles. Had done
complicated thing between webfinger and UMA, some of those principles
could come back.

Mike Jones: observe that if you're using dynamic client registration,
you have to hit discovery first, there's a chicken and egg problem

Dick: echo conerns about dynamic clients, having recently implemented
activitypub. another approach would be a version, not a query string.

Filip: doesn't work with resolving based on identifier

OAuth IETF 121 Tuesday

Notetakers:

• Joseph Heenan
• Pieter Kasselman

91 attendees

OAuth Identity and Authorization Chaining Across Domains

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

https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/

• Arndt Gives an overview of the Identity Chaining draft

  • Describes two models of where either theAuthorization Server or
    the Resource Server can act as a client
  • Introduces challenges when sender constaining tokens

• Kelly describes additional processing rules

  • Introduces the "requested cnf" claim that is included in the JWT
    assertion
  • Authorization in next domain then binds the new Access Token to
    the "requested_cnf" claim.
  • Brian - points out that the use case Kelly was decribing does
    not match the use case.
  • Brian - in use cases where the resource server is acting as the
    client there is no need for the requested_cnf claim. It is only
    required when the Authorization Server acts as the client since
    it is requesting the access token on-behalf of the resource
    server.
  • George - Are you effectively treating the access token as a
    bearer token for authentication? Kelly - correct.
  • Kelly - the inbound token may be sender constrained, but the AS
    may not be able do proof-of-posession.
  • Arndt - between Resource Server and Client is as before. When
    using the access token as a subject_token the resource server
    cannot provide proof of posession to the authorization server.
    Mitigation is to use client authentication.
  • Brian - the scope was limited in IETF 120 to only focus on the
    final key, not binding of the original key. Kelly agrees.
  • Kelly - Arndt prepared a new draft with the additional details.
  • Dean - very hard to follow. Asked for numbered diagram for
    future presentation, Hannes - suggests adding labels as well
  • Kelly describes second flow that requires the use of the
    requested_cnf claim when the AS requests an access token
    on-behalf of the resource server.

Open Issues

• 4 open issues to address as a result of the addition

Action

• Merge the PR

• Volunteers to review

  • Tony
  • Aaron
  • Dick
  • George

• Hope to do WGLC before next IETF

Identity Assertion Authorization Grant - Aaron (15 min)

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

• Aaron provides overview

  • This is a profile of OAuth Identity and Authorization Chaining
    Across Domains
  • Get an authorization grant and then get an access token
  • Use an ID token or a SAML grant to obtain an assertion grant.

  • George - critical elemant, all trust domains use the same IdP.

    • The IdP is a global IdP that allows for the trust
    • Aaron - mostly yes, but there may be relationshships to
      other IdPs as well.

  • Why profile Identity and Authorization Chaining draft

    • Aaron presented slide showing differnt aspects being
      profiled.
    • Profiled to use ID tokens and SAML assertions.

  • Requested Token Type - defined in this spec

    • No changes to token response.

  • Implementation Status

    • Okta - Now in implementation.
    • Atlassian - In-progress with implementation.

  • Dean

    • Likes the idea - use Wiki and some other service - how to
      ensure that access is not shared across users. Not sure how
      it gets solved. How would you verify trust.
    • Aaron - the input token is a user's SSO token. Access is
      only in the context of one specific user.
    • Application still needs to know how to process the OAuth
      token, but no different from other Access Token processing.
    • Unspoken things - IdP has ways to now if the application is
      allowed to access another application, decides whether to
      issue the authorization grant - controlled by policy.
    • Hannes - how much additional information about the unstated
      assumption
    • Dean - perhaps covered in security considerations

    • George - still relying on client and AS to do its usual
      enforcement and follow rules.

      • Aaron - there are existing relationships between
        applications already. Now it can be managed by the IdP.
      • George - Without that relationship that does not work.

    • Justin - this is very powerful and should be carefull
      positioned. Someone may see the machinery and abuse it.

      • The goal is to profile this and put the guardrails on
        it.
      • Need to be very prescriptiove of what those rails are.
      • Need to be very specific.
      • Aaron - have given very specific names to the AS/client
        etc in this draft to address that
      • Justin will read the updated version of the draft.

  • Hannes - build on the chaining draft - will do working group
    call for adoption depending on identity chaining draft.

First Party Apps – Aaron (30 min)

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

• Work done with George and Pieter
• Motivation is to improve user experience for users
• People are avoiding RFC 8252 and building dangerous work-arounds.

• Overview - mirrors authorization code flow. Leaves a gap for actual
  authentication.

  • Doing it this way we can leverage building block of OAuth
    eco-system

• Draft has been adopted

  • No changes since then

• Implementation

  • WSO2 - presentation from IIW last week
  • 4 other implementations

• Hannes - we need reviewers for the draft

  • Dean, Andy, Kelly volunteered

• Pull request from Tim Cappalli

  • Should passkey be included in the draft
  • Hannes - has the PR been reviewed?
  • Tim - text uses WebAuthn and is very generic - use case is
    passkeys.
  • Tim folks from openVC team wants to use this as well.
  • Hannes - request for review of draft and passkeys.

• Dean: Is authentication included in this?

  • Arron: Spec only defines input & output of an authorizaiton
    code, stuff in the middle is out of scope
  • Dean propose to keep passkey PR out of doc.
  • George: Agrees with Dean. Should be a separate extension doc.
  • Aaron: WSO2 example from IIW does define syntax for middle
    chunk, e.g. asking for OTP or OS level biometrics, see their
    slides
  • Tim: for redirect to web, AS might need to tell client more
    about what's happening
  • Aaron - Redirect to web is suported

• Justin: First 'blue arrow' is PAR. Redirect to web is
  indistinguishable from a PAR response.

  • Aaron - made it more compatible with the PAR endpoint. There is
    a reason to not beiong PAR. George - the PAR spec does not allow
    for anything other than the redirect URI to be returned.

    • Justin - update PAR to have flexibility.

    • Aaron, George, Pieter was not comfortable overloading PAR

      • Now that it is a working group draft we can revisit.

    • Justin proposes to update PAR RFC to support this.

      • If WebAuthn fits in this spec, it can be reused in other
        places that support PAR as well.
      • Dangerous to define something that is almost but not
        quite like PAR
      • Hannes - add this to the open issues list.
      • Brian disagrees with Justin. PAR is a transport
        mechanism for a genreal web based authorization request.
        Overloading it would be more dangerous than not
        overloading. PAR is more like a SAML transport binding
        than an application binding.
      • Justin - we should at least investigate and make a
        definitve decision if this is a PAR extension or not. If
        PAR can safely co-exist then we are in good shape.
      • Brian - default mode for PAR is web redirect. Native
        apps flow default mode is to stay in the application.

    • Aaron - good next thing to explore. Will open an issue in
      the github repo.

OAuth Client ID Metadata Document - Aaron (15 min)

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

• How to provde metadata out of band
• client registration - the AS needs to know redirect URI, Name, Logo,
  Scopes, client authentication modes etc.
• Pre-registraion of client is not possible if no prior relatinship
  with the Authorization server.
• dynamic client registration - not always pracical (stale clients
  getting cleaned up, causes a frequent re-regisration flow).
• Real example of Mastadon using 400k client registrations

• Neil Jenkins - prefer dynamic client registration. Not as big a
  problem as may be suspected.

  • Aaron agrees it can be done - but needs to be written down.
  • Example of adding client authentication - needs to establish
    keys
  • Not clear if there is an existing client already registered.
  • Makes sense for desktop/native clients.
  • Both are useful.

  • Filip Skokan RFC 7592 describes how a client can know it has
    been registered

    • Experimental RFC
    • Justin - ignore the experiemntal label - it is usable
      (experimental label was chosen to get it through the working
      group due to implemetation choices).
    • Justin: I have seen this implemented this with Dynamic
      client Registration with a relative aggressive cleanup
      schedule if no access token seen for a while - but that
      doesn't fit here
    • Hannes, it can also be revisted as a standards track RFC.
    • Justin - registration parts are more used than management
      parts.

  • Aaron - alternative is to define a URL that acts as the client
    ID and also points to all the metadata for the client. Build
    management of data into the mechanism.

    • Establish a public key which matches the private key used by
      the client.

  • Implementation with FedCM possible

    • Use the client ID to bridge the gap.
    • FedCM can just make the pop-up appear.

• Mike Jones: Bigger discussion tha what we want athte mic - VC
  Presentation just finished work on how to identify clients. They
  chose a prefix mechanism. Could fit into federation as well. There
  are cross-eco-system considerations

  • https://openid.net/specs/openid-federation-1_0.html#name-automatic-registration

• Matthiu Sieben - chose this solution as it solved practical problems
  for them.

• Joseph Heenan - a bad idea not to tell the AS how it should find the
  client metadata. Creates a conflict with federation. Creates
  security issues that client authenticates with federation as well as
  with this scheme - different levels of authentication. Very
  different ways to do authentication. Don't want to set a precedent.

• Filip Skokan - There is differences between how federation and this
  porposal works, it may be distinguishable.

  • Joseph and Mike makes the point that this will create confusion.
  • Aaron suggest the use cases are very different so they will not
    clash
  • Mike - Trust establishment may be needed with things that are
    not you.
  • Joseph - people may want to use both this and federation, and
    there are other schemes people are defining also based on https
    urls
  • Hannes - may create user experience issues.
  • David: client ID and prefix resolution - your claiming a URL
    (OAuth 1). There are 5 different ways to claim a URL now. Don't
    want multiple ways that canbe used that may result in a security
    issue.

  • George - what's in the dynamic client registration spec is
    different from what people are implementing. It's not a prblem
    with DCR, doingit from a web client ceates additional
    complexities.

    • Aaron, this can be used in native apps as well.
    • George - you would loose a lot when using this with native
      apps (no unique keys).
    • Aaron, there is no pre-existing relationship and CR does not
      add anything. This proposal address that.
    • George - this can be solved with client attestation and DCR.

  • Justin - agrees with the concern brought up. A seperate layer of
    trust to convey. Came up in both DCR and OpenID Federation. DCR
    was built to be extensible with authentication mechanisms.
    Raises additional security concrns with URL abuse.

    • Aaron, we should list them out.
    • App attestaion barely makes sense in this space

• Implementation that exist or are planned.

• Interesting discussion on how to use local host and development
• GitHub issues with challenges.
  • Aaron asks working group member to take a look.

OAuth 2.1 update – Aaron (15 min)

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

Changes since last draft:

• 'bearer' token type is case insensitive, people wanted BeArEr as an
  example
• Security BCP no longer a blocker as it's in editor's queue
• Browser BCP is still a blocker but moving forwards
• Hopes for WGLC in Jan/Feb.

Various open issues, most already discussed

OAuth Meeting Thursday (120 min)

We have three meetings, is that still OK with people?

• two meetings + side meetings was a problem
• three meetings seems to be its own problem

What can we do about it?

• go back to two meetings
• add more interims

Justin: We should consider dividing the work in the working group into
other forums. We've gotten too big. IETF has successfully realigned work
in the past.

SD-JWT – Brian (30 min)

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

• Brian provides an overview of the history of SD-JWT and updates
  since IETF 120

• Working Group Last Call

  • Couple of iterations

• Looking ahead

  • Goal is to not talk about SD-JWT at IETF 122

SD-JWT-VC – Brian (30 min)

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

• Brian gives overview of SD-JWT VCs

• You can have a SD-JWT VC without any selectivve disclosure

  • Expresses VC's as SD-JWTs

    • It's a no-op - so it could just be a VC in effect

  • Does not use the W3C Data Model

• Brian shows a conceptual representation of how PID may be
  represented.

  • Signed JWT with appended disclosures (aka disclosure hashes)
  • Range of hash values - each references a disclosure (including
    salt value and name/value pair of the claim)
  • The person holding the phone can choose what information they
    should disclosue about themselves

• Since IETF 120

  • Draft -05 published

    • included display and claim type metadata
    • added/fixed examples

  • Added new construct for finding the location of the claim in the
    credential

  • Harder than people think - lots of opinions
  • Used in DCQL - credential query langugage for finding
    claims/credentials

  • Re-using the construct in multiple places

    • Violating the DRY (don't repeat yourself) principle.
    • Just the pathing construct of the query langugage, not the
      language itself.

  • Aaron

    • Why not using JSON Path.

    • Daniel Fett - yes there are good reason not to use JSON Path
      or JSON Point

      • JSON Path is too complex
      • Do need to parse the string for JSON Path - in this
        proposal, just an array and using a nested loop to go
        through claims.
      • Can they be trusted to be used for these applications

      • JSON Pointer - a little more appropriate

        • • still need to pass a string,

        • still need to use escaping,

        • lacks facility to address all array elements.

      • Very important to be able to address all elements.

    • Justin Richer

      • Same question as Aaron Parecki and Darrel Miller
      • Agrees this is clean and clever.
      • If scoped to just path, need not be DCQL
      • Why not re-use all of it? That may bring more complexity
        over time.
      • Still seems strange to be simplifying in this way

      • Daniel Fett Response

        • Presentation Exchange as an example that has JSON
          Path and Schema
        • Very very complex - swiss army knife for quering
          credentials
        • Took this into DCQL - biggest problem that is does
          not have JSON path in it.
        • Pulling all of dCQL into it makes no sense - too big
          • just the path construct that is needed.

      • Brian - can this be pulled out of DCQL and easily
        referneced

      • Draft should explain why this is different from other
        query langugages
      • This draft should also say why it is done this way.

    • Darrel

      • There is fair amount of precedent for using JSON
        pointer, would encourage editors to look at it.

    • Hannes - what is the next steps here?

      • Daniel - problem with JSON pointer is you can't use it
        all, but will take another look.
      • This evolved out of a certain need.
      • The idea here is to pull it out somewhere - no plans
        beyond it.
      • could do it here, could do it later.
      • Brian - just drawing attention to the need to pull it
        out.

  • Brian: Lots of open issues that need triage

    • May need to re-think using of .wellknown

      • is about the host, and this case is about the credential
        • so not appropriate
      • Talked about the type metadata

    • Remove DIDs and DID resolutions

      • Not interoperable, underspecified
      • Document already allows for extensibility
      • But reduces cognitive overhead of the document.
      • Proposal is to remove it
      • If there is any concerns, now is a good time to raise
        them
      • Nothing breaks if it is removed as it can be introduced
        back in through extensibility.

  • A tale of two types

    • JWS/JWE/JWT

      • incldes type headers,including a media type.
      • Media type describes what is in the paylaod
      • JWT recommends typing JWT as JWT
      • Type has not been super valuable in that construct
      • Does not allow hints on whether an object is signed or
        encypted.
      • You have to parse the whole thing, so you already know
        what the type is before getting to the type claims
      • A long way of saying - what things are used for is not
        actually what they are used for.

      • JWT became very popular - some criticism

        • Hannes: the WG has addressed this criticism, most
          critics are trying to replace JWT with their own
          invention
        • Justin: is this different from inventing an
          alternative to JSON Path?

      • Created a BCP for the common security pitfalls (RFC
        8725)

      • Introduced explicit typing

        • Mechanism what you expect is what your getting
        • Not "what you have, now you know what do do with it"
        • application/at+jwt - access token with JWT - similar
          for DPoP

      • Explicit typing recommendations +sd-jwt in June 2023

      • Commonly used to conform that your processing what you
        are already procesing.

      • Verifiable Credentials is not a term owned by anyone -
        first used by W3C

        • Some considered it hard to access work in W3C

      • Will JSON-LD be a hard requirement - agreed it would not
        if regualar JSON is used.

        • JSON-LD became a hard requriement after this

        • Brett Zendell

          • It was decided in Miami that transformation to
            the W3C data model could call themselves
            verifieable credentials if they are
            transformable.

        • Brian - Net result - folks who wanted simlicity were
          not interested in abstract transformation
          algorithms.

      • Some people decided to pursue similar work in the IETF

      • Justin - is this like reinventing JSON Path?

        • Brian - yes

      • July 2023 introduced at IETF 117

        • vc+sd-jwt introduced at IETF 117

      • vc+ld+json+sd-jwt registered by W3C

      • Confusing datatypes - Brian disowns being responsible

    • Media types for multiple suffixes (because there are no
      multiple suffixes)

    • Change introdiced so that there can only be one "+" in a
      mediatype

    • Registered against the moral equivalent of working group
      draft in the W3C

      • Brett Zundell as chair to the W3C VC working group - it
        is more like a WGLC

    • Now vc exists as aregistered media types

    • As result there is conflicts in registry for media types.
      • Causes confusion to have same registration entries for
        something that has the media type but different
        meanings.
      • We will have this conflict.

  • Options

    • JOSE and COSE can use their own data types - not in direct
      violations, but increasingly unlikely.

      • Compromise unlikely

    • Stay the course

    • Change the media type in SD-JWT VC (breaks downstream
      implementations and specs)
    • Hedge, Pivto and Defer

  • The Dublin Proposal

    • Recommend the media type in sd-jwt vcto dc+sd-jwt
    • Don't change other names
    • Tighten the scope and accelerate RFC timeline.

  • Justin

    • agrees with the proposal
    • agree with dropping DID support

  • Murray

    • Agrees and will help

  • Tim Cappalli

    • Agrees and supports

  • Mike Jone

    • Agrees, also drop DID support
    • As a security construct explicit typing has worked well
      (e.g. can tell wht a token is intended for - logout example)

  • Deb

    • will yu ask for provisional registry
    • Brian - yes

  • Daniel

    • Agrees with first two points

  • Darrell Miller

    • Work is going on to introduce wording from avoiding this
      type of thing from happening in the future.

  • Pamela Dingle

    • Will you also register application/dc
    • Brian - no
    • Darell - proposal is that there is a mechanism to trigger
      conversations so if you don't need it do'nt put it in.

  • Yogesh

    • Will the use of dc result in a loss of context if it is not
      vc
    • Brian VC term is problematic to start with. Intent is to
      change 'v' to 'd' and leave everything else in place.
    • Justin - support the change
    • Darrell - its a small change.

  • Paul Bastian

    • Inaudible

One-time confirmation tokens - Dmitry Telegin (30 min)

(No draft at this point)

• May result in multple drafts
• Looking for feedback on ideas
• Can this be done in OAuth

• Existing one-time tokens

  • authorization codes
  • DPoP prrofs
  • Acces Tokens?

• Use cases

  • The primary use case is payments
  • All examples come from the finance world
  • Differs from Neil's proposal

  • Characeteristics

    • Very short lived, one time, not refreshable, specific to an
      operation, no session, complimentary to access token.

  • Try to reduce scope of the token/scopes

  • Pass it in as a custom header, revoked

• How to indicate that an access token is not enough.

  • Examples to follow - DPoP.

  • Scheme parameter - if one is DPoP and one Bearer what to do?
    Always refer to access token.

    • Perhaps use same scheme for both?

  • Issue simultaniously with other tokens

    • ID token, Access token etc.

  • Introduce new claim "use" number of uses

  • How should introduction be used?

    • Only once
    • Also have a "uses left"

  • Privacy

    • Make and suumption, maybe first party apps

  • Not re-inventing 3D Secure.

  • Other types "Action Tokens"
    • Not part of the draft

One-time auth tokens - via macaroons – Neil Madden (30 min)

• Inaudible - refer to transcript.
• One-time auth on top of normal OAuth long lived grants.

• Mike Jones

  • What is it?
  • One-timeuse of a token

• Joseph Heenan

  • One time use - sometimes you need to do that

• Pieter

  • How does this work with Transaction Tokens?

• Arndt

  • Why not just de-dupe on server side?

• Justin

  • Topic coming up a lot more
  • Token bucket work may be related.
  • Not everything should be treated as an access token

• Yogesh

  • Why keep creating tokens within tokens
  • Why not just have short lived tokens

• George

  • Not seen as tokens within tokens
  • No see downscoping for scialised access tokens a lot

• Aaron

  • If the client needs to do something different, its a new type,
    if not it is something else.

• Hannes

  • Interested parties should present the problem.
  • Review in an interrim meeting.