From jricher@mitre.org Mon Dec 2 11:05:31 2013 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 840F81ADDCA for ; Mon, 2 Dec 2013 11:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 OnVEXGCkAf5l for ; Mon, 2 Dec 2013 11:05:28 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id AE16B1AD94A for ; Mon, 2 Dec 2013 11:05:28 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 845C81F073D; Mon, 2 Dec 2013 14:05:24 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 718251F04A4; Mon, 2 Dec 2013 14:05:24 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.251]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 14:05:24 -0500 From: "Richer, Justin P." To: Prabath Siriwardena Thread-Topic: Adding resource owner id to the introspection response {was :Introspection spec still active? } Thread-Index: AQHO7DA8A+obsZJq6Eag4p5PDiWXpJpBnlkA Date: Mon, 2 Dec 2013 19:05:23 +0000 Message-ID: <288C7DCF-4B84-44C8-8AA7-5C77C054CA4F@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.15] Content-Type: multipart/alternative; boundary="_000_288C7DCF4B8444C88AA75C77C054CA4Fmitreorg_" MIME-Version: 1.0 Cc: IETF oauth WG Subject: Re: [OAUTH-WG] Adding resource owner id to the introspection response {was :Introspection spec still active? } 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: Mon, 02 Dec 2013 19:05:31 -0000 --_000_288C7DCF4B8444C88AA75C77C054CA4Fmitreorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sure, you can do that, if you've got an ID Token or similar. You could alte= rnatively define another endpoint to get user info back. Not every API is g= oing to have an ID Token defined (or even end users), so this isn't exactly= a general construct. But if it works for your API, go ahead and pass it al= ong with the rest of the information. It's important to make a distinction between ID Tokens that are gotten in t= his way, which pass information about the user who authorized the access to= ken, and ID Tokens that are gotten in the normal OpenID Connect way, which = convey information about the authentication event and are more closely tied= to the end user's authentication. In other words, you wouldn't want to acc= ept an access token, introspect to get an ID token, and then assume the use= r is "present" and log them in. -- Justin On Nov 28, 2013, at 6:51 AM, Prabath Siriwardena > wrote: Currently the introspection response has an optional parameter to pass the = client_id to the caller. It would also be useful to pass an ID token back i= n the response - just like in OpenID Connect - to include end user details. WDYT ? Thanks & regards, -Prabath On Tue, Nov 12, 2013 at 3:27 AM, Nat Sakimura > wrote: Great. I may have something for you based on our implementation. I will get back t= o you individually. Best, Nat 2013/11/12 Richer, Justin P. > Expiration of drafts happens automatically after a set amount of time has p= assed without edits. There haven't needed to be any edits to the introspect= ion draft in many months (apart from a couple typos), so I haven't updated = it. -- Justin ________________________________ From: oauth-bounces@ietf.org [oauth-bounces@= ietf.org] on behalf of Nat Sakimura [sakimur= a@gmail.com] Sent: Monday, November 11, 2013 9:47 AM To: Todd W Lainhart Cc: IETF oauth WG Subject: Re: [OAUTH-WG] Introspection spec still active? By no means. If Justin let it go, I will pick it up :-) 2013/11/11 Todd W Lainhart = > http://tools.ietf.org/html/draft-richer-oauth-introspection-04 expired as o= f 11/02/13. I'm assuming that this spec still has some traction, and that = the expiration is not an indicator of retraction? Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainhart@us.ibm.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://blog.api-security.org --_000_288C7DCF4B8444C88AA75C77C054CA4Fmitreorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <88E892207E13AE40B076F318580562A4@imc.mitre.org> Content-Transfer-Encoding: quoted-printable Sure, you can do that, if you've got an ID Token or similar. You could alte= rnatively define another endpoint to get user info back. Not every API is g= oing to have an ID Token defined (or even end users), so this isn't exactly= a general construct. But if it works for your API, go ahead and pass it along with the rest of the inform= ation. 

It's important to make a distinction between ID Tokens that are gotten= in this way, which pass information about the user who authorized the acce= ss token, and ID Tokens that are gotten in the normal OpenID Connect way, w= hich convey information about the authentication event and are more closely tied to the end user's authentic= ation. In other words, you wouldn't want to accept an access token, introsp= ect to get an ID token, and then assume the user is "present" and= log them in. 

 -- Justin

On Nov 28, 2013, at 6:51 AM, Prabath Siriwardena <prabath@wso2.com>
 wrote:

Currently the introspection response has an optional = parameter to pass the client_id to the caller. It would also be useful to p= ass an ID token back in the response - just like in OpenID Connect - to inc= lude end user details.

WDYT ?

Thanks & regards,
-Prabath

On Tue, Nov 12, 2013 at 3:27 AM, Nat Sakimura <sakimura@gmail.= com> wrote:
Great. 

I may have something for you based on our implementation. I will get b= ack to you individually. 

Best, 

Nat


2013/11/12 Richer, Justin P. &= lt;jricher@mitre.org= >

Expiration o= f drafts happens automatically after a set amount of time has passed withou= t edits. There haven't needed to be any edits to the introspection draft in= many months (apart from a couple typos), so I haven't updated it.

 -- Justin

From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] on behalf of Nat Sakimura [sakimura@gmail.com] Sent: Monday, November 11, 2013 9:47 AM
To: Todd W Lainhart
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Introspection spec still active?

By no means. If Justin let it go, I will pick it up :-)


2013/11/11 Todd W Lainhart <= ;lainhart@us.ibm.c= om>
http://tools.ietf.org/= html/draft-richer-oauth-introspection-04 expired as of 11/02/13.  I'm assuming= that this spec still has some traction, and that the expiration is not an = indicator of retraction?



Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart@us.ibm.co= m


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com http://blog.api-security.org =

--_000_288C7DCF4B8444C88AA75C77C054CA4Fmitreorg_-- From andreas.kohn@gmail.com Tue Dec 3 03:56:03 2013 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 404B61AE11B for ; Tue, 3 Dec 2013 03:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 P-qXiAJjygTD for ; Tue, 3 Dec 2013 03:56:01 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 716EE1AE0FC for ; Tue, 3 Dec 2013 03:56:01 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so11601403wgh.29 for ; Tue, 03 Dec 2013 03:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6KJeDwIJ1u1jDXT0sGRHRLTrdoJ4TfLP4CsCgkgHG7A=; b=VdnDIF4pkTuKLyBOKj0eVcTw9nHAlDc91VnRm/YdWDD+PwQEl6R7zOyCMWIx8tgjl9 VEP90e2dk5i7R12Mu6ZWy91y4anpQg3JIz+MVIDJm5BYrM7OE/zWnTXOz/CRwpmLRB68 skBO0H/WNWMmQD+Kr67j4opHyq/Q19rsRmfjM7Iq/mLdPNIyWIfi+PbdmouHJoF8sMU3 PsUkWn9D9m7XCh3tJeV1BuT3DbgNHCrHllvD1F4U3gFhc2tZYEj0ZhmRvLEBUDp6Y4V6 6jaUVLYal2wgz0SJZGOH19xTh9ZAHeAvZZHL//EA/g+Gc6ZY8camblyRAnrBjebNDVlh fkjw== MIME-Version: 1.0 X-Received: by 10.194.20.230 with SMTP id q6mr6758380wje.49.1386071758426; Tue, 03 Dec 2013 03:55:58 -0800 (PST) Received: by 10.194.249.97 with HTTP; Tue, 3 Dec 2013 03:55:58 -0800 (PST) Date: Tue, 3 Dec 2013 12:55:58 +0100 Message-ID: From: Andreas Kohn To: oauth@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d971bcb581404ec9ffa52 Subject: [OAUTH-WG] Scopes in access token response 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: Tue, 03 Dec 2013 11:56:03 -0000 --047d7b5d971bcb581404ec9ffa52 Content-Type: text/plain; charset=ISO-8859-1 Hi, the current RFC for OAuth 2.0 (http://www.rfc-editor.org/rfc/rfc6749.txt) is very unclear on *how* to return the scope in the access token response if there are multiple scopes requested/returned. Could someone please clarify whether the scopes are supposed to be returned as 1. space separated string value (i.e. in the same syntax in which they came in), or 2. as JSON array (looks most "JSON-y"), or 3. in another format (for example github uses ',') There is a related question on stackoverflow: http://stackoverflow.com/questions/13290994/how-should-approved-scopes-be-returned-from-an-oauth2-0 Regards, -- Andreas --047d7b5d971bcb581404ec9ffa52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

the current RFC = for OAuth 2.0 (http:/= /www.rfc-editor.org/rfc/rfc6749.txt) is very unclear on *how* to return= the scope in the access token response if there are multiple scopes reques= ted/returned.

Could someone please clarify whether the scopes are supposed to be retu= rned as
1. space separated string value (i.e. in the same syntax in whi= ch they came in), or
2. as JSON array (looks most "JSON-y"), = or
3. in another format (for example github uses ',')

The= re is a related question on stackoverflow: http://stackoverflow.com/questions/13290994/how-should-approved-scopes= -be-returned-from-an-oauth2-0


Regards,
--
Andreas



