Note takers: Phil Hunt, Tony Nadalin, and Aaron Parecki JWT Profile for ATs - Vittorio ============================== Phil/Tony's Notes: ------------------ Recap - Though JWTs widely used, inconsistent syntax leading to interop issues. Common anti-pattern of clients asking for ID Tokens instead of access tokens because they want standard token format. Limited interop due to different syntax being used, no guidance Schema for most common entities Token Validation Guidance Nutshell Provides claims layout, relationships and references, validation guidance, security and privacy considerations. Tony asked about validation. Is this meant to be normative? E.g. library conformance. (e.g. best practice vs. normative draft) V: that could be a possible outcome 00->01/02 main changes Changes and Issues Added introspection, privacy section, added notes to peeking into AT tokens, IANA registry updates, removed notes on subject type, federated IdPs Need to discuss the difference between user/app tokens, auth_time behavior Discussion Anabel – step up Authn, password based can happen at initial access token and then step up may happen sometime later and thus there may need to be correlation Distinguishing between user and app tokens Justin: Don’t let client’s choose their own id V: agreed J: grant_type was not very helpful. We differentiated based on if sub and client_id are same. Client_id alone introduced wierd signalling issues. Clients can use client assertions on their own which is not client credential type which introduces other issues. J: Annabelle has a draft for subject type identifiers. That might provide more structure and could be adopted into this. It provides rules about how subject identifiers relate to sub claim Annabelle Backman: I think that would be bad idea because the draft talks about subj identifiers and not subject types. They could be handles to an app, entity org or anything. Maybe there is a parallel approach but I would not recommend AB: I agree with not use grant type because it couples this to protocol implementation details which may not make sense. If you have this it will introduce coupling which undermines the value of the spec. What are the key use cases being solved? V: I tried to tease this out. The API wants to know if the client was confidential or not. Or when they want to ensure only particular client_id can be used for a specific purpose AB: That seems different from user vs. app. (3-leg vs. 2-leg) J: I have a concrete example with medical records Auth_time behaviour Doubts about complexity, ambiguity May need additional claims to provide meaning. e.g does auth_time change during a step-up authentication or does it point back to the original login? Bran Campbell: I am one of the doubters. A step up authentication in a session after a token issued draws a lot of links between things that aren’t linked. V: I agree it is confusing and potentially dangerous. This link between login and token session already exists. B: There can be an issue that tokens issued against a different authentication context may have no relation to the original login AB: It may be useful to differentiate so that you know when a step-up has occurred (e.g. password auth one day and MF occurs after) V; There is already some discussion of this in the spec along these lines. Authenticated encryption Should we recommend the current specs being only symmetric? Mike Hones: JWE does authenticated encryption. BC: that doesn’t give the properties we are looking for Rifaat - unfortunately we are out of time. Aaron's Notes ------------- Recap of the document * most ASs already use JWTs for access tokens * the tokens contain the same entities but different syntax * this happened in an organic fashion so is a good candidate for standardization * more products are asking clients to send ID tokens instead of access tokens to APIs * e.g. kubernetes, amazon * because the APIs need the data contained in the ID token Summary * defined a layout with common claims used in existing access tokens * defined a clear relationship between resources, scopes, etc * wrote guidance on token validation * detailed privacy and security considerations Example of JWT access token Tony: is the token validation guidance meant to be normative? Vittorio: the guidance is meant to be exact steps to follow Changes and open issues * changed the references to the claims to JWT specification instead of OIDC * added introspection as a source of claim types * expanded privacy sections * added a reminder that clients should not peek into access tokens * added IANA registration templates Discussion items Distinguishing between user and app ATs * existing systems have a mechanism to determine whether an access token was issued to a resource owner or an application * e.g. does the subject represent a user or a client * there are very different ways people have achieved this * omit the "sub" for app tokens - IdentityServer does this * add a "grant_type" claim - don't want to burden the client with this knowledge * [sub == client_id] => app token - but doesn't work when a system uses different mechanisms to define sub and client_id terms * "subject_type" claim - indicate that the "sub" represents a resource owner or an application Justin: * if you're letting clients pick their own client_id you're opening up to a lot of other problems * we tried a grant_type claim in a deployment and it wasn't helpful, ended up dropping it and used sub==client_id claim * annabelle has a draft for subject identifiers, in secevents - draft-ietf-secevent-subject-identifiers-05 - there is an object structure for user subjects Annabelle: * subject identifier is probably not a good idea, that draft talks about types of subject identifiers, not types of subjects * what are the use cases where people distinguish between user and app subjects? Vittorio: * sometimes the API wants to know whether the client was confidential or not * ... Annabelle: * that sounds less like user vs app, and sounds like something about how the client was authenticated and maybe the user was authenticated * when I hear user vs app subject types I think was there a user involved at all Justin: * +1 to annabelle, and I have a concrete example of that Vittorio: * we'll go back to the list on this Auth_time (amr, acr) Presentation by Aaron - OAuth 2 for Browser Based Apps ====================================================== Should use AUTH_CODE FLOW Must not return access tokens Must use state param Same-Domain apps. Aaron: should this be part of the discussion if it recommends don’t use oauth Justin: Yes I think this is useful and we need to be clear about boundaries. Eg. if your backend does oauth thats fine but it is outside the scope of this document. One problem is the bafckend developer and the spa developer see themselves as decoupled when they actually aren’t. V: I agree 100% we need to give guidance even if it is to not use oauth. Help people to understand the implications of the choice. If in the future they make architectural changes than they need to understand the implications of their choice. B: It doesn’t necessarily mean backchoicing. V: It depends on the developer stack and may or may not be difficult Torsten (via Jabber): I think single-domain apps do not belong in the BCP they should have their own BCP Aaron: Same-domain is not normally a distinction oauth normally makes. What are the questions people are going to ask and expect H: We should find out what the majority thinks. It might not be an IETF topic at all (referring to single domain apps) B: I do agree with Justin. But there is a problem of assuming by omission. Some mention should be made…I don’t know how. Aaron presented other open questions Re: PKCE vs. State usage Daniel: Suggested using must using PKCE per security bcp. A: that changes the spec as it states use state. Is it better to not mention it? Jabber(unknown); leave it out Should we remove password grant: John Bradley: +1 torsten and phillip (jabber unknown) : +1 each There are a couple of items in the draft not in the security bcp. E.g. there are some historical aspects of implicit flow. JR: +1 A: I don’t want to duplicate but would like to summarize and normatively refer to the sec BCP SPA w/backend - should we have some indication that the AT may be sent to the browser? The problem is the AS may be confused that the browser token was issued to a confidential client but it is flowing through a much less trusted browser? Is anyone opposed to this (section)? Nat: Do we need to send tokens to the browser in this case? A; In some deployments it is much easier. We could say don’t do that but then it limits architecture. AB: I think there are some cases where the credentials need to flow through the browser. The AT is acquired by the backend and then supplied to the front end. I am not strongly opposed to a signal but we have to be realistic that we often don’t know what clients are doing with ATs. We might be creating a false sense of confidence in such a signal. Torsten: I don’t think this is a good idea without sender constraining. BC: I tend to agree with AB. It’s a slipper slope. It feels not good. Recognizing it is going to happen and providing guidance is useful V: If there is a way to tell the authorization server the intent that might be useful. AB: As a developer I am already dependent on something in the browser such as cookies (sessions). We already have to think about the downstream security. It is the same whether or not the AT flows. Refresh tokens in SPAs *out of time* Aaron: I will continue the discussion on the list Daniel - OAuth 2 Demonstration Proof-of-Possession ================================================== MTLS is good but not great for browser. TOKBIND has no current browser support Need solution for browser apps. Main goal to prevent token replay at a different endpoint. Currently at version 02. Hannes: We have existing WG items with similar stuff. Have you considered that work. One part is key transport, second piece is Justin’s HTTP signing document which had challenges. What motivated to come up with a new mechanism? D: DPOP is hopefully a simple and concise mechanism. H: The other is too. We tried to balance in HTTP and COAP. Nat: Wondering about the relationship of this draft ot key distribution. There is another draft I wrote called JPOP. This one looks like more the same thing but limited to code flow. BC: DPOP came out of a desire for a simplified concise public key mechanism at both the authz and resource server. I think it does more with less. It has a lot of conceptual similarities and is much more concise. H: Where it is simpler? BC: It is simpler in key distribution because there isn’t the overhead for symmetric keys. H: The reason we have it is for alignment with other groups. BC: The work here is specifically geared at work in the wild. The other specs are underpinning for work in other groups. H: There is historical decision to have the work here because of the HTTP requirements (as opposed to ACE) AB: We too find it limiting without symmetric as asymmetric can be just too slow. Does proliferation of methods and utility outweigh the simplicity gain? JB: The origin of this came from the security workshop specifically focused on applications to do PoP should token binding not come to fruition. We could use web-crypto and create a non-exportable key in the browser. This is why there is no support for symmetric key. Should we reconstitute that document and profile it for this use? We could re-factor the document to refer to other specs that need to be resurrected if the group wants. But the issue is we have no current method to solve the use case. DO we address in a narrow sense or refactor to point to the other specs? I am open MJ: Representing MS engineering teams who did detailed analysis. 3 comments: 1. Want to use different POP keys for AT and RT. 2. Surprised by tokens being bearer tokens and secondly being a proof distinct from the token where the recipient checks the proof. Aaron: this has been changed in the draft. It is no longer a bearer token 3. Despite sentiments of the WG, we are going to use implicit for years. We would like a proposal for using DPOP with implicit flows. Aaron: We should discuss after if the WG would like to adopt. MJ: Want to see it minimally in a separate draft. BC agrees. JR: signatures are surprisingly hard. signing headers and bodies are very important in other types of requests. I really like this approach. But I agree with Hannes that having a server provided symmetric key is useful. H: none of the documents allow server side generated keys JR: I used this pattern in the XYZ proposal. I also didn’t use the signing draft for that because of the lack of energy to move it forward. Message signing and key possession are both really needed. Cavage draft seems to be generating momentum. Roman: strongly urge the equities of other groups and surface them Daniel - Pushed Request Objects =============================== Create a new request object endpoint so that JAR requests can be POSTed. Aaron: I think these are good points. This is exactly what I implemented when justin talked about xyz JB: JAR has been in place for a while, We left JAR open to this pattern but didn’t include it. Had the timing been different it may have been included. AB: This is very similar to what the device auth draft defines. Only difference is how the response gets back to the client. It seems wierd to standardize two different methods to do essentially the same thing. JR: Does not think this can be collapsed into a common model. It does need to be its own thing. It is motivation for a next gen protocol like XYZ has. Nat: Sending the request URI is already covered in the JAR document to keep it small and concise. Note: the document is not yet published to IETF as an ID. Chairs: Should we bring this to the IETF. General hum in favour. None against Annabelle: Request Signing in AWS Presented ============================================ Used for authentication, message integrity and replay protection Used on almost all requests use this What goes into the sig – method, endpoint, path, timestamps and parameters along with some headers 3 steps C14N request Create string to sign Calculate signature Issues: Versions of HTTPS changed headers and what was signed and what was expected Rifaat: Nested JWT Presented ============================ Volunteers to read Phil Hunt, Nat Sakimura and Mike Jones will read it.