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

[Vittorio Bertocci <[e-mail]>]

Hi Takahiko,
thank you for reviewing and taking the time to write down your feedback!
Inline

[..]  apparently conflicts with RFC 8707. I'm afraid vendors that support
> RFC 8707 won't support this draft unless the requirement is loosened, for
> example from MUST to SHOULD.

I don't think this can be characterized as conflict. As a profile, it is
expected that this spec will be more restrictive. As long as a token
complying with the profile requirements is also valid according to 8707, I
believe we are in valid territory even if the vice versa does not hold (eg
a token can comply with 8707 but not be well formed according to a profile).

  The rule described here whereby to determine the default value of the
> "aud" claim is unintelligible.

Could you expand on the specific points you find unclear?

  I don't think the rule referring to the "scope" parameter is worth being
> defined. That "aud" is missing but "scope" is available is enough for
> resource servers. In other words, if "aud" is determined based on the
> "scope", why do we have to set "aud" redundantly?

Scope is actually not sufficient for many resource servers. Whenever an RS
is facading a collection of existing finer grained resources, scopes
representing permissions might be ambiguous - if my API facades both
calendar and inbox, what does the "read" scope refer to? Having an audience
resolves that ambiguity.
Also, many AS operate as multitenant services, where the need to solve
resource references ambiguity is even greater; and plenty of real world 1st
party solutions use OAuth for calling their first party API, without
implementing delegated authz logic hence not using scopes directly.
Also, see the next point.

  Requiring the "aud" as a MUST claim is the reason that this draft has to
> introduce philosophy about "aud" that may conflict with other
> specifications and may not be supported by all implementers. I would
> suggest changing "REQUIRED" to "OPTIONAL".

The most widespread JWT token validation logic deployed today is repurposed
from OIDC, where aud is mandatory. Most of the JWT AT solutions in the wild
use it. I believe that's enough reason to mandate aud in an interop profile.

On Mon, Mar 23, 2020 at 11:47 PM Takahiko Kawasaki <[e-mail]>
wrote:

> (1)
> The requirement in the paragraph below excerpted from "3. Requesting a JWT
> Access Token":
>
> *If it receives a request for an access token containing more than one
> resource parameter, an authorization server issuing JWT access tokens MUST
> reject the request and fail with "invalid_request" as described in section
> 4.1.2.1 of [RFC6749] or with "invalid_target" as defined in section 2 of
> [RFC8707].  See Section 2.2 and Section 5 for more details on how this
> measure ensures there's no confusion on to what resource the access token
> granted scopes apply.*
>
>
> apparently conflicts with RFC 8707. I'm afraid vendors that support RFC
> 8707 won't support this draft unless the requirement is loosened, for
> example from MUST to SHOULD.
>
> (2)
> Regarding another paragraph shown below from the same section.
>
> *If the request does not include a resource parameter, the authorization
> server MUST use in the aud claim a default resource indicator.  If a scope
> parameter is present in the request, the authorization server SHOULD use it
> to infer the value of the default resource indicator to be used in the aud
> claim.  The mechanism through which scopes are associated to default
> resource indicator values is outside the scope of this specification.  If
> the values in the scope parameter refer to different default resource
> indicator values, the authorization server SHOULD reject the request with
> invalid_scope as described in section 4.1.2.1 of [RFC6749].*
>
>
> The rule described here whereby to determine the default value of the
> "aud" claim is unintelligible. In addition, I don't think the rule
> referring to the "scope" parameter is worth being defined. That "aud" is
> missing but "scope" is available is enough for resource servers. In other
> words, if "aud" is determined based on the "scope", why do we have to set
> "aud" redundantly?
>
> Requiring the "aud" as a MUST claim is the reason that this draft has to
> introduce philosophy about "aud" that may conflict with other
> specifications and may not be supported by all implementers. I would
> suggest changing "REQUIRED" to "OPTIONAL".
>
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
> On Tue, Mar 24, 2020 at 10:32 AM Nikos Fotiou <[e-mail]> wrote:
>
>> Hi all,
>>
>>
>>
>> Allow me some comments and forgive me if some of them are naïve.
>>
>> - In Section 2.2 why nbf claim (
>> https://tools..ietf.org/html/rfc7519#section-4.1.5)
>> <https://tools.ietf.org/html/rfc7519#section-4.1.5)> is not considered?
>> I can imagine some interesting applications of this claim.
>>
>> - In the same section, it is not clear why some claims are required,
>> especially exp, sub, and client_id. The last two claims are not even used
>> during token validation.
>>
>> - RFC7519 specifies that, in the general case, the aud claim is an array
>> of StringOrURI values. In this draft it is not clear if this still the
>> case, or here aud is a simple string (e.g., in page 5 it is stated: the
>> resource indicated in the aud claim, rather than the resource*s*).
>>
>> - In the token validation procedure, i.e., Section 4, is there any reason
>> why the resource server first checks the aud claim, then the signature, and
>> finally the exp claim? Given the fact that Error responses are not
>> specified, returning something like “invalid aud claim” even for tokens
>> with invalid signature may result in privacy/security attacks.
>>
>> - IMHO The token validation procedure it too bound to the particular
>> discovery mechanisms mentioned at the beginning of this section. E.g., Step
>> 2 mentions a “registration” process, and Step 3 mentions and an “Issuer
>> Identifier” which must much the iss claim. Moreover, I think it should be
>> explicitly mentioned that the resource server “must validate that the JWT
>> access token has been singed with a signing key that corresponds to the
>> authorization server included in the iss claim”
>>
>>
>>
>>
>>
>> Best,
>>
>> Nikos
>>
>>
>>
>> *From:* OAuth <oauth-bounces@ietf..org <[e-mail]>> *On
>> Behalf Of *Hannes Tschofenig
>> *Sent:* Monday, March 23, 2020 11:18 PM
>> *To:* oauth <[e-mail]>
>> *Subject:* [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
>> 2.0 Access Tokens"
>>
>>
>>
>> Hi all,
>>
>>
>>
>> this is a working group last call for "JSON Web Token (JWT) Profile for
>> OAuth 2.0 Access Tokens".
>>
>>
>>
>> Here is the document:
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04
>>
>>
>>
>> Please send you comments to the OAuth mailing list by April 6, 2020.
>>
>>
>>
>> Ciao
>>
>> Hannes & Rifaat
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>