Subject: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question

From: Logan Widick <[email-masked]>
Date: Wed, 16 Sep 2020 17:21:27 -0400

I took a look at Section 2.2.3.1: Claims for Authorization Outside of
Delegation Scenarios (
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-08#section-2.2.3.1)
and I do not understand what exactly the formats of the "roles", "groups",
and "entitlements" claims will be.

Will the "roles" claim be an array of strings (role names, IDs, or links),
an array of the "roles" objects from the SCIM User schema (pages 66-67 of
RFC 7643), or something else?

Will the "groups" claim be an array of strings (group names, IDs, or
links), an array of the "groups" objects from the SCIM User schema (pages
63-64 of RFC 7643), an array of SCIM Group schema objects (pages 69-70 of
RFC 7643), or something else?

Will the "entitlements" claim be an array of strings (entitlement names,
IDs, or links), an array of the "entitlements" objects from the SCIM User
schema (pages 65-66 of RFC 7643), or something else?

Sincerely,

Logan Widick

---

From: Vittorio Bertocci <[email-masked]>
Date: Sat, 19 Sep 2020 00:27:00 +0000

Hi Logan,
Thanks for the note.
The intent would be to present that information in the same way you would when querying a users/<id>, encoded in claims; hence groups would be a list of values representing  what groups the subject belongs to, rather than a list of full group definitions (with all the other members belonging to them, for example) which would go beyond the intended use of the information (supplying authorization information about the subject).
I tried to keep the language high level as I didn’t want to duplicate SCIM guidance, or inadvertently narrow down the options products have to implement this.  If you think this is too vague, we can try to be more specific.

From: OAuth <[email-masked]> on behalf of Logan Widick <[email-masked]>
Date: Wednesday, September 16, 2020 at 14:21
To: "[email-masked]" <[email-masked]>
Subject: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question

I took a look at Section 2.2.3.1<http://2.2.3.1>: Claims for Authorization Outside of Delegation Scenarios (https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-08#section-2.2.3.1) and I do not understand what exactly the formats of the "roles", "groups", and "entitlements" claims will be.

Will the "roles" claim be an array of strings (role names, IDs, or links), an array of the "roles" objects from the SCIM User schema (pages 66-67 of RFC 7643), or something else?

Will the "groups" claim be an array of strings (group names, IDs, or links), an array of the "groups" objects from the SCIM User schema (pages 63-64 of RFC 7643), an array of SCIM Group schema objects (pages 69-70 of RFC 7643), or something else?

Will the "entitlements" claim be an array of strings (entitlement names, IDs, or links), an array of the "entitlements" objects from the SCIM User schema (pages 65-66 of RFC 7643), or something else?

Sincerely,

Logan Widick

---

From: Brian Campbell <[email-masked]>
Date: Mon, 21 Sep 2020 13:33:00 -0600

At some point I'm going to be among the lucky few who will be asked to
review the JWT claims registration request. One of the criteria to consider
is "whether the registration description is clear" and Logan's questions
suggest that perhaps the descriptions of these claims are not sufficiently
clear. My assumption was that the claim value for "roles", "groups" and
"entitlements" was going to be an array of strings. Trying to validate my
assumption, I went looking at the text in
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-2.2.3.1
and
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-7.2
and followed the reference to
https://tools.ietf.org/html/rfc7643#section-4.1.2 and, honestly, it wasn't
particularly clear to me. Maybe it's my lack of familiarity with the
details of SCIM and the language of RFC 7643. But I think that, for the
sake of clarity and interoperability, some additional specificity is
needed.

Side note: the "Section 2.2.2.1 of [[this specification]]" references in
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-7.2.1
are problmatic (there is no such section in this document) and probably
should be to 2.2.3.1.

On Fri, Sep 18, 2020 at 6:28 PM Vittorio Bertocci <vittorio.bertocci=
[email-masked]> wrote:

> Hi Logan,
>
> Thanks for the note.
>
> The intent would be to present that information in the same way you would
> when querying a users/<id>, encoded in claims; hence groups would be a list
> of values representing  what groups the subject belongs to, rather than a
> list of full group definitions (with all the other members belonging to
> them, for example) which would go beyond the intended use of the
> information (supplying authorization information about the subject).
>
> I tried to keep the language high level as I didn’t want to duplicate SCIM
> guidance, or inadvertently narrow down the options products have to
> implement this.  If you think this is too vague, we can try to be more
> specific.
>
>
>
> *From: *OAuth <[email-masked]> on behalf of Logan Widick <
> [email-masked]>
> *Date: *Wednesday, September 16, 2020 at 14:21
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question
>
>
>
> _______________________________________________
> 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: Logan Widick <[email-masked]>
Date: Mon, 21 Sep 2020 22:09:23 -0400

If I understand "The intent would be to present that information in the
same way you would when querying a users/<id>, encoded in claims" correctly,
the "roles", "groups", and "entitlements" claims are the same types as the
"roles", "groups", and "entitlements" attributes of the User resource
schema (pages 24-25 of RFC 7643 for the text; pages 63-67 of RFC 7643 for
the schema)? In the schema the attributes are all "complex" (object) type
and "multivalued" (array of), although the text for some of these
attributes has some "No vocabulary or syntax..." remarks.

If that understanding is correct, it might be a good idea to replace the
references to "RFC 7643", "Section 4.1.2 of RFC 7643", and "RFC 7643,
Section 4.1.2" with something more specific like "the ____ attribute(s) of
the User resource schema from Section 4.1.2 of RFC 7643".

On Mon, Sep 21, 2020, 15:33 Brian Campbell <[email-masked]>
wrote:

> https://tools.ietf.org/html/rfc7643#section-4.1.2 and, honestly, it
> wasn't particularly clear to me. Maybe it's my lack of familiarity with the
>> I tried to keep the language high level as I didn’t want to duplicate
>> SCIM guidance, or inadvertently narrow down the options products have to
>> Will the "roles" claim be an array of strings (role names, IDs, or
>> links), an array of the "roles" objects from the SCIM User schema (pages
>> 66-67 of RFC 7643), or something else?
>>
> *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: Deepak Tiwari <[email-masked]>
Date: Tue, 22 Sep 2020 11:59:55 +0530

Please remove my email from the conversation

On Tue, Sep 22, 2020 at 7:39 AM Logan Widick <[email-masked]> wrote:

>>> The intent would be to present that information in the same way you
>>> would when querying a users/<id>, encoded in claims; hence groups would be
>>> a list of values representing  what groups the subject belongs to, rather
>>> than a list of full group definitions (with all the other members belonging
>>> to them, for example) which would go beyond the intended use of the

-- 

Regards,

*Deepak Tiwari|* Software Engineer
Intigate Technologies Pvt. Ltd. | www.intigate.co.in
Ist Floor, A-119
Sector-63
Noida (U.P.) 201301

---

From: Guilherme Kun <[email-masked]>
Date: Tue, 22 Sep 2020 09:22:18 -0300

Em ter., 22 de set. de 2020 às 03:25, Deepak Tiwari <
[email-masked]> escreveu:

>>>> Will the "entitlements" claim be an array of strings (entitlement
>>>> names, IDs, or links), an array of the "entitlements" objects from the SCIM
>>>> User schema (pages 65-66 of RFC 7643), or something else?
>>>>
>>>> Sincerely,
>>>>
>>>> Logan Widick

-- 
Att.
Guilherme Ap. Sona Kun - Desenvolvimento

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 23 Sep 2020 07:27:44 +0000

Thanks Brian, Logan.
On clarity. I tweaked that section and produced a new draft (-10).
Details:

  *   Formally, the fact that we are referring to the User entity should be unambiguous. 4.1.2 is a subsection of 4.1, which is titled "User Resource Schema”.
However as a frequent critic of the excessive cyclomatic complexity of the specs, I am making myself guilty of precisely the same sin 😊 your suggestion can save the reader the need to follow and parse the reference to understand the situation, hence it’s a good improvement to clarity.
  *   For what concerns the actual format of the claims. The groups entity actually appears as non-normative example in https://tools.ietf.org/html/rfc7643#section-8.2; I can make an explicit reference to that and make things a bit more discoverable.
  *   For roles and entitlements, things are murkier.
Before embarking in this endeavor I too had the expectation that this would be a flat list of strings, but digging a bit in existing implementations it turns out that’s not necessarily the case. For example, Slack SCIM represents individual roles as two possible forms { “value”:<name>, “primary”; <bool>}|  { “value”:<name>}, whereas databricks uses { “value”:<name>}; WSO2 uses { “value”:<name>, “type”; <enum>}.
So for those two I don’t think we can do better than the current statement about SCIM not supplying a vocabulary for them.
  *   I had some issues w the references where the section links were turned into local links, as it happened in the past. That should be fixed too.
  *   I applied the “” notation to the attributes, given that we are turning them into claims it seems clearer to sue the same typographic concention.

  *   side note… <nonexistent section reference>
Excellent point, fixed.

From: Logan Widick <[email-masked]>
Date: Monday, September 21, 2020 at 19:09
To: Brian Campbell <[email-masked]>
Cc: Vittorio Bertocci <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question

If I understand "The intent would be to present that information in the same way you would when querying a users/<id>, encoded in claims" correctly, the "roles", "groups", and "entitlements" claims are the same types as the "roles", "groups", and "entitlements" attributes of the User resource schema (pages 24-25 of RFC 7643 for the text; pages 63-67 of RFC 7643 for the schema)? In the schema the attributes are all "complex" (object) type and "multivalued" (array of), although the text for some of these attributes has some "No vocabulary or syntax..." remarks.

If that understanding is correct, it might be a good idea to replace the references to "RFC 7643", "Section 4.1.2 of RFC 7643", and "RFC 7643, Section 4.1.2" with something more specific like "the ____ attribute(s) of the User resource schema from Section 4.1.2 of RFC 7643".

On Mon, Sep 21, 2020, 15:33 Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
At some point I'm going to be among the lucky few who will be asked to review the JWT claims registration request. One of the criteria to consider is "whether the registration description is clear" and Logan's questions suggest that perhaps the descriptions of these claims are not sufficiently clear. My assumption was that the claim value for "roles", "groups" and "entitlements" was going to be an array of strings. Trying to validate my assumption, I went looking at the text in https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-2.2.3.1 and https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-7.2 and followed the reference to https://tools.ietf.org/html/rfc7643#section-4.1.2 and, honestly, it wasn't particularly clear to me. Maybe it's my lack of familiarity with the details of SCIM and the language of RFC 7643. But I think that, for the sake of clarity and interoperability, some additional specificity is needed.

Side note: the "Section 2.2.2.1 of [[this specification]]" references in https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-09#section-7.2.1 are problmatic (there is no such section in this document) and probably should be to 2.2.3.1.

On Fri, Sep 18, 2020 at 6:28 PM Vittorio Bertocci <vittorio.bertocci=[email-masked]<mailto:[email-masked]>> wrote:
Hi Logan,
Thanks for the note.
The intent would be to present that information in the same way you would when querying a users/<id>, encoded in claims; hence groups would be a list of values representing  what groups the subject belongs to, rather than a list of full group definitions (with all the other members belonging to them, for example) which would go beyond the intended use of the information (supplying authorization information about the subject).
I tried to keep the language high level as I didn’t want to duplicate SCIM guidance, or inadvertently narrow down the options products have to implement this.  If you think this is too vague, we can try to be more specific.

From: OAuth <[email-masked]<mailto:[email-masked]>> on behalf of Logan Widick <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 16, 2020 at 14:21
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question

Sincerely,

Logan Widick
_______________________________________________
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.