Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

George Fletcher <gffletch@aol.com> Thu, 07 February 2019 16:47 UTC

Return-Path: <gffletch@aol.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A78E129284 for <ace@ietfa.amsl.com>; Thu, 7 Feb 2019 08:47:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.098
X-Spam-Level:
X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=aol.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 R2arB00fFOuZ for <ace@ietfa.amsl.com>; Thu, 7 Feb 2019 08:47:26 -0800 (PST)
Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (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 B8B191271FF for <ace@ietf.org>; Thu, 7 Feb 2019 08:47:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1549558044; bh=Pt/qGn07qbI8rDxfxj6SZveM6EaqafY5Edsrn8t/LeA=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=sblqlDNYmSsdQZuJ4SLIiV3CxGdwwsNxrHG8cJO+Uk2CtNhLZ62kHMqBCC4Nky/uVVxKxzVuQOFrSvPxAMP6EqwS2/w9W5OMvT0b3APDoHNbZrAhvodTc1pcaYWgD+yM1OfBQm7oTAqliw9H4gRyqpmt8qhbbuIgiEj4DseNdSZaaKF/8s0l7/UboXF8dNnYP7FSbzxAL72KOJqqhn68m4r83It0jn1ZIY8wbNxjtoDM/nm3410HTUcSmhdb3EO3AL9hYg9/GZrhUiiuyI8GWmy7p1SRkF13b4aiPFIN4kLSpa9b9c6erZE7GjVQ3fDIKSZNjP6cUhoTrZ0F1mMysw==
X-YMail-OSG: PcXimEYVM1mg.v6SSUpAlOs4weV2aMaoxC9bMKM96OiRU_2WX7Ac8rvzQx9gDq3 YFMPh6Gata06uJPowWOTgKcDiC7bz.6.PAALqkLaEQRo3Erfphq3MjLRlAv_1gYoikoAJZloNGLw N.vooiw8hJw4LBig36lA5ul6pp5FEfCIZ8r.Rvc.mbnAZdCFMdyHvuPRuKaBmUPmT8Zlsc12wfQ0 tz9YcHlqvduSgnQpE_.hFILs.3wItpcASPdDp4mVFTB55hws5LyUNgBsnpPQv04RZpGDgC9QVFBK AFp_i8SH8so3nr61m1yCp.pgLsCriSa1ScuQlg6hxX7D_3TppIhrqoWc7eo5ODoC4rehbweDJC5f x_2B6K27uz6AlTL9vOkWtq91ag34ivWCX2b6sowCrXNOd30F.YMGkLm.r2HF2jPM8_3xcvqgyzhY XTQ6UPzIkJQ0pDwNTmuXrjVkljvQBT._jLwd6hQDAEvfrLN_gZW0qyRpa2PNy97WXo9pdyDARlvV eF81ICMIS3c.NLJRhi2PWju275Gz_37gzLaMNlPu6BMoFbBhZtba3GsB_h.1CtNY7Ffif4EO5a39 IsWLZ.3MN7zGxKs9XjJVQlSg3kyu9ep.qKtkpzpP82ILJ7pU35lUIfPXMtnfk2tP5_.N7yeypA9g .YvbnVAVGy1yHbRqEwmkF7vIO.8Syc9SkGyXCDmRWSKpE5QyWyjtzFiRiF2sdS.UhJq8Ho6VbAND 1FN306ZqsJTV9HKOjt9sDiumGaxiNu1D47J_K1Ut3MoDevFfjeK3GTv0_zTBKr9jm2Ffpw3Ihki2 c9m5.jiCacU5Bm2pTn4AvEZSSuq6FdN495kA3X.IDsfwzop6uLb_9cC7VkTMKxgUEjenRThiOfnF UmcEGAfJrmzI0.gSwQLcsOF5aJtvTxpVepOSjGq_LLOa.HjCkncIfxIsH0iV_bGP2C.pc0GsoENV e_SkVqT9jgL2EhL3NJ.lPiJ.Wamr5.S0PzsffcYPpjsMmWeHvUge5d0NC2lnbJNJ1Hqo.tLp_pkv Lm3isuqcDjSeH.o4lGWcxpjgiat67ed9pbf_vYUlI4IlPPsiM6JImzWuxLkMyRodvin_O
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 7 Feb 2019 16:47:24 +0000
Received: from nat-vpn-users4.cfw-a-gci.net.buffalo.office.oath (EHLO [10.89.92.247]) ([184.165.8.99]) by smtp413.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 529dbd89a71b4f4c15f45e060ceb9676; Thu, 07 Feb 2019 16:47:20 +0000 (UTC)
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Ludwig Seitz <ludwig.seitz@ri.se>, "ace@ietf.org" <ace@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
References: <CAGL6epKeGW195z2SJdcXU-MyVBwTBDnsvGeo7mNJvn8UkAWmnw@mail.gmail.com> <199fa6bd-8103-b1b3-12a3-08b5e3aad925@aol.com> <CAGL6epKismmWSnNcca41HWHEGhaJG7XhOULUwAz9jd5AemvuOg@mail.gmail.com> <BL0PR00MB02920F6A16D28D1652F21B2DF59A0@BL0PR00MB0292.namprd00.prod.outlook.com> <CAGL6epKjUJQNZdyHjrsJYvXE_p8QvjqxhcxXVnax2_VJ3qMO6g@mail.gmail.com> <CA+k3eCT-dU96D+_LdCtZGMA2TJij2Jzc=BgzCDkbkBGf=jKWnA@mail.gmail.com> <55a0362e-e588-bce5-f65f-856a1e21e88e@aol.com> <BL0PR00MB029262B150B2D8F3C3792302F5960@BL0PR00MB0292.namprd00.prod.outlook.com> <CA+k3eCT+ndfChx1-tqsxyqg8kX5Sc=BDw6UJyu2VQU3MDs1ssQ@mail.gmail.com> <65a8e83e-c72f-bbf5-77fd-ea8540b7ddc3@aol.com> <848e0ab3-f95f-2885-d24e-69925ed7ab1c@ri.se> <a62553e1-0f04-4068-92fb-7be1fd086f80@aol.com> <VI1PR0801MB2112ABDD90AEB1208EC656CCFA680@VI1PR0801MB2112.eurprd08.prod.outlook.com> <d4081519-90dd-01a2-0df8-c78b9e29e088@aol.com> <VI1PR0801MB21122F4357775349577965E6FA680@VI1PR0801MB2112.eurprd08.prod.outlook.com>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <af339823-3aca-f6b9-1d24-067c6f15b18f@aol.com>
Date: Thu, 7 Feb 2019 11:47:19 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <VI1PR0801MB21122F4357775349577965E6FA680@VI1PR0801MB2112.eurprd08.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------14B335B4606FD30721E12CF0"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/8Cam0RUzFhLxPeaj9ml6e0MV9_Y>
Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 16:47:30 -0000

Then I think we have a bigger issue:(

To me the point of the "resource-indicators" spec is to define semantics 
around how a client can request that tokens be "constrained" in where 
they can be used. If it is not going to define the actual 'resource' 
parameter and rather use the registered value from the token-exchange 
spec, then it seems like the resource-indicators spec has the wrong 
title. Instead it should be about "constraining where a token can be 
used" and in that view should describe how to use either the 'audience' 
or 'resource' parameter. I believe we need clear guidance for when to 
use one over the other (if possible).

It is then left up to the AS to determine whether it is going to support 
just 'audience', just 'resource' or both when constraining tokens.

We should also provide some "best practice" guidance on how resource 
servers can ensure these tokens are for them. In a wide eco-system 
deployment where a resource server is supporting multiple authorization 
servers, this could get complicated for the resource server. The 
resource-indicators spec implies that the AS should use the resource 
parameter to set the 'audience' of the returned access_token. There is 
no guidance for what a AS should return from the /introspection endpoint 
in regards to the "constrained" token. Do both 'resource' and 'audience' 
values get returned in the "aud" claim?

Thanks,
George

On 2/7/19 11:26 AM, Hannes Tschofenig wrote:
>
> Hi George,
>
> The IANA registry does not indicate in what context these parameters 
> are supposed to be used. To me it feels totally normal to use the 
> audience parameter instead of the resource parameter when I have a 
> logical name.
>
> Stuffing everything into a URI is possible but in certain scenarios 
> may feel quite unnatural. It must have felt unnatural already to the 
> group when working on the token exchange spec…
>
> Ciao
>
> Hannes
>
> *From:*George Fletcher <gffletch@aol.com>
> *Sent:* Donnerstag, 7. Februar 2019 17:06
> *To:* Hannes Tschofenig <Hannes.Tschofenig@arm.com>om>; Ludwig Seitz 
> <ludwig.seitz@ri.se>se>; ace@ietf.org; oauth@ietf.org
> *Subject:* Re: [Ace] [OAUTH-WG] Shepherd write-up for 
> draft-ietf-oauth-resource-indicators-01
>
> This is true... however, to my knowledge there is no support for this 
> parameter outside of the token-exchange spec. Just because it is 
> documented as an OAuth parameter I don't consider it usable in other 
> contexts unless spec'd to do so. If we want to use 'audience' for 
> logical audience names when binding audiences to tokens, then we need 
> a spec for that (or add it to the resource-indicators spec).
>
> Personally, I see a lot of overlap even between the 'audience' and 
> 'resource' parameters. I'd really prefer we just have one parameter 
> that can be either logical or specific. As outlined in this thread, 
> 'https://api.exampl.com' to me is a logical representation of the 
> resource if the "real" endpoint(s) are 
> "https://api.example.com/mail/user/inbox" 
> <https://api.example.com/mail/user/inbox>, ...
>
> Thanks,
> George
>
> On 2/7/19 10:16 AM, Hannes Tschofenig wrote:
>
>     Hi George,
>
>       * I believe that since the latest draft of the resource
>         indicators spec [1] allows for abstract identifiers, and since
>         a URN is also a URI, you could easily use a URN syntax to
>         accomplish the use case outlined in your email.
>
>
>     After re-reading the token exchange draft I realized that we have
>     already defined a separate parameter for “abstract”, or logical,
>     names via the audience parameter. Here is the definition:
>
>        audience
>
>           OPTIONAL.  The logical name of the target service where the
>     client
>
>           intends to use the requested security token.  This serves a
>
>           purpose similar to the "resource" parameter, but with the client
>
>           providing a logical name rather than a location.  Interpretation
>
>           of the name requires that the value be something that both the
>
>           client and the authorization server understand.  An OAuth client
>
>           identifier, a SAML entity identifier [OASIS.saml-core-2.0-os
>     <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16#ref-OASIS.saml-core-2.0-os>],
>     an
>
>           OpenID Connect Issuer Identifier [OpenID.Core
>     <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16#ref-OpenID.Core>],
>     or a URI are
>
>           examples of things that might be used as "audience" parameter
>
>           values.  Multiple "audience" parameters may be used to indicate
>
>           that the issued token is intended to be used at the multiple
>
>           audiences listed.  The "audience" and "resource" parameters
>     may be
>
>           used together to indicate multiple target services with a mix of
>
>           logical names and locations.
>
>     Ciao
>
>     Hannes
>
>     *From:*Ace <ace-bounces@ietf.org> <mailto:ace-bounces@ietf.org>
>     *On Behalf Of * George Fletcher
>     *Sent:* Dienstag, 29. Januar 2019 14:15
>     *To:* Ludwig Seitz <ludwig.seitz@ri.se>
>     <mailto:ludwig.seitz@ri.se>; ace@ietf.org <mailto:ace@ietf.org>;
>     oauth@ietf.org <mailto:oauth@ietf.org>
>     *Subject:* Re: [Ace] [OAUTH-WG] Shepherd write-up for
>     draft-ietf-oauth-resource-indicators-01
>
>     Thank you so much for the background!
>
>     I believe that since the latest draft of the resource indicators
>     spec [1] allows for abstract identifiers, and since a URN is also
>     a URI, you could easily use a URN syntax to accomplish the use
>     case outlined in your email.
>
>     resource=urn:x-mydevices:temperatureSensorGroup4711
>
>     The spec currently outlines examples where the "resource
>     identifier" is not a "single resource" in the context of a fully
>     qualified API endpoint.
>
>         Another example, for an API like SCIM [RFC7644  <https://tools.ietf.org/html/rfc7644>] that has
>
>             multiple endpoints such as"https://apps.example.com/scim/Users"  <https://apps.example.com/scim/Users>,
>
>             "https://apps.example.com/scim/Groups"  <https://apps.example.com/scim/Groups>, and
>
>             "https://apps.example.com/scim/Schemas"  <https://apps.example.com/scim/Schemas>  The client would use
>
>             "https://apps.example.com/scim/"  <https://apps.example.com/scim/>  as the resource so that the issued
>
>             access token is valid for all the endpoints of the SCIM API.
>
>     Using "https://apps.example.com/scim"
>     <https://apps.example.com/scim> is semantically equivalent to
>     using "temperatureSensorGroup4711", at least to me:)
>
>     Thanks,
>     George
>
>     [1]
>     https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02
>
>     On 1/29/19 2:56 AM, Ludwig Seitz wrote:
>
>         On 28/01/2019 23:12, George Fletcher wrote:
>
>
>             I also don't know that this raises to the level of
>             "concern" but I find the parameter name of "req_aud" odd.
>             Given that the parameter in the resource-indicators spec
>             is 'resource' why not use a parameter name of 'audience'.
>             That said, I have not read the thread on the ACE working
>             group list so there could be very good reasons for the
>             chosen name:)
>
>             I do think that there is a lot of overlap (in most cases)
>             between 'resource' and 'audience' and having two
>             parameters that cover a lot of the same semantics is going
>             to be confusing for developers. When calling an API at a
>             resource server, the 'audience' and the 'resource' are
>             pretty equivalent. Maybe in other use cases they are
>             distinctly separate?
>
>
>         To give you all the background of "req_aud" from ACE (sorry
>         for the long text):
>
>         Originally in ACE we had defined the "aud" parameter for
>         requests to the token endpoint with the semantics that the
>         client was requesting a token for a certain audience (i.e.
>         requesting that the AS copy the "aud" parameter value into the
>         "aud" claim value of the token).
>         We were then told that this collided with a use of "aud" in
>         OAuth, that specifies the intended audience of Authorization
>         Servers (if I remember correctly), so we decided to rename our
>         parameter to "req_aud" for "requested audience".
>         Mike Jones then made us aware of the work on resource
>         indicators, but upon closer examination I found the "resource"
>         parameter to be more limited than the "req_aud", since
>         resource specifically states:
>
>         "Its value MUST be an absolute URI ... the "resource"
>         parameter URI value is an identifier representing the identity
>         of the resource"
>
>         My interpretation of this is that "resource" refers to a
>         single resource, which is more constrained than the definition
>         of the "aud" claim from 7519, which uses a StringOrURI value. 
>         For example my intent was to use "aud" and "req_aud" for group
>         identifiers ("temperatureSensorGroup4711") and other non-uri
>         strings (hash-of-public-key), which I cannot do with
>         "resource". We therefore decided to keep the "req_aud"
>         parameter in draft-ietf-ace-oauth-params, even though is
>         clearly overlaps with "resource".
>
>         Any comments and suggestions about that line of reasoning
>         (especially from the OAuth point of view) are very welcome.
>
>         /Ludwig
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose 
> the contents to any other person, use it for any purpose, or store or 
> copy the information in any medium. Thank you.