Thanks Mike! Those are great comments. Inline- also, who should I put in the acknowledgements for this contribution? Or does the commenter wish to remain anonymous?
>spaces, typos, abbreviations etc Fixed, thx! > 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. The language follows fairly closely https://tools.ietf.org/html/rfc8417#section-2.3. I think the twist here is that the MUST refers to the need to use that media type rather than that particular format. > Does this mean these claims should only be used when the subject is a user? > If so, then it might be good to clarify. Good catch! I added language clarifying that those claims may be used in the context of grants involving the resource owner. I didn’t add language explicitly disallowing using acr/amr/auth_time in case of client only grants.. Open to feedback on whether that’s necessary. > 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?) Similarly to the above, I think it’s worth clarifying that the section refers to grants where the resource owner is involved. I am adding language to that effect. For the delegation cascade scenario, I’d prefer to avoid the complication and stick with attributes of the authenticated subject. > Link to section 4.1.2 of SCIM Core is actually linking to section 4.1.2 of > this doc. Oh wow. That’s a feature of XML2RFC,… my source simply says by section 4.1.2 of SCIM Core in a <t> block, and the processor interpret it as an internal link. I’ll need to dig on how to prevent that from happening for this instance. Good catch! >, “groups” does have a syntax defined in SCIM Hmm. What I really meant there is that there’s no enumeration with fixed values, rather than a schema- but I can see how that might be confusing. Also, I am not crazy about forcing people to build a composite structure when a simple string might suffice. I’ll cull “As in their original definition in [RFC7643]”. > 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? Well, maybe. It’s true that an AS implementing RFC8414 must serve its metadata on a URL containing the issuer, but that’s not necessarily the method a client in real scenarios will use to resolve that URL- think metadata document cached locally from earlier runs, a private URL mapper or any other proprietary discovery mechanism. I am not advocating that clients should use any other method than direct retrieval from the well known URL, but given that the issuer info is available in both the URL and the metadata, I see no harm in recommending that the value ins extracted from the metadata if that results in a more generally applicable approach. > The value “application/at+jwt” should also be accepted. >From the way it’s currently phrased, both values should indeed be mentioned. >Fixing that > if the “typ” value is not “at+jwt”, it should rejected for this profile. (But > maybe that’s already understood?) I think it’s fair to assume that everything unless otherwise specified is for this profile > 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. See earlier comment, I don’t think instantiating the issuer in the well known URL will be an operation performed by every client directly- and even if it would be, the issuer value is there anyway hence it remains actionable. > Use of singular suggests there is only one possible “aud” value that a > resource server would accept. Fair. Until recently, that was the case! Adjusted the language to still use the singular, but switched to indefinite articles to express the possibility of different values. > 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 see the technical possibility of that scenario happening, but I am reluctant to complicate the language and/or open up the possibility for errors here. I think the scenario you describe could be characterized as out of band setup, more about how the key is generated in the first place- but afterwards, the key should end up in the AS metadata anyway regardless of how it has been generated. Doing otherwise might make it more likely that people will end up with implementations that don’t work well with key rotation, or rely on out of band checks for key validity considerations. > I expected some reference to JWT validation steps from RFC 7519 Are you thinking about anything in particular? >“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). True, but the existence of scenarios where this risk doesn’t materialize doesn’t make it any less of an issue in the cases where it does. Not sure if clarifying that client only cases aren’t affected would add much here.. >“To preventing cross-JWT confusion”: might be good to reference section 2.8 of >RFC 8725 to clarify what “cross-JWT confusion” is Added! > slight conflict between the specs. I think it’s OK for a profile to be more restrictive. The language might be flipped to adopt the RS perspective and describe a more generic setup where shared scopes are possible, but I worry about making the description of the problem class less crisp. I avoided uppercase RFC keywords there, if there’s language that makes it even less normative without eroding its clarity, I am all ears. > Missing double quotes around claim and parameter names (e.g. 2.2, 2.2.3), Sigh, you’re right. I was planning to add those eventually, I guess the time has come. From: Mike Jones <michael.jo...@microsoft.com> Date: Tuesday, April 21, 2020 at 11:07 To: oauth <oauth@ietf.org>, Vittorio Bertocci <vitto...@auth0.com> Cc: Rifaat Shekh-Yusef <rifaat.i...@gmail.com> Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" 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 <oauth-boun...@ietf.org> On Behalf Of Rifaat Shekh-Yusef Sent: Wednesday, April 15, 2020 11:59 AM To: oauth <oauth@ietf.org> 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
