Minutes interim-2020-oauth-04: Mon 12:00
minutes-interim-2020-oauth-04-202004131200-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.