From nobody Mon Sep 21 19:09:38 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14F43A10DF for ; Mon, 21 Sep 2020 19:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyVclGNvNNRC for ; Mon, 21 Sep 2020 19:09:36 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C26A3A10DE for ; Mon, 21 Sep 2020 19:09:36 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id y8so15464970ilm.11 for ; Mon, 21 Sep 2020 19:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HjEBjXU7NKgVGkykeHCGfwWlvACEYPoNI9HTxrmgQCE=; b=LVjfxcX0g96Q3xdCaR4cJVqAb76ZfIV88HL/jfSdsJbW+tIGTHJtkdrkmabS5eWAFK bEzRwRAdg+qZ0xh2Hlzu+rw3I1oXxUFZDCWKojY7Z2yWPp1LB/zx3edpCVomCzNPlQ+z wmlcXJwfz/A3TV0K3A/3QHnOjtWHhfaC1Jk9h4FbESgMt8ekXaLMWR2UhgknmWXfwHGQ XLVKhqTzKO79HW0TrZukUcUmcAYlbD3mfYxXTAlGsKEGJjkIm3MRyels9LHAhlwWX0t3 2z/Cr8L9Ldw6TVYb+roRab9KbxL5r3kpNuv4ZZWPJsq80+L41B0fuLqqJunbpyDNg64w ljDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HjEBjXU7NKgVGkykeHCGfwWlvACEYPoNI9HTxrmgQCE=; b=YpH3oto3zKL0fylwmDVzKxDhQ8xdmg6czAwOsvoKoC6JRyAZWRfnWv5V82063BpCs/ pohlfdJm6na/8WMXQa7OBfvQ1gQ6yec63heVCX4elLSxg0Q/ilvch04YhSdemeCwwW46 cYZI0kvh1mEB79+NP0XzHUo3Fc44UroEbuUNHuz7lwnjFQBhthzL2DSSS+nogj+qdweI CYZesu2O2Ua7NisRiLJ7Lz62oMmJh9cFwnsrE2H2VoLAB04fbUoW8vvBmUw5o3zzF9OF H6B6v9urVR9w/qoWUDPphfU3xmYPTF5Swzw1VbcF1wLcWJqItqhrk661GUhXBYnpuMx2 YYPA== X-Gm-Message-State: AOAM530xBgbt4IXSZ6NbIHIxvxqVr7zUHAPk98XpCP2yL5Ih3D7zUl/N qYig/+aBy6/BlXx1jms/ew7fn5YmclR++DUPPY0= X-Google-Smtp-Source: ABdhPJzTDdaEo5wJVU10AUItDzJfnqcFzIlcy9ZkYDvGSz/s9wX8VtOq2CFwrOaMLmXAT5yAtKh5f0NtcmvQPC129eo= X-Received: by 2002:a92:d0c7:: with SMTP id y7mr2538324ila.250.1600740575119; Mon, 21 Sep 2020 19:09:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Logan Widick Date: Mon, 21 Sep 2020 22:09:23 -0400 Message-ID: To: Brian Campbell Cc: Vittorio Bertocci , oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000005b941105afdd75aa" Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 02:09:38 -0000 --0000000000005b941105afdd75aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If I understand "The intent would be to present that information in the same way you would when querying a users/, 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 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 consid= er > is "whether the registration description is clear" and Logan's questions > suggest that perhaps the descriptions of these claims are not sufficientl= y > 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 t= he > 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 40auth0.com@dmarc.ietf.org> wrote: > >> Hi Logan, >> >> Thanks for the note. >> >> The intent would be to present that information in the same way you woul= d >> when querying a users/, encoded in claims; hence groups would be a l= ist >> 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=E2=80=99t want to dupl= icate >> 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 on behalf of Logan Widick < >> logan.widick@gmail.com> >> *Date: *Wednesday, September 16, 2020 at 14:21 >> *To: *"oauth@ietf.org" >> *Subject: *[OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question >> >> >> >> 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 (page= s >> 63-64 of RFC 7643), an array of SCIM Group schema objects (pages 69-70 o= f >> 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 Use= r >> schema (pages 65-66 of RFC 7643), or something else? >> >> Sincerely, >> >> Logan Widick >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> 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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* --0000000000005b941105afdd75aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I understand "The intent would be to present that information in the same way yo= u would when querying a users/<id>, encoded in claims"=C2=A0correctly, the "roles", "groups", and "entitlem= ents" 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 sch= ema)? In the schema the attributes are all "complex" (object) typ= e and "multivalued" (array of), although the text for some of the= se attributes has some "No vocabulary or syntax..." remarks.

If that understanding is cor= rect, it might be a good idea to replace the references to "RFC 7643&q= uot;, "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 <bcampbell@pingidentity.com> wrot= e:
At some po= int 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 questio= ns suggest that perhaps the descriptions of these claims are not sufficient= ly clear. My assumption was that the claim value for "roles", &qu= ot;groups" and "entitlements" was going to be an array of st= rings. Trying to validate my assumption, I went looking at the text in https://tools.ietf.org/h= tml/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 t= o 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 764= 3. But I think that, for the sake of clarity and interoperability, some add= itional specificity is needed.=C2=A0

Side not= e: 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.=C2=A0

On Fri, Sep 18, 2020 at 6:28 PM Vittorio Bertocci <= vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

Hi Logan,

Thanks for the note.

The intent would be to present that information in t= he same way you would when querying a users/<id>, encoded in claims; = hence groups would be a list of values representing =C2=A0what groups the s= ubject belongs to, rather than a list of full group definitions (with all the other members belonging to them, for examp= le) which would go beyond the intended use of the information (supplying au= thorization information about the subject).

I tried to keep the language high level as I didn=E2= =80=99t want to duplicate SCIM guidance, or inadvertently narrow down the o= ptions products have to implement this.=C2=A0 If you think this is too vagu= e, we can try to be more specific.

=C2=A0

From: = OAuth <oauth-b= ounces@ietf.org> on behalf of Logan Widick <logan.widick@gmai= l.com>
Date: Wednesday, September 16, 2020 at 14:21
To: "oauth@ietf.org" <oauth@ietf.org>
Subject: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question=

=C2=A0

I took a look at Section 2.2.3.1: Claims for Authorization Outside of Delegatio= n 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 s= chema (pages 66-67 of RFC 7643), or something else?

Will the "groups" claim be an array of strings (group names, I= Ds, or links), an array of the "groups" objects from the SCIM Use= r 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 (entitlem= ent 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

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.
--0000000000005b941105afdd75aa--