This feedback is from a Microsoft engineer on the Azure Active Directory
identity team:
* 1
* Missing space at “Tokens(JWT)”
* 2.1
* Use of “MUST” saying one form must be used, followed by “SHOULD”
saying a different format should be used is a bit confusing. I get the point,
but I had to read it several times.
* Missing space at “Therefore,the”
* 2.2.1
* References the definitions of “acr”, “amr” and “auth_time” from OpenID
Connect. In OpenID Connect, these explicitly refer to the end-user’s
authentication. Does this mean these claims should only be used when the
subject is a user? If so, then it might be good to clarify. If not (and these
also apply for client credentials, for example), then a reference to OpenID
Connect may not be ideal.
* 2.2.2
* Use of “resource owner” suggests the resource owner is the subject of
the token. This is not always true. In client credentials it’s not, and even in
scenarios with a user, is it necessarily the resource owner who is
authenticated/authorized? (Or could it be a different user who has been
separate authorized for the requested access by the resource owner?)
* 2.2.3.1
* Link to section 4.1.2 of SCIM Core is actually linking to section
4.1.2 of this doc.
* States “groups”, “roles” and “entitlements” in SCIM don’t have a
vocabulary defined, but as far as I can tell, “groups” does have a syntax
defined in SCIM.
* 3
* Missing newline in the example, before “&state”
* 4
* States the configuration metadata is used to: “advertise to resource
servers [and] what iss claim value to expect via the issuer metadata value”.
This seems circular, since the configuration metadata is itself obtained by
appending a suffix to a known (and trusted) issuer value, right?
* “AS” I used without having been introduced as abbreviation of
“authorization server”.
* States that any JWT token with “typ” value other than “at+jwt” must be
rejected.
* The value “application/at+jwt” should also be accepted.
* As written, this might be interpreted to mean there is no
possibility of a future JWT token profile to be specified for use as a Bearer
token (e.g. one with media type “application/example+jwt”). I believe the
intent is to say that if the “typ” value is not “at+jwt”, it should rejected
for this profile. (But maybe that’s already understood?)
* Third bullet suggests the issuer identifier is obtained through
discovery. Discovery defines the location of the metadata to be derived from
the issuer identifier. This circular reference is confusing.
* Use of singular suggests there is only one possible “aud” value that a
resource server would accept.
* States the signing key must be obtained from the authorization server.
Is this requirement necessary? (E.g. I believe Azure AD supports a resource
server owner providing a custom signing key, in which case the RS is not
retrieving the signing key from the AS.)
* I expected some reference to JWT validation steps from RFC 7519
* 5
* “as this would allow malicious clients to select the sub of a high
privilege resource owner”: the subject of the access token is not necessarily
the resource owner (e.g. client credentials).
* “To preventing cross-JWT confusion”: might be good to reference
section 2.8 of RFC 8725 to clarify what “cross-JWT confusion” is
* “each scope string included in the resulting JWT access token, if any,
can be unambiguously correlated to a specific resource among the ones listed in
the aud claim” specifies an unambiguous mapping, but section 2.1.1 of
RFC8693<https://tools.ietf.org/html/rfc8693#section-2.1.1> suggests a Catesian
product of resources and scopes is possible, meaning that one scope value could
(legitimately) map to multiple audience values. It’s unclear if the intent here
is to avoid the ambiguity for specifying that it must not be ambiguous, or if
there’s a slight conflict between the specs.
* Extra ‘n’ at “OpennID Connect’
* 7.1.1
* Typo at “JTW”
* Missing ‘A’ at “N/”
* 7.2
* Missing space at ‘”roles”,”groups”’
* Reference:
* No link to OpenID.Core
* All over:
* Missing double quotes around claim and parameter names (e.g. 2.2,
2.2.3), which is inconsistent with other OAuth 2.0 specs, I think.
From: OAuth <[email protected]> On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, April 15, 2020 11:59 AM
To: oauth <[email protected]>
Subject: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens"
Hi all,
This is a second 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-06
Please send your comments to the OAuth mailing list by April 29, 2020.
Regards,
Rifaat & Hannes
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
