Minutes interim-2020-oauth-04: Mon 12:00
|Web Authorization Protocol (oauth) WG
|Date and time
|Minutes interim-2020-oauth-04: Mon 12:00
Minutes taker: Jared Jennings Interim 2020 OAUTH 2020-04-13 meeting notes Participants Alan Cota Brian Campbell Brock Allen Denis Abilashini Thiyagardjah Hannes Tschofenig Rifaat Shekh-Yusef Dick Hardt Tony Nadalin Dominick Baier George Fletcher Janak Amarasena Jim Schaad Jared Jennings Justin Richer Mike Jones Cristofer Gonzales Bjorn Hjelm Annabelle Backman George Fletcher Kazunori Fujiwara Phil Hunt Nico Peterson Peter Yee Roman Danyliw Tim Cappalli Thumilan Mikunthan Matthew de Haast Vittorio Bertocci Brock Allen Aaron Parecki David Waite ** Plus others a total of 32 Upcoming meetings can be found at https://events.oauth.net/tag/ietf Other official meeting events can be found at https://datatracker.ietf.org/meeting/upcoming 1. Nested JWT https://www.ietf.org/archive/id/draft-yusef-oauth-nested-jwt-03.txt 2. JWT Profile for Access Tokens https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ https://datatracker.ietf.org/doc/slides-interim-2020-oauth-04-sessa-chairs-slides/ https://datatracker.ietf.org/doc/slides-interim-2020-oauth-04-sessa-nested-jwt/ https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth Meeting Kick-Off * Rifaat - Nested JWT Introduction * Enclosing JWT is limited to contain the full Goal Extend the scope of the nested JWT to allow claim payloads Use Cases Native App Telephony Service controlled by an AS STIR Use Case PASSporTExtension for Diverted Calls draft Hannes: reminded the group that this use case could be critical for handling Robocalls Brian Campbell: also reminded the group that there is another draft in process that relates to this use case. Questions Annabelle: Questioned the value of the JWT. That it's not clear what the JWT is for or the nature of the value. Mike J: Naming would be clearer if we didn't use the "nested JWT" term. If this goes further, Mike suggested other wording for example. Included JWT. Brian C: Noted that nested was designed for a very different purpose; like Signed or Encrypted JWT. Also, do we need a content type in a claim, when during processing the processor will process the NJWT. Anthony (Tony): Agreed that there is a need for nested claims, at least for proof presentations concerned or claim aggregation, but yet separated traceability of the claims. Annabelle: Regarding naming - presented the idea that the outer JWT is playing the role of an envelope. Question: Tony, what do you see that is missing today. Tony: Multiple subjects need to be defined. To be able to track backwards (the multiple subjects) Annabelle: What can be generalized? Can the use case or how we relate the outer JWT to the inner. Jared: Can this be considered a referred_to or a referenced JWT. George: If we are designing a protocol, per say, an inclosed JWT. How can we bind these claims together or how can we add value if these are not referenced. Mike: I want to support the comment, that a new content type is not warranted. Normally, it would apply to the whole body. Instead, the content type seems to be specifying a specific element of the claim. Mike does support the mobile drivers license use case. Phil: Inclosed vs. nested - nested supposes that additional claims could be, meaning the chain could be multi-level. Comments will be taken back to the list for additional conversation and additional details. Rifaat will work with Tony to get additional use cases. Vittorio JSON Web Token (JWT) Profile for OAUTH 2.0 Access Tokens 1. Claims layout for the 2. Token validation & AS metadata 3. Detailed security and privacy considerations 4. Clear relationship between resource references, scopes, and token Main Changes since WGLC Clarifications amr,acr, auth_time, iat error responses (invalid_token) Warning about the futility of using different keys for signing ATs and ID tokens as a security measure Clarified that the JWT AT validation steps aren't meant to be executed in strict sequence Normative removed explicit auth_time check description iat,jti (OPTIONAL -> RECOMMENDED) Open Questions 1. Should JTI, IAT be REQUIRED 2. Should single resource/audience constraints be relaxed New Items 1. Should the profile be richer (what is missing) 2. privacy Question Should jti, iat be REQUIRED? Annabelle: supports "REQUIRED" Dick: Supports "REQUIRED" George: +1 "The vote passed" Single resource/audience constraints * scope (scoping) is one possible solution * Just weaken the language and instead add the recommendations and guidance to a Best Practice. Comments/Questions Annabelle: The current language tries to address the confusion of a specific scenario that leads to this possible confusion. Maybe instead provide language that specifically blocks. Vittorio: Current position is adding wording that depicts the scenario and that you want to avoid the particular scenario from occurring. Annabelle: "Missed Opportunity"? next opportunity is in the Rich Authorization draft. George: Believes that adding and using the language of RECOMMENDED and including best practices and examples and these would likely be in a separate document. Depending on the scenario or entity, scoped scopes could be a big deal while not so much for a single entity. Brian C: The wording and clarification of amr, acr, auth_time, iat seems to reference OAUTH, but with no clarification. Vittorio: explained that he had just moved the wording around, paragraph arrangement to add clarity. Denis: Privacy concerns regarding privacy and traceability of parameters. At least these privacy considerations should be outlined in detail. Vittorio: 1. Privacy principles - doesn't believe we are adding anything that goes against 2. Knowing where a token is going - we are following best practices - per existing RFC's. 3. sub: depends on what the AS places in the sub 4. client content inspection: architectural mistake. The fact that a JWT is being used doesn't change the flow. The content is the matter of the AS and RS. All I can see is that it is in a form that I can pass. Meeting concluded.