Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054491ACE53 for ; Wed, 6 Jan 2016 02:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 wY2moEVfL5ze for ; Wed, 6 Jan 2016 02:19:23 -0800 (PST) Received: from p3plsmtpa11-08.prod.phx3.secureserver.net (p3plsmtpa11-08.prod.phx3.secureserver.net [68.178.252.109]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8FF91ACDE1 for ; Wed, 6 Jan 2016 02:19:23 -0800 (PST) Received: from [192.168.0.112] ([77.77.164.50]) by p3plsmtpa11-08.prod.phx3.secureserver.net with id 2aKM1s00A15ZTut01aKNlz; Wed, 06 Jan 2016 03:19:23 -0700 To: oauth@ietf.org References: From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <568CEA28.6070204@connect2id.com> Date: Wed, 6 Jan 2016 12:19:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060507050603050207060803" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us -03 announcement redux X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 10:19:27 -0000 This is a multi-part message in MIME format. --------------060507050603050207060803 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Brian, 1. The introduction is excellent! Previous versions were lacking in this regard and readers were left guessing or unaware about key aspects of the spec and how to make use of it. Good work! 2.1. Are clients allowed to mix or include both "resource" and "audience" request parameters at the same time? A.1. Wouldn't the impersonation example be more straightforward if the returned token is an access token? I see that a "N_A" token is also demonstrated there, but that could confuse readers if the main point is to show an impersonation example. A.1 + A.2. It is stated that the client is anonymous. But is that really so if the supplied JWTs are apparently signed by the client and the AS will have to verify them? Overall I'm very pleased with this new version! Cheers, Vladimir On 05/01/16 23:40, Brian Campbell wrote: > On the off chance that it was missed in the final throes of 2015, I'd l= ike > to re-announce the publication of a new revision of the OAuth 2.0 Token= > Exchange draft. > > http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 > > Due to the substantial changes in this draft, I'd encourage (a.k.a. beg= ) WG > participants to review the document. As Mike said, this draft reconcile= s > the differences in approaches taken in the previous working group draft= and > draft-campbell-oauth-sts while incorporating working group input and ro= ugh > consensuses from the in-person discussions in Prague and mailing list > discussions. > > Changes from -02 are summarized in Appendix D > http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#appendix-= D > and the more meaningful are copied here: > > o Updated the format of the request to use application/x-www-form- > urlencoded request parameters and the response to use the existin= g > token endpoint JSON parameters defined in OAuth 2.0. > o Changed the grant type identifier to urn:ietf:params:oauth:grant-= > type:token-exchange. > o Removed the Implementation Considerations and the requirement to > support JWTs. > o Changed "on_behalf_of" to "subject_token", > "on_behalf_of_token_type" to "subject_token_type", "act_as" to > "actor_token", and "act_as_token_type" to "actor_token_type". > o Added a "want_composite" request parameter used to indicate the > desire for a composite token rather than trying to infer it from > the presence/absence of token(s) in the request. > o Added an "audience" request parameter used to indicate the logica= l > names of the target services at which the client intends to use > the requested security token. > o Added a "resource" request parameter used to indicate the URLs of= > resources at which the client intends to use the requested > security token. > o Specified that multiple "audience" and "resource" request > parameter values may be used. > o Defined the JWT claim "act" (actor) to express the current actor > or delegation principal. > o Defined the JWT claim "may_act" to express that one party is > authorized to act on behalf of another party. > o Defined the JWT claim "scp" (scopes) to express OAuth 2.0 scope- > token values. > o Added the "N_A" (not applicable) OAuth Access Token Type > definition for use in contexts in which the token exchange syntax= > requires a "token_type" value, but in which the token being issue= d > is not an access token. > o Added examples. > > > And the (known) outstanding issues are listed in Appendix C > http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#appendix-= C > but also copied here: > > o Should there be a way to use short names for some common token > type identifiers? URIs are necessary in the general case for > extensibility and vendor/deployment specific types. But short > names like "access_token" and "jwt" are aesthetically appealing > and slightly more efficient in terms of bytes on the wire and url= - > encoding. There seemed to be rough consensus in Prague ('No > objection to use the proposed mechanism for a default prefix' fro= m > https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth) for= > supporting a shorthand for commonly used types - i.e. when the > value does not contain a ":" character, the value would be treate= d > as though "urn:ietf:params:oauth:token-type:" were prepended to > it. So, for example, the value "jwt" for "requested_token_type" > would be semantically equivalent to "urn:ietf:params:oauth:token-= > type:jwt" and the value "access_token" would be equivalent to > "urn:ietf:params:oauth:token-type:access_token". However, it was= > a fairly brief discussion in Prague and it has since been > suggested that making participants handle both syntaxes will > unnecessarily complicate the supporting code. > > o Provide a way to include supplementary claims or information in > the request that would/could potentially be included in the issue= d > token. There are real use cases for this but we would need to > work through what it would look like. > > o Understand and define exactly how the presentation of PoP/non- > bearer tokens works. Of course, the specifications defining thes= e > kinds of tokens need to do so first before there is much we can d= o > in this specification in this regard. > > o It seems there may be cases in which it would be desirable for th= e > authenticated client to be somehow represented in the issued > token, sometimes in addition to the actor, which can already be > represented using the "act" claim. Perhaps with a "client_id" > claim? > > > > > ---------- Forwarded message ---------- > From: Mike Jones > Date: Mon, Dec 14, 2015 at 1:05 AM > Subject: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us= > To: "oauth@ietf.org" > > > I=92m happy to report that a substantially revised OAuth 2.0 Token Exch= ange > draft has been published that enables a broad range of use cases, while= > still remaining as simple as possible. This draft unifies the approach= es > taken in the previous working group draft and draft-campbell-oauth-sts,= > incorporating working group input from the in-person discussions in Pra= gue > and mailing list discussions. Thanks to all for your interest in and > contributions to OAuth Token Exchange! Brian Campbell deserves special= > recognition for doing much of the editing heavy lifting for this draft.= > > > > The core functionality remains token type independent. That said, new > claims are also defined to enable representation of delegation actors i= n > JSON Web Tokens (JWTs). Equivalent claims could be defined for other t= oken > types by other specifications. > > > > See the Document History section for a summary of the changes made. Pl= ease > check it out! > > > > The specification is available at: > > =B7 http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03= > > > > An HTML-formatted version is also available at: > > =B7 http://self-issued.info/docs/draft-ietf-oauth-token-exchange-= 03.html > > > > -- Mike > > > > P.S. This note was also posted at http://self-issued.info/?p=3D1509 an= d as > @selfissued . > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------060507050603050207060803 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Brian,

1. The introduction is excellent! Previous versions were lacking in this regard and readers were left guessing or unaware about key aspects of the spec and how to make use of it. Good work!

2.1. Are clients allowed to mix or include both "resource" and "audience" request parameters at the same time?

A.1. Wouldn't the impersonation example be more straightforward if the returned token is an access token? I see that a "N_A" token is also demonstrated there, but that could confuse readers if the main point is to show an impersonation example.

A.1 + A.2. It is stated that the client is anonymous. But is that really so if the supplied JWTs are apparently signed by the client and the AS will have to verify them?


Overall I'm very pleased with this new version!

Cheers,

Vladimir



On 05/01/16 23:40, Brian Campbell wrote:
On the off chance that it was missed in the final throes of 2015, I'd like
to re-announce the publication of a new revision of the OAuth 2.0 Token
Exchange draft.

http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03

Due to the substantial changes in this draft, I'd encourage (a.k.a. beg) WG
participants to review the document. As Mike said, this draft reconciles
the differences in approaches taken in the previous working group draft and
draft-campbell-oauth-sts while incorporating working group input and rough
consensuses from the in-person discussions in Prague and mailing list
discussions.

Changes from -02 are summarized in Appendix D
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#appendix-D
and the more meaningful are copied here:

   o  Updated the format of the request to use application/x-www-form-
      urlencoded request parameters and the response to use the existing
      token endpoint JSON parameters defined in OAuth 2.0.
   o  Changed the grant type identifier to urn:ietf:params:oauth:grant-
      type:token-exchange.
   o  Removed the Implementation Considerations and the requirement to
      support JWTs.
   o  Changed "on_behalf_of" to "subject_token",
      "on_behalf_of_token_type" to "subject_token_type", "act_as" to
      "actor_token", and "act_as_token_type" to "actor_token_type".
   o  Added a "want_composite" request parameter used to indicate the
      desire for a composite token rather than trying to infer it from
      the presence/absence of token(s) in the request.
   o  Added an "audience" request parameter used to indicate the logical
      names of the target services at which the client intends to use
      the requested security token.
   o  Added a "resource" request parameter used to indicate the URLs of
      resources at which the client intends to use the requested
      security token.
   o  Specified that multiple "audience" and "resource" request
      parameter values may be used.
   o  Defined the JWT claim "act" (actor) to express the current actor
      or delegation principal.
   o  Defined the JWT claim "may_act" to express that one party is
      authorized to act on behalf of another party.
   o  Defined the JWT claim "scp" (scopes) to express OAuth 2.0 scope-
      token values.
   o  Added the "N_A" (not applicable) OAuth Access Token Type
      definition for use in contexts in which the token exchange syntax
      requires a "token_type" value, but in which the token being issued
      is not an access token.
   o  Added examples.


And the (known) outstanding issues are listed in Appendix C
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#appendix-C
but also copied here:

   o  Should there be a way to use short names for some common token
      type identifiers?  URIs are necessary in the general case for
      extensibility and vendor/deployment specific types.  But short
      names like "access_token" and "jwt" are aesthetically appealing
      and slightly more efficient in terms of bytes on the wire and url-
      encoding.  There seemed to be rough consensus in Prague ('No
      objection to use the proposed mechanism for a default prefix' from
      https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth) for
      supporting a shorthand for commonly used types - i.e. when the
      value does not contain a ":" character, the value would be treated
      as though "urn:ietf:params:oauth:token-type:" were prepended to
      it.  So, for example, the value "jwt" for "requested_token_type"
      would be semantically equivalent to "urn:ietf:params:oauth:token-
      type:jwt" and the value "access_token" would be equivalent to
      "urn:ietf:params:oauth:token-type:access_token".  However, it was
      a fairly brief discussion in Prague and it has since been
      suggested that making participants handle both syntaxes will
      unnecessarily complicate the supporting code.

   o  Provide a way to include supplementary claims or information in
      the request that would/could potentially be included in the issued
      token.  There are real use cases for this but we would need to
      work through what it would look like.

   o  Understand and define exactly how the presentation of PoP/non-
      bearer tokens works.  Of course, the specifications defining these
      kinds of tokens need to do so first before there is much we can do
      in this specification in this regard.

   o  It seems there may be cases in which it would be desirable for the
      authenticated client to be somehow represented in the issued
      token, sometimes in addition to the actor, which can already be
      represented using the "act" claim.  Perhaps with a "client_id"
      claim?




---------- Forwarded message ----------
From: Mike Jones <Michael.Jones@microsoft.com>
Date: Mon, Dec 14, 2015 at 1:05 AM
Subject: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us
To: "oauth@ietf.org" <oauth@ietf.org>


I’m happy to report that a substantially revised OAuth 2.0 Token Exchange
draft has been published that enables a broad range of use cases, while
still remaining as simple as possible.  This draft unifies the approaches
taken in the previous working group draft and draft-campbell-oauth-sts,
incorporating working group input from the in-person discussions in Prague
and mailing list discussions.  Thanks to all for your interest in and
contributions to OAuth Token Exchange!  Brian Campbell deserves special
recognition for doing much of the editing heavy lifting for this draft.



The core functionality remains token type independent.  That said, new
claims are also defined to enable representation of delegation actors in
JSON Web Tokens (JWTs).  Equivalent claims could be defined for other token
types by other specifications.



See the Document History section for a summary of the changes made.  Please
check it out!



The specification is available at:

·       http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03



An HTML-formatted version is also available at:

·       http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03.html



                                                          -- Mike



P.S.  This note was also posted at http://self-issued.info/?p=1509 and as
@selfissued <https://twitter.com/selfissued>.

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




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


-- 
Vladimir Dzhuvinov :: vladimir@connect2id.com
--------------060507050603050207060803--