[OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us -03 announcement redux
Brian Campbell <bcampbell@pingidentity.com> Tue, 05 January 2016 21:40 UTC
Return-Path: <bcampbell@pingidentity.com>
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 7BB231A92F3 for <oauth@ietfa.amsl.com>; Tue, 5 Jan 2016 13:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 FVhkxwy0TRFc for <oauth@ietfa.amsl.com>; Tue, 5 Jan 2016 13:40:47 -0800 (PST)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 A6B321A92F0 for <oauth@ietf.org>; Tue, 5 Jan 2016 13:40:47 -0800 (PST)
Received: by mail-io0-x22b.google.com with SMTP id 1so153483597ion.1 for <oauth@ietf.org>; Tue, 05 Jan 2016 13:40:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:content-type; bh=4QgMsk/OWwIn3eQZEoAFg3KnnY+IalOZP0eh2PxfDlY=; b=A5X9v85aHXiyfVrEWPpzdZTcAXjVJA7qd3Lt8XrSEf0k5arHxrsNe153U6u38CDav3 WufPY+IsSHOHDQDlcsgfC3xaqycebpwAJ8AXL/POsBki/GWWS7JWWcSLj0DW5vNfUgFg gC5iB8PSrrDrK+L5YP4KSLXywGVLnHK+wOETs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=4QgMsk/OWwIn3eQZEoAFg3KnnY+IalOZP0eh2PxfDlY=; b=e1MEfi5n5lkNrvHF2fwKTtdNGBdE/UVr3JILBJLWWtaeDVVYkWOmZ9NY/UJmGor0OB 8o8uun6fh+j+N5eOfPo2nYqzAha0bdkcIb0rhTxKOhOJpboTq+ruN5dJLihc8kWSzrH3 Oz2wi0QEHjcav3ZpmQSOBCJGr9P5pSu948bzP2w9ahzwR3pPgmR5F3FYBGui2aMPXIGG BnSLs4opD0cDD6aFJ/N8XcjQfSen4YW5Jg2qZS6iW9DhrxLHQTyXuuk0MOx+ByMDeVGL Meb86u7hDE8ypRltvjlVCl2GR5rFhwv3IMKfezzW5Mx+O0QhFv9TyDPMXS2dHxvQ4ESs K+yA==
X-Gm-Message-State: ALoCoQlRqB3HJC5WaWkMQEBMMgqLRxMCJ3QJK1+oPDRZiMNkxpxFlw/APBLuXQxj1qacLccYyt7WD95sEd0C039VbLMzKL+l+OlgOawvXBDgU0+S+g4o83c=
X-Received: by 10.107.16.226 with SMTP id 95mr54849664ioq.147.1452030046522; Tue, 05 Jan 2016 13:40:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.23.133 with HTTP; Tue, 5 Jan 2016 13:40:17 -0800 (PST)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 05 Jan 2016 14:40:17 -0700
Message-ID: <CA+k3eCT0_MpD6w8+aF3QAONxO02VbPb=fhFdPViUDs1evZUMBQ@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a113ecda02067fb05289d17e3"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/fNS8P7flckTsWjxN2bYtpOe6VSU>
Subject: [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 <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: Tue, 05 Jan 2016 21:40:50 -0000
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-WG] OAuth 2.0 Token Exchange: An STS for t… Brian Campbell
- Re: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS f… Vladimir Dzhuvinov
- Re: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS f… Brian Campbell