# OAuth WG Agenda {#oauth-wg-agenda} # Monday Nov 7th {#monday-nov-7th} Minute taker: Hannes Tschofenig ## Chairs Update - Rifaat/Hannes - 15 minutes {#chairs-update---rifaathannes---15-minutes} Side sessions of OAuth at * Tuesday at 14:00 - 15:30 (Richmond 6) * Thursday at 14:00 - 15:30 (Richmond 6) Roman mentioned that the JWT Response for OAuth Token Introspection is waiting for completion of the security BCP. Discussion about reviewing the comments on the security BCP during the side meetings. For the DPoP Roman wants to specifically talk about algorithm agility. The DPoP draft also has 6 authors and this needs to be mentioned in the write-up (with a justification). ## OAuth 2.1- Aaron - 20 mins {#oauth-21---aaron---20-mins} Aaron talks about the changes since the last IETF meeting and the planned changes. The draft open issues can be found at https://github.com/aaronpk/oauth-v2-1/issues. * CORS Recommendations (#133) Aaron suggests to add a section with CORS recommendations to the draft. Daryl Miller: In the world of WASM does this also apply? Aaron: I think we should not mention JavaScript BrianC: Agree with the recommendations but requires background information. Mike: Asking what the specific language is we should be using. * redirect\_uri at token endpoint (#54) Should this parameter be required at the token endpoint? Mike: I suspect some code is going to break because the parameter is required to be there for backwards compatibility reasons. I would be fine with a note saying that this parameter is redundant when PKCE is used. Aaron: If OAuth 2.1 is used then there is always PKCE. +1 from George Aaron: If an AS follows best current practices then it should already support the OAuth 2.1 functionality and the absence of the redirect\_uri parameter does not cause any problems. Daniel: We should make sure that we are not introducing a security BCP and OAuth 2.1 incompatibility. Filip Skokan: If the purpose of OAuth 2.1 is to take 2.0 and to apply all the BCPs then we should not omit this parameter. Aaron: The question is whether an OAuth 2.1 client can interact with an OAuth 2.0 AS that has all the BCP applied. Filip: If there is a discovery service then we can do this. Aaron: I think there is nothing else like this yet, things where 2.1 is describing things that are not in the BCP. So if there are other things, then it could make sense to use a discovery flag. I don't think there are anything else like this yet but it is worth double-checking. Justin: If we do option 2, we don't need discovery, because regardless what the client does the AS will do the right thing if it's a 2.1 AS. Aaron: That works great for 2.0 and 2.1 client talking to a 2.1 AS. But that doesn't work for a 2.1 client talking to an OAuth 2.0 AS. So that's the only one that breaks and if we're okay with that it's fine. Rifaat: Are people comfortable with that? I see nods. Brian: Don't see problems with approach #2. Aaron: There is only a problem when a OAuth 2.0 client talks to an Oauth 2.1 AS. Brian: That's OK for me. Way forward: AS should accept and verify the redirect\_uri if present, but not require it. optionally allow clients to send it (see item 2 on slide 8) Rifaat: And make sure that the one breaking change is documented. Filip: Personally I'm not okay with it breaking but if the consensus is that we're okay if it's documented then sure. But I'm not sure that should be the outcome unless there's discovery. Aaron: My gut feeling is that it's okay, clients are less likely to update unless they need to. So if they want to update, and they update to what's called a 2.1 client, they won't be expecting it to work with a 2.0 server anyway, since there will be other things that break anyway since 2.0 is a broad definition anyway. It feels like this is the okay way to have it break. Let's also revisit this decision after I make the list of other breaking changes from 2.0. So if it ends up being the only breaking change for that combination of roles then we can revisit this discussion. ## Browser-based apps - Aaron - 20 mins {#browser-based-apps---aaron---20-mins} Aaron talks about the changes since the last IETF meeting, particularly the architectural patterns. Aaron is soliciting feedback on the architectural patterns saying that there are different ways to design the implementions. There are different drawbacks with the present techniques and none of them is good. Aaron: Action item - Capture the recommendation of not using the Cookie API as a storage API Planned changes: * Add a section with recommendations for storing tokens * Review Security BCP to ensure consistency * Mention the endpoints that need CORS protection Aaron anticipates to get these changes in before the next IETF meeting. ## Selective Disclosure (SD)-JWT - Daniel - 30 mins {#selective-disclosure-sd-jwt---daniel---30-mins} Repo: https://github.com/oauth-wg/oauth-selective-disclosure-jwt Daniel presents the updates since the last IETF meeting. Draft became a WG item in the interim. New draft uses improved terminology. Digest derivation algorithm was introduced to refer to keyed and unkeyed hash function. Brian: The concept of digest derivation algorithms is problematic for developers. The name, digest derivation algorithm, is not used in the industry. The need for both approaches is questionable. The use of HMAC is unspecified. John: Agree with Brian. What you are doing is similar to KDF. You might want to name it similarly. I would either remove it and say that you have hashing algorithms or you have to add a lot more specifications. Signature validation: Brian raises a question about the holder binding and the complexity it uses. Daniel says that this is discussed later. Tony: Does the holder binding also do device binding also? Daniel: Yes, it can be. Tony: I didn't see any text. We need to add text explaining his. Daniel talks about the problems with the transfer of JSON and the use of hasing. It is possible that the JSON is modified along the way from the issuer to the verifier. Hannes believes that canonicalization is unavoidable. Daniel disagrees. Daniel uses a different approach by changing the JSON into a byte string with the assumption that the byte string is not modifed -- only the JSON. Justin: JSON strings have the ability to use unicode-encoded characters. You have to be more precise. For example, inside JSON strings you are allowed to replace forward with backwards characters. This works until it does not. Look at RFC 8785 - JSON Canonicalization Scheme (JCS). Daniel does not see the problem and believes that when you call JSON encode and then JSON decode you get the same data. Justin: You have to be precise when you assume to fetch and use the data. Justin: I am not against the approach but you need to be precise. Orie: What you are doing is canonicalization. Mike: I think you are doing hardening the JSON against modifications. Yaron: Maybe you can change the claim names and the cardinality. A well-defined claim document that is robust from a security point of view. Daniel: I am not sure whether this helps. 5 implementations and interoperability testing envisioned. ## Step-up Authentication - Brian - 15 mins {#step-up-authentication---brian---15-mins} Brian provided background for the draft and also walked the group through the changes of the draft versions. Daryl: If you add a new parameter into the www-authorize HTTP header field. Have you looked into the structured header fields work of the HTTP working group? Brian: I have to look into it. The space-delimited field is in the value of the field. Jaimandeep Singh: Do we want to include the other parameters as well, like client authentication parameters? Brian: It is beyond the scope of this document or not applicable. Next step: Waiting for shepherd write-up. ## Interactive Authentication of Non-Interactive HTTP Requests - Ben Schwartz - 15 mins {#interactive-authentication-of-non-interactive-http-requests---ben-schwartz---15-mins} The draft is about pop-up authentication. Assumption: OAuth requires client to know who they are going to talk to. Aaron: What we don't have is where the AS is? Define location of the AS at the resource server. Armando Faz-Hernandez: We are working on an option in the HTTP header working group. (In privacy pass working group) David Waite: There was an IETF OAuth draft to use the link header to advertise the AS. Filip Skokan: The presentation did not clarify who is driving the interaction. If it is the user agent then it is limited to the web use case. Benjamin: This draft is expected to also work with a CLI application. John: This is an interesting idea that needs to be explored. The error from the RS returned what scopes were required but we didn't provide information about what AS to use. There were security concerns. If we change the model, we have to do a deep security review. Nat wrote a draft about it. There are also a bunch of things in browsers that allow WebViews that may be in conflict with how browsers work (such as proof-of-possession tokens). It is definitely worth thinking about. # Wednesday Nov 9th {#wednesday-nov-9th} Minute taker: Hannes Tschofenig ## JWT Embedded Tokens - Rifaat - 15 minutes {#jwt-embedded-tokens---rifaat---15-minutes} Rifaat goes through his slides. Yaron: Over time there have been multiple different semantics for different tokens. Maybe it is good to express it explicit in the token what the semantic is. Not necessarily to standardize it but to include information in the token since it is signed. Rifaat: give me an example. Yaron: This is use case specific. For example, you shouldn't Brian: I haven't worked a lot in this field but you have an extra parameter. The idea behind the token exchange was to use the token type to use rather than using additional parameters. Robin Wilton: Regarding the repurposing one claim from one area to another area: Don't worry about the semantics. ? : You are wrapping the original token into the new token. You give the recipient the full control over -- complete delegated. Kelley Burgin: If you include a token from one AS into a token that is issued by a different AS. Rifaat: That's the idea. Kelly: You have to validate both. Rifaat: Yes. ## Fine-grained Transactional Authorization - Atul - 15 minutes {#fine-grained-transactional-authorization---atul---15-minutes} Atul goes through his presentation (but had to skip a few slides). Discussion about this topic will continue at the side meeting tomorrow. Interested parties are encouraged to read the background material linked in the slide deck and to join the side meeting tomorrow. ## Cross-Device Flows - Pieter - 30 minutes {#cross-device-flows---pieter---30-minutes} Pieter presents the slides. Justin: This is really important work. The user interation is often overlooked. Are we getting close to standardizing the UX? This would be important for cross- and same-device situations Pieter: The word standardized is the word. We want a very consistent user experience. Strong guidance and turning the guidance into requirements. I have low expectations standardizing the pixel. Justin: There is an entire community of UX experts we want to reach out to. Rifaat: Which community is that? Justin: CM lab is the first group that comes to my mind. The Internet 2 community comes to mind. A lot of them are in the research community. Pieter: There are plenty of us here working with UX experts. We should get them involved. We can use this document to anchor the discussion. Justin: That's a good point. This is quite specific to have something to work with. Pieter: We could present this work and ask the researchers how to solve these problems. Joseph Heenan: I have read the document. I refer people to the document. I think there is interest. I think we should opt it. George Fletcher: Design pattern makes a lot of sense. John Bradley: I think this is good work. A couple of observations: The WebAuthN thing (formly known as CABLE/Hybrid) is a different thing. It is a transport thing. It may confuse people Pieter: I take the point. We establish proximity through this Hybrid protocol. John: It is more than proximity. You are not doing the OAuth flow. From a protocol flow it is pretty different. John: CIBA was cross device because it was through a call center. That's the origin of it. It was never meant to be used via a QR code. But once it started people used it for lots of things. Pieter: These protocols get designed for specific use cases in mind but then they are used for other context. They shouldn't have used the protocol in that way. I appreciate that it is not a traditional device authorization flow. John: We need a way to describe it. I think it is useful but there are some challenges for describing it. Pieter: I want to leave it with the implementers that they have better options but separating it from multiple device OAuth. Aaron Parecki: This is important. I also agree that the UX side is worth pursing. This is something that's been missing from other work we've published, but interestingly the user experience has ended up coming out similarly between different implementations of the authorization flow and device flow, there are a lot of commonalities. This is often a question asked when people go to build the authorization screen, what should you put there and how should it work. Kristina Yasuda: Great work. Regarding: "Don't use cross device flows on single device flows.". I believe that the cross device flow can also be used on single device flows in the protocols I am involved with. I think an extra sentence in the document would be useful. People are doing this today. Pieter: It is in the next version. Hannes: Are you aware of any IPRs on this document? I looked at the document and no IPRs are filed at the moment. Pieter: No, I am not aware of any. Rifaat: We will do a call for adoption on the document. ## Client ID for anonymous clients - Kristina - 30 minutes {#client-id-for-anonymous-clients---kristina---30-minutes} Kristina describes a number of different approach for how client\_ids are assigned and used in IETF/OpenID specifications today. Aaron Parecki: OAuth 2.1: Yes, the language got relaxed to say "issued by a trusted third party". I would like to further relax it to "issued by an outside party". The security BCP says that the OAuth client should not influence their own client id. That's not the right recommendation. The example use case I would like to bring up is the open web where there is no trust chain available (Wordpress, for example, where blogs are run independently and are edited using an app running on a phone. The app on the phone does not know what all the Wordpress instances are installed). There is precedent for client IDs as a URL since 2014. The IndieAuth spec was published as a [W3C Note][1], now at [https://indieauth.spec.indieweb.org/][2] Brian Campbell: What is client id used for? It is used as a record for what authorization is granted for. That needs to be added. That's what every authorization server does. Darrel Miller: We have so many issues with developer experience. We have a lot of concerns around garbage collection and the consent issue. When someone attempts to get access and the user confirms that an app grants consent to access information to the client id. Justin Richer: Most of what is in the slide is about the registration and not in the client id. As a response to Brian, you do not need a client id to identify a row in the database. The dynamic registration spec was added to obtain a client id. There are a number of cases where you do not need the client id. Today, if the client id has to be there and if you do not utilize it things break. Technically, you do not need the client id, however. The language in 2.1 is an improvement. I think we need to think about client registration. Client id is used as a stand-in on the registration. Kristina: I didn't want to use "registration" when the client brings its own metadata. Justin: I agree, registration is very narrowly defined in OAuth. So, it may need to be defined more generically. Tobias Looker: Strong support for his work. Have done some work myself in this area. Much of the language on this client id language is limiting. The ability for the client to have some identifier that is assigned by some third party as well as self-assigned is important. Associating a client id with meta-data is best described as registration. It may be associated with some policy. (Missed some parts) Looking for feedback on https://datatracker.ietf.org/doc/html/draft-looker-oauth-client-discovery-01 John Bradley: There is a perception of the OpenID Foundation to require a unique root. That's a wrong perception. There are an infinite number of roots supported. Kristina: I think this needs clarified. [1]: (https://www.w3.org/TR/indieauth/) [2]: https://indieauth.spec.indieweb.org/