Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[George Fletcher <[e-mail]>]

Feedback on the spec...

Section 1. Introduction
 ��� second line: scenario should be plural --> scenarios
 ��� second sentence: "are not ran by" --> "are not run by"

Section 2.2.1 Authentication Information Claims
 ��� I'm not sure that this definition of `auth_time` allows for the 
case where a user is required to solve an additional challenge. Take the 
case of a user who is required to pass a secondary challenge before the 
"stock purchase" action can be completed. According to the current spec 
definition, the `auth_time` value MUST NOT be updated when this 
secondary challenge is completed.

 ��� I think there is a difference between session_start_time and last 
auth_time. This feels more like it's defining the session_start_time 
concept.

 �� These same issues can apply to the `acr` and `amr` values as well.

 �� Even if for this secondary challenge a new refresh_token is issued, 
it is unlikely many relying parties will want to treat that as issuing a 
new session. The goal is to keep the user logged in to a single session.

Section 2.2.3 Authorization Claims
 �� I find the statement "All the individual scope strings in the scope 
claim MUST have meaning for the resource indicated in the aud claim" 
somewhat problematic. In many deployments today for 1st party clients to 
the authorization server and taking into account mobile applications, 
the access token most like contains scopes for many of the 1st party 
backend APIs. It's possible to get around this by setting the 'aud' 
claim to something like "com.example.apis" and hence all the issued 
scopes map to that audience claim but that is just working around the 
MUST in the spec. Given the lack of specificity of the 'aud' claim and 
the 'resource indicator' claim for that matter, pretty much anything can 
be made to comply. In that context, it seems like RECOMMEND is a better 
normative clause.

Section 3. Requesting a JWT Access Token
 �� Per my comments above I suspect that requiring all JWT access tokens 
to include an audience claim will just devolve to audience claims that 
are somewhat pointless (in order to meet this MUST in the spec). Given 
the mobile app environment today, it is unreasonable to ask the mobile 
apps to downscope every access token before making an API call to the 
backend APIs which is what the spirit of audience and resource 
indicators seem to imply.

 �� Why MUST the AS reject a request with more than one resource 
parameter? If a request comes in with no resource parameter and multiple 
scopes the AS is not required to reject that request. Is there much of a 
semantic difference between the two? In the case of no resource 
parameter and multiple scopes the AS might issue an access token with 
multiple audience values (as is allowed by RFC 7519). Also, the audience 
claim is not solely for resource indicator values but is defined to just 
be a string. To me it feels like the text is implying that the only 
valid audience value is also a resource indicator (which from previous 
discussions on the list it was implied they have a slightly different 
semantic).

 �� The model described here works well if myco.example really only 
provides a single service. But if instead myco.example provides multiple 
services each with their own endpoints (srva.myco.example, 
srvb.myco.example) and scopes, for me this model begins to break down. 
Either mobile apps are required to downscope all tokens to just the 
service they are calling at that point in time (which can have latency 
and connectivity issues), or myco.example has to create a generic 
"audience" string that represents all of example.com which doesn't seem 
to be the spirit of the existing specs.

 �� In summary, I feel that this text is binding too tightly resource 
indicators to the audience claim. What is described is perfectly 
reasonable in a use case that is applying resource indicators in this 
way but is not indicative of the widely deployed models that already exist.

Section 4. Validating JWT Access Tokens
 �� Step 4. -- Can we change the wording to not require resource 
indicators? What about... "The resource server MUST validate that the 
'aud' claim contains a string that represents the audience of this 
resource server."

Section 5. "cross-JWT confusion"
 �� I think there may be confusion around what is meant by "distinct 
resources". In my example above, are srva.myco.example and 
srvb.myco.example "distinct resources"? or is the goal here to say that 
we want different audience values generated for cross-organization 
resources. For example, are mail.google.com and youtube.com "distinct 
resources"? or would an audience for google suffice in meeting the 
meaning of this paragraph?

 � I'm having the same confusion in the next paragraph regarding the 
phrase "different resources". Are services provided by the same company 
"different resources" or are they all considered the same resource. Can 
an access token be issued with scopes for both mail.google.com and 
youtube.com? And if not, why note? Preventing this puts undue burden on 
mobile based applications.

Section 6. Privacy
 �� cofidentiality --> confidentiality


Thanks,
George