--047d7b5d971bcb581404ec9ffa52-- From t.broyer@gmail.com Tue Dec 3 04:43:30 2013 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 3C94A1ADEB6 for ; Tue, 3 Dec 2013 04:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 VF_dA_TY15XZ for ; Tue, 3 Dec 2013 04:43:29 -0800 (PST) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CD3271ADEA6 for ; Tue, 3 Dec 2013 04:43:28 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id oy12so10453446veb.1 for ; Tue, 03 Dec 2013 04:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EC29nRwq43Dg6GcBgF/Uc008FuGBtoUCdNmDsOa+RUE=; b=c8FEPHP1dzR3nQaQkBRTtfPd79zlbWe16W5WMfdUlOl6lhpVVucRix9o9q+vGxF1q/ ES/BE90e19qWtb6DnF200y8bLjMFrb4UuRFkVEC26LE/J3qWgIHBSkDXj9C+9s2Hamgd zYjC8xBgCCJ8ZuHfji3G5bVj/86gTOUg25YI6ipfdrm082hPVMAoXwglCSiU2j7PAf1w 2g4gHcWznMHFfHYfnBTbE9BbZ8MctsJ4CkmU2T1OF3Xs7yATu9avW1qBlGXn5oMWT9ml yOMwzPfEM2EVLtNNw8mK4ycNJ3E/rx9Nmk5z1AA9RRoJ7miqGItc0FY63v/dYm9tCSka kWuw== MIME-Version: 1.0 X-Received: by 10.52.186.228 with SMTP id fn4mr3866007vdc.34.1386074605886; Tue, 03 Dec 2013 04:43:25 -0800 (PST) Received: by 10.220.219.132 with HTTP; Tue, 3 Dec 2013 04:43:25 -0800 (PST) Received: by 10.220.219.132 with HTTP; Tue, 3 Dec 2013 04:43:25 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Dec 2013 13:43:25 +0100 Message-ID: From: Thomas Broyer To: Andreas Kohn Content-Type: multipart/alternative; boundary=bcaec54858f684520104eca0a42b Cc: "" Subject: Re: [OAUTH-WG] Scopes in access token response 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: Tue, 03 Dec 2013 12:43:30 -0000 --bcaec54858f684520104eca0a42b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le 3 d=C3=A9c. 2013 12:56, "Andreas Kohn" a =C3=A9= crit : > > Hi, > > the current RFC for OAuth 2.0 (http://www.rfc-editor.org/rfc/rfc6749.txt) is very unclear on *how* to return the scope in the access token response if there are multiple scopes requested/returned. I think it's very clear, on the opposite. Section 5.1 defers to section 3.3 which says very clearly that the value is a space-delimited list. --bcaec54858f684520104eca0a42b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Le 3 d=C3=A9c. 2013 12:56, "Andreas Kohn" <andreas.kohn@gmail.com> a =C3=A9crit :
>
> Hi,
>
> the current RFC for OAuth 2.0 (http://www.rfc-editor.org/rfc/rfc6749.txt) is very uncle= ar on *how* to return the scope in the access token response if there are m= ultiple scopes requested/returned.

I think it's very clear, on the opposite. Section 5.1 de= fers to section 3.3 which says very clearly that the value is a space-delim= ited list.

--bcaec54858f684520104eca0a42b-- From Adam.Lewis@motorolasolutions.com Wed Dec 4 11:37:39 2013 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 2C8951AE26D for ; Wed, 4 Dec 2013 11:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 bjJZbSe41JaG for ; Wed, 4 Dec 2013 11:37:32 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7911AE180 for ; Wed, 4 Dec 2013 11:37:32 -0800 (PST) Received: from mail106-va3-R.bigfish.com (10.7.14.230) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 19:37:28 +0000 Received: from mail106-va3 (localhost [127.0.0.1]) by mail106-va3-R.bigfish.com (Postfix) with ESMTP id A890E14010D for ; Wed, 4 Dec 2013 19:37:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:129.188.136.18; KIP:(null); UIP:(null); IPV:NLI; H:il06msg02.am.mot-solutions.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz9371Ic89bh1432Ic857hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail106-va3: domain of motorolasolutions.com designates 129.188.136.18 as permitted sender) client-ip=129.188.136.18; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg02.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.85; KIP:(null); UIP:(null); (null); H:BL2PRD0410HT004.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail106-va3 (localhost.localdomain [127.0.0.1]) by mail106-va3 (MessageSwitch) id 138618584648115_19868; Wed, 4 Dec 2013 19:37:26 +0000 (UTC) Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.242]) by mail106-va3.bigfish.com (Postfix) with ESMTP id F099E2A00EA for ; Wed, 4 Dec 2013 19:37:25 +0000 (UTC) Received: from il06msg02.am.mot-solutions.com (129.188.136.18) by VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 19:37:25 +0000 Received: from il06msg02.am.mot-solutions.com (il06vts02.mot.com [129.188.137.142]) by il06msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id rB4JbP5M015217 for ; Wed, 4 Dec 2013 14:37:25 -0500 (EST) Received: from CO9EHSOBE042.bigfish.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by il06msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id rB4JbOAJ015214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 4 Dec 2013 14:37:25 -0500 (EST) Received: from mail67-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE042.bigfish.com (10.236.130.105) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 19:37:24 +0000 Received: from mail67-co9 (localhost [127.0.0.1]) by mail67-co9-R.bigfish.com (Postfix) with ESMTP id 0589FE099B for ; Wed, 4 Dec 2013 19:37:24 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(51704005)(199002)(189002)(76482001)(79102001)(81542001)(81342001)(47736001)(47976001)(50986001)(66066001)(65816001)(80022001)(69226001)(18717965001)(19609705001)(15202345003)(63696002)(87266001)(74876001)(46102001)(74316001)(19580405001)(19580395003)(74366001)(80976001)(51856001)(53806001)(49866001)(76576001)(15975445006)(54356001)(4396001)(2656002)(83322001)(81686001)(81816001)(74706001)(90146001)(54316002)(47446002)(56776001)(74502001)(56816005)(83072001)(87936001)(31966008)(19300405004)(74662001)(85306002)(85852002)(33646001)(77982001)(59766001)(76786001)(76796001)(16236675002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR04MB733; H:DM2PR04MB735.namprd04.prod.outlook.com; CLIP:150.130.133.39; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail67-co9 (localhost.localdomain [127.0.0.1]) by mail67-co9 (MessageSwitch) id 1386185841583248_24638; Wed, 4 Dec 2013 19:37:21 +0000 (UTC) Received: from CO9EHSMHS022.bigfish.com (unknown [10.236.132.234]) by mail67-co9.bigfish.com (Postfix) with ESMTP id 870313C01DB; Wed, 4 Dec 2013 19:37:21 +0000 (UTC) Received: from BL2PRD0410HT004.namprd04.prod.outlook.com (157.56.240.85) by CO9EHSMHS022.bigfish.com (10.236.130.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 19:37:21 +0000 Received: from DM2PR04MB733.namprd04.prod.outlook.com (10.141.177.14) by BL2PRD0410HT004.namprd04.prod.outlook.com (10.255.99.39) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 4 Dec 2013 19:37:05 +0000 Received: from DM2PR04MB735.namprd04.prod.outlook.com (10.141.177.17) by DM2PR04MB733.namprd04.prod.outlook.com (10.141.177.14) with Microsoft SMTP Server (TLS) id 15.0.837.10; Wed, 4 Dec 2013 19:37:02 +0000 Received: from DM2PR04MB735.namprd04.prod.outlook.com ([10.141.177.17]) by DM2PR04MB735.namprd04.prod.outlook.com ([10.141.177.17]) with mapi id 15.00.0837.004; Wed, 4 Dec 2013 19:37:02 +0000 From: Lewis Adam-CAL022 To: Thomas Broyer , Andreas Kohn Thread-Topic: [OAUTH-WG] Scopes in access token response Thread-Index: AQHO8CVU9Zaip9JLYkywu6mYjZxPBJpEbuQg Date: Wed, 4 Dec 2013 19:37:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.133.39] x-forefront-prvs: 0050CEFE70 Content-Type: multipart/alternative; boundary="_000_cc2cb7ed880547cf8a75d5e107629c36DM2PR04MB735namprd04pro_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMAIL.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "" Subject: Re: [OAUTH-WG] Scopes in access token response 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, 04 Dec 2013 19:37:39 -0000 --_000_cc2cb7ed880547cf8a75d5e107629c36DM2PR04MB735namprd04pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoZSBxdWVzdGlvbiB3YXMgYXNraW5nIGFib3V0IGhvdyB0aGUgc2NvcGUgaXMg cmV0dXJuZWQgaW4gdGhlIGFjY2VzcyB0b2tlbi4gIFNlY3Rpb24gNS4xLzMuMyBhcmUgcmVhbGx5 IGRlc2NyaWJpbmcgaG93IHRoZSBzY29wZSBpcyAqcmVxdWVzdGVkKg0KDQpBbmRyZWFzIOKApi4g VGhlIGFuc3dlciB0byB5b3VyIHF1ZXN0aW9uIGlzIHRoYXQgaXQgaXMgb3V0IG9mIHNjb3BlIGZv ciB0aGUgT0F1dGggUkZDLiAgT0F1dGggZG9lcyBub3QgZGVmaW5lIHRoZSBzdHJ1Y3R1cmUgb2Yg dGhlIGFjY2VzcyB0b2tlbiwgc28gaXQgd2lsbCBiZSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4g IE1hbnkgaW1wbGVtZW50YXRpb25zIHBhc3MgYW4gdW5zdHJ1Y3R1cmVkIGFjY2VzcyB0b2tlbiB3 aGljaCBpcyBzZW50IGJhY2sgdG8gdGhlIEFTIGZvciBpbnRyb3NwZWN0aW9uLCBhbmQgcmV0dXJu ZWQgYSBKU09OIHNldCBvZiBjbGFpbXMgaW5jbHVkaW5nIHRoZSBzY29wZS4gIE90aGVycyB1c2Ug SldULXN0cnVjdHVyZWQgYWNjZXNzIHRva2Vucy4gIERvIHlvdSBoYXZlIGEgc3BlY2lmaWMgaW1w bGVtZW50YXRpb24gdGhhdCB5b3UgYXJlIGFza2luZyBhYm91dCwgb3Igd2FzIGl0IHNpbXBseSBh IGdlbmVyaWMgcXVlc3Rpb24/DQoNCmFkYW0NCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGhvbWFzIEJyb3llcg0KU2VudDogVHVlc2Rh eSwgRGVjZW1iZXIgMDMsIDIwMTMgNjo0MyBBTQ0KVG86IEFuZHJlYXMgS29obg0KQ2M6IDxvYXV0 aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFNjb3BlcyBpbiBhY2Nlc3MgdG9r ZW4gcmVzcG9uc2UNCg0KDQpMZSAzIGTDqWMuIDIwMTMgMTI6NTYsICJBbmRyZWFzIEtvaG4iIDxh bmRyZWFzLmtvaG5AZ21haWwuY29tPG1haWx0bzphbmRyZWFzLmtvaG5AZ21haWwuY29tPj4gYSDD qWNyaXQgOg0KPg0KPiBIaSwNCj4NCj4gdGhlIGN1cnJlbnQgUkZDIGZvciBPQXV0aCAyLjAgKGh0 dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzY3NDkudHh0KSBpcyB2ZXJ5IHVuY2xlYXIg b24gKmhvdyogdG8gcmV0dXJuIHRoZSBzY29wZSBpbiB0aGUgYWNjZXNzIHRva2VuIHJlc3BvbnNl IGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBzY29wZXMgcmVxdWVzdGVkL3JldHVybmVkLg0KDQpJIHRo aW5rIGl0J3MgdmVyeSBjbGVhciwgb24gdGhlIG9wcG9zaXRlLiBTZWN0aW9uIDUuMSBkZWZlcnMg dG8gc2VjdGlvbiAzLjMgd2hpY2ggc2F5cyB2ZXJ5IGNsZWFybHkgdGhhdCB0aGUgdmFsdWUgaXMg YSBzcGFjZS1kZWxpbWl0ZWQgbGlzdC4NCg== --_000_cc2cb7ed880547cf8a75d5e107629c36DM2PR04MB735namprd04pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBiZWxpZXZlIHRoZSBxdWVz dGlvbiB3YXMgYXNraW5nIGFib3V0IGhvdyB0aGUgc2NvcGUgaXMgcmV0dXJuZWQgaW4gdGhlIGFj Y2VzcyB0b2tlbi4mbmJzcDsgU2VjdGlvbiA1LjEvMy4zIGFyZSByZWFsbHkgZGVzY3JpYmluZyBo b3cgdGhlIHNjb3BlIGlzICo8Yj5yZXF1ZXN0ZWQ8L2I+KjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5kcmVhcyDigKYu IFRoZSBhbnN3ZXIgdG8geW91ciBxdWVzdGlvbiBpcyB0aGF0IGl0IGlzIG91dCBvZiBzY29wZSBm b3IgdGhlIE9BdXRoIFJGQy4mbmJzcDsgT0F1dGggZG9lcyBub3QgZGVmaW5lIHRoZSBzdHJ1Y3R1 cmUgb2YgdGhlIGFjY2VzcyB0b2tlbiwgc28gaXQgd2lsbCBiZQ0KIGltcGxlbWVudGF0aW9uIHNw ZWNpZmljLiZuYnNwOyBNYW55IGltcGxlbWVudGF0aW9ucyBwYXNzIGFuIHVuc3RydWN0dXJlZCBh Y2Nlc3MgdG9rZW4gd2hpY2ggaXMgc2VudCBiYWNrIHRvIHRoZSBBUyBmb3IgaW50cm9zcGVjdGlv biwgYW5kIHJldHVybmVkIGEgSlNPTiBzZXQgb2YgY2xhaW1zIGluY2x1ZGluZyB0aGUgc2NvcGUu Jm5ic3A7IE90aGVycyB1c2UgSldULXN0cnVjdHVyZWQgYWNjZXNzIHRva2Vucy4mbmJzcDsgRG8g eW91IGhhdmUgYSBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbg0KIHRoYXQgeW91IGFyZSBhc2tpbmcg YWJvdXQsIG9yIHdhcyBpdCBzaW1wbHkgYSBnZW5lcmljIHF1ZXN0aW9uPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YWRh bTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5UaG9tYXMgQnJveWVyPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IERlY2VtYmVyIDAzLCAyMDEzIDY6NDMgQU08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJlYXMgS29objxi cj4NCjxiPkNjOjwvYj4gJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW09BVVRILVdHXSBTY29wZXMgaW4gYWNjZXNzIHRva2VuIHJlc3BvbnNlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwPjxicj4NCkxlIDMgZMOpYy4gMjAxMyAxMjo1NiwgJnF1b3Q7QW5kcmVhcyBL b2huJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YW5kcmVhcy5rb2huQGdtYWlsLmNvbSI+YW5k cmVhcy5rb2huQGdtYWlsLmNvbTwvYT4mZ3Q7IGEgw6ljcml0IDo8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBIaSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyB0aGUgY3VycmVudCBSRkMgZm9yIE9BdXRoIDIuMCAo PGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNjc0OS50eHQiPmh0dHA6 Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzY3NDkudHh0PC9hPikgaXMgdmVyeSB1bmNsZWFy IG9uICpob3cqIHRvIHJldHVybiB0aGUgc2NvcGUgaW4gdGhlIGFjY2VzcyB0b2tlbiByZXNwb25z ZSBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgc2NvcGVzIHJlcXVlc3RlZC9yZXR1cm5lZC4NCjxvOnA+ PC9vOnA+PC9wPg0KPHA+SSB0aGluayBpdCdzIHZlcnkgY2xlYXIsIG9uIHRoZSBvcHBvc2l0ZS4g U2VjdGlvbiA1LjEgZGVmZXJzIHRvIHNlY3Rpb24gMy4zIHdoaWNoIHNheXMgdmVyeSBjbGVhcmx5 IHRoYXQgdGhlIHZhbHVlIGlzIGEgc3BhY2UtZGVsaW1pdGVkIGxpc3QuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_cc2cb7ed880547cf8a75d5e107629c36DM2PR04MB735namprd04pro_-- From jricher@mitre.org Wed Dec 4 11:50:11 2013 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 BE79F1AE2E6 for ; Wed, 4 Dec 2013 11:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 CEzqQjHE2mDa for ; Wed, 4 Dec 2013 11:50:09 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0F00C1AE2D1 for ; Wed, 4 Dec 2013 11:50:09 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CCA721F08D0; Wed, 4 Dec 2013 14:50:05 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AF1FA1F0821; Wed, 4 Dec 2013 14:50:05 -0500 (EST) Received: from [10.146.15.6] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 14:50:05 -0500 Message-ID: <529F8735.9040102@mitre.org> Date: Wed, 4 Dec 2013 14:49:09 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Lewis Adam-CAL022 , Thomas Broyer , Andreas Kohn References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060607000104050706010703" X-Originating-IP: [129.83.31.51] Cc: "" Subject: Re: [OAUTH-WG] Scopes in access token response 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, 04 Dec 2013 19:50:12 -0000 --------------060607000104050706010703 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Actually, section 5.1 is quite specifically how it's returned, and the intent of the cross-reference to 3.3 is that they use the same format: a space-separated list presented as a single JSON string. The grammar in section A.4 applies to both. -- Justin On 12/04/2013 02:37 PM, Lewis Adam-CAL022 wrote: > > I believe the question was asking about how the scope is returned in > the access token. Section 5.1/3.3 are really describing how the scope > is **requested** > > Andreas .... The answer to your question is that it is out of scope > for the OAuth RFC. OAuth does not define the structure of the access > token, so it will be implementation specific. Many implementations > pass an unstructured access token which is sent back to the AS for > introspection, and returned a JSON set of claims including the scope. > Others use JWT-structured access tokens. Do you have a specific > implementation that you are asking about, or was it simply a generic > question? > > adam > > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Thomas Broyer > *Sent:* Tuesday, December 03, 2013 6:43 AM > *To:* Andreas Kohn > *Cc:* > *Subject:* Re: [OAUTH-WG] Scopes in access token response > > > Le 3 déc. 2013 12:56, "Andreas Kohn" > a écrit : > > > > Hi, > > > > the current RFC for OAuth 2.0 > (http://www.rfc-editor.org/rfc/rfc6749.txt) is very unclear on *how* > to return the scope in the access token response if there are multiple > scopes requested/returned. > > I think it's very clear, on the opposite. Section 5.1 defers to > section 3.3 which says very clearly that the value is a > space-delimited list. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------060607000104050706010703 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Actually, section 5.1 is quite specifically how it's returned, and the intent of the cross-reference to 3.3 is that they use the same format: a space-separated list presented as a single JSON string. The grammar in section A.4 applies to both.

 -- Justin

On 12/04/2013 02:37 PM, Lewis Adam-CAL022 wrote:

I believe the question was asking about how the scope is returned in the access token.  Section 5.1/3.3 are really describing how the scope is *requested*

 

Andreas …. The answer to your question is that it is out of scope for the OAuth RFC.  OAuth does not define the structure of the access token, so it will be implementation specific.  Many implementations pass an unstructured access token which is sent back to the AS for introspection, and returned a JSON set of claims including the scope.  Others use JWT-structured access tokens.  Do you have a specific implementation that you are asking about, or was it simply a generic question?

 

adam

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Thomas Broyer
Sent: Tuesday, December 03, 2013 6:43 AM
To: Andreas Kohn
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Scopes in access token response

 


Le 3 déc. 2013 12:56, "Andreas Kohn" <andreas.kohn@gmail.com> a écrit :
>
> Hi,
>
> the current RFC for OAuth 2.0 (http://www.rfc-editor.org/rfc/rfc6749.txt) is very unclear on *how* to return the scope in the access token response if there are multiple scopes requested/returned.

I think it's very clear, on the opposite. Section 5.1 defers to section 3.3 which says very clearly that the value is a space-delimited list.



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

--------------060607000104050706010703-- From Adam.Lewis@motorolasolutions.com Wed Dec 4 12:06:17 2013 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 80E7B1AD8E1 for ; Wed, 4 Dec 2013 12:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 TfmhRHbC-_Sj for ; Wed, 4 Dec 2013 12:06:12 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8085E1AD6A4 for ; Wed, 4 Dec 2013 12:06:12 -0800 (PST) Received: from mail68-co9-R.bigfish.com (10.236.132.250) by CO9EHSOBE014.bigfish.com (10.236.130.77) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 20:06:09 +0000 Received: from mail68-co9 (localhost [127.0.0.1]) by mail68-co9-R.bigfish.com (Postfix) with ESMTP id 5DD79480847 for ; Wed, 4 Dec 2013 20:06:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.160.210.20; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg01.am.mot-solutions.com; RD:ct11msg01.mot-solutions.com; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zzbb2dI98dI9371Ic89bhc85dh1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail68-co9: domain of motorolasolutions.com designates 192.160.210.20 as permitted sender) client-ip=192.160.210.20; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg01.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.85; KIP:(null); UIP:(null); (null); H:BL2PRD0410HT004.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail68-co9 (localhost.localdomain [127.0.0.1]) by mail68-co9 (MessageSwitch) id 1386187566992535_3351; Wed, 4 Dec 2013 20:06:06 +0000 (UTC) Received: from CO9EHSMHS003.bigfish.com (unknown [10.236.132.234]) by mail68-co9.bigfish.com (Postfix) with ESMTP id EE6436009F for ; Wed, 4 Dec 2013 20:06:06 +0000 (UTC) Received: from ct11msg01.am.mot-solutions.com (192.160.210.20) by CO9EHSMHS003.bigfish.com (10.236.130.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 20:06:06 +0000 Received: from ct11msg01.am.mot-solutions.com (ct11vts02.am.mot.com [10.177.16.160]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id rB4K64LE020891 for ; Wed, 4 Dec 2013 14:06:04 -0600 (CST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id rB4K64ue020888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 4 Dec 2013 14:06:04 -0600 (CST) Received: from mail109-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 20:06:04 +0000 Received: from mail109-va3 (localhost [127.0.0.1]) by mail109-va3-R.bigfish.com (Postfix) with ESMTP id EE1A04C0106 for ; Wed, 4 Dec 2013 20:06:03 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(377454003)(199002)(189002)(51704005)(24454002)(83322001)(81686001)(56776001)(54316002)(90146001)(47446002)(56816005)(74502001)(81816001)(74706001)(53806001)(4396001)(2656002)(49866001)(76576001)(15975445006)(54356001)(77982001)(33646001)(76796001)(16236675002)(59766001)(76786001)(19300405004)(83072001)(87936001)(74662001)(85306002)(85852002)(31966008)(66066001)(69226001)(65816001)(80022001)(81542001)(76482001)(79102001)(50986001)(81342001)(47976001)(47736001)(19580405001)(19580395003)(74366001)(80976001)(51856001)(63696002)(87266001)(18717965001)(15202345003)(74316001)(46102001)(74876001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR04MB735; H:DM2PR04MB735.namprd04.prod.outlook.com; CLIP:150.130.133.39; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail109-va3 (localhost.localdomain [127.0.0.1]) by mail109-va3 (MessageSwitch) id 1386187553587058_3498; Wed, 4 Dec 2013 20:05:53 +0000 (UTC) Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.229]) by mail109-va3.bigfish.com (Postfix) with ESMTP id F404E42016F; Wed, 4 Dec 2013 20:05:41 +0000 (UTC) Received: from BL2PRD0410HT004.namprd04.prod.outlook.com (157.56.240.85) by VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 20:05:41 +0000 Received: from DM2PR04MB735.namprd04.prod.outlook.com (10.141.177.17) by BL2PRD0410HT004.namprd04.prod.outlook.com (10.255.99.39) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 4 Dec 2013 20:05:41 +0000 Received: from DM2PR04MB735.namprd04.prod.outlook.com (10.141.177.17) by DM2PR04MB735.namprd04.prod.outlook.com (10.141.177.17) with Microsoft SMTP Server (TLS) id 15.0.837.10; Wed, 4 Dec 2013 20:05:39 +0000 Received: from DM2PR04MB735.namprd04.prod.outlook.com ([10.141.177.17]) by DM2PR04MB735.namprd04.prod.outlook.com ([10.141.177.17]) with mapi id 15.00.0837.004; Wed, 4 Dec 2013 20:05:39 +0000 From: Lewis Adam-CAL022 To: Justin Richer , Thomas Broyer , Andreas Kohn Thread-Topic: [OAUTH-WG] Scopes in access token response Thread-Index: AQHO8Soj1tYfaLrHGEa/EHF+WtTqFJpEdVCw Date: Wed, 4 Dec 2013 20:05:37 +0000 Message-ID: <25a5d1b216944de0879196904b9501e9@DM2PR04MB735.namprd04.prod.outlook.com> References: <529F8735.9040102@mitre.org> In-Reply-To: <529F8735.9040102@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.133.39] x-forefront-prvs: 0050CEFE70 Content-Type: multipart/alternative; boundary="_000_25a5d1b216944de0879196904b9501e9DM2PR04MB735namprd04pro_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMAIL.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%MITRE.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "" Subject: Re: [OAUTH-WG] Scopes in access token response 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, 04 Dec 2013 20:06:17 -0000 --_000_25a5d1b216944de0879196904b9501e9DM2PR04MB735namprd04pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I stand corrected. Thanks Justin :-) And of course that makes perfect sense since the AT is typically opaque to = the client, yet the client would need to know if it obtained the requested = scope. From: Justin Richer [mailto:jricher@mitre.org] Sent: Wednesday, December 04, 2013 1:49 PM To: Lewis Adam-CAL022; Thomas Broyer; Andreas Kohn Cc: Subject: Re: [OAUTH-WG] Scopes in access token response Actually, section 5.1 is quite specifically how it's returned, and the inte= nt of the cross-reference to 3.3 is that they use the same format: a space-= separated list presented as a single JSON string. The grammar in section A.= 4 applies to both. -- Justin On 12/04/2013 02:37 PM, Lewis Adam-CAL022 wrote: I believe the question was asking about how the scope is returned in the ac= cess token. Section 5.1/3.3 are really describing how the scope is *reques= ted* Andreas .... The answer to your question is that it is out of scope for the= OAuth RFC. OAuth does not define the structure of the access token, so it= will be implementation specific. Many implementations pass an unstructure= d access token which is sent back to the AS for introspection, and returned= a JSON set of claims including the scope. Others use JWT-structured acces= s tokens. Do you have a specific implementation that you are asking about,= or was it simply a generic question? adam From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Thomas Broyer Sent: Tuesday, December 03, 2013 6:43 AM To: Andreas Kohn Cc: Subject: Re: [OAUTH-WG] Scopes in access token response Le 3 d=E9c. 2013 12:56, "Andreas Kohn" > a =E9crit : > > Hi, > > the current RFC for OAuth 2.0 (http://www.rfc-editor.org/rfc/rfc6749.txt)= is very unclear on *how* to return the scope in the access token response = if there are multiple scopes requested/returned. I think it's very clear, on the opposite. Section 5.1 defers to section 3.3= which says very clearly that the value is a space-delimited list. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_25a5d1b216944de0879196904b9501e9DM2PR04MB735namprd04pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I stand corrected.  = Thanks Justin :-)

 <= /p>

And of course that makes = perfect sense since the AT is typically opaque to the client, yet the clien= t would need to know if it obtained the requested scope. 

 <= /p>

 <= /p>

 <= /p>

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, December 04, 2013 1:49 PM
To: Lewis Adam-CAL022; Thomas Broyer; Andreas Kohn
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Scopes in access token response

 

Actually, section 5.1= is quite specifically how it's returned, and the intent of the cross-refer= ence to 3.3 is that they use the same format: a space-separated list presen= ted as a single JSON string. The grammar in section A.4 applies to both.

 -- Justin

On 12/04/2013 02:37 PM, Lewis Adam-CAL022 wrote:

I believe the question wa= s asking about how the scope is returned in the access token.  Section= 5.1/3.3 are really describing how the scope is *requested*

 <= /p>

Andreas …. The answ= er to your question is that it is out of scope for the OAuth RFC.  OAu= th does not define the structure of the access token, so it will be implementation specific.  Many implementations pass an unstructured a= ccess token which is sent back to the AS for introspection, and returned a = JSON set of claims including the scope.  Others use JWT-structured acc= ess tokens.  Do you have a specific implementation that you are asking about, or was it simply a generic question?

 <= /p>

adam

 <= /p>

From: OAuth [<= a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org] On Behalf Of Thomas Broyer
Sent: Tuesday, December 03, 2013 6:43 AM
To: Andreas Kohn
Cc: <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Scopes in access token response<= /o:p>

 


Le 3 d=E9c. 2013 12:56, "Andreas Kohn" <andreas.kohn@gmail.com> a =E9crit :
>
> Hi,
>
> the current RFC for OAuth 2.0 (http://www.rfc-editor.org/rfc/rfc6749.txt) is very uncle= ar on *how* to return the scope in the access token response if there are m= ultiple scopes requested/returned.

I think it's very clear, on the opposite. Section 5.1 defers to section = 3.3 which says very clearly that the value is a space-delimited list.<= /o:p>




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

 

--_000_25a5d1b216944de0879196904b9501e9DM2PR04MB735namprd04pro_-- From ve7jtb@ve7jtb.com Wed Dec 4 12:06:58 2013 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 83A7E1AE193 for ; Wed, 4 Dec 2013 12:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 39ThexTJOJKR for ; Wed, 4 Dec 2013 12:06:55 -0800 (PST) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 71FB41AD6A4 for ; Wed, 4 Dec 2013 12:06:55 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id 1so14660932qee.10 for ; Wed, 04 Dec 2013 12:06:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=+d6QHsAYi+NGfNKvzwPkUmaG7g27dpAZfkaTX5tS8Io=; b=Db/SW7jnAzZQ3BCew218akPPSF13Z9PZ0aaBhX8XZ2oO8I8IBk0OaXdWBIfPEWKQfl YpJj6YPQejFVq4vdlb4PBGE5YbUHxOdYLoUh/Axl92QD/zUCQvRFPtgKNPSrDAm7yozs tgiYLCW6wWzkj/bXXRft0uXkjj6uqVKUyTr+HtwsMTsvZ6VQgRZAnjG831/v5gG2wemV yz06YZEfg4Z6NRpvbTehZbPLJyfKH65MTNOm0m8dk6elFzg4NmMan4L5ruZcjM6Heweg brebCvOTA6JUbEzTqBEY6szcloVMz9O8+xv1h8PZgVhpKzCZpyuG6fOYFeIN3ULQLYN1 anTQ== X-Gm-Message-State: ALoCoQkdaRw2EhRUDquJHmihYnITC5wz7EFZchD/pTvhnAqpKkQLdJ6D407cf7FecomMkykLQOmO X-Received: by 10.49.82.130 with SMTP id i2mr106874151qey.68.1386187612071; Wed, 04 Dec 2013 12:06:52 -0800 (PST) Received: from [192.168.0.200] ([201.187.201.237]) by mx.google.com with ESMTPSA id o10sm21974460qaa.6.2013.12.04.12.06.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 12:06:51 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C1B55A47-2D71-418E-BDDD-1887D6F4CB6C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: John Bradley In-Reply-To: Date: Wed, 4 Dec 2013 17:06:39 -0300 Message-Id: <35C05D8E-7772-4052-B8C8-A8E1A4A7DCE7@ve7jtb.com> References: To: Andreas Kohn X-Mailer: Apple Mail (2.1822) Cc: oauth Subject: Re: [OAUTH-WG] Scopes in access token response 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, 04 Dec 2013 20:06:59 -0000 --Apple-Mail=_C1B55A47-2D71-418E-BDDD-1887D6F4CB6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Per Sec 3.3 and Appendix A.4 scope is a space SP separated list of scope-token which are 1*NQCHAR=20 So query encoded it looks like &scope=3Dopenid%20profile%20email (you = would be sending it in a POST form encoded to the token endpoint in your = case)=20 and the response will be JSON: { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "scope":"openid profile email" } Yes the examples probably should have included scope but it is clear = from the normative text. John B. On Dec 3, 2013, at 8:55 AM, Andreas Kohn wrote: > Hi, >=20 > the current RFC for OAuth 2.0 = (http://www.rfc-editor.org/rfc/rfc6749.txt) is very unclear on *how* to = return the scope in the access token response if there are multiple = scopes requested/returned.=20 >=20 > Could someone please clarify whether the scopes are supposed to be = returned as=20 > 1. space separated string value (i.e. in the same syntax in which they = came in), or=20 > 2. as JSON array (looks most "JSON-y"), or=20 > 3. in another format (for example github uses ',') >=20 > There is a related question on stackoverflow: = http://stackoverflow.com/questions/13290994/how-should-approved-scopes-be-= returned-from-an-oauth2-0 >=20 >=20 > Regards, > -- > Andreas >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_C1B55A47-2D71-418E-BDDD-1887D6F4CB6C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMjA0MjAwNjQwWjAjBgkqhkiG9w0BCQQxFgQUeWs3faRr LhUdY0BXGUg4M0oxOnMwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAQNu/mdMMJGHEJSDsZc1ZGZN8sxHEJfUgjHArMeas yKP1BG6CxE8kpUsMuHvXpVq7bV1V/kbbo8944h0EP7MNZsFot6TMnbzOldjUSajG/A7NYb+QatdP JleUMcM+N3LiF2iS0oIwfN1nEqPlYb/3mggOhOjuPsUKJtTTG1FgrojGppCdfYF+ftGe4inWbr1N fOyiynkPe6biyCwKw1kV0jhvM+Z78yuGtT0RgInMfSOsFuVMFTxkpD38f1gQqZ7AWrAdS1rX3iFQ R6W2N6pybPobD+1riU8NKVzBn4sHGhfI0QlrGXXzTpl61NI5Cz5NkEUw9eW2yrZOcYldp2xklgAA AAAAAA== --Apple-Mail=_C1B55A47-2D71-418E-BDDD-1887D6F4CB6C-- From ppatterson@salesforce.com Wed Dec 4 16:02:00 2013 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 55E631AE165 for ; Wed, 4 Dec 2013 16:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 npPemRriD-YK for ; Wed, 4 Dec 2013 16:01:58 -0800 (PST) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id D7A601ADFBD for ; Wed, 4 Dec 2013 16:01:57 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id oz11so12651683veb.7 for ; Wed, 04 Dec 2013 16:01:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Gn9VjGV0t3VoF9N5BRKg0WFgXFeENUajQBJyHGMPtRI=; b=gsWTUvel3By8cYXsFtwhHwnelMpbO6hhJObZXlMl/sr1Lq1I06PMskRWyOisxrrGQO Fl0SqVhPa11bPYX6LAztoP5q/Mc12m6RSs5p7k8zabc+4j78B3ZS9jXvR5bclHoWnOKR InqB8wiZMUDoQiAvzaLaJ3L1npwYGTPdscZ0Ox7l6oideC0OAHl7gTJRvss/fRmaYxPt eivwJTSm7SlA7v5HQGtY08eoW0r+9rEXnkrq8HMioQa+dq+c66ZPTtwvr0xEAlwMtknM M9melH7iWrJ/CUS2HDMzbafuMwe/Lm31xOWEJm8jNzcmixmXzVSX/zBxzXuauCMWDz2s I5Sw== X-Gm-Message-State: ALoCoQnX3hQOKTAhun0Y9g4EKajd+Umd2z4aL071yinbNetxOjjkqqlnrsUEyixVpyqZX/WRjO0g MIME-Version: 1.0 X-Received: by 10.221.37.9 with SMTP id tc9mr161652vcb.39.1386201714196; Wed, 04 Dec 2013 16:01:54 -0800 (PST) Received: by 10.58.135.101 with HTTP; Wed, 4 Dec 2013 16:01:54 -0800 (PST) In-Reply-To: <35C05D8E-7772-4052-B8C8-A8E1A4A7DCE7@ve7jtb.com> References: <35C05D8E-7772-4052-B8C8-A8E1A4A7DCE7@ve7jtb.com> Date: Wed, 4 Dec 2013 16:01:54 -0800 Message-ID: From: Pat Patterson To: John Bradley Content-Type: multipart/alternative; boundary=001a11337ed4c3509004ecbe3cc0 Cc: oauth Subject: Re: [OAUTH-WG] Scopes in access token response 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: Thu, 05 Dec 2013 00:02:00 -0000 --001a11337ed4c3509004ecbe3cc0 Content-Type: text/plain; charset=ISO-8859-1 For what it's worth, we pass back a space-separated list in the response: { "id":" https://login.salesforce.com/id/00Dd0000000f6kcEAA/005d0000001kTmOAAU", "issued_at":"1386201559129", *"scope":"id api refresh_token",* "instance_url":"https://aloha.my.salesforce.com", "refresh_token":"5Ae...vDy", "signature":"5cN...mw=", "access_token":"00D...1aI" } Cheers, Pat -- Pat Patterson | Developer Evangelist Architect | http://about.me/patpatterson On Wed, Dec 4, 2013 at 12:06 PM, John Bradley wrote: > Per Sec 3.3 and Appendix A.4 > > scope is a space SP separated list of scope-token which are 1*NQCHAR > > So query encoded it looks like &scope=openid%20profile%20email (you would > be sending it in a POST form encoded to the token endpoint in your case) > and the response will be JSON: > { > "access_token":"2YotnFZFEjr1zCsicMWpAA", > "token_type":"example", > "expires_in":3600, > "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", > "scope":"openid profile email" > } > > Yes the examples probably should have included scope but it is clear from > the normative text. > > John B. > > On Dec 3, 2013, at 8:55 AM, Andreas Kohn wrote: > > > Hi, > > > > the current RFC for OAuth 2.0 (http://www.rfc-editor.org/rfc/rfc6749.txt) > is very unclear on *how* to return the scope in the access token response > if there are multiple scopes requested/returned. > > > > Could someone please clarify whether the scopes are supposed to be > returned as > > 1. space separated string value (i.e. in the same syntax in which they > came in), or > > 2. as JSON array (looks most "JSON-y"), or > > 3. in another format (for example github uses ',') > > > > There is a related question on stackoverflow: > http://stackoverflow.com/questions/13290994/how-should-approved-scopes-be-returned-from-an-oauth2-0 > > > > > > Regards, > > -- > > Andreas > > > > > > > > _______________________________________________ > > 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 > > --001a11337ed4c3509004ecbe3cc0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For what it's worth, we pass back a space-separated li= st in the response:

{
=A0 "issued_at":"1386201559129",
=A0 = "scope":"id api refresh_token",
=A0 "= ;instance_url":"https= ://aloha.my.salesforce.com",
=A0 "refresh_token":"5Ae...vDy",
=A0 &qu= ot;signature":"5cN...mw=3D",
=A0 "access_toke= n":"00D...1aI"
}

Cheers,

Pat

--=A0

Pat Patterson |=A0Developer Evang= elist Architect | http://about.me/patpatterson



On Wed, Dec 4, 2013 at 12:06 PM, John Br= adley <ve7jtb@ve7jtb.com> wrote:
Per Sec 3.3 and Appendix A.4

scope is a space SP separated list of scope-token which are 1*NQCHAR

So query encoded it looks like &scope=3Dopenid%20profile%20email (you w= ould be sending it in a POST form encoded to the token endpoint in your cas= e)
and the response will be JSON:
{
=A0 =A0"access_token":"2YotnFZFEjr1zCsicMWpAA",
=A0 =A0"token_type":"example",
=A0 =A0"expires_in":3600,
=A0 =A0"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
=A0 =A0"scope":"openid profile email"
=A0}

Yes the examples probably should have included scope but it is clear from t= he normative text.

John B.

On Dec 3, 2013, at 8:55 AM, Andreas Kohn <andreas.kohn@gmail.com> wrote:

> Hi,
>
> the current RFC for OAuth 2.0 (http://www.rfc-editor.org/rfc/rfc6749.txt<= /a>) is very unclear on *how* to return the scope in the access token respo= nse if there are multiple scopes requested/returned.
>
> Could someone please clarify whether the scopes are supposed to be ret= urned as
> 1. space separated string value (i.e. in the same syntax in which they= came in), or
> 2. as JSON array (looks most "JSON-y"), or
> 3. in another format (for example github uses ',')
>
> There is a related question on stackoverflow: http://stackoverflow.com/questions/13290994/= how-should-approved-scopes-be-returned-from-an-oauth2-0
>
>
> Regards,
> --
> Andreas
>
>
>
> __________________= _____________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--001a11337ed4c3509004ecbe3cc0-- From torsten@lodderstedt.net Wed Dec 4 22:07:24 2013 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 4879D1AE373 for ; Wed, 4 Dec 2013 22:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 JAft_hTneTgu for ; Wed, 4 Dec 2013 22:07:20 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) by ietfa.amsl.com (Postfix) with ESMTP id 15FBA1AE1FC for ; Wed, 4 Dec 2013 22:07:19 -0800 (PST) Received: from [91.2.77.12] (helo=android-60db911877f02c67.fritz.box) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1VoS5j-0003oN-Ds; Thu, 05 Dec 2013 07:07:15 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <35C05D8E-7772-4052-B8C8-A8E1A4A7DCE7@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----G52HV3PQY3HKBELLLJKRXU803UJUHA" From: Torsten Lodderstedt Date: Thu, 05 Dec 2013 07:07:13 +0100 To: Pat Patterson , John Bradley Message-ID: <0488be5b-4377-4c9c-ae5b-420688f0a651@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth Subject: Re: [OAUTH-WG] Scopes in access token response 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: Thu, 05 Dec 2013 06:07:24 -0000 ------G52HV3PQY3HKBELLLJKRXU803UJUHA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Pat, out of couriosity: what is the meaning of the "refresh_token" scope value? regards, Torsten. Pat Patterson schrieb: >For what it's worth, we pass back a space-separated list in the >response: > >{ > "id":" >https://login.salesforce.com/id/00Dd0000000f6kcEAA/005d0000001kTmOAAU", > "issued_at":"1386201559129", > *"scope":"id api refresh_token",* > "instance_url":"https://aloha.my.salesforce.com", > "refresh_token":"5Ae...vDy", > "signature":"5cN...mw=", > "access_token":"00D...1aI" >} > >Cheers, > >Pat > >-- > >Pat Patterson | Developer Evangelist Architect | >http://about.me/patpatterson > > >On Wed, Dec 4, 2013 at 12:06 PM, John Bradley >wrote: > >> Per Sec 3.3 and Appendix A.4 >> >> scope is a space SP separated list of scope-token which are 1*NQCHAR >> >> So query encoded it looks like &scope=openid%20profile%20email (you >would >> be sending it in a POST form encoded to the token endpoint in your >case) >> and the response will be JSON: >> { >> "access_token":"2YotnFZFEjr1zCsicMWpAA", >> "token_type":"example", >> "expires_in":3600, >> "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", >> "scope":"openid profile email" >> } >> >> Yes the examples probably should have included scope but it is clear >from >> the normative text. >> >> John B. >> >> On Dec 3, 2013, at 8:55 AM, Andreas Kohn >wrote: >> >> > Hi, >> > >> > the current RFC for OAuth 2.0 >(http://www.rfc-editor.org/rfc/rfc6749.txt) >> is very unclear on *how* to return the scope in the access token >response >> if there are multiple scopes requested/returned. >> > >> > Could someone please clarify whether the scopes are supposed to be >> returned as >> > 1. space separated string value (i.e. in the same syntax in which >they >> came in), or >> > 2. as JSON array (looks most "JSON-y"), or >> > 3. in another format (for example github uses ',') >> > >> > There is a related question on stackoverflow: >> >http://stackoverflow.com/questions/13290994/how-should-approved-scopes-be-returned-from-an-oauth2-0 >> > >> > >> > Regards, >> > -- >> > Andreas >> > >> > >> > >> > _______________________________________________ >> > 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 >> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth ------G52HV3PQY3HKBELLLJKRXU803UJUHA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Pat,

out of couriosity: what is the meaning of the "refresh_token" scope value?

regards,
Torsten.



Pat Patterson <ppatterson@salesforce.com> schrieb:
For what it's worth, we pass back a space-separated list in the response:

{
  "issued_at":"1386201559129",
  "scope":"id api refresh_token",
  "instance_url":"https://aloha.my.salesforce.com",
  "refresh_token":"5Ae...vDy",
  "signature":"5cN...mw=",
  "access_token":"00D...1aI"
}

Cheers,

Pat

-- 

Pat Patterson | Developer Evangelist Architect | http://about.me/patpatterson



On Wed, Dec 4, 2013 at 12:06 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Per Sec 3.3 and Appendix A.4

scope is a space SP separated list of scope-token which are 1*NQCHAR

So query encoded it looks like &scope=openid%20profile%20email (you would be sending it in a POST form encoded to the token endpoint in your case)
and the response will be JSON:
{
   "access_token":"2YotnFZFEjr1zCsicMWpAA",
   "token_type":"example",
   "expires_in":3600,
   "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
   "scope":"openid profile email"
 }

Yes the examples probably should have included scope but it is clear from the normative text.

John B.

On Dec 3, 2013, at 8:55 AM, Andreas Kohn <andreas.kohn@gmail.com> wrote:

> Hi,
>
> the current RFC for OAuth 2.0 (http://www.rfc-editor.org/rfc/rfc6749.txt) is very unclear on *how* to return the scope in the access token response if there are multiple scopes requested/returned.
>
> Could someone please clarify whether the scopes are supposed to be returned as
> 1. space separated string value (i.e. in the same syntax in which they came in), or
> 2. as JSON array (looks most "JSON-y"), or
> 3. in another format (for example github uses ',')
>
> There is a related question on stackoverflow: http://stackoverflow.com/questions/13290994/how-should-approved-scopes-be-returned-from-an-oauth2-0
>
>
> Regards,
> --
> Andreas
>
>
>
> _______________________________________________
> 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



OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------G52HV3PQY3HKBELLLJKRXU803UJUHA-- From ppatterson@salesforce.com Thu Dec 5 13:24:28 2013 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 5E32B1ADDBD for ; Thu, 5 Dec 2013 13:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 bhja_UlAWMl5 for ; Thu, 5 Dec 2013 13:24:26 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id C7D841ACCDE for ; Thu, 5 Dec 2013 13:24:25 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id ia6so13891524vcb.32 for ; Thu, 05 Dec 2013 13:24:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NaoWnmhMA5yg/LTF+0kqGI4xCGO8UJqgRFJsRscsjRc=; b=XWAKbPmAuWjm2n1Op4v7Cm6hbqENBhDCt7aIMnVLWGTlik5dfOQMvCppyWS5rAJnjA SrtKn8qaFxWezY7q/DOPT2rWtJ5Ff3VsqYs/11sqpgzCN1v6/n/dZ3151KTAwLiGQ0W4 O0EZVHXr3Wyxa9pGYMDUymaSvWygTXbgnckFtuupv9ONtY6i2+G7fVxV8HxivvD3zyfh VNZldsxbr9RUtb9hTI5kq/8dxM0FT01XJZCvb945Z3YD2NO9GgbdZ+ND9u8LHZ9cMqA9 iimFTH7sndphgl03rbTCAYK4ugq8+xC7atg+KQh+dNntU26RH9f4QRVh4isuVFYYF+l1 ETIg== X-Gm-Message-State: ALoCoQkfKIebByLD/mPKyAZt+iePiFYKms6j1FbTS62HdINqkoDcSI5uT56vWdDKYugJQXqrgkJc MIME-Version: 1.0 X-Received: by 10.58.11.73 with SMTP id o9mr77963veb.8.1386278662014; Thu, 05 Dec 2013 13:24:22 -0800 (PST) Received: by 10.58.135.101 with HTTP; Thu, 5 Dec 2013 13:24:21 -0800 (PST) In-Reply-To: <0488be5b-4377-4c9c-ae5b-420688f0a651@email.android.com> References: <35C05D8E-7772-4052-B8C8-A8E1A4A7DCE7@ve7jtb.com> <0488be5b-4377-4c9c-ae5b-420688f0a651@email.android.com> Date: Thu, 5 Dec 2013 13:24:21 -0800 Message-ID: From: Pat Patterson To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=047d7b2ed34135cecc04ecd02765 Cc: oauth Subject: Re: [OAUTH-WG] Scopes in access token response 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: Thu, 05 Dec 2013 21:24:28 -0000 --047d7b2ed34135cecc04ecd02765 Content-Type: text/plain; charset=ISO-8859-1 It means 'issue me (the client app) with a refresh token' - see https://help.salesforce.com/apex/HTViewHelpDoc?id=remoteaccess_oauth_scopes.htm&language=enand https://help.salesforce.com/apex/HTViewHelpDoc?id=remoteaccess_oauth_refresh_token_flow.htm&language=en Cheers, Pat -- Pat Patterson | Developer Evangelist Architect | http://about.me/patpatterson On Wed, Dec 4, 2013 at 10:07 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Pat, > > out of couriosity: what is the meaning of the "refresh_token" scope value? > > regards, > Torsten. > > > > Pat Patterson schrieb: > >> For what it's worth, we pass back a space-separated list in the response: >> >> { >> "id":" >> https://login.salesforce.com/id/00Dd0000000f6kcEAA/005d0000001kTmOAAU", >> "issued_at":"1386201559129", >> *"scope":"id api refresh_token",* >> "instance_url":"https://aloha.my.salesforce.com", >> "refresh_token":"5Ae...vDy", >> "signature":"5cN...mw=", >> "access_token":"00D...1aI" >> } >> >> Cheers, >> >> Pat >> >> -- >> >> Pat Patterson | Developer Evangelist Architect | >> http://about.me/patpatterson >> >> >> On Wed, Dec 4, 2013 at 12:06 PM, John Bradley wrote: >> >>> Per Sec 3.3 and Appendix A.4 >>> >>> scope is a space SP separated list of scope-token which are 1*NQCHAR >>> >>> So query encoded it looks like &scope=openid%20profile%20email (you >>> would be sending it in a POST form encoded to the token endpoint in your >>> case) >>> and the response will be JSON: >>> { >>> "access_token":"2YotnFZFEjr1zCsicMWpAA", >>> "token_type":"example", >>> "expires_in":3600, >>> "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", >>> "scope":"openid profile email" >>> } >>> >>> Yes the examples probably should have included scope but it is clear >>> from the normative text. >>> >>> John B. >>> >>> On Dec 3, 2013, at 8:55 AM, Andreas Kohn wrote: >>> >>> > Hi, >>> > >>> > the current RFC for OAuth 2.0 ( >>> http://www.rfc-editor.org/rfc/rfc6749.txt) is very unclear on *how* to >>> return the scope in the access token response if there are multiple scopes >>> requested/returned. >>> > >>> > Could someone please clarify whether the scopes are supposed to be >>> returned as >>> > 1. space separated string value (i.e. in the same syntax in which they >>> came in), or >>> > 2. as JSON array (looks most "JSON-y"), or >>> > 3. in another format (for example github uses ',') >>> > >>> > There is a related question on stackoverflow: >>> http://stackoverflow.com/questions/13290994/how-should-approved-scopes-be-returned-from-an-oauth2-0 >>> > >>> > >>> > Regards, >>> > -- >>> > Andreas >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 >>> >>> >> ------------------------------ >> >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> --047d7b2ed34135cecc04ecd02765 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Cheers,

Pat

--=A0

Pat Patterson |=A0Devel= oper Evangelist Architect | http://about.me/patpatterson



On Wed, Dec 4, 2013 at 10:07 PM, Torsten= Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Pat,

out of couriosity: what is the meaning of the "refresh_token" sco= pe value?

regards,
Torsten.



Pat Patterson <ppatterson@salesforce.com> schrieb:
For what it's worth, we pass back a space-separated li= st in the response:

{
=A0 "issued_at":"1386201559129",
=A0 = "scope":"id api refresh_token",
=A0 "= ;instance_url":"https://aloha.my.salesforce.com",
=A0 "refresh_token":"5Ae...vDy",
=A0 &qu= ot;signature":"5cN...mw=3D",
=A0 "access_toke= n":"00D...1aI"
}

Cheers,

Pat

--=A0

Pat Patterson |=A0Developer Evang= elist Architect | http://about.me/patpatterson



On Wed, Dec 4, 2013 at 12:06 PM, John Br= adley <ve7jtb@ve7jtb.com> wrote:
Per Sec 3.3 and Appendix A.4

scope is a space SP separated list of scope-token which are 1*NQCHAR

So query encoded it looks like &scope=3Dopenid%20profile%20email (you w= ould be sending it in a POST form encoded to the token endpoint in your cas= e)
and the response will be JSON:
{
=A0 =A0"access_token":"2YotnFZFEjr1zCsicMWpAA",
=A0 =A0"token_type":"example",
=A0 =A0"expires_in":3600,
=A0 =A0"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
=A0 =A0"scope":"openid profile email"
=A0}

Yes the examples probably should have included scope but it is clear from t= he normative text.

John B.
> _______________________________________________<= br> > OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


OAuth@ietf.org
https://www.ietf.org/mailman/listinf= o/oauth


--047d7b2ed34135cecc04ecd02765-- From andreas.kohn@gmail.com Thu Dec 5 13:44:03 2013 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 7411A1AE1BE for ; Thu, 5 Dec 2013 13:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 RkoHoh-iv6Rv for ; Thu, 5 Dec 2013 13:43:58 -0800 (PST) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id B53BD1AC3DA for ; Thu, 5 Dec 2013 13:43:58 -0800 (PST) Received: by mail-yh0-f49.google.com with SMTP id z20so13009971yhz.8 for ; Thu, 05 Dec 2013 13:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:in-reply-to:references:from:to:cc :subject:content-type; bh=Fo6D/Y13FMUCppxtiyu8AxaXACxGnfKETnuyJp3+1cQ=; b=gxIlay2bB3it/EWFHISp2YbH5MRovpuvC57/dzE+hNCc50VLtIkWpZySO07QTQSLD5 A7KcCdyzZH5cbydSWyuVTRF98ttOitygpkWTPjQADGxBKYSCeArQ9/sJSyUUS5ElOGjU fvEee6TI/Ztea3uoKvP9XuF73Bn8I+lNBq80UW2flUX50nTFjZwnfHAea1ybwniSk4VM M5rV6OWT1ZD5YUrjrel+BaCifCBM8zNz26kZ96qUP/cwmyT0q938abaWINy1rnovsKmL ljKPyuhQIjgjOjlSmQZm9VBcMNT3JqL2QytZzlSRWffLzq2rQ4buLyYVYiec0+YhREGU 2bEg== X-Received: by 10.236.181.137 with SMTP id l9mr547270yhm.97.1386279835032; Thu, 05 Dec 2013 13:43:55 -0800 (PST) Received: from [127.0.0.1] (ec2-54-235-159-137.compute-1.amazonaws.com. [54.235.159.137]) by mx.google.com with ESMTPSA id h66sm93792189yhb.7.2013.12.05.13.43.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 13:43:53 -0800 (PST) MIME-Version: 1.0 X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) Date: Thu, 05 Dec 2013 13:43:53 -0800 (PST) Message-Id: <1386279833082.b39c048e@Nodemailer> In-Reply-To: References: X-Orchestra-Oid: 2F699FB1-FBE0-4035-B7B8-898898E93CF1 X-Orchestra-Sig: b8baeeb86e6ff9b55e4029a76681a153cc52beb5 X-Orchestra-Thrid: T8DD6812C-BF57-4C7E-8D0B-CEA5FD770671_1453401580139446917 X-Orchestra-Thrid-Sig: ccb1edc21006560e4a9f0ecf87fc48fba0041a98 X-Orchestra-Account: 07201ed2c1b5acbb977b5403be0a66fce3ced255 From: "Andreas Kohn" To: "Pat Patterson" Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1386279833904" Cc: oauth Subject: Re: [OAUTH-WG] Scopes in access token response 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: Thu, 05 Dec 2013 21:44:03 -0000 ------Nodemailer-0.5.0-?=_1-1386279833904 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=C2=A0 Thank you all for your answers.=C2=A0 I was asking mainly because I'm considering to use scopes for implementing = versioning in our API, and so was expecting to request multiple scopes = (each representing a known (subset of) the API), and check the response = which scopes have been made available to the client.=C2=A0 Best regards, -- Andreas On Thu, Dec 5, 2013 at 10:24 PM, Pat Patterson wrote: > It means 'issue me (the client app) with a refresh token' - see > https://help.salesforce.com/apex/HTViewHelpDoc=3Fid=3Dremoteaccess=5Foaut= h=5Fscopes.htm&language=3Denand > https://help.salesforce.com/apex/HTViewHelpDoc=3Fid=3Dremoteaccess=5Foaut= h=5Frefresh=5Ftoken=5Fflow.htm&language=3Den > Cheers, > Pat > --=20 > Pat Patterson | Developer Evangelist Architect | > http://about.me/patpatterson > On Wed, Dec 4, 2013 at 10:07 PM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: >> Hi Pat, >> >> out of couriosity: what is the meaning of the =22refresh=5Ftoken=22 = scope value=3F >> >> regards, >> Torsten. >> >> >> >> Pat Patterson schrieb: >> >>> For what it's worth, we pass back a space-separated list in the = response: >>> >>> { >>> =22id=22:=22 >>> https://login.salesforce.com/id/00Dd0000000f6kcEAA/005d0000001kTmOAAU= =22, >>> =22issued=5Fat=22:=221386201559129=22, >>> *=22scope=22:=22id api refresh=5Ftoken=22,* >>> =22instance=5Furl=22:=22https://aloha.my.salesforce.com=22, >>> =22refresh=5Ftoken=22:=225Ae...vDy=22, >>> =22signature=22:=225cN...mw=3D=22, >>> =22access=5Ftoken=22:=2200D...1aI=22 >>> } >>> >>> Cheers, >>> >>> Pat >>> >>> -- >>> >>> Pat Patterson | Developer Evangelist Architect | >>> http://about.me/patpatterson >>> >>> >>> On Wed, Dec 4, 2013 at 12:06 PM, John Bradley = wrote: >>> >>>> Per Sec 3.3 and Appendix A.4 >>>> >>>> scope is a space SP separated list of scope-token which are 1*NQCHAR >>>> >>>> So query encoded it looks like &scope=3Dopenid%20profile%20email (you >>>> would be sending it in a POST form encoded to the token endpoint in = your >>>> case) >>>> and the response will be JSON: >>>> { >>>> =22access=5Ftoken=22:=222YotnFZFEjr1zCsicMWpAA=22, >>>> =22token=5Ftype=22:=22example=22, >>>> =22expires=5Fin=22:3600, >>>> =22refresh=5Ftoken=22:=22tGzv3JOkF0XG5Qx2TlKWIA=22, >>>> =22scope=22:=22openid profile email=22 >>>> } >>>> >>>> Yes the examples probably should have included scope but it is clear >>>> from the normative text. >>>> >>>> John B. >>>> >>>> On Dec 3, 2013, at 8:55 AM, Andreas Kohn = wrote: >>>> >>>> > Hi, >>>> > >>>> > the current RFC for OAuth 2.0 ( >>>> http://www.rfc-editor.org/rfc/rfc6749.txt) is very unclear on *how* = to >>>> return the scope in the access token response if there are multiple = scopes >>>> requested/returned. >>>> > >>>> > Could someone please clarify whether the scopes are supposed to be >>>> returned as >>>> > 1. space separated string value (i.e. in the same syntax in which = they >>>> came in), or >>>> > 2. as JSON array (looks most =22JSON-y=22), or >>>> > 3. in another format (for example github uses ',') >>>> > >>>> > There is a related question on stackoverflow: >>>> http://stackoverflow.com/questions/13290994/how-should-approved-scopes= -be-returned-from-an-oauth2-0 >>>> > >>>> > >>>> > Regards, >>>> > -- >>>> > Andreas >>>> > >>>> > >>>> > >>>> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= >>>> > OAuth mailing list >>>> > OAuth@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >>>> 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 >>> >>> ------Nodemailer-0.5.0-?=_1-1386279833904 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Thank you all for your answers.=C2=A0

I was asking mainly because I'm considering to use scopes for = implementing versioning in our API, and so was expecting to request = multiple scopes (each representing a known (subset of) the API), and check = the response which scopes have been made available to the client.= =C2=A0

Best regards,
--
Andreas




On Thu, Dec 5, 2013 at 10:24 PM= , Pat Patterson <ppatterson@salesforce.= com> wrote:


Cheers,

Pat

--=C2=A0

Pat Patterson |=C2=A0Developer Evangelist Architect | http://about.= me/patpatterson



On Wed, Dec 4, 2013 at 10:07 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:
Hi Pat,

out of couriosity: what is the meaning of the =22refresh=5Ftoken=22 scope = value=3F

regards,
Torsten.



Pat Patterson <ppatterson@salesforce.com> schrieb:
For what it's worth, we pass back a space-separated = list in the response:

{
=C2=A0 =22issued=5Fat=22:=221386201559129=22,
=C2=A0 =22scope=22:=22id api refresh=5Ftoken=22,
=C2=A0 =22instance=5Furl=22:=22https://aloha.my.salesforce.com=22,
=C2=A0 =22refresh=5Ftoken=22:=225Ae...vDy=22,
=C2=A0 =22signature=22:=225cN...mw=3D=22,
=C2=A0 =22access=5Ftoken=22:=2200D...1aI=22
}

Cheers,

Pat

--=C2=A0

Pat Patterson |=C2=A0Developer Evangelist Architect | http://about.= me/patpatterson



On Wed, Dec 4, 2013 at 12:06 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
Per Sec 3.3 and Appendix A.4

scope is a space SP separated list of scope-token which are = 1*NQCHAR

So query encoded it looks like &scope=3Dopenid%20profile%20email (you = would be sending it in a POST form encoded to the token endpoint in your = case)
and the response will be JSON:
{
=C2=A0 =C2=A0=22access=5Ftoken=22:=222YotnFZFEjr1zCsicMWpAA=22,
=C2=A0 =C2=A0=22token=5Ftype=22:=22example=22,
=C2=A0 =C2=A0=22expires=5Fin=22:3600,
=C2=A0 =C2=A0=22refresh=5Ftoken=22:=22tGzv3JOkF0XG5Qx2TlKWIA=22,
=C2=A0 =C2=A0=22scope=22:=22openid profile email=22
=C2=A0}

Yes the examples probably should have included scope but it is clear from = the normative text.

John B.

On Dec 3, 2013, at 8:55 AM, Andreas Kohn <andreas.kohn@gmail.com> wrote:

> Hi,
>
> the current RFC for OAuth 2.0 (http://www.rfc-editor.org/rfc/rfc6749.txt) is = very unclear on *how* to return the scope in the access token response if = there are multiple scopes requested/returned.
>
> Could someone please clarify whether the scopes are supposed to be = returned as
> 1. space separated string value (i.e. in the same syntax in which they= came in), or
> 2. as JSON array (looks most =22JSON-y=22), or
> 3. in another format (for example github uses ',')
>
> There is a related question on stackoverflow: http://stackoverflow.= com/questions/13290994/how-should-approved-scopes-be-returned-from-an-oauth= 2-0
>
>
> Regards,
> --
> Andreas
>
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> OAuth mailing list
> OAuth@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/oauth


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F OAuth mailing list
OAuth@ietf.= org
http= s://www.ietf.org/mailman/listinfo/oauth



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


------Nodemailer-0.5.0-?=_1-1386279833904-- From torsten@lodderstedt.net Sun Dec 8 08:05:47 2013 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 81F6B1ADFC9 for ; Sun, 8 Dec 2013 08:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 Pr3Fgy2pYxx1 for ; Sun, 8 Dec 2013 08:05:44 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id C62291ADFC7 for ; Sun, 8 Dec 2013 08:05:43 -0800 (PST) Received: from [79.253.62.208] (helo=[192.168.71.64]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1VpgrS-0007KI-0t; Sun, 08 Dec 2013 17:05:38 +0100 Message-ID: <52A498D1.5020803@lodderstedt.net> Date: Sun, 08 Dec 2013 17:05:37 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Pat Patterson References: <35C05D8E-7772-4052-B8C8-A8E1A4A7DCE7@ve7jtb.com> <0488be5b-4377-4c9c-ae5b-420688f0a651@email.android.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010802010106070508060706" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth Subject: Re: [OAUTH-WG] Scopes in access token response 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: Sun, 08 Dec 2013 16:05:47 -0000 This is a multi-part message in MIME format. --------------010802010106070508060706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Pat, sounds reasonable for the scope parameter of the access token request. As your example is an access token response, I would expect the scope parameter to contain the scope values associated with the access token. regards, Torsten. Am 05.12.2013 22:24, schrieb Pat Patterson: > It means 'issue me (the client app) with a refresh token' - see > https://help.salesforce.com/apex/HTViewHelpDoc?id=remoteaccess_oauth_scopes.htm&language=en > and > https://help.salesforce.com/apex/HTViewHelpDoc?id=remoteaccess_oauth_refresh_token_flow.htm&language=en > > Cheers, > > Pat > > -- > > Pat Patterson | Developer Evangelist Architect | > http://about.me/patpatterson > > > > On Wed, Dec 4, 2013 at 10:07 PM, Torsten Lodderstedt > > wrote: > > Hi Pat, > > out of couriosity: what is the meaning of the "refresh_token" > scope value? > > regards, > Torsten. > > > > Pat Patterson > schrieb: > > For what it's worth, we pass back a space-separated list in > the response: > > { > > "id":"https://login.salesforce.com/id/00Dd0000000f6kcEAA/005d0000001kTmOAAU", > "issued_at":"1386201559129", > *"scope":"id api refresh_token",* > "instance_url":"https://aloha.my.salesforce.com", > "refresh_token":"5Ae...vDy", > "signature":"5cN...mw=", > "access_token":"00D...1aI" > } > > Cheers, > > Pat > > -- > > Pat Patterson | Developer Evangelist Architect | > http://about.me/patpatterson > > > > On Wed, Dec 4, 2013 at 12:06 PM, John Bradley > > wrote: > > Per Sec 3.3 and Appendix A.4 > > scope is a space SP separated list of scope-token which > are 1*NQCHAR > > So query encoded it looks like > &scope=openid%20profile%20email (you would be sending it > in a POST form encoded to the token endpoint in your case) > and the response will be JSON: > { > "access_token":"2YotnFZFEjr1zCsicMWpAA", > "token_type":"example", > "expires_in":3600, > "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", > "scope":"openid profile email" > } > > Yes the examples probably should have included scope but > it is clear from the normative text. > > John B. > > On Dec 3, 2013, at 8:55 AM, Andreas Kohn > > > wrote: > > > Hi, > > > > the current RFC for OAuth 2.0 > (http://www.rfc-editor.org/rfc/rfc6749.txt) is very > unclear on *how* to return the scope in the access token > response if there are multiple scopes requested/returned. > > > > Could someone please clarify whether the scopes are > supposed to be returned as > > 1. space separated string value (i.e. in the same syntax > in which they came in), or > > 2. as JSON array (looks most "JSON-y"), or > > 3. in another format (for example github uses ',') > > > > There is a related question on stackoverflow: > http://stackoverflow.com/questions/13290994/how-should-approved-scopes-be-returned-from-an-oauth2-0 > > > > > > Regards, > > -- > > Andreas > > > > > > > > _______________________________________________ > > 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 > > > ------------------------------------------------------------------------ > > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --------------010802010106070508060706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Pat,

sounds reasonable for the scope parameter of the access token request. As your example is an access token response, I would expect the scope parameter to contain the scope values associated with the access token.

regards,
Torsten.

Am 05.12.2013 22:24, schrieb Pat Patterson:

Cheers,

Pat

-- 

Pat Patterson | Developer Evangelist Architect | http://about.me/patpatterson



On Wed, Dec 4, 2013 at 10:07 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Pat,

out of couriosity: what is the meaning of the "refresh_token" scope value?

regards,
Torsten.



Pat Patterson <ppatterson@salesforce.com> schrieb:
For what it's worth, we pass back a space-separated list in the response:

{
  "issued_at":"1386201559129",
  "scope":"id api refresh_token",
  "instance_url":"https://aloha.my.salesforce.com",
  "refresh_token":"5Ae...vDy",
  "signature":"5cN...mw=",
  "access_token":"00D...1aI"
}

Cheers,

Pat

-- 

Pat Patterson | Developer Evangelist Architect | http://about.me/patpatterson



On Wed, Dec 4, 2013 at 12:06 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Per Sec 3.3 and Appendix A.4

scope is a space SP separated list of scope-token which are 1*NQCHAR

So query encoded it looks like &scope=openid%20profile%20email (you would be sending it in a POST form encoded to the token endpoint in your case)
and the response will be JSON:
{
   "access_token":"2YotnFZFEjr1zCsicMWpAA",
   "token_type":"example",
   "expires_in":3600,
   "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
   "scope":"openid profile email"
 }

Yes the examples probably should have included scope but it is clear from the normative text.

John B.

On Dec 3, 2013, at 8:55 AM, Andreas Kohn <andreas.kohn@gmail.com> wrote:

> Hi,
>
> the current RFC for OAuth 2.0 (http://www.rfc-editor.org/rfc/rfc6749.txt) is very unclear on *how* to return the scope in the access token response if there are multiple scopes requested/returned.
>
> Could someone please clarify whether the scopes are supposed to be returned as
> 1. space separated string value (i.e. in the same syntax in which they came in), or
> 2. as JSON array (looks most "JSON-y"), or
> 3. in another format (for example github uses ',')
>
> There is a related question on stackoverflow: http://stackoverflow.com/questions/13290994/how-should-approved-scopes-be-returned-from-an-oauth2-0
>
>
> Regards,
> --
> Andreas
>
>
>
> _______________________________________________
> 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



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


--------------010802010106070508060706-- From internet-drafts@ietf.org Mon Dec 9 13:00:57 2013 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 03CC31AE0D9; Mon, 9 Dec 2013 13:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 RReQ_53vEz2Y; Mon, 9 Dec 2013 13:00:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E701AE578; Mon, 9 Dec 2013 13:00:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131209210054.4629.22134.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2013 13:00:54 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-13.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 21:00:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : Assertion Framework for OAuth 2.0 Client Authentication = and Authorization Grants Author(s) : Brian Campbell Chuck Mortimore Michael B. Jones Yaron Y. Goland Filename : draft-ietf-oauth-assertions-13.txt Pages : 22 Date : 2013-12-09 Abstract: This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-assertions-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-assertions-13 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Dec 9 13:04:55 2013 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 0EA7E1AE580; Mon, 9 Dec 2013 13:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JZJu5j4fG7te; Mon, 9 Dec 2013 13:04:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B76A91AE585; Mon, 9 Dec 2013 13:04:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131209210452.4629.87684.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2013 13:04:52 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bearer-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 21:04:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : JSON Web Token (JWT) Profile for OAuth 2.0 Client Authen= tication and Authorization Grants Author(s) : Michael B. Jones Brian Campbell Chuck Mortimore Filename : draft-ietf-oauth-jwt-bearer-07.txt Pages : 13 Date : 2013-12-09 Abstract: This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-bearer-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Dec 9 13:05:52 2013 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 135931AE591; Mon, 9 Dec 2013 13:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PC8MukI3GDkb; Mon, 9 Dec 2013 13:05:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EAF1AE595; Mon, 9 Dec 2013 13:05:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131209210549.30132.80556.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2013 13:05:49 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-18.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 21:05:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : SAML 2.0 Profile for OAuth 2.0 Client Authentication and= Authorization Grants Author(s) : Brian Campbell Chuck Mortimore Michael B. Jones Filename : draft-ietf-oauth-saml2-bearer-18.txt Pages : 20 Date : 2013-12-09 Abstract: This specification defines the use of a SAML 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-saml2-bearer-18 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bcampbell@pingidentity.com Mon Dec 9 13:30:10 2013 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 61BE41AE586 for ; Mon, 9 Dec 2013 13:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 WntusYFDu3Ea for ; Mon, 9 Dec 2013 13:30:07 -0800 (PST) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0808D1AE08B for ; Mon, 9 Dec 2013 13:30:06 -0800 (PST) Received: from mail-ie0-f176.google.com ([209.85.223.176]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKUqY2We8iVksAVuR2e4eJapeCpLe5Kpmy@postini.com; Mon, 09 Dec 2013 13:30:02 PST Received: by mail-ie0-f176.google.com with SMTP id at1so6972609iec.7 for ; Mon, 09 Dec 2013 13:30:01 -0800 (PST) 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:cc :content-type; bh=6k+6t/OE/1pcsSlYP9KijMMozGY9MdhGZiEzTXCNRGU=; b=Uw6afLKmwXOHpSJHuWjpG+qn+dWCywFY2cGYDPzKREEWQkZgXZSlbRjxcfbPF9U41t NV1n9w0QeYYFLfdpXIiytwR0apVyzhL9GgRiyP93QDqIPTmKnUl+s5G81WA7bN8cwAwf MQeCeju66n5esdiLsGseFE4wQfJ1AnEg+QiDnNjMDCQ5M4NiyV/r+o2LHWdPuaxxtd+K MshaVQ8ovXSGJE1fHbSGyOyQDXOao8I7yx+LY5Jqkjcm2pFnM1p3sQPiAyPoyUddZU5P rpjnLt7lqWV/ZuQodVrzvDMdQIlQZOuK6u0WaNFesMbhoQtRyXTq+V0qvuQ7WUbZaLwg tXcA== X-Gm-Message-State: ALoCoQlq7yXMnnPMbmSfl44bv7EVlTd8Y29aSnnxoWCcbrMozGas3On3ULj+/AieDbwS3eN2wYRwldHMisqFBRfGXRjTkfKygZKq6bFxzs++7tp3V5qHaho8t32oqJ3+zFaWWU+t1uF3Cc674IYUQOqiriLspEn+Dg== X-Received: by 10.50.119.4 with SMTP id kq4mr17634865igb.40.1386624601686; Mon, 09 Dec 2013 13:30:01 -0800 (PST) X-Received: by 10.50.119.4 with SMTP id kq4mr17634859igb.40.1386624601566; Mon, 09 Dec 2013 13:30:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Mon, 9 Dec 2013 13:29:31 -0800 (PST) From: Brian Campbell Date: Mon, 9 Dec 2013 14:29:31 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=089e013c6e4ad0b1a404ed20b2d5 Cc: "oauth-chairs@tools.ietf.org" Subject: [OAUTH-WG] New Assertion Drafts Published 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: Mon, 09 Dec 2013 21:30:10 -0000 --089e013c6e4ad0b1a404ed20b2d5 Content-Type: text/plain; charset=ISO-8859-1 New versions of all three OAuth related assertion documents have been published. Links to the htmlized drafts and change logs (mostly clarification resulting from Shepherd review in early November) are listed below. Thanks to Mike Jones for the preliminary review and updates/fixes. Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants http://tools.ietf.org/html/draft-ietf-oauth-assertions-13 draft-ietf-oauth-assertions-13 o Clean up language around subject per the subject part of http:// www.ietf.org/mail-archive/web/oauth/current/msg12155.html o Replace "Client Credentials flow" by "Client Credentials _Grant_" as suggested in http://www.ietf.org/mail-archive/web/oauth/current /msg12155.html o For consistency with SAML and JWT per http://www.ietf.org/mail- archive/web/oauth/current/msg12251.html and http://www.ietf.org/ mail-archive/web/oauth/current/msg12253.html Stated that "In the absence of an application profile specifying otherwise, compliant applications MUST compare the audience values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 ." o Added one-time use, maximum lifetime, and specific subject and attribute requirements to Interoperability Considerations. JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 draft-ietf-oauth-jwt-bearer-07 o Clean up language around subject per http://www.ietf.org/mail- archive/web/oauth/current/msg12250.html . o As suggested in http://www.ietf.org/mail-archive/web/oauth/current /msg12251.html stated that "In the absence of an application profile specifying otherwise, compliant applications MUST compare the audience values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 ." o Added one-time use, maximum lifetime, and specific subject and attribute requirements to Interoperability Considerations based on http://www.ietf.org/mail-archive/web/oauth/current/msg12252.html. o Remove "or its subject confirmation requirements cannot be met" text. o Reword security considerations and mention that replay protection is not mandated based on http://www.ietf.org/mail-archive/web/ oauth/current/msg12259.html . SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-18 draft-ietf-oauth-saml2-bearer-18 o Clean up language around subject per http://www.ietf.org/mail- archive/web/oauth/current/msg12254.html . o As suggested in http://www.ietf.org/mail-archive/web/oauth/current /msg12253.html stated that "In the absence of an application profile specifying otherwise, compliant applications MUST compare the audience/issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 ." o Clarify the potentially confusing language about the AS confirming the assertion http://www.ietf.org/mail-archive/web/oauth/current/ msg12255.html . o Combine the two items about AuthnStatement and drop the word presenter as discussed in http://www.ietf.org/mail-archive/web/ oauth/current/msg12257.html . o Added one-time use, maximum lifetime, and specific subject and attribute requirements to Interoperability Considerations based on http://www.ietf.org/mail-archive/web/oauth/current/msg12252.html. o Reword security considerations and mention that replay protection is not mandated based on http://www.ietf.org/mail-archive/web/ oauth/current/msg12259.html . --089e013c6e4ad0b1a404ed20b2d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
3D""Ne= w versions of all three OAuth related assertion documents have been published. Links to the htmlized drafts and change = logs (mostly clarification resulting from Shepherd review in early November= ) are listed below. Thanks to Mike Jones for the preliminary review and upd= ates/fixes.

Assertion Framework for OAuth 2.0 Client Authentication and Authorizati= on Grants
http://tools.ietf.org/html/draft-ietf-oauth-assertions-13

   draft-ietf-oauth-assertions-13

   o  Clean up language around subject per the subject part of http://
      www.ietf.org/mail-archive/web/oauth/current/msg12155.html

   o  Replace "Client Credentials flow" by "Client Credentia=
ls _Grant_"
      as suggested in http://www.ietf.org/mail-archive/web/oauth/current<=
/a>
      /msg12155.html

   o  For consistency with SAML and JWT per http://www.ietf.org/mail-
      archive/web/oauth/current/msg12251.html and http://www.ietf.o=
rg/
      mail-archive/web/oauth/current/msg12253.html Stated that "=
In the
      absence of an application profile specifying otherwise, compliant
      applications MUST compare the audience values using the Simple
      String Comparison method defined in Section=A06.2.1 of RFC 3986."

   o  Added one-time use, maximum lifetime, and specific subject and
      attribute requirements to Interoperability Considerations.

<= br>JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Aut= horization Grants
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07

   draft-ietf-oauth-jwt-bearer-07

   o  Clean up language around subject per http://www.ietf.org/mail-
      archive/web/oauth/current/msg12250.html.

   o  As suggested in http://www.ietf.org/mail-archive/web/oauth/current<=
/a>
      /msg12251.html stated that "In the absence of an applicati=
on
      profile specifying otherwise, compliant applications MUST compare
      the audience values using the Simple String Comparison method
      defined in Section=A06.2.1 of RFC 3986."

   o  Added one-time use, maximum lifetime, and specific subject and
      attribute requirements to Interoperability Considerations based on
      http://www.ietf.org/mail-archive/web/oauth/current/msg12252.html.

   o  Remove "or its subject confirmation requirements cannot be met&q=
uot;
      text.

   o  Reword security considerations and mention that replay protection
      is not mandated based on http://www.ietf.org/mail-archive/web/
      oauth/current/msg12259.html.


SAML 2.0 Profile for = OAuth 2.0 Client Authentication and Authorization Grants
http://tools.ietf.= org/html/draft-ietf-oauth-saml2-bearer-18
   draft-ietf-oauth-saml2-bearer-18

   o  Clean up language around subject per http://www.ietf.org/mail-
      archive/web/oauth/current/msg12254.html.

   o  As suggested in http://www.ietf.org/mail-archive/web/oauth/current<=
/a>
      /msg12253.html stated that "In the absence of an applicati=
on
      profile specifying otherwise, compliant applications MUST compare
      the audience/issuer values using the Simple String Comparison
      method defined in Section=A06.2.1 of RFC 3986."

   o  Clarify the potentially confusing language about the AS confirming
      the assertion http://www.ietf.org/mail-archive/web/oauth/current/
      msg12255.html.

   o  Combine the two items about AuthnStatement and drop the word
      presenter as discussed in http://www.ietf.org/mail-archive/web/
      oauth/current/msg12257.html.

   o  Added one-time use, maximum lifetime, and specific subject and
      attribute requirements to Interoperability Considerations based on
      http://www.ietf.org/mail-archive/web/oauth/current/msg12252.html.

   o  Reword security considerations and mention that replay protection
      is not mandated based on http://www.ietf.org/mail-archive/web/
      oauth/current/msg12259.html.

--089e013c6e4ad0b1a404ed20b2d5-- From gerdes@tzi.de Wed Dec 11 05:49:07 2013 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 D17641ADE7C; Wed, 11 Dec 2013 05:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] 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 SZ-07BSEa9s7; Wed, 11 Dec 2013 05:49:05 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 364A81ADDDA; Wed, 11 Dec 2013 05:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBBDksGc018161; Wed, 11 Dec 2013 14:46:55 +0100 (CET) Received: from [134.102.218.230] (dynamic-218-c.informatik.uni-bremen.de [134.102.218.230]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7D110C4B; Wed, 11 Dec 2013 14:46:54 +0100 (CET) Message-ID: <52A86CCE.3090906@tzi.de> Date: Wed, 11 Dec 2013 14:46:54 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "core@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org, dtls-iot@ietf.org, jose@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Invitation to New Non-WG Mailing List: Authentication and Authorization for Constrained Environments (ace) 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, 11 Dec 2013 13:49:08 -0000 Hi everybody, As a result of discussions in the CoRE WG in Berlin and Vancouver the new non-WG mailing list Authentication and Authorization for Constrained Environments (ace) was created. The purpose of this list is to organize interest in a group to define the charter for work on Authentication and Authorization for Constrained Environments. Our mailing list can be found at (1), existing work can be found at (2), and the draft charter can be found at (3). Please feel welcome to join the list and provide your feedback! Thanks, Kind Regards Kepeng & Stefanie (1)Mailing List https://www.ietf.org/mailman/listinfo/ace (2)Existing work: Use Cases: http://tools.ietf.org/id/draft-garcia-core-security http://tools.ietf.org/id/draft-greevenbosch-core-authreq http://tools.ietf.org/id/draft-seitz-core-sec-usecases Solutions http://tools.ietf.org/id/draft-gerdes-core-dcaf-authorize http://tools.ietf.org/id/draft-kang-core-secure-reconfiguration http://tools.ietf.org/id/draft-selander-core-access-control http://tools.ietf.org/id/draft-zhu-core-groupauth http://tools.ietf.org/id/draft-pporamba-dtls-certkey http://tools.ietf.org/id/draft-schmitt-two-way-authentication-for-iot http://tools.ietf.org/id/draft-seitz-core-security-modes (3)Draft Charter - Authentication and Authorization for Constrained Environment (ACE) The CoAP (Constrained Application Protocol) is a light-weight application layer protocol, especially suitable for applications such as smart energy, smart home, building automation, remote patient monitoring etc. Due to the nature of these applications, including a critical, unattended infrastructure and usage in the personal sphere, security and privacy protection are critical components. Currently, a problem with constrained devices is the realization of such secure communication. The devices only have limited resources such as memory, storage and transmission capacity. These constraints severely limit the security functions and communications the device can perform. Missing functionality includes authentication, which provides trust and ensures an entity is who it says it is, and authorization, which defines and enforces access rights for different clients. The ACE WG focuses on providing constrained devices with the necessary prerequisites to use REST operations in a secure way. Constrained devices will thus be enabled to authenticate communications from other (constrained or less-constrained) devices, to communicate securely with them and to verify their individual authorization to access specific resources. To achieve this, ACE will be able to employ an architecture with one or more trusted less-constrained devices which will relieve the constrained nodes from complex security related tasks (e.g. managing authorization policies and a large number of keys). ACE will use CoAP and employ security properties of DTLS whenever possible. The ACE WG has the following tasks: - Document the use cases and high-level requirements for secured communication between constrained devices. - Define certificate profiling (what kinds of certificates and which attributes are to be used). - Define a mechanism for authenticated and protected transfer of authorization information suitable for constrained device to constrained device communication. - Define an access ticket and authorization information format suitable for constrained devices. - Define bootstrapping for authorization information using the Resource Directory. From bcampbell@pingidentity.com Thu Dec 12 15:43:08 2013 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 BCDDE1AE00D for ; Thu, 12 Dec 2013 15:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 Y9C8YuazVV1u for ; Thu, 12 Dec 2013 15:43:06 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAF01AE068 for ; Thu, 12 Dec 2013 15:43:05 -0800 (PST) Received: from mail-ie0-f178.google.com ([209.85.223.178]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKUqpKBJRHLIi7u7hu3WV/m4G3N2Ltb+BZ@postini.com; Thu, 12 Dec 2013 15:43:00 PST Received: by mail-ie0-f178.google.com with SMTP id lx4so1802535iec.37 for ; Thu, 12 Dec 2013 15:42:59 -0800 (PST) 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=y+Pn+2dYj1xwjzQeK48XQWHh0cTtR8nAISWNHwduNBU=; b=JItJvxRwDkMdsHTTudnulnYaz69KKOpfXXGXDaGUFnp9ki+R+2MEdWG3S4N+ollmmM OzYiCV1lnhSfOTTSt0OZsqDV4iAMkNHZ0UynCxbua2O0ckXnwpk09osvZsWoMom6KPvg wpJFvfjx41pZAqp6fu4bFfD4IgJUy87ftEp6UJenPUWXh2HjKaLFAJcOANvKbW5GVma4 sqkqtm3TzVIFjsmTD7IY2oAWSpdCIlmlujinkjR4VfIh/XOJJdhoqF/F7y+mQGfL74rg zFNYGCtYGH9RkLsS0Co3BTqOVYS0DIKLvfvTlPzyKqOApFVVPQaNFOFIWQ6sGfcQKpmO zRCA== X-Gm-Message-State: ALoCoQkRQO7DLGyS5kkgx3euDj0xhvfrjyco1GYUnK3/e0qsV1M+QX0csg37l4/jzk29cP+xxjEcp6nRl4GtJ8m4KcOpR2Mc5Gp/k4KoRHT6y54/LEchYFv8LXKQ399Rbw61aG7r/koXsxoNTFH2KD5SDcipsd2C1w== X-Received: by 10.50.79.138 with SMTP id j10mr91198igx.2.1386891779823; Thu, 12 Dec 2013 15:42:59 -0800 (PST) X-Received: by 10.50.79.138 with SMTP id j10mr91194igx.2.1386891779727; Thu, 12 Dec 2013 15:42:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.245.233 with HTTP; Thu, 12 Dec 2013 15:42:29 -0800 (PST) From: Brian Campbell Date: Thu, 12 Dec 2013 16:42:29 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=089e0122ab74df833f04ed5ee7aa Subject: [OAUTH-WG] Question on RFC 7009 OAuth 2.0 Token Revocation 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: Thu, 12 Dec 2013 23:43:08 -0000 --089e0122ab74df833f04ed5ee7aa Content-Type: text/plain; charset=ISO-8859-1 The second paragraph of section 2 of RFC 7009 [1] says that the revocation endpoint must conform to the rules in section 3.1 of RFC 6749 (The OAuth 2.0 Authorization Framework) [2] but that section is about the *Authorization Endpoint*, which doesn't make much sense to me. The resource owner is involved with the authorization endpoint but not with the revocation endpoint. The authorization endpoint MUST accept GET and MAY accept POST while the revocation endpoint always accepts POST except for the JSONP support which is just a MAY for GET. There's also talk elsewhere in RFC 7009 about client authentication, which only happens at the token endpoint, not the authorization endpoint (note that the link in in 2.1 of RFC 7009 [3] that should go to 2.3 of RFC6749 actually links back to itself). Is the reference a mistake in RFC 7009? If not, could someone explain what the intent was there or what it really means? Thanks for any clarification! [1] http://tools.ietf.org/html/rfc7009#section-2 [2] http://tools.ietf.org/html/rfc6749#section-3.1 [3] http://tools.ietf.org/html/rfc7009#section-2.1 --089e0122ab74df833f04ed5ee7aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The second paragraph of section 2 of RFC 7009 [1= ] says that the revocation endpoint must conform to the rules in section 3.= 1 of RFC 6749 (The OAuth 2.0 Authorization Framework) [2] but that section = is about the *Authorization Endpoint*, which doesn't make much sense to= me. The resource owner is involved with the authorization endpoint but not= with the revocation endpoint. The authorization endpoint MUST accept GET a= nd MAY accept POST while the revocation endpoint always accepts POST except= for the JSONP support which is just a MAY for GET. There's also talk e= lsewhere in RFC 7009 about client authentication, which only happens at the= token endpoint, not the authorization endpoint (note that the link in in 2= .1 of RFC 7009 [3] that should go to 2.3 of RFC6749 actually links back to = itself).

Is the reference a mistake in RFC 7009? If not, could someone exp= lain what the intent was there or what it really means?

T= hanks for any clarification!
--089e0122ab74df833f04ed5ee7aa-- From sberyozkin@gmail.com Fri Dec 20 13:55:49 2013 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 648241AE1CA for ; Fri, 20 Dec 2013 13:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 CEUw95hVi_6h for ; Fri, 20 Dec 2013 13:55:44 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A263C1ACC87 for ; Fri, 20 Dec 2013 13:55:44 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id q58so2991869wes.5 for ; Fri, 20 Dec 2013 13:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MaNKngslfbvUjQX5Wok0xS4ae28MENCARPqoVCxZI3g=; b=ttUYnAmqSa1gc6cByi6HDTOoZXs9SW+g0ZNDwL/RTaTkLaV7lXivlDxkPADPmpSLkk UxD3BHKsLH/A/x/X/UZiivQ1S1jSgCgfpsp5nlc6s/A6LZXoU//4aDhvSJYvCTzGuGRg Y84mo1kLG4Y3xKhMtosLs8DCcf5CWDf5Dh3oB2PwAMtXXllVuOsTSGmqg4ovtrUDUocW TJgj78exdGeYAK33Ky3b5wx8fP1utAF4fxgvnb15VzKdNqbG7nKcy+8SAhAogIHhSNC3 6XvHqaZyZxd8MoUX6aWexeqD2fWUHhZTxBMeOmMvAq9vUXoDQjKhFx48Uie4z0ogami4 eNGg== X-Received: by 10.180.207.239 with SMTP id lz15mr9402299wic.28.1387576541913; Fri, 20 Dec 2013 13:55:41 -0800 (PST) Received: from [192.168.2.5] ([89.100.140.5]) by mx.google.com with ESMTPSA id fu1sm16689964wib.9.2013.12.20.13.55.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Dec 2013 13:55:41 -0800 (PST) Message-ID: <52B4BCD0.5080600@gmail.com> Date: Fri, 20 Dec 2013 21:55:28 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: oauth@ietf.org References: <20131019101348.9565.3370.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt 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: Fri, 20 Dec 2013 21:55:49 -0000 Hi IMHO the fact the transformation of the code_verifier is pluggable is a major improvement, and the whole text somehow reads much easier (few minor typos in the introduction). The only doubt is about the 'MUST' bit where the client is expected to figure out that the server supports this spec. Not a problem for me as I don't work on implementing a client, but it seems like it makes the whole process suddenly much more complex than may be it should be. Would it make sense to change 'MUST' to 'RECOMMENDED' and have the authorization service return a code_verifier_accepted or some similar response parameter, alongside with the 'code', instead ? Not really though, Cheers, Sergey On 19/10/13 11:15, Nat Sakimura wrote: > Incorporated the discussion at Berlin meeting and after in the ML. > > Best, > > Nat > > ---------- Forwarded message ---------- > From: ** > > Date: 2013/10/19 > Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt > To: Nat Sakimura >, John > Bradley >, > Naveen Agarwal > > > > > A new version of I-D, draft-sakimura-oauth-tcse-02.txt > has been successfully submitted by Nat Sakimura and posted to the > IETF repository. > > Filename: draft-sakimura-oauth-tcse > Revision: 02 > Title: OAuth Symmetric Proof of Posession for Code Extension > Creation date: 2013-10-19 > Group: Individual Submission > Number of pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt > Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse > Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02 > > Abstract: > The OAuth 2.0 public client utilizing authorization code grant is > susceptible to the code interception attack. This specification > describe a mechanism that acts as a control against this threat. > > > > > > 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 > . > > The IETF Secretariat > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From pranamcs@sg.ibm.com Sat Dec 21 12:03:54 2013 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 4206A1AE009 for ; Sat, 21 Dec 2013 12:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] 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 pAp1ZJbX74P5 for ; Sat, 21 Dec 2013 12:03:53 -0800 (PST) Received: from e23smtp09.au.ibm.com (e23smtp09.au.ibm.com [202.81.31.142]) by ietfa.amsl.com (Postfix) with ESMTP id A16DC1ADF63 for ; Sat, 21 Dec 2013 12:03:52 -0800 (PST) Received: from /spool/local by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 22 Dec 2013 06:03:47 +1000 Received: from d23dlp01.au.ibm.com (202.81.31.203) by e23smtp09.au.ibm.com (202.81.31.206) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sun, 22 Dec 2013 06:03:46 +1000 Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [9.190.234.120]) by d23dlp01.au.ibm.com (Postfix) with ESMTP id 0BAFB2CE802D for ; Sun, 22 Dec 2013 07:03:46 +1100 (EST) Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rBLJjK384129218 for ; Sun, 22 Dec 2013 06:45:21 +1100 Received: from d23av01.au.ibm.com (localhost [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rBLK3jVX011918 for ; Sun, 22 Dec 2013 07:03:45 +1100 Received: from d23ml125.sg.ibm.com (d23ml125.sg.ibm.com [9.127.37.179]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rBLK3iEk011912 for ; Sun, 22 Dec 2013 07:03:44 +1100 Auto-Submitted: auto-generated From: Codur Sreedhar Pranam To: oauth@ietf.org Message-ID: Date: Sun, 22 Dec 2013 04:00:59 +0800 X-MIMETrack: Serialize by Router on d23ml125/23/M/IBM(Release 8.5.3FP2HF29 | July 24, 2012) at 12/22/2013 04:01:00 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=C7BBF6DBDFFE72CA8f9e8a93df938690918cC7BBF6DBDFFE72CA" Content-Disposition: inline X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13122120-3568-0000-0000-000004B75F53 Subject: [OAUTH-WG] AUTO: Codur Sreedhar Pranam is out of the office (returning 01/08/2014) 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: Sat, 21 Dec 2013 20:03:54 -0000 --0__=C7BBF6DBDFFE72CA8f9e8a93df938690918cC7BBF6DBDFFE72CA Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 01/08/2014. Note: This is an automated response to your message "OAuth Digest, Vol= 62, Issue 11" sent on 12/22/2013 4:00:06. This is the only notification you will receive while this person is awa= y.= --0__=C7BBF6DBDFFE72CA8f9e8a93df938690918cC7BBF6DBDFFE72CA Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 01= /08/2014.




Note: Thi= s is an automated response to your message  "OAuth Digest, Vol 62, Issue 11"=  sen= t on 12/22/2013 4:00:06<= /b>.
=
This is t= he only notification you will receive while this person is away.= = --0__=C7BBF6DBDFFE72CA8f9e8a93df938690918cC7BBF6DBDFFE72CA-- From lukeh@padl.com Mon Dec 23 17:03:50 2013 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 9FD231AE351 for ; Mon, 23 Dec 2013 17:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 A5Pn_NtyZp7n for ; Mon, 23 Dec 2013 17:03:49 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 56BF11AE0F2 for ; Mon, 23 Dec 2013 17:03:49 -0800 (PST) Received: by us.padl.com with ESMTP id rBO13XI3014165; Mon, 23 Dec 2013 20:03:36 -0500 From: Luke Howard Content-Type: multipart/alternative; boundary="Apple-Mail=_E5E4A67D-9EA8-48E5-924B-9638CBBA4CAE" Message-Id: <62F725C1-050D-4C33-9C89-AA2E30CDD04E@padl.com> Date: Tue, 24 Dec 2013 12:03:41 +1100 To: oauth@ietf.org, dev-identity@lists.mozilla.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Subject: [OAUTH-WG] JWT Attribute Certificates 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: Tue, 24 Dec 2013 01:03:50 -0000 --Apple-Mail=_E5E4A67D-9EA8-48E5-924B-9638CBBA4CAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Seasons greetings! I've recently been working on adding support for selective claim = disclosure to Mozilla Persona. A component of this was defining a JWT = Attribute Certificate structure that can contain a set of claims bound = to a primary JWT. The following Internet Draft documents this: Name: draft-howard-jwt-attr-cert Revision: 00 Title: JWT Attribute Certificate (JAC) Document date: 2013-12-24 Group: Individual Submission Pages: 18 URL: = http://www.ietf.org/internet-drafts/draft-howard-jwt-attr-cert-00.txt Status: = https://datatracker.ietf.org/doc/draft-howard-jwt-attr-cert/ Htmlized: http://tools.ietf.org/html/draft-howard-jwt-attr-cert-00 Abstract: A JSON Web Token Attribute Certificate (JAC) contains additional claims, grouped by scope, to be presented alongside a primary JWT. -- Luke= --Apple-Mail=_E5E4A67D-9EA8-48E5-924B-9638CBBA4CAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Seasons greetings!


I've recently = been working on adding support for selective claim disclosure to Mozilla = Persona. A component of this was defining a JWT Attribute Certificate = structure that can contain a set of claims bound to a primary JWT. The = following Internet Draft documents = this:

Name: = draft-howard-jwt-attr-cert
Revision: = 00
Title: JWT Attribute Certificate (JAC)
Document date: = 2013-12-24
Group: Individual = Submission
Pages: 18
URL: =            http://www.ietf.org/internet-drafts/draft-howard-jwt-attr-cert-00.txt=
Status:         http= s://datatracker.ietf.org/doc/draft-howard-jwt-attr-cert/
Htmlized: =       http://t= ools.ietf.org/html/draft-howard-jwt-attr-cert-00


Abstract:<= br>  A JSON Web Token Attribute Certificate (JAC) contains = additional
  claims, grouped by scope, to be presented = alongside a primary JWT.

-- = Luke
= --Apple-Mail=_E5E4A67D-9EA8-48E5-924B-9638CBBA4CAE-- From manfred.steyer@gmx.net Tue Dec 24 13:38:50 2013 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 691701AE0DE for ; Tue, 24 Dec 2013 13:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] 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 NOG_popGjn7c for ; Tue, 24 Dec 2013 13:38:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 0239A1AE0C6 for ; Tue, 24 Dec 2013 13:38:48 -0800 (PST) Received: from IWINB07 ([88.117.41.104]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M6BKc-1VXguv1tfO-00y9d8 for ; Tue, 24 Dec 2013 22:38:43 +0100 From: "Manfred Steyer" To: Date: Tue, 24 Dec 2013 22:38:42 +0100 Message-ID: <001301cf00f0$845d1ec0$8d175c40$@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01CF00F8.E624E220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8A8GJJKKuiHD7yS72o9a+doO4TQw== Content-Language: de X-Provags-ID: V03:K0:UTCUlzhzfDjl6lpVGukYVlybxbYShG3on7ikAVku898nMa3gIRr 7MeespLvoIGMGAg5kJ3TUEgv3uSy9jfDp4CgZJWnyoPSB+wtWwoZTc4hf+2wtkcgbMKQsbp fzTLGA2NxSKUSWTW26zyw33K7aw+hktLgTDtHzw9IUBaBxIldeRtCgD0mqs4E49WLeXhGBJ QFxZrMPduQzG+s7Q1u0yg== Subject: [OAUTH-WG] JWT Profile: Does it make sense to demand a subject? 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: Tue, 24 Dec 2013 21:38:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0014_01CF00F8.E624E220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, the draft about the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [1] says: "The JWT MUST contain a "sub" (subject) claim identifying theprincipal that is the subject of the JWT. Two cases need to be differentiated: A. For the authorization grant, the subject SHOULD identify an authorized accessor for whom the access token is being requested (typically the resource owner, or an authorized delegate). B. For client authentication, the subject MUST be the "client_id" of the OAuth client." I'm not sure, if this makes sense, cause in an federation-scenario the original jwt is issued in an other security-domain and the auth-server in question does not necessarily know the users in thouse domain. Furthermore, it is very likely that the auth-server is not interested in the subject claim, but just in other incoming claims in view of mapping them to outgoing ones. IMHO, all the auth-server can do with the subject-claim is to create a protocol entry that says that some action was performed for this subject. Do I see that right? Wishes, Manfred [1] https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 ------=_NextPart_000_0014_01CF00F8.E624E220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

the draft = about the

 

JWT Profile for OAuth 2.0 Client = Authentication and Authorization Grants [1]

 

says:

 

„The JWT MUST contain a = "sub" (subject) claim identifying theprincipal that is the = subject of the JWT.  Two cases need to be = differentiated:

 

        = A.  For the authorization grant, the subject SHOULD identify = an

       &n= bsp;    authorized accessor for whom the access token is = being

       &n= bsp;    requested (typically the resource owner, or an = authorized

       &n= bsp;    delegate).

 

        = B.  For client authentication, the subject MUST be = the

       &n= bsp;    "client_id" of the OAuth = client.“

 

 

I’m = not sure, if this makes sense, cause in an federation-scenario the = original jwt is issued in an other security-domain and the auth-server = in question does not necessarily know the users in thouse domain. = Furthermore, it is very likely that the auth-server is not interested in = the subject claim, but just in other incoming claims in view of mapping = them to outgoing ones. IMHO, all the auth-server can do with the = subject-claim is to create a protocol entry that says that some action = was performed for this subject.

 

Do I see = that right?

 

Wishes,

Manfred

 

[1] = https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07

------=_NextPart_000_0014_01CF00F8.E624E220-- From c_w_1979@q.com Fri Dec 27 13:43:16 2013 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 6C48E1AE655 for ; Fri, 27 Dec 2013 13:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 nJCFArltwdVP for ; Fri, 27 Dec 2013 13:43:14 -0800 (PST) Received: from smtp.q.com (smtp.quartz.synacor.com [205.169.121.111]) by ietfa.amsl.com (Postfix) with ESMTP id 84E461AE656 for ; Fri, 27 Dec 2013 13:43:14 -0800 (PST) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=VaTOYjZ9 c=1 sm=0 tr=0 a=MVt/OeM/O+V7psr6YXG+1g==:117 a=K-v-2zaBAAAA:8 a=FKkrIqjQGGEA:10 a=MXlVqA_T49gA:10 a=5uzyEDg2IGAA:10 a=gdltxjTeQbIA:10 a=IkcTkHD0fZMA:10 a=BM2Wo2QsAAAA:8 a=8kUiTb72d5AA:10 a=48vgC7mUAAAA:8 a=VVlED5B4AAAA:8 a=D-Ja6WEZHWC_eaVZVPIA:9 a=IaAiG6q939LhS7wr:21 a=yTOTGwjsn0A5qX_h:21 a=QEXdDO2ut3YA:10 a=dQLDrkYtQ5oA:10 a=c4BbMYGOkqYA:10 a=lZB815dzVvQA:10 a=BFDKbZatV3MA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp03.quartz.synacor.com smtp.mail=c_w_1979@q.com; spf=softfail; sender-id=softfail Authentication-Results: smtp03.quartz.synacor.com header.from=c_w_1979@q.com; sender-id=softfail Received-SPF: softfail (smtp03.quartz.synacor.com: transitional domain q.com does not designate 10.30.7.251 as permitted sender) Received: from [10.30.7.251] ([10.30.7.251:54981] helo=md31.quartz.synacor.com) by smtp.q.com (envelope-from ) (ecelerity 2.2.2.40 r(29895/29896)) with ESMTP id 79/A6-07655-D64FDB25; Fri, 27 Dec 2013 16:43:09 -0500 Date: Fri, 27 Dec 2013 16:43:09 -0500 (EST) From: "c_w_1979@q.com" To: oauth@ietf.org Message-ID: <1331901716.3621046.1388180589518.JavaMail.root@md31.quartz.synacor.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [66.87.73.63] X-Mailer: Zimbra 6.0.8_GA_2685 (zclient/6.0.8_GA_2685) Subject: Re: [OAUTH-WG] OAuth Digest, Vol 62, Issue 14 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: Fri, 27 Dec 2013 21:43:16 -0000 Elaborate Please...I've Yet To Ackowledge The Presentation Of How This Responce Came About, Or The Reckolection If Your Asking, Telling, Or, Saying... What Kind Of Communication & To What Comprehensive Level From Who It May Consern As To What You And I Of A Conclusion Of The Outcome Of This Reading Shall Come About ----- Original Message ----- From: oauth-request@ietf.org To: oauth@ietf.org Sent: Wed, 25 Dec 2013 15:00:07 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 14 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. JWT Profile: Does it make sense to demand a subject? (Manfred Steyer) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Dec 2013 22:38:42 +0100 From: "Manfred Steyer" To: Subject: [OAUTH-WG] JWT Profile: Does it make sense to demand a subject? Message-ID: <001301cf00f0$845d1ec0$8d175c40$@gmx.net> Content-Type: text/plain; charset="us-ascii" Hi, the draft about the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [1] says: "The JWT MUST contain a "sub" (subject) claim identifying theprincipal that is the subject of the JWT. Two cases need to be differentiated: A. For the authorization grant, the subject SHOULD identify an authorized accessor for whom the access token is being requested (typically the resource owner, or an authorized delegate). B. For client authentication, the subject MUST be the "client_id" of the OAuth client." I'm not sure, if this makes sense, cause in an federation-scenario the original jwt is issued in an other security-domain and the auth-server in question does not necessarily know the users in thouse domain. Furthermore, it is very likely that the auth-server is not interested in the subject claim, but just in other incoming claims in view of mapping them to outgoing ones. IMHO, all the auth-server can do with the subject-claim is to create a protocol entry that says that some action was performed for this subject. Do I see that right? Wishes, Manfred [1] https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 14 ************************************* From c_w_1979@q.com Fri Dec 27 13:45:32 2013 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 A97161AE670 for ; Fri, 27 Dec 2013 13:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 5aGPtc2lJJ7q for ; Fri, 27 Dec 2013 13:45:30 -0800 (PST) Received: from smtp.q.com (smtp.quartz.synacor.com [205.169.121.111]) by ietfa.amsl.com (Postfix) with ESMTP id 418AA1AE66F for ; Fri, 27 Dec 2013 13:45:30 -0800 (PST) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=VaTOYjZ9 c=1 sm=0 tr=0 a=MVt/OeM/O+V7psr6YXG+1g==:117 a=K-v-2zaBAAAA:8 a=FKkrIqjQGGEA:10 a=MXlVqA_T49gA:10 a=5uzyEDg2IGAA:10 a=gdltxjTeQbIA:10 a=IkcTkHD0fZMA:10 a=BM2Wo2QsAAAA:8 a=8kUiTb72d5AA:10 a=48vgC7mUAAAA:8 a=VVlED5B4AAAA:8 a=UcUYSBSbAAAA:8 a=pQs5aej7AAAA:8 a=86BQ12ZPDLB-4UdyGhUA:9 a=lbFyiFiBJ2ByheYu:21 a=uHyvYA8Kl1Qm-fuG:21 a=QEXdDO2ut3YA:10 a=dQLDrkYtQ5oA:10 a=c4BbMYGOkqYA:10 a=X2LoQc-CR68A:10 a=lZB815dzVvQA:10 a=BFDKbZatV3MA:10 a=Dr4NP4fjpT0A:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp03.quartz.synacor.com smtp.mail=c_w_1979@q.com; spf=softfail; sender-id=softfail Authentication-Results: smtp03.quartz.synacor.com header.from=c_w_1979@q.com; sender-id=softfail Received-SPF: softfail (smtp03.quartz.synacor.com: transitional domain q.com does not designate 10.30.7.251 as permitted sender) Received: from [10.30.7.251] ([10.30.7.251:39933] helo=md31.quartz.synacor.com) by smtp.q.com (envelope-from ) (ecelerity 2.2.2.40 r(29895/29896)) with ESMTP id B6/47-07655-5F4FDB25; Fri, 27 Dec 2013 16:45:25 -0500 Date: Fri, 27 Dec 2013 16:45:25 -0500 (EST) From: "c_w_1979@q.com" To: oauth@ietf.org Message-ID: <877711432.3621060.1388180725565.JavaMail.root@md31.quartz.synacor.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [66.87.73.63] X-Mailer: Zimbra 6.0.8_GA_2685 (zclient/6.0.8_GA_2685) Subject: Re: [OAUTH-WG] OAuth Digest, Vol 62, Issue 13 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: Fri, 27 Dec 2013 21:45:32 -0000 Elaborate Please...I've Yet To Ackowledge The Presentation Of How This Responce Came About, Or The Reckolection If Your Asking, Telling, Or, Saying... What Kind Of Communication & To What Comprehensive Level From Who It May Consern As To What You And I Of A Conclusion Of The Outcome Of This Reading Shall Come About ----- Original Message ----- From: oauth-request@ietf.org To: oauth@ietf.org Sent: Wed, 25 Dec 2013 15:00:07 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 14 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. JWT Profile: Does it make sense to demand a subject? (Manfred Steyer) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Dec 2013 22:38:42 +0100 From: "Manfred Steyer" To: Subject: [OAUTH-WG] JWT Profile: Does it make sense to demand a subject? Message-ID: <001301cf00f0$845d1ec0$8d175c40$@gmx.net> Content-Type: text/plain; charset="us-ascii" Hi, the draft about the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [1] says: "The JWT MUST contain a "sub" (subject) claim identifying theprincipal that is the subject of the JWT. Two cases need to be differentiated: A. For the authorization grant, the subject SHOULD identify an authorized accessor for whom the access token is being requested (typically the resource owner, or an authorized delegate). B. For client authentication, the subject MUST be the "client_id" of the OAuth client." I'm not sure, if this makes sense, cause in an federation-scenario the original jwt is issued in an other security-domain and the auth-server in question does not necessarily know the users in thouse domain. Furthermore, it is very likely that the auth-server is not interested in the subject claim, but just in other incoming claims in view of mapping them to outgoing ones. IMHO, all the auth-server can do with the subject-claim is to create a protocol entry that says that some action was performed for this subject. Do I see that right? Wishes, Manfred [1] https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 14 ************************************* ----- Original Message ----- From: oauth-request@ietf.org To: oauth@ietf.org Sent: Tue, 24 Dec 2013 15:00:06 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 13 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. JWT Attribute Certificates (Luke Howard) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Dec 2013 12:03:41 +1100 From: Luke Howard To: oauth@ietf.org, dev-identity@lists.mozilla.org Subject: [OAUTH-WG] JWT Attribute Certificates Message-ID: <62F725C1-050D-4C33-9C89-AA2E30CDD04E@padl.com> Content-Type: text/plain; charset="us-ascii" Seasons greetings! I've recently been working on adding support for selective claim disclosure to Mozilla Persona. A component of this was defining a JWT Attribute Certificate structure that can contain a set of claims bound to a primary JWT. The following Internet Draft documents this: Name: draft-howard-jwt-attr-cert Revision: 00 Title: JWT Attribute Certificate (JAC) Document date: 2013-12-24 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-howard-jwt-attr-cert-00.txt Status: https://datatracker.ietf.org/doc/draft-howard-jwt-attr-cert/ Htmlized: http://tools.ietf.org/html/draft-howard-jwt-attr-cert-00 Abstract: A JSON Web Token Attribute Certificate (JAC) contains additional claims, grouped by scope, to be presented alongside a primary JWT. -- Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 13 ************************************* From c_w_1979@q.com Fri Dec 27 13:48:54 2013 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 87A601AE68D for ; Fri, 27 Dec 2013 13:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 AdFL72WvZ_fU for ; Fri, 27 Dec 2013 13:48:52 -0800 (PST) Received: from smtp.q.com (smtp.quartz.synacor.com [205.169.121.111]) by ietfa.amsl.com (Postfix) with ESMTP id 09F0B1AE674 for ; Fri, 27 Dec 2013 13:48:52 -0800 (PST) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=Ku90hwmN c=1 sm=0 tr=0 a=MVt/OeM/O+V7psr6YXG+1g==:117 a=K-v-2zaBAAAA:8 a=FKkrIqjQGGEA:10 a=MXlVqA_T49gA:10 a=5uzyEDg2IGAA:10 a=gdltxjTeQbIA:10 a=IkcTkHD0fZMA:10 a=BM2Wo2QsAAAA:8 a=8kUiTb72d5AA:10 a=48vgC7mUAAAA:8 a=VVlED5B4AAAA:8 a=UcUYSBSbAAAA:8 a=pQs5aej7AAAA:8 a=VnNF1IyMAAAA:8 a=yEtWj7B9bVTjxMvwcBEA:9 a=iwRJSMZ9iBoggOIW:21 a=Cai297mWBdCyo_1p:21 a=QEXdDO2ut3YA:10 a=dQLDrkYtQ5oA:10 a=c4BbMYGOkqYA:10 a=X2LoQc-CR68A:10 a=RlEbjTLmgIMA:10 a=lZB815dzVvQA:10 a=BFDKbZatV3MA:10 a=Dr4NP4fjpT0A:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.quartz.synacor.com smtp.mail=c_w_1979@q.com; spf=softfail; sender-id=softfail Authentication-Results: smtp02.quartz.synacor.com header.from=c_w_1979@q.com; sender-id=softfail Received-SPF: softfail (smtp02.quartz.synacor.com: transitional domain q.com does not designate 10.30.7.251 as permitted sender) Received: from [10.30.7.251] ([10.30.7.251:40102] helo=md31.quartz.synacor.com) by smtp.q.com (envelope-from ) (ecelerity 2.2.2.40 r(29895/29896)) with ESMTP id 35/9D-03769-FB5FDB25; Fri, 27 Dec 2013 16:48:47 -0500 Date: Fri, 27 Dec 2013 16:48:47 -0500 (EST) From: "c_w_1979@q.com" To: oauth@ietf.org Message-ID: <1727687415.3621109.1388180927121.JavaMail.root@md31.quartz.synacor.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [66.87.73.63] X-Mailer: Zimbra 6.0.8_GA_2685 (zclient/6.0.8_GA_2685) Subject: Re: [OAUTH-WG] OAuth Digest, Vol 62, Issue 12 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: Fri, 27 Dec 2013 21:48:54 -0000 Elaborate Please...I've Yet To Ackowledge The Presentation Of How This Responce Came About, Or The Reckolection If Your Asking, Telling, Or, Saying... What Kind Of Communication & To What Comprehensive Level From Who It May Consern As To What You And I Of A Conclusion Of The Outcome Of This Reading Shall Come About ----- Original Message ----- From: oauth-request@ietf.org To: oauth@ietf.org Sent: Wed, 25 Dec 2013 15:00:07 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 14 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. JWT Profile: Does it make sense to demand a subject? (Manfred Steyer) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Dec 2013 22:38:42 +0100 From: "Manfred Steyer" To: Subject: [OAUTH-WG] JWT Profile: Does it make sense to demand a subject? Message-ID: <001301cf00f0$845d1ec0$8d175c40$@gmx.net> Content-Type: text/plain; charset="us-ascii" Hi, the draft about the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [1] says: "The JWT MUST contain a "sub" (subject) claim identifying theprincipal that is the subject of the JWT. Two cases need to be differentiated: A. For the authorization grant, the subject SHOULD identify an authorized accessor for whom the access token is being requested (typically the resource owner, or an authorized delegate). B. For client authentication, the subject MUST be the "client_id" of the OAuth client." I'm not sure, if this makes sense, cause in an federation-scenario the original jwt is issued in an other security-domain and the auth-server in question does not necessarily know the users in thouse domain. Furthermore, it is very likely that the auth-server is not interested in the subject claim, but just in other incoming claims in view of mapping them to outgoing ones. IMHO, all the auth-server can do with the subject-claim is to create a protocol entry that says that some action was performed for this subject. Do I see that right? Wishes, Manfred [1] https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 14 ************************************* ----- Original Message ----- From: oauth-request@ietf.org To: oauth@ietf.org Sent: Tue, 24 Dec 2013 15:00:06 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 13 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. JWT Attribute Certificates (Luke Howard) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Dec 2013 12:03:41 +1100 From: Luke Howard To: oauth@ietf.org, dev-identity@lists.mozilla.org Subject: [OAUTH-WG] JWT Attribute Certificates Message-ID: <62F725C1-050D-4C33-9C89-AA2E30CDD04E@padl.com> Content-Type: text/plain; charset="us-ascii" Seasons greetings! I've recently been working on adding support for selective claim disclosure to Mozilla Persona. A component of this was defining a JWT Attribute Certificate structure that can contain a set of claims bound to a primary JWT. The following Internet Draft documents this: Name: draft-howard-jwt-attr-cert Revision: 00 Title: JWT Attribute Certificate (JAC) Document date: 2013-12-24 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-howard-jwt-attr-cert-00.txt Status: https://datatracker.ietf.org/doc/draft-howard-jwt-attr-cert/ Htmlized: http://tools.ietf.org/html/draft-howard-jwt-attr-cert-00 Abstract: A JSON Web Token Attribute Certificate (JAC) contains additional claims, grouped by scope, to be presented alongside a primary JWT. -- Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 13 ************************************* ----- Original Message ----- From: oauth-request@ietf.org To: oauth@ietf.org Sent: Sun, 22 Dec 2013 15:00:05 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 12 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. AUTO: Codur Sreedhar Pranam is out of the office (returning 01/08/2014) (Codur Sreedhar Pranam) ---------------------------------------------------------------------- Message: 1 Date: Sun, 22 Dec 2013 04:00:59 +0800 From: Codur Sreedhar Pranam To: oauth@ietf.org Subject: [OAUTH-WG] AUTO: Codur Sreedhar Pranam is out of the office (returning 01/08/2014) Message-ID: Content-Type: text/plain; charset="us-ascii" I am out of the office until 01/08/2014. Note: This is an automated response to your message "OAuth Digest, Vol 62, Issue 11" sent on 12/22/2013 4:00:06. This is the only notification you will receive while this person is away. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 12 ************************************* From c_w_1979@q.com Fri Dec 27 13:52:56 2013 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 E33841AE6A6 for ; Fri, 27 Dec 2013 13:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 aSqjD9LoxifJ for ; Fri, 27 Dec 2013 13:52:54 -0800 (PST) Received: from smtp.q.com (smtp.quartz.synacor.com [205.169.121.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3D51AE6A5 for ; Fri, 27 Dec 2013 13:52:54 -0800 (PST) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=Ku90hwmN c=1 sm=0 tr=0 a=MVt/OeM/O+V7psr6YXG+1g==:117 a=K-v-2zaBAAAA:8 a=FKkrIqjQGGEA:10 a=MXlVqA_T49gA:10 a=5uzyEDg2IGAA:10 a=gdltxjTeQbIA:10 a=IkcTkHD0fZMA:10 a=BM2Wo2QsAAAA:8 a=8kUiTb72d5AA:10 a=48vgC7mUAAAA:8 a=VVlED5B4AAAA:8 a=UcUYSBSbAAAA:8 a=pQs5aej7AAAA:8 a=VnNF1IyMAAAA:8 a=pGLkceISAAAA:8 a=LS6YZpeZAAAA:8 a=1XWaLZrsAAAA:8 a=DVqm7IH0AAAA:8 a=eBPf_qlhqy17A2TsfpgA:9 a=D3vTzbH-49Nmv65P:21 a=I8je4GkIkmPpftBy:21 a=QEXdDO2ut3YA:10 a=dQLDrkYtQ5oA:10 a=c4BbMYGOkqYA:10 a=X2LoQc-CR68A:10 a=RlEbjTLmgIMA:10 a=lZB815dzVvQA:10 a=BFDKbZatV3MA:10 a=Dr4NP4fjpT0A:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.quartz.synacor.com header.from=c_w_1979@q.com; sender-id=softfail Authentication-Results: smtp02.quartz.synacor.com smtp.mail=c_w_1979@q.com; spf=softfail; sender-id=softfail Received-SPF: softfail (smtp02.quartz.synacor.com: transitional domain q.com does not designate 10.30.7.251 as permitted sender) Received: from [10.30.7.251] ([10.30.7.251:44464] helo=md31.quartz.synacor.com) by smtp.q.com (envelope-from ) (ecelerity 2.2.2.40 r(29895/29896)) with ESMTP id 40/FE-03769-1B6FDB25; Fri, 27 Dec 2013 16:52:49 -0500 Date: Fri, 27 Dec 2013 16:52:49 -0500 (EST) From: "c_w_1979@q.com" To: oauth@ietf.org Message-ID: <1791617254.3621171.1388181169307.JavaMail.root@md31.quartz.synacor.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [66.87.73.63] X-Mailer: Zimbra 6.0.8_GA_2685 (zclient/6.0.8_GA_2685) Subject: Re: [OAUTH-WG] OAuth Digest, Vol 62, Issue 11 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: Fri, 27 Dec 2013 21:52:57 -0000 Elaborate Please...I've Yet To Ackowledge The Presentation Of How This Responce Came About, Or The Reckolection If Your Asking, Telling, Or, Saying... What Kind Of Communication & To What Comprehensive Level From Who It May Consern As To What You And I Of A Conclusion Of The Outcome Of This Reading Shall Come About ----- Original Message ----- From: oauth-request@ietf.org To: oauth@ietf.org Sent: Wed, 25 Dec 2013 15:00:07 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 14 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. JWT Profile: Does it make sense to demand a subject? (Manfred Steyer) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Dec 2013 22:38:42 +0100 From: "Manfred Steyer" To: Subject: [OAUTH-WG] JWT Profile: Does it make sense to demand a subject? Message-ID: <001301cf00f0$845d1ec0$8d175c40$@gmx.net> Content-Type: text/plain; charset="us-ascii" Hi, the draft about the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [1] says: "The JWT MUST contain a "sub" (subject) claim identifying theprincipal that is the subject of the JWT. Two cases need to be differentiated: A. For the authorization grant, the subject SHOULD identify an authorized accessor for whom the access token is being requested (typically the resource owner, or an authorized delegate). B. For client authentication, the subject MUST be the "client_id" of the OAuth client." I'm not sure, if this makes sense, cause in an federation-scenario the original jwt is issued in an other security-domain and the auth-server in question does not necessarily know the users in thouse domain. Furthermore, it is very likely that the auth-server is not interested in the subject claim, but just in other incoming claims in view of mapping them to outgoing ones. IMHO, all the auth-server can do with the subject-claim is to create a protocol entry that says that some action was performed for this subject. Do I see that right? Wishes, Manfred [1] https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 14 ************************************* ----- Original Message ----- From: oauth-request@ietf.org To: oauth@ietf.org Sent: Tue, 24 Dec 2013 15:00:06 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 13 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. JWT Attribute Certificates (Luke Howard) ---------------------------------------------------------------------- Message: 1 Date: Tue, 24 Dec 2013 12:03:41 +1100 From: Luke Howard To: oauth@ietf.org, dev-identity@lists.mozilla.org Subject: [OAUTH-WG] JWT Attribute Certificates Message-ID: <62F725C1-050D-4C33-9C89-AA2E30CDD04E@padl.com> Content-Type: text/plain; charset="us-ascii" Seasons greetings! I've recently been working on adding support for selective claim disclosure to Mozilla Persona. A component of this was defining a JWT Attribute Certificate structure that can contain a set of claims bound to a primary JWT. The following Internet Draft documents this: Name: draft-howard-jwt-attr-cert Revision: 00 Title: JWT Attribute Certificate (JAC) Document date: 2013-12-24 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-howard-jwt-attr-cert-00.txt Status: https://datatracker.ietf.org/doc/draft-howard-jwt-attr-cert/ Htmlized: http://tools.ietf.org/html/draft-howard-jwt-attr-cert-00 Abstract: A JSON Web Token Attribute Certificate (JAC) contains additional claims, grouped by scope, to be presented alongside a primary JWT. -- Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 13 ************************************* ----- Original Message ----- From: oauth-request@ietf.org To: oauth@ietf.org Sent: Sun, 22 Dec 2013 15:00:05 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 12 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. AUTO: Codur Sreedhar Pranam is out of the office (returning 01/08/2014) (Codur Sreedhar Pranam) ---------------------------------------------------------------------- Message: 1 Date: Sun, 22 Dec 2013 04:00:59 +0800 From: Codur Sreedhar Pranam To: oauth@ietf.org Subject: [OAUTH-WG] AUTO: Codur Sreedhar Pranam is out of the office (returning 01/08/2014) Message-ID: Content-Type: text/plain; charset="us-ascii" I am out of the office until 01/08/2014. Note: This is an automated response to your message "OAuth Digest, Vol 62, Issue 11" sent on 12/22/2013 4:00:06. This is the only notification you will receive while this person is away. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 12 ************************************* ----- Original Message ----- From: oauth-request@ietf.org To: oauth@ietf.org Sent: Sat, 21 Dec 2013 15:00:06 -0500 (EST) Subject: OAuth Digest, Vol 62, Issue 11 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt (Sergey Beryozkin) ---------------------------------------------------------------------- Message: 1 Date: Fri, 20 Dec 2013 21:55:28 +0000 From: Sergey Beryozkin To: oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt Message-ID: <52B4BCD0.5080600@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi IMHO the fact the transformation of the code_verifier is pluggable is a major improvement, and the whole text somehow reads much easier (few minor typos in the introduction). The only doubt is about the 'MUST' bit where the client is expected to figure out that the server supports this spec. Not a problem for me as I don't work on implementing a client, but it seems like it makes the whole process suddenly much more complex than may be it should be. Would it make sense to change 'MUST' to 'RECOMMENDED' and have the authorization service return a code_verifier_accepted or some similar response parameter, alongside with the 'code', instead ? Not really though, Cheers, Sergey On 19/10/13 11:15, Nat Sakimura wrote: > Incorporated the discussion at Berlin meeting and after in the ML. > > Best, > > Nat > > ---------- Forwarded message ---------- > From: ** > > Date: 2013/10/19 > Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt > To: Nat Sakimura >, John > Bradley >, > Naveen Agarwal > > > > > A new version of I-D, draft-sakimura-oauth-tcse-02.txt > has been successfully submitted by Nat Sakimura and posted to the > IETF repository. > > Filename: draft-sakimura-oauth-tcse > Revision: 02 > Title: OAuth Symmetric Proof of Posession for Code Extension > Creation date: 2013-10-19 > Group: Individual Submission > Number of pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt > Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse > Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02 > > Abstract: > The OAuth 2.0 public client utilizing authorization code grant is > susceptible to the code interception attack. This specification > describe a mechanism that acts as a control against this threat. > > > > > > 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 > . > > The IETF Secretariat > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 62, Issue 11 ************************************* From internet-drafts@ietf.org Sun Dec 29 04:43:23 2013 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 486711AE0FB; Sun, 29 Dec 2013 04:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jrvRupS5slfv; Sun, 29 Dec 2013 04:43:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A64161AE170; Sun, 29 Dec 2013 04:43:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131229124320.4468.8379.idtracker@ietfa.amsl.com> Date: Sun, 29 Dec 2013 04:43:20 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 12:43:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : JSON Web Token (JWT) Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-14.txt Pages : 29 Date : 2013-12-29 Abstract: JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. The suggested pronunciation of JWT is the same as the English word "jot". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-json-web-token-14 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Sun Dec 29 04:58:46 2013 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 AE5901AE1C2 for ; Sun, 29 Dec 2013 04:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 BytA-CGCnyB5 for ; Sun, 29 Dec 2013 04:58:43 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id B91681AE027 for ; Sun, 29 Dec 2013 04:58:43 -0800 (PST) Received: from BLUPR03CA028.namprd03.prod.outlook.com (10.141.30.21) by BLUPR03MB049.namprd03.prod.outlook.com (10.255.209.149) with Microsoft SMTP Server (TLS) id 15.0.851.11; Sun, 29 Dec 2013 12:58:36 +0000 Received: from BN1BFFO11FD027.protection.gbl (2a01:111:f400:7c10::1:194) by BLUPR03CA028.outlook.office365.com (2a01:111:e400:879::21) with Microsoft SMTP Server (TLS) id 15.0.842.7 via Frontend Transport; Sun, 29 Dec 2013 12:58:37 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD027.mail.protection.outlook.com (10.58.144.90) with Microsoft SMTP Server (TLS) id 15.0.837.10 via Frontend Transport; Sun, 29 Dec 2013 12:58:36 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.67]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0158.002; Sun, 29 Dec 2013 12:58:01 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JOSE -19 drafts intended for Working Group Last Call Thread-Index: Ac8ElFUb4ddjYn6yQ3mJg8Va1mrr3AAATugg Date: Sun, 29 Dec 2013 12:58:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739437CD794B7@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739437CD77450@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739437CD77450@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739437CD794B7TK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(69234005)(377454003)(199002)(189002)(49866001)(47736001)(46102001)(50986001)(47976001)(512954002)(77096001)(20776003)(80976001)(63696002)(81816001)(87936001)(6806004)(74366001)(76786001)(76796001)(90146001)(74502001)(19580405001)(31966008)(44976005)(16236675002)(2656002)(51856001)(33656001)(56816005)(69226001)(83322001)(4396001)(74706001)(84326002)(74662001)(53806001)(74876001)(54356001)(47446002)(76482001)(55846006)(81686001)(59766001)(15975445006)(87266001)(83072002)(77982001)(19580395003)(561944002)(66066001)(65816001)(71186001)(80022001)(85806002)(54316002)(56776001)(85852003)(85306002)(81542001)(79102001)(19300405004)(81342001)(15202345003)(6606295002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB049; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0075CB064E X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] FW: JOSE -19 drafts intended for Working Group Last Call 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: Sun, 29 Dec 2013 12:58:46 -0000 --_000_4E1F6AAD24975D4BA5B16804296739437CD794B7TK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Sunday, December 29, 2013 4:49 AM To: jose@ietf.org Cc: Sean Turner Subject: [jose] JOSE -19 drafts intended for Working Group Last Call JSON Object Signing and Encryption (JOSE) -19 drafts have been published th= at address all my remaining to-do items for the open issues. I believe the= remainder of the issues are either ready to close because of actions alrea= dy taken in the drafts (the majority of them), require further input to ide= ntify any specific remaining proposed actions, if any (a few of them), or w= ill be considered during Working Group Last Call (a few of them). Only edi= torial changes and one addition were made - no breaking changes. In short, I believe I have addressed everything needed to bring us to Worki= ng Group Last Call for the JWS, JWE, JWK, and JWA specs. (Chairs and Sean,= please let me know whether you agree or whether you believe anything else = remains to be done before WGLC.) The one addition was to add the optional "use_details" JWK field, as discus= sed on the JOSE list and the WebCrypto list. While I realize that this pro= posal hasn't gotten much review yet (I believe due to the holidays), I want= ed to get it in so people can review it in context, and as a concrete step = towards meeting a perceived need for additional JWK functionality from the = WebCrypto working group. It's cleanly separable from the rest of the spec,= so if the JOSE WG ends up hating it, we can always take it back out and po= ssibly move it to a separate spec. But at least we have a concrete write-u= p of it now to review. I also made a one-paragraph change to the JSON Web Token (JWT) spec to refe= rence text in JWE, rather than duplicating it in JWT. See the History entries for details of the (small number of) changes made. The drafts are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-19 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-19 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-19 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-19 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-14 HTML formatted versions are also available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-19= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-1= 9.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-19.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-1= 9.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-14.ht= ml -- Mike --_000_4E1F6AAD24975D4BA5B16804296739437CD794B7TK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI<= /p>

 

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Sunday, December 29, 2013 4:49 AM
To: jose@ietf.org
Cc: Sean Turner
Subject: [jose] JOSE -19 drafts intended for Working Group Last Call=

 

JSON Object Signing and Encryption (JOSE) -19 drafts= have been published that address all my remaining to-do items for the open= issues.  I believe the remainder of the issues are either ready to cl= ose because of actions already taken in the drafts (the majority of them), require further input to identify any s= pecific remaining proposed actions, if any (a few of them), or will be cons= idered during Working Group Last Call (a few of them).  Only editorial= changes and one addition were made – no breaking changes.

 

In short, I believe I have addressed everything need= ed to bring us to Working Group Last Call for the JWS, JWE, JWK, and JWA sp= ecs.  (Chairs and Sean, please let me know whether you agree or whethe= r you believe anything else remains to be done before WGLC.)

 

The one addition was to add the optional “use_details” J= WK field, as discussed on the JOSE list and the WebCrypto list.  While= I realize that this proposal hasn’t gotten much review yet (I believe due to the holidays), I wanted to get it in so people can review i= t in context, and as a concrete step towards meeting a perceived need for a= dditional JWK functionality from the WebCrypto working group.  It̵= 7;s cleanly separable from the rest of the spec, so if the JOSE WG ends up hating it, we can always take it back out = and possibly move it to a separate spec.  But at least we have a concr= ete write-up of it now to review.

 

I also made a one-paragraph change to the JSON Web T= oken (JWT) spec to reference text in JWE, rather than duplicating it in JWT= .

 

See the History entries for details of the (small nu= mber of) changes made.

 

The drafts are available at:

·        http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-19

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-19

·        http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-19

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-19

·        http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-14

 

HTML formatted versions are also available at:<= /o:p>

·        http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-19.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-19.html

·        http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-19.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-19.html

·        http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-14.html

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739437CD794B7TK5EX14MBXC286r_--