Skip to main content

Minutes IETF118: oauth: Tue 14:30
minutes-118-oauth-202311071430-00

Meeting Minutes Web Authorization Protocol (oauth) WG
Date and time 2023-11-07 14:30
Title Minutes IETF118: oauth: Tue 14:30
State Active
Other versions markdown
Last updated 2023-11-13

minutes-118-oauth-202311071430-00

IETF118 - OAuth WG Agenda

Tuesday (60 min)

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

Rifaat remembers Vittorio.

Rifaat encourages the OAuth working group to provide feedback to the
Nomcom (https://datatracker.ietf.org/nomcom/2023/feedback/).

Rifaat notes that the bi-weekly OAuth Office Hour meeting invitations
might be out of date and that it be best if people removed their
possibly stale invitations from their calendars and downloaded new ones.

Two new documents published as RFCs, namely

Security BCP pushed to the IESG.

New documents adopted:

  • SD-JWT
  • Attestation-based client authentication
  • Status Lists

Charter discussion (30 min)

Yaron and Hannes briefly summarized the WIME and the SPICE BOFs

Rifaat says that the new documents are already in scope of the charter.

Justin: What is the reach of this group? What is the identity of this
working group?
We are not just doing extensions to OAuth. SD-JWT is not an extension to
OAuth.

Mike: OAuth WG is doing good work and I don't think there is need for a
course correction.
We have well-informed discussions about newly proposed work. I am happy
of where we are.

Brian: Since JWT was developed in this group I see SD-JWT as an
extension of the JWT. I would like to continue the work here.

Rifaat: Do you see a need update the charter?

Brian: I don't know. I also haven't read the charter recently.

Orie: It is web authorization: the web is more than HTTP and the web is
more than JOSE.
I agree with Brian. The work done here is excellent. No reason to move
the work anyway.
But: you also need to think about attracting people. Where do you send
the people when they work on CBOR-based extensions?

Rifaat: What is your proposal for the re-chartering?

Orie: If people bring CWT Status Lists here, would you send them to ACE?

Rohan: It's not clear to me why JWT was done in OAuth and not JOSE, same
as CWT in ACE.

Hannes: JWT was done here because it was a clear gap in the Oauth
protocol with the token format not described.
CWT was in ACE where HTTP was replaced with COAP, JWT was shrunk and
replaced with CBOR. Was that a good idea? Not sure.

Richard: There is a logical demarc point that was reached. With the
SPICE BOF there is a reason to move work over there.

Manu: I was looking for a group doing authentication. We have been
working on confidential computing. Is this the right place? Where can we
go to do this work?

Rifaat: OAuth works on authorization - not authentication. Maybe
SECDISPATCH is the right place.

Mike: Often decisions are the result of the people involved in making
the decisions. I am OK with all the outcomes.

Brian: ...

Pieter: It is important to have the right people involved in doing the
work. We have the right people here doing the work.

Roman: I don't know how to use the feedback. People want to continue

  • Token,
  • OAuth protocol
  • Extension.

I would some of the things a bit more first order.

Justin: We don't need to make decisions in the same way as we did in the
past. Should we put JWT in the charter? "yes" Same for "SD-JWT". We
should also be careful that we are so widely welcoming so that it ends
up in this working group.
We need to be careful that it doesn't just become like a bluc of us
doing these things because we are interested in it.

Paul: In an ideal world, SD-JWT and Status Lists belong to SPICE. W ant
to issue government credentials in eIDAS and we need to consider the
urgency. The eIDAS is highly volatile and if we pull these specs out of
OAuth into something new then this appears to be dangerous. The time for
doing so is not right.

Summary from Rifaat: The documents should stay here. Nobody is arguing
that to move them somewhere. There is room for improvements of the OAuth
charter.

Orie: I want to echo what Paul said: "this group has a reputation".
People will send messages for review to the OAuth list. You need to
update the charter to reflect the scope of the group.

SD-JWT – Kristina Yasuda/Daniel Fett – (15 min)

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

Daniel goes through the changes in the draft. Neil had comments about
cryptography.
More issues on the issue tracker.

Nine implementations available today.

Rohan: I can provide an example of a attack that can be mitigated In
MIMI we have an architecture with multiple hops. The local provider
could copy disclosures as the message passes by and include them
elsewhere.

Orie: There may be an agility issue with the hash algorithm. How do you
prevent people from having to implement multiple hash algorithm.

Daniel: We haven't decided about this yet. This is an open issue.

Orie: I have an idea. You lock it to the same scheme that the issuer
committed to.

Brian: This is what is says now.

Richard: I think Brian is right. I am fairly new to this draft. This is
getting pretty good. I am concerned about the key binding because it is
an ortonogonal thing. It seems useful to be without the key binding. I
would suggest to move this out. Has there been any formal modelling on
the key binding?

Daniel: The key binding is extremly simple: it is a signed JWT. It is
good to have it in there. It is closely connected to the use case for
selective disclosure. It is also relatively simple. If you move it into
a separate spec, there is not much to specify. I am wondering whether
the mechanism is not too simple. Having done a lot of formal analysis, I
think the analysis would be extremely boring because there is not much
to analyse.

Tristan: We ran into a few issues with the implementation with the more
complex constructions (like recursive JWTs). We got feedback from the
list but the draft would benefit from clarifications. Where should we
send those comments?

Daniel: I believe you have submitted a few clarifications to Github. If
you want, a PR is very welcome.

David Waite: I can see a profile for SD-JWT for access tokens. Key
binding would be an alternative for DPoP.

Wednesday (120 min)

Protected Resource Metadata – Mike Jones, Aaron Parecki (20 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/

Mike and Aaron go through their slide deck. Purpose of the spec is to
define an automated way to determine meta-data about the resource
server.

Two open issues:

  1. Should WWW-Authenticate return the Resource Identifier (RFC 8707) or
    the Resource Metadata URL?

George: Is there value to specify that the URI has to be a URL rather
than allowing a URL as well?

Justin: I would argue we should explore returning both under different
keys. If we do that we define what the semantics is.

Aaron argues for one approach. Return the URL to the metada.

Justin: Believes there is an argument for both as a logical resource
indicator may have specific meaning to the client. However, the
relatioship between the two needs to be defined.

Filip: We like that the resource indicators allow a URN. This is
probably not applicable here. Resolving the URI to a .well-known is a
problem. I think it should return the URL to the well-known document.
What resource to use would be in this document. Returning a URI should
be allowed at all.

Brian: The Resource Indicator allows a URI but it does not mean that it
needs to be used here. We can constrain it. Clients are not the only
entities that are doing the discovery. The well-known path construction
runs counter to what the recommendations are. I am worried about the
future way of progressing the draft.

Mike: You pointed out that others would also use this discovery. We
updated the draft. The server can also use this mechanism.

Regarding the well-known, we have made an update to the draft. I don't
want to repeat the experience with AS meta-data draft. Mark's argument
is that the Web security model is based on the web origin model.

Roman: We could ask the HTTP directorate for an early review if we want
to avoid suprise.

Neil Jenkins: This work is interesting to us. Having a document that
allows this client registration/discovery is important. The URL would be
a lot easier. I cannot see what scope I need. This is also important.

Mike: WWW-Authenticate can return a scope that you need to perform an
authorization. We are not touching this building block.

Aaron: We should mention this in the draft. The scope problem is a hard
problem because you need to have some information agreed to get this to
work.

Dimitri: The solid project uses a similar approach. Instead of the level
of the indirection, it links to the AS server directly.

Aaron: We use this approach initially. I cannot remember the exact
arguments. We agreed to point to the metadata, which points to the AS.
What happens if a request to example.com returns a pointer to a
meta-data from a completely different domain. At a minimum I would
expect the meta-data to point back to the resource. This is currently an
open issue.

Mike: We take a pass at returning the meta-data link diretly. Then, we
see how it looks like and then we take it from there.

Justin: Can you be more precise?

Mike: I would put the resource indicator in the meta-data directly. And
return the meta-data URL.

SD-JWT-based Verifiable Credentials (SD-JWT VC) – Oliver Terbu, Daniel Fett (20 min)

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

Oliver and Daniel go through the slides.

Slide about obtaining the verification key.

Brian: Do we really need to bring DIDs into the spec in a normative way?

Daniel: Yes, we need.

Brian: No, you don't.

Richard agrees with Brian.

Daniel believes otherwise. Describing a way to obtain the issuer's
verification key.

Brian: I want to push back on the DID.

Richard: Saying "did" means "we use a protocol". There are so many of
them.

Discussion will continue on the list.

Daniel mentions that there is a discussion in Github on the draft.

Richard: You may run into problems because if the only authorized usage
is TLS server authentication.
You could split the difference in the format of the credential based on
discovery.

Kristina: There are a punch of people implementing DID web with this
method and I do not want to shy them away. Specifying to use DID web
would be useful.

Attestation-Based Client Authentication – Paul Bastian (20 min)

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

Paul goes through the slides. The motivator is coming from the eIDAS
ecosystem.

Justin: This smells a lot like dynamic client registration. This is
directly applicable to other use cases.

Paul: I am not an OAuth expert. There is some overlap to dynamic client
registrations.

Tobias: I wanted to say that we call it the client backend.

Justin: Yes, this feels a bit more than being part of client
registration.

Tobias: How the client registers to the AS is outside the scope.

Filip: There was a use case slide and I want to say that this has to
work as a general mechanism. The reltionship between the key used by the
AS to verify the key needs to be specified (pre-registration, or
meta-data).

Aaron: Client attestation is not the same as client authentication. I
would like to do both. I want to use this mechanism also in other
endpoints like Dynamic Client Registration, PAR, etc.

Kristina: ... missed it ...

George: Agrees with what Aaron said. Attestation is different from
authentication. I would like to say that there are many places where
this could be used.

Ben Bucks: I work on Thunderbird. How can this be abused to prevent the
use of Thunderbird by specific some servers.

Browser-Based Apps - Aaron Parecki (20 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/

Aaron goes through his slides. Recommendations for developers building
apps that run in browser-based apps.

The document now starts with a description of the threats related to the
different deployment scenarios. The architectural patterns are now able
to reference which threats they do and do not protect against. It is
supposed to be more readable.

Rifaat: Are we ready for a WGLC?

Aaron: I believe we are ready (even though many have not read the latest
draft).

Justin: I have not yet read the latest version of the document. Does
this doc have considerations for storage of keys bound to access tokens?

Aaron: There is a section about the web crypto API and that the storage
of those keys are not necessarily hardware bound and may be stored on
the filesystem of the device.

Neil Jenkins: I am trying to find the DPoP references to see how the
secrets are stored.

Philippe: There is a section that briefly combines the use of DPoP. Even
with DPoP enabled it does not necessarily solve the problem because the
attacker can mount other attacks.

Aaron: The subject heading is called "sender-constrained tokens" and not
DPoP. There may be value in adding a section higher up in the doc to
show which attacks it helps mitigate and which is doesn't.

Justin: I would like that. The storage of keys is another deployment
pattern rather than just a security consideration. I would suggest to
"bubble up" this sec

Reviewers: Justin, Filip, and Andy Barlow volunteered.

Philippe: Justin, please review the draft and tell us again whether the
storage of keys needs to be a separate pattern.

Aaron: I am not sure where to "slot in" DPoP because it is not a silver
bullet because it does not solve all problems.

Cross-Device Flows – Pieter Kasselman (15 min)

https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/

Pieter goes through his slides.

There are three open issues. Daniel will re-write the formal analysis
section (in December).

Tony: Why are we adding a reference to the ISO mDL document? Which
document are you talking about?

Daniel: We need to think about it.

Kristina: If we talk about mDL we need to talk the entire VC space.

Daniel: We should talk about places where cross-device flows are used.

Reviewers: Tony, Andy

OAuth Status List - Paul Bastian (20 min)

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

Paul goes through the slides.

Leif: Scalability - numbers may be conservative. Some use cases have 20%
revocation. Integration with the token should have some algorithm
agility. Only one way of dealing with status lists. There should be a
way of improving the mechanisms when a better mechanisms is defined.

Paul: Agree with need for some updatability.

Justin: .. missed comments ..

Paul: URI should not contain the index and that will destroy the desired
privacy features

Aaron: Lot of applications of this in OAuth for tokens that are not
related to VCs. For example JWT Access Tokens. RS could cache the status
list and get the performance benefit.

Tobias: Trying to generally represent this as a generic token.

Aaron: Since OAuth has a JWT Access token and this work is in OAuth,
there should be a mention.

Hannes: Should reference the work in the W3C and also the reference to
"Let's revoke". Also it would be good to use the CWT-based status list
version instead of the JWT-based version since it is smaller in size
(particularly the Base64)

Yaron: Not a fan of CBOR but size would be valuable here. Are we
competing with W3C on the solution?

George: You need to describe under what conditions to use which
revocation mechanism.

David: Also seen much higher revocation rates (e.g. HR person attribute
change causes VC to be invalidated and reissued). Agrees with the
arguments regarding doing the work in the IETF (instead of doing it in
the W3C).

Oliver: If we want to support addition methods in the future, we can
define extensions.

Friday

Note-taking: Kristina

Transaction Tokens – George Fletcher (20 min)

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

  • what are transaction tokens

    • goal: look at authz in multi workload environment, when need
      immutable context that transcends multiple internal services
    • currently, there is no such thing at the transaction level
    • can be anything from a simple req adding a stock or can go
      through multiple services. how do you maintain the context where
      the user came from
    • if something fails can't roll-back. if authorized at the edge,
      you should let it go through
    • you will mint a short lived token that transcends. currently, if
      each of the services calls back to validate AT, can create
      problems
    • good for finer grained capabilities
  • Updates to the existing draft

    • intermediary service cannot change the destination where the
      token is used
    • removed nested tokens because complex, no use-case
    • added claims

      • aud: meant to scoped for a single trust boundary
      • purp (purpose of the transaction): authorization model
        outside is different from inside your trust boundary. can
        bridge the two
      • azd (authorization_details): add more context
      • req_ctx (context of the transaction)
    • new examples

  • Open questions

    • is transaction token an authorization token? or if you are using
      header to carry sender constrained token as opposed to doing
      mTLS. delete authz header? Justin's token buckets might be
      related. would like feedback
    • subject of the transaction token. allow both sub and sub_id.
      issuer of the transaction token is not the same as the simple
      issuer of sub claim (note-taker did not really follow)
    • iss required or optional? there are some cases where you might
      want your transaction tokens to be distributed within so might
      want multiple issuers. no spec language around this yet, but
      feels like resolving
    • sender constrained transaction tokens: you are within the same
      trust boundary, so maybe not really. client authentication
      request being bound to a specific transaction token? do i have a
      secure call chain path is the question to answer
  • would like to ask for WG adoption

    • Yaron Sheffer: please explain down scoping and how it works
      without nesting.
    • George: Think about a mobile client. When I went through my
      OAuth flow. I consent the client yto read/write transations.
      When I transfer x amount of money, the downscope would allow the
      backend to only transfer a specific amount of money.
    • Yaron: not attenuation later on. comment. part of my job is
      chasing PII - seeing IP address in the transaction token makes
      me nervous. it is worth privacy considerations.
    • George: I completely agree that we should have a privacy
      consideration section. Having the information in the token is,
      however, often pretty useful. There is a trade-off.
    • Yaron: certainly useful, but makes it hard to chase stuff in the
      token.
    • George: agreed to add guidance in the spec to hash or
      obfusticate anything that can be considered PII
    • Yaron have not thought about whether supports adoption or not.
      goes into workload, so interested but not sure if useful yet,
    • Justin Richer: There are two aspects that will be tricky to
      navigate: It will look like an access token and where should it
      be. I therefore lean towards not using the field in the regular
      header. SD-JWT could be a potential container to pass things
      like this to pass parts. not sure OAuth is the right place, but
      not sure there is a better place.
    • George: Justin, please add an issue on a potential use of SD-JWT
    • Cedric: What is the purpose of the transaction token? worried
      about privacy
    • George: one of the drivers was twofold. usual systems being
      server to server trust, If you compromise an intermediate server
      then you can impact the overall system. Often, validation
      required going back to the IDP. Using these short-lived access
      tokens internally allows for better performance. Finally, having
      something that carries the transaction information (id and what
      services will be invoked) is important for introduction
      detection systm.
    • Mike: want things to be consistent. you are using a claim
      defined in security event token, but it is only in the request.
    • George: That's a bug.
    • Ned: There was a WIMSE BOF with focus on workflows. It seems
      that this overlaps with the work you propose.
    • George: It might be. There are timing issues. We started here to
      get the work done.
    • Ned: There is maybe a charter discussion.
    • Pieter: Another benefit is that we do not have to pass access
      tokens around through microservers, as you are processing the
      requests. but people do it, so not having a standardized
      mechanism to do it will bite us later.
    • Hannes: Rifaat and I talked, we will still do a call for
      adoption but we might have to shuffle things around depending on
      how the charter goes - might need to be moved.
    • Brian: I have not reviewed the document. It is not ready yet.
      There are
    • Hannes: criteria for call for adoption is 1/ is there a
      recognized problem? 2/ ok to be rought, content-wise (we change
      things anyway).
  • Question to the group: Is the working group interested in solving
    this problem?

    • Yes: 24
    • No: 4
  • Question to the group: Should we adopt the Transaction Token as a
    starting point?

    • Yes: 15
    • No: 4

Will take to the list and confirm as a final decision.

Identity Chaining – Pieter Kasselman (20 min)

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

  • A little related to previous George's presentation (this time:
    cross-domain). More editors onboard
  • The challenge:

    • service is constituted of multiple components. want to be able
      to share context cross-domain, among those components
    • by the time request comes to the last service, still wants to
      presernve all the context
  • proposed approach

    • reusing two existing RFCs: token exchange and assertion
      framework
    • get authorization grant using token exchange, use it at another
      domain
    • two models where want to use it: 1/ used by the microservice
      itself; 2/ used by the resource server (high assurance
      use-case).
    • client in domain 1 should not know about AS in domain 2.
  • Thank you to Brian for the help.

  • Open issues: limiting token format to JWT. how to transcribe claims.
  • next steps: pursue?

Q&A

  • Mike: what do you mean by transcribing claims?
  • Pieter: Should we describe how the claims are preserved when you get
    the assertion grant? Should they be available?
  • Mike: Is it like "encapsulating"?
  • Pieter: Yes. We wanted to avoid copying the access token and instead
    only carry the info around that is relevant.
  • George: There are interesting problems worth solving: The claims
    about user in one domain are different from the claims used for a
    user in a different domain. How do I present the right amount of
    information to the parties involved.
  • Rifaat: sounds like there is interest. want to see the feeling in
    the room.

  • Poll

    • Question to the group: Is the working group interested in
      solving this problem?
    • Yes: 24
    • No: 0
  • Question to the group: Should we adopt the this document as a
    starting point?

    • Yes: 18
    • No: 0

Will take to the ML to confirm.

The Use of Attestation in DCR – Ned Smith (20 min)

https://datatracker.ietf.org/doc/draft-tschofenig-oauth-attested-dclient-reg/

  • client implemented in the confidential compute environment. client
    is configured with credential and attests
  • attestation can be used with different OAuth endpoint. attestation
    supports at the registration endpoint. complimentary with client
    auth draft.
  • based on RATS architecture. in terms of terminology communication
    pattern and passport model, etc.
  • passport model:

      1. client obtains attestation result (e.g. passport) from RATS
        verifier. the purpose is to check that client runs in
        Confidential compute env (CCE).
      1. DCR between AS and Client. AS has a policy that DCR is
        performed if client is a valid CCE.
      1. AT is obtained and used
  • Next steps:

    • trying to keep simple; prototype going on; adoption?

Q&A

  • George: client and attestors relationship seems to be the same as
    another client auth draft. the attestation piece is very important.
    presenting at multiple endpoints seems to be useful. value in
    separating client auth from client attestation. wonder if it is
    possible to combine both drafts.
  • Ned: what we found beneficial in RATS is separating role from
    entity. An AS can be RATS verifier, can be separate
  • George: producing attestation/evidence about the client should be
    stand alone.
  • Hannes: both documents do that separation.
  • George: do both documents solve the same or different problems?
  • Ned: they solve different problems but they can be combined into the
    same
  • Aaron: +1 to George. opposed to havign two drafts that do the same
    things but with different terminology. attestation output is useful
    at many different endpoints. want to combine the two. The
    terminology needs to be aligned.
  • Ned: happy to work with other drafts on terminology.
  • Paul: +1 to George and Aaron. if the feedback from the previous
    session is reflected, might arrive there. ok, merging the efforts.
  • John: agree with what has been said. if there is something specific
    about CCE, it should be a profile on top of general purpose
    mechanism. CCE should be able to do all those basic things anyway.
  • Ned: please take a look at RATS draft list.
  • John: it is a CCE profile of a general attestation mechanism in
    OAuth.
  • Jacob: reiterate what John said. strong argument not to use
    attestation only as client attestation. SW statement can be used
    there. but makes sense to look deeper at the token content and how
    to structure.
  • Joseph: uncomfortable with Paul's draft that targets cllient
    authentication to be used at the DCR endpoint. don't force to be
    presented in the same manner at different endpoints
  • Ned: let's figure out the terminology and look at the goals.
  • Hannes: Chair hat off. terminology is RATS specific. unfortunate
    that some of the terms overlap.
  • Aaron: DCR spec explicitly says this endpoint can require client
    authentication. this attestation is an input for that. it's all
    already there.
  • Ned: in the context of attestation, the things that labelled client
    has client_id within RATS verifier, which is different from
    client_id at the AS.
  • Brian: another draft is merely attesting for the key. not sure the
    parrallels are as significant as being reiterated.
  • Justin: Aaron is right. the other draft is wrong. attestation should
    be usable at any endpoint.

  • Rifaat: The authors of the two drafts will work together. let's
    decide on the next steps after authors of both drafts get together.

First-Party Native Applications - Aaron Parecki (20 min)

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

  • presented previously.
  • recaps third-app flows: mobile apps take over the web flows and
    going to safe browser, etc.
  • developers want a better user experience for first-party apps.
  • people are finding ways to go around the requirements in rfc8252.
    and all of these lead to worse outcomes that having a guidance how
    to do it safely.
  • back to oauth world. by design user authn, consent gathering, etc.
    are not defined. this was a success
  • define a flow start and end of the flow, leaving what is currently
    out of scope, out of scope.
  • goal: reuse existing building blocks. mirror the web-based authz
    code flow.
  • specifics of user authn can be defined as extension?
  • Authorization Challenge Endpoint

    • new endpoint
    • accepts POST from client
    • content of req res, same as current endpoint
    • no changes to the token endpoint
    • resource server error response unchanged.
  • why new endpoint?

    • current AS is only interacted by the browser, never interacted
      with by the oauth client
    • currently expects html
    • people unwilling to change current Authz endpoint
  • updates

    • renamed device session.
    • enable transitioning to the web

      • added redirect_response error. no longer trusts the app,
        etc.
    • removed native from the spec. nothing was specific about
      native apps..? even if it is an intended use of it. not intended
      for SPA though you can do it... want to discuss

    • a lot of interest to use FIDO as authorization grant and
      exchange it for access token. no browser appears, do passkey
      challenge and exchange to AT at backend. this draft can be used
      as a basis for that.
    • clients need nonces. how do we shoehorn nonces.
  • any interest on defining a profile of this for webauthn

Q&A

  • Dmitri: For SIOPv2 and OpenID for Credential Presentations
    implementers need to get a nonce and an API endpoint (to send this
    nonce to) and I wonder whether the workflows (scanning a QR code)
    can be re-used. At least both communities should be informed by each
    other.
  • Aaron: nonce issue is not the most important issue to discuss.
  • Jacob: I have concerns with the spec. We have a similar
    implementation. The flow is unauthenticated and this should be
    client-authenticated at some point. This can lead to a lot of
    vulnerable implementations to it, particularly since you removed the
    "native" from it. I believe this ccould lead to implementations that
    are really insecure. If you combine this with attestation, then you
    could use DPoP and use it throughout the authentication flow. Why
    not access-token bound and have it attested. There should be a
    security baseline.
  • Aaron: agree that it would be a bad idea to build an implementation
    of this that is opened up. prefer layering approach combining
    different drafts that solve different problems. I would fully expect
    that you could use an attestation mechanism along with this to
    protect the endpoint. This would be a good recommendation. We cannot
    really do stuff with pre-enrolled client on the mobile. Yes, there
    are concerns there and I have documented them in the draft. I would
    like to reference the attestation document but I don't want to
    reference the attestation draft right now when it is so in flux.
  • Rifaat asked Jacob to review the latest version of the draft
  • Paul: have a similar set up for the high-assurance use-case. is
    there a need to standardize? better be a BCP?
  • Aaron: Even though this is a first-party flow it is using components
    from different developers. As such, there is a standardization need.
  • Paul: I think it is a good idea. We also want to use this type of
    flow with attestation. There was a proposal to create a nonce
    endpoint and we should consider it.
  • Aaron: This is worth a discussion.
  • Justin: Thanks for this. This is an interesting gap. This is the
    third time we have re-invented "intent" registration. At what point
    are we going to invent throwing parameter on top of that, these
    things tend to need nonces. Should we just abstract up from PAR and
    what this type of intent registration looks like.
  • Aaron: it is an interesting idea
  • John: I was too wondering about the relationship with PAR. I have
    mixed feelings about the ideas from Guiseppe. We should have a more
    specific profile for passkeys and it should be the only profile. For
    mobile apps, there is no particular reason why you would do anything
    else. Passkeys also provides attestation.
  • Filip: fan of the layering approach. Jacob mentioned they have a
    proprietary implementation.
  • Jacob: I am all for standardizing this. I like what Justin was
    regarding PAR. Maybe it is time. We shouldn't be too scared about
    "content types" to perform content type negotiation. It is web
    protocols. I disagree with John. We see a lot of different devices
    that fail to do attestation because they have an incorrect
    implementation of the chip or a different "trust group". For a
    vendor an x% of devices failing is signifant. If it is not attested,
    it should still work.
  • John: WebAuthn is universally available (except for a few devices
    from China). Those devices will get fixed as well.
  • Kristina: An additional endpoint is extra complexity. Does WebAuthn
    be a profile of first party app?
  • Aaron: It does not need to be a profile of this document. But for
    this document it seems to be the right
  • John: The audience of the WebAuthn is different between the
    first-party and the third-party app is. There are different
    challgnes.
  • Pieter: while passkeys might be the future, need transition from
    what people have deployed now.
  • Rifaat: there was a lot of good feedback. please incorporate and we
    can talk about adoption.

OAuth Global Token Revocation - Aaron Parecki (20 min)

https://datatracker.ietf.org/doc/draft-parecki-oauth-global-token-revocation/

  • draft swapped from what was originally on the agenda
  • original draft was 2 steps later from what this updated draft is
    about.
  • problem: things external to AS (enterprise IdP, security monitoring
    tools) may ask to revoke tokens.
  • goal: token revocation API that standardize this
  • existing related standards

    • token revocation rfc 7009
    • not applicable because client initiated. client that has a token
      send it back to the server and asks to revoke
  • OIDC front-channel logout

    • not related because it is also client initiated
  • OIDC back-channel logout

    • mostly talks about sessions, 0 mention of access tokens.
    • refresh tokens issued with offline_access property normally
      should not be revoked.
    • might be able to change this draft or remove should
    • larger point: these servers do not have OIDC deployed and have
      not gone near OIDC.
  • Shared signals framework

    • the closest
    • CAEP is more like a hint - not meant to be a command
    • RISC language is stronger.
    • a lot of back and forth to set up the event listeners
  • look at the existing implementations that do it in proprietary way.

    • zoom, box, slack, zendesk have a similar token revocation API
      implemented in a proprietary way
    • POST or DELETE
  • draft published today.

    • it is very simple.
    • input is security event token subject identifier - close to RFC
    • authentication is required, but out of scope, just like token
      introspection.
    • outcomes

      • must revoke refresh token
      • should revoke access tokens
      • no issuing of AT or RT without re-authenticating the user
    • the draft does not use a word log-out. but achieves the same
      end-result.

    • not saying to delete all user context, just re-authenticate the
      user next time.
  • John: We should consider adding an optional session identifier
    (which is what we used in OpenID) to address state from different
    devices (e.g. to distinguish sessions on mobile devices and from a
    tablet). I would like to avoid duplication with the OpenID
    specifications.

  • Aaron: I wanted to start with the base case (delete everything) and
    then expand it from there.
  • ??: The reaction we got (from Google and Apple) was "we cannot do
    that" without a session.
  • Justin: Neat idea. Have you thought about this for direct token
    management?
  • Aaron: this is really meant to cover the case when there is no token
    available.
  • Mike: what backchannel draft did and did not say? it does not
    mention AT, only talks about session.
  • Aaron: Yes, and no. It implies there is one session while there may
    be multiple.
  • Mike: I point out that there is language you could re-use. It also
    talks about information about cookies and HTML5 state. The more
    specific we are the less confusing it will be.
  • Aaron: Interesting point. The question is whether we should also
    clear client state.
  • George: concern about 404 response. really liked current API
    approach getting 200 back every time. relatively easy to compromise.
  • Aaron: The input is not an access token.
  • George: to me API keys are note very secret. there is a security
    element. identifier that is largely known. may be ok if you pushed
    out authentication context..?
  • Aaron: I prefer strong authentication mechanisms. I would encourage
    it but I don't want to create barriers.
  • George: I would take out the "404 response" and whether there is an
    active session there.
  • Aaron: we can dig into that if it is needed.
  • Justin: The reason that token revocation with a 200 every time
    because it is a best effort response. The 200 response is that the
    AS got the messasge and I will figure it out. I will not make
    promises (even if there is nothing there). I am not convinced it is
    entirely the same here. We will have to be careful about how we
    specify it here.
  • Dmitri: 404 is definitely a red flag whether the user has an account
    or an active session. two options to mitigate - to always signal
    success whether there is user or not, not only because best effort,
    but also security. another option is to always return 404 if the
    user is unauthenticated or unauthorized. 401s and 403s become 404s.
  • Aaron: The thing making the request is a security monitoring tool,
    an IDP and none of it is in the context of the user. The concerns I
    agree with is that if one of these tools is compromised and then
    these concerns are valid. That is a deep compromise. There is no
    unauthenticated user input here.
  • David Waite: we probably need to think how this cascades up and
    down. i have enterprise IdP, signal to do something with user
    session does not cascade up. intents behind this are usually not
    captured. log out signal is characterized as "user who is coming
    back might not be the same user". API might not have the context
    what happened
  • Aaron: I think you are talking about client state, I want to target
    already issued Access tokens.

Thank you all!