# IETF118 - OAuth WG Agenda {#ietf118---oauth-wg-agenda} ## Tuesday (60 min) {#tuesday-60-min} ### Chairs update – Rifaat Shekh-Yusef/Hannes Tschofenig (15 min) {#chairs-update--rifaat-shekh-yusefhannes-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 * DPoP: RFC 9449 * Step up authentication: RFC 9470 Security BCP pushed to the IESG. New documents adopted: * SD-JWT * Attestation-based client authentication * Status Lists ### Charter discussion (30 min) {#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) {#sd-jwt--kristina-yasudadaniel-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) {#wednesday-120-min} ### Protected Resource Metadata – Mike Jones, Aaron Parecki (20 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) {#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) {#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) {#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) {#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) {#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 {#friday} Note-taking: Kristina ### Transaction Tokens – George Fletcher (20 min) {#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) {#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 {#qa} * 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) {#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) {#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 {#qa-1} * 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) {#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!