Minutes interim-2020-oauth-04: Mon 12:00
Web Authorization Protocol
||Minutes interim-2020-oauth-04: Mon 12:00
Minutes taker: Jared Jennings
Interim 2020 OAUTH 2020-04-13 meeting notes
Matthew de Haast
** 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
1. Nested JWT
2. JWT Profile for Access Tokens
* Rifaat - Nested JWT Introduction
* Enclosing JWT is limited to contain the full
Extend the scope of the nested JWT to allow claim payloads
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.
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.
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
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)
1. Should JTI, IAT be REQUIRED
2. Should single resource/audience constraints be relaxed
1. Should the profile be richer (what is missing)
Should jti, iat be REQUIRED?
Annabelle: supports "REQUIRED"
Dick: Supports "REQUIRED"
"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.
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.