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

From: Mike Jones <[email-masked]>
Date: Tue, 21 Apr 2020 18:07:37 +0000

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-masked]> On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, April 15, 2020 11:59 AM
To: oauth <[email-masked]>
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

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 22 Apr 2020 07:26:40 +0000

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 <[email-masked]>
Date: Tuesday, April 21, 2020 at 11:07
To: oauth <[email-masked]>, Vittorio Bertocci <[email-masked]>
Cc: Rifaat Shekh-Yusef <[email-masked]>
Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

  *   1

  *   2.1

  *   2.2.1

  *   2.2.2

  *   2.2.3.1

  *   3

  *   4

  *   5

  *   7.1.1

     *   Typo at “JTW”
     *   Missing ‘A’ at “N/”

  *   7.2

  *   Reference:

     *   No link to OpenID.Core

  *   All over:

Hi all,

Here is the document:

Regards,
 Rifaat & Hannes

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 24 Apr 2020 19:02:27 -0700

Just on the xml2rfc bits...

> 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 tha…

The short form is "you can't".

You're using the "v2" XML format for xml2rfc, which produces as various
output formats text, pdf, and "htmlized" output.  The "htmlized" output is
called that and not "html" because it's the result of taking the text
output and running a script to turn common constructions in I-Ds and RFCs
into hopefully-useful HTML formatting.  In this case, "Section N" outside
of "Section N of [bracketed-reference]" is assumed to be "Section N of the
current document", and that's all that the htmlization script is going to
give you, since it's not working with the semantic richness of the XML
source.

We do, however, as of fairly recently have a "v3" XML format, which is
capable of producing native HTML output that includes SVG figures and the
other exciting features of "v3 XML".  For an example, see
https://www.ietf.org/id/draft-ietf-tsvwg-datagram-plpmtud-19.html .

I personally haven't done any v2-to-v3 conversions yet (too busy reading to
have time to do much writing), but the FAQ entry for doing so is at
https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-how-do-i-convert-my-xml-fil
.

Hope that helps,

Ben

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 27 Apr 2020 08:34:03 +0000

Thank you for bringing this up Benjamin, you saved me from a long wild goose chase!
It' good to know that there's a new rfc format version, but I am a bit worried about venturing there given that I am barely managing the v2 as it is __ v3 still feels pretty experimental, and other than this issue, this spec doesn't give a lot of opportunities to take advantage of the new features (SVG etc).  
Wondering whether I can find a periphrase to express the same notion without triggering the script, e.g. omitting the word section or changing the order.
Thx
V.

On 4/24/20, 19:02, "Benjamin Kaduk" <[email-masked]> wrote:

    

    
    
    Hope that helps,
    
    Ben

---

From: Brian Campbell <[email-masked]>
Date: Mon, 27 Apr 2020 07:25:31 -0600

This old thread
https://mailarchive.ietf.org/arch/msg/oauth/1ajE-d3nVOFRGLbwMmPViDhEdqw/
has some discussion of working with/around that particular quirk of the
htmlizing tool.

On Mon, Apr 27, 2020 at 2:34 AM Vittorio Bertocci <vittorio.bertocci=
[email-masked]> wrote:

> It' good to know that there's a new rfc format version, but I am a bit
> worried about venturing there given that I am barely managing the v2 as it
> is __ v3 still feels pretty experimental, and other than this issue, this
> spec doesn't give a lot of opportunities to take advantage of the new
> features (SVG etc).
> Wondering whether I can find a periphrase to express the same notion
> without triggering the script, e.g. omitting the word section or changing
> the order.
> Thx
> V.
>
>     > 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!
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 27 Apr 2020 17:48:16 +0000

Thanks Brian, that appears to have worked!

From: OAuth <[email-masked]> on behalf of Brian Campbell <bcampbell=[email-masked]>
Date: Monday, April 27, 2020 at 06:26
To: Vittorio Bertocci <vittorio.bertocci=[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

This old thread https://mailarchive.ietf.org/arch/msg/oauth/1ajE-d3nVOFRGLbwMmPViDhEdqw/ has some discussion of working with/around that particular quirk of the htmlizing tool.

On Mon, Apr 27, 2020 at 2:34 AM Vittorio Bertocci <vittorio.bertocci=[email-masked]<mailto:[email-masked]>> wrote:
Thank you for bringing this up Benjamin, you saved me from a long wild goose chase!
It' good to know that there's a new rfc format version, but I am a bit worried about venturing there given that I am barely managing the v2 as it is __ v3 still feels pretty experimental, and other than this issue, this spec doesn't give a lot of opportunities to take advantage of the new features (SVG etc).
Wondering whether I can find a periphrase to express the same notion without triggering the script, e.g. omitting the word section or changing the order.
Thx
V.

On 4/24/20, 19:02, "Benjamin Kaduk" <[email-masked]<mailto:[email-masked]>> wrote:

    I personally haven't done any v2-to-v3 conversions yet (too busy reading to
    have time to do much writing), but the FAQ entry for doing so is at
    https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-how-do-i-convert-my-xml-fil<https://www.rfc-editor.org/materials/FAQ-xml2rfcv3..html#name-how-do-i-convert-my-xml-fil>
    .

    Hope that helps,

    Ben

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.