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

Vittorio Bertocci <> Sat, 19 September 2020 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 674C53A11BC for <>; Fri, 18 Sep 2020 17:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.855
X-Spam-Status: No, score=-0.855 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, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S5CbRGcNvAyo for <>; Fri, 18 Sep 2020 17:27:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D08D3A1075 for <>; Fri, 18 Sep 2020 17:27:05 -0700 (PDT)
Received: by with SMTP id gf14so3842356pjb.5 for <>; Fri, 18 Sep 2020 17:27:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=AhVl0KqT0C3yrIFAjiJJTa9Eix2R1YHlBdiJPlGzV1M=; b=gbrQ+oKOVDuDTBfLaD9tGIwk4zbHZsiUjhlZdabBwyA1mVlMkMuh/GRSFx1Am8LKwd bWT1cz6JD4rJTrcwrWv7X/xCot6CTg8Bu+BKs/k+pBEs3jWbNSTei3ShLS1o3iILUPgT su2lXs5DtDC/ZSzzypgd97/9eioRtvZf0LMtHUSCZ8xV/L4jEYq6Mz4Lz7bWWtyqyShW 4ZIOVf5vs5KGtVx6n6gyUib7gjayowpXEQg7R6m4u22PWJuX7GHB9/dUM27rPuLZ3PYW hCfFAW5Ix+Wkdy0AcqTXxJ3VM2kloymUsldTvFuWw0jQ23p7MY+O9t53gcYKyGzX9RpD g+ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=AhVl0KqT0C3yrIFAjiJJTa9Eix2R1YHlBdiJPlGzV1M=; b=F1tTTsDYKyfgcNVCBtILeG0vJUi0DIO8Iw4qq1E0OS4CVSIqEKcuSmwWue3Ke/NJf3 O7G2sPFoqLdSaWLGs+5GaWZG/3b2YBxTGPEeSBcx4uoQoMvX/HHN1/kFBaEQxCCQ6Zab mFYfoBlaCw+SD5nconYRhOtfmowL/1L4epD0hW+jsPEWJPygb4rSuA/XPDCNzZ7rZ9W1 lJOiTdBECv1mfA8DYgG6KXNcxC7JyWQyFwmI8gCVlCJb7OBaQ+CmlTbDZPe3kPsZMPhb 6VdJzaYGWeg+s8eoXW1pp2RMsrT/sZREqpYKiaWnJK+8GmpqvfQljOUEqpWQ3VUjfWtq NnOQ==
X-Gm-Message-State: AOAM5338QppqVb8ezT+srSWgDFFm0CZlXtG4dzXIN3aw/WFOsMBzS1v7 ufGJNM1infHS2D1p+i2ZtVHMgA==
X-Google-Smtp-Source: ABdhPJwSSJvmBtAKSmidCVh/Vjk3cElSz2TcXLacR+tGDYOG5FkODBIHFpSnN//D+gFiIaHOlS5u6Q==
X-Received: by 2002:a17:902:7896:b029:d0:89f1:9e33 with SMTP id q22-20020a1709027896b02900d089f19e33mr35666232pll.15.1600475224477; Fri, 18 Sep 2020 17:27:04 -0700 (PDT)
Received: from ([2603:1036:120:1d::5]) by with ESMTPSA id j144sm4718585pfd.106.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2020 17:27:04 -0700 (PDT)
From: Vittorio Bertocci <>
To: Logan Widick <>, "" <>
Thread-Topic: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question
Thread-Index: AWdVOGRZfCffrbDQDUZf8aHBptBej95xxmVl
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Sat, 19 Sep 2020 00:27:00 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_MWHPR19MB150101C01962881B13665C21AE3C0MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question
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: Sat, 19 Sep 2020 00:27:26 -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 <> on behalf of Logan Widick <>
Date: Wednesday, September 16, 2020 at 14:21
To: "" <>
Subject: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-08 question

I took a look at Section<>: Claims for Authorization Outside of Delegation Scenarios ( 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?


Logan Widick