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

George Fletcher <gffletch@aol.com> Thu, 07 February 2019 16:05 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 29546130F53 for <ace@ietfa.amsl.com>; Thu, 7 Feb 2019 08:05:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 lrWkPdVrSF-T for <ace@ietfa.amsl.com>; Thu, 7 Feb 2019 08:05:45 -0800 (PST)
Received: from sonic306-3.consmr.mail.bf2.yahoo.com (sonic306-3.consmr.mail.bf2.yahoo.com [74.6.132.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 6C8C21295D8 for <ace@ietf.org>; Thu, 7 Feb 2019 08:05:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1549555542; bh=xUSK28T0q+SQ8IwDt7wC5xD7R1Xy9IPs39OALqCzkAo=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=ZYDNJCJVDFWDVlBybTu7KYVhbWvsXRvnoZuZH8ZlAzwJZrf05cnPyO0YeoGWgmz9xyFNjTWpIgZrt+tLWuIhxnVTib6ziI6yg5ammVL7eOfO5zibnlk8ADZbfVv2YK7gWCNBXwSWtUKBZwYDDh11LDPH+DWdhl12VTS2ttfumNl1Rh/lod5y+lW4R/wm13cUsUxzYz/EhSRUTLwyqZtIVLTzRUUMX3RNOw9aA07cSbP6q35FxLTLYbkwzkMid5vZ2EZHOQw59um1pZ0lr2kNS3p2v6RICRsH0N5pfgTjqXEOAwrAaq89QJiDjJW6zoxPyMHLuEIPEHhodnZY87ftEg==
X-YMail-OSG: s29ItuEVM1kz6xW0gkS1ricGDd2y.afhLkACLAJpf9EPNZW8YN49nSazeLOdnnE xh7OL8AdjWWLDetPF3JgiMLNJLofGzrCqX9EwiK72TxRpZloSQ5ABxZRE2JvHVSeHardlzHn_eMh Z2D58WXsvrApl8ydHKzapuFFwnfQueCDVf4C7QaKiaPeJn2zZn8evww84U3d70DxGta1PQIAwP4R u5atYGUEql_pterd67vpm._Kt5rL4Vs4iEzh2NvecI3gvi5rQkJlfih.by4XYESGGaT3e7oVmZLs IWCUhRoNoJiJoCKJbqZ.8TgKeBG6hgsjGAJEDF4F5YTEZWidHBCMP3MXB3okN9RLW0695i.NR8zI OFpJfGdaZ5YAMaXtmxYxsVFEdRyODoe4rCZarvvWCJ7XGVGK67.NRCyJxK7IegPUtcWHlvzBVpZr EvgQIF3u6KBfu0pAwDXD4nwx.XveUnM6cfoVsjbN_bemcXT5NlOGgh.rZFAzYtSZo70zLFfBlL0o zQyYaXPx.FYJOyAgdZMR9_MlLSosmzUd0kBdh7eVQj7vEgLRcpijLvvzyixprT0tQMp3ISj_IZ9v 0F9E15__r9pkRX1vgeMIJUi0qBneUJjdLw7QfvH_Dir3mna3M76hDnhq3q5qjkC1ZdMPDyK4EIli ._qt0H2qP0.zXfRxtG98J7WxaG73shT_EgpA27Kr5izBiM4OAd52x8db0._HvoW5hbGWD7Vd0Yi1 7z43hq6dzQL7hK6MsWWb8U4oEzcMlkxmACTwlpsXHPDji_5nKV.pgdYuEGJR2Yh600NQYAnQhZHu AXjPx5xMmeUkRPfEIrpNW7X.tnvx7h4VoTCMG_m6bqGsgZb7Urn9HNCB0DmkiMXrix1lvWsXqz.j V030438hYXYFjw2.fgOdFSdUFm9__HFzxKjoEyF92oTn4jimhP75efAGHBTfiHlEAQ9cCw4FQy0x wvI1H57lVQx9ZUIacfptKMrq8s3h.sUGivthDcO8K6aVSklNtW1P2RHlr1LWrh_QO3Mckct33YSQ onTMN4.NaxmgClqQQWleLomW0qzwz8cXigzNaSS2PGg5eIDmkmvNYJVvbzj1kTOPX
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Thu, 7 Feb 2019 16:05:42 +0000
Received: from nat-vpn-users4.cfw-a-gci.net.buffalo.office.oath (EHLO [10.89.92.247]) ([184.165.8.99]) by smtp414.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 483a52b58039239bac8fef3b4f174921; Thu, 07 Feb 2019 16:05:39 +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> <DM5PR00MB0293B214D198F4D9DBD08814F5990@DM5PR00MB0293.namprd00.prod.outlook.com> <CAO_FVe6CecdCxtJ78FcZ6pFJZwu6dudomjFgVeLr_cHNFbUZXQ@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>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <d4081519-90dd-01a2-0df8-c78b9e29e088@aol.com>
Date: Thu, 7 Feb 2019 11:05:37 -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: <VI1PR0801MB2112ABDD90AEB1208EC656CCFA680@VI1PR0801MB2112.eurprd08.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------9ED1AE8C0B808192A81FAB79"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/laQW18_lNM2a1ry-akS0jHXZN1A>
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:05:51 -0000

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", ...

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> *On Behalf Of *George Fletcher
> *Sent:* Dienstag, 29. Januar 2019 14:15
> *To:* 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
>
> 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
>