Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt

Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 26 March 2017 19:51 UTC

Return-Path: <torsten@lodderstedt.net>
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 8841E1296A3 for <oauth@ietfa.amsl.com>; Sun, 26 Mar 2017 12:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.029
X-Spam-Level:
X-Spam-Status: No, score=-1.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 3Zk6OgRnlSO4 for <oauth@ietfa.amsl.com>; Sun, 26 Mar 2017 12:51:52 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC7712969B for <oauth@ietf.org>; Sun, 26 Mar 2017 12:51:52 -0700 (PDT)
Received: from [31.133.133.240] (helo=dhcp-85f0.meeting.ietf.org) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <torsten@lodderstedt.net>) id 1csECb-0003X8-Ny; Sun, 26 Mar 2017 21:51:49 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <9199091B-5D7F-4D66-9EC5-CB0EF2D3CF6D@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_5AC98A42-0416-4D4C-81C4-A294BF2EB57D"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Sun, 26 Mar 2017 16:00:10 +0200
In-Reply-To: <CA+k3eCTE1NM90QcZRFR0jATCqdeJWyTRUb6Ryp52n9FRg6aGpA@mail.gmail.com>
Cc: oauth <oauth@ietf.org>
To: Brian Campbell <bcampbell@pingidentity.com>
References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> <CA+k3eCTE1NM90QcZRFR0jATCqdeJWyTRUb6Ryp52n9FRg6aGpA@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/wwPJ8sK8A3qE0WKltsuYmwjpm_0>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Mar 2017 19:51:55 -0000

Hi Brian,

thanks for the clarification around resource, audience and scope. 

Here are my comments on the draft:

In section 2.1 it states: „Multiple "resource" parameters may be used to indicate
      that the issued token is intended to be used at the multiple
      resources listed.“

Can you please explain the rational in more detail? I don’t understand why there is a need to ask for access tokens, which are good for multiple resources at once. This is a request type more or less exclusively used in server to server scenarios, right? So the only reason I can think of is call reduction. 

On the other side, this feature increases the AS's complexity, e.g. its policy may prohibit to issue tokens for multiple resources in general or the particular set the client is asking for. How shall the AS handles such cases?

And it is getting even more complicated given there could also be multiple audience values and the client could mix them: 

"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 physical
      locations.“

And in the end the client may add some scope values to the „meal“, which brings us to 

„Effectively, the requested access rights of the
   token are the cartesian product of all the scopes at all the target
   services."

I personally would suggest to drop support for multiple audience and resource parameters and make audience and resource mutual exclusive. I think this is sufficient and much easier to implement.

kind regards,
Torsten.


> Am 11.01.2017 um 20:04 schrieb Brian Campbell <bcampbell@pingidentity.com>:
> 
> Draft -07 of "OAuth 2.0 Token Exchange" has been published. The primary change in -07 is the addition of a description of the relationship between audience/resource/scope, which was a request or comment that came up during the f2f meeting in Seoul. 
> 
> Excerpted from the Document History:
> 
>    -07
> 
>    o  Fixed typo (desecration -> discretion).
>    o  Added an explanation of the relationship between scope, audience
>       and resource in the request and added an "invalid_target" error
>       code enabling the AS to tell the client that the requested
>       audiences/resources were too broad.
> 
> 
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
> Date: Wed, Jan 11, 2017 at 12:00 PM
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt
> To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
> Cc: oauth@ietf.org <mailto:oauth@ietf.org>
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Web Authorization Protocol of the IETF.
> 
>         Title           : OAuth 2.0 Token Exchange
>         Authors         : Michael B. Jones
>                           Anthony Nadalin
>                           Brian Campbell
>                           John Bradley
>                           Chuck Mortimore
>         Filename        : draft-ietf-oauth-token-exchange-07.txt
>         Pages           : 31
>         Date            : 2017-01-11
> 
> Abstract:
>    This specification defines a protocol for an HTTP- and JSON- based
>    Security Token Service (STS) by defining how to request and obtain
>    security tokens from OAuth 2.0 authorization servers, including
>    security tokens employing impersonation and delegation.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/>
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07 <https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07>
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07 <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07>
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth