writes: >>>=20 >>>> Not quite. I will call you.=20 >>>>=20 >>>> I am saying we are transitioning from the old public client model. The n= ew >>>> model proposes quasi-confidential characteristics but in some respects i= s >>>> missing key information from the public m! >>>> odel.=20 >>>> Namely that a group of clients >>>> are related and there have common behaviour and security characteristic= s.=20 >>>>=20 >>>> We need to add to the self-asserted model an assertion equiv to the old= common >>>> client_id. That is all.=20 >>>>=20 >>>> I am NOT looking for a proof of application identity here. That is too f= ar. >>>> But certainly what we define here can open that door.=20 >>>>=20 >>>> Phil >>>=20 >>> I think I understand what you're saying here. In the "old way", a >>> public client had a constant client_id amongst all instances of that >>> public client, whereas in the "new way", a public client will have >>> different client_ids amongst all instances of that client. You feel >>> this is a loss, whereas it seems most people seem to feel this change is= >>> okay. >>>=20 >>> Since you are effectively the lone dissenter on this one topic, let me >>> ask you a question: What is a technical reason that you need to have a >>> constant, assertion that would bind to! >>> gether >>> (in a non-authenticated >>> way) multiple instances of a client? >>>=20 >>> I believe that Justin has provides some attacks against this; so I'm >>> trying to understand, (with my chair hat on), why you need this >>> functionality? >>>=20 >>> With my security-mafia hat on, I feel like the old way was bad, and I >>> much prefer the newer way where each instance of a client gets its own >>> ID and a locally-stored secret. >>>=20 >>> -derek >>>=20 >>> --=20 >>> Derek Atkins 617-623-3745 >>> derek@ihtfp.com www.ihtfp.com >>> Computer and Internet Security Consultant >>=20 >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-6E69AAC9-6BAF-466F-B80A-48D96F025037 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Yes. However the contents and format a= re out of scope.

Phil

On 2013-06-03, at 2= 2:32, Torsten Lodderstedt <tor= sten@lodderstedt.net> wrote:

<= div>Hi Phil,

isn't the initial registration token such a credential, which allows to co-= relate different instances of the same software?

regards,
Torsten.

Phil Hunt <phil.hunt@oracle.com> schrieb:

Finally i believe the bb+ doesn't have the issue be=
cause they are solving with an initial authn credential that contains the sa=
me info. 

My feeling is that this functionality needs to be standardi=
zed one way or another. 

Phil

On 2013-06-03, at 19:16, Derek A=
tkins <derek@ihtfp.com> wrote:<=
br>
Phil,

Phil Hunt &=
lt;phil.hunt@oracle.com> writ=
es:

Not quite. I will c=
all you. 

I am saying we are transitioning from the old public client=
 model. The new
model proposes quasi-confidential characteristics but in s=
ome respects is
missing key information from the public m!
 odel.=20
Namely that a group of clients
are related and there have common behaviou=
r and security characteristics. 

We need to add to the self-asserted m=
odel an assertion equiv to the old common
client_id. That is all. 
I am NOT looking for a proof of application identity here. That is too far.=

But certainly what we define here can open that door. 

Phil
I think I understand what you're saying here.  In the "old way", a=

public client had a constant client_id amongst all instances of that
=
public client, whereas in the "new way", a public client will have
differ=
ent client_ids amongst all instances of that client.  You feel
this is a l=
oss, whereas it seems most people seem to feel this change is
okay.
Since you are effectively the lone dissenter on this one topic, let me
=
ask you a question: What is a technical reason that you need to have a
co=
nstant, assertion that would bind to!
 gether
(in a non-authenticated
way) multiple instances of a client?

I bel=
ieve that Justin has provides some attacks against this; so I'm
trying to=
 understand, (with my chair hat on), why you need this
functionality?
=

With my security-mafia hat on, I feel like the old way was bad, and Imuch prefer the newer way where each instance of a client gets its own
I=
D and a locally-stored secret.

-derek

-- 
Derek Atkins     =
            617-623-3745
derek@ihtfp.c=
om             www.ihtfp.com
Com=
puter and Internet Security Consultant

OAuth mailing=
 list
OAuth@ietf.org
https://www.ietf.org/mailman/li=
stinfo/oauth

= --Apple-Mail-6E69AAC9-6BAF-466F-B80A-48D96F025037-- From hannes.tschofenig@nsn.com Tue Jun 4 05:48:00 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C689821F9D4F for ; Tue, 4 Jun 2013 05:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cu9zPxSJ9juk for ; Tue, 4 Jun 2013 05:47:45 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E42C721F9058 for ; Tue, 4 Jun 2013 04:20:56 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r54BKrKv030105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 4 Jun 2013 13:20:53 +0200 Received: from USCHHTC001.nsn-intra.net ([10.159.161.14]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r54BKqfe008728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Jun 2013 13:20:53 +0200 Received: from USCHMBX001.nsn-intra.net ([169.254.1.6]) by USCHHTC001.nsn-intra.net ([10.159.161.14]) with mapi id 14.03.0123.003; Tue, 4 Jun 2013 06:20:52 -0500 From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "OAuth@ietf.org" Thread-Topic: Review of the Dynamic Registration Draft Thread-Index: Ac5hFZGg59iSssXlQAmTL7tr4RW9Mg== Date: Tue, 4 Jun 2013 11:20:51 +0000 Message-ID: <1373E8CE237FCC43BCA36C6558612D2A9F13E9@USCHMBX001.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.161.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3572 X-purgate-ID: 151667::1370344853-000017BA-DE0DF139/0-0/0-0 Subject: [OAUTH-WG] Review of the Dynamic Registration Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 12:48:00 -0000 Dear draft authors, Dear working group, I read through the dynamic registration draft and here a few observations I= have made:=20 * The 'Initial Access Token' is really more a developer identifier. If you = give it a different=20 name then it might be more intuitive for the reader since the current wordi= ng is a bit fuzzy.=20 For example, in Section 1.3 you only hint to the fact that this identifier = refers to the=20 developer later in the text.=20 * From the description I have problems understanding the value of the "Regi= stration Access Token".=20 I believe you can accomplish exactly the same security benefits if you just= use the client=20 credentials instead. Do I see this wrong?=20 * OAuth 2.0 supports a number of authorization grants and I have assumed th= at the dynamic=20 client registration would focus on the authorization code grant. To my surp= rise the=20 implicit grant also seems to be supported. The implicit grant has weak secu= rity properties=20 and it's usage should actually be discouraged. Why would you want to suppor= t the implicit=20 grant for the dynamic client registration?=20 * There is a lot of RFC 2119 language in the document but it is used in a w= ay that does not=20 relate to protocol interoperability. Every time you write SHOULD or MAY thi= nk about whether=20 a developer could write some useful code. Just to give you an example:=20 " client_name Human-readable name of the Client to be presented to the user. If omitted, the Authorization Server MAY display the raw "client_id" value to the user instead. " First, in this sentence what is presented to the user isn't really part of = protocol interoperability.=20 So, I wouldn't use RFC 2119 language here. What is necessary for protocol i= nteroperability is whether=20 the field is optional/mandatory to send by the client-side, and optional/ma= ndatory to understand on=20 the server-side. Additionally, do you think that an end user will likely se= e a lot of meaning in the=20 client_id, which is a random string. What is the end user supposed to use t= hat information for?=20 Another example:=20 " Extensions and profiles of this specification MAY expand this list, but Authorization Servers MUST accept or ignore all parameters on this list. The Authorization Server MUST ignore any additional parameters sent by the Client that it does not understand. " In the first sentence you don't want to use RFC 2119 language either. If th= ere are ways to extend the=20 functionality via registries then point to the sections that explain how to= extend it. The next two=20 sentences are confusing. It seems that you want to have any additional para= meter to be purely optional=20 for the authorization server to understand. That's fine but what does this = sentence then mean:=20 "Authorization Servers MUST accept or ignore all parameters on this list."? * An editorial issue: There is an excessive usage of capitalization in the = document. If you look=20 at previously published RFCs in the OAuth working group you will noticed th= at the RFC editor=20 changes those to lower-case. For example, just use authorization server ins= tead of Authorization=20 Server. Same for Client, Developer, etc. Ciao Hannes PS: I obviously noticed that the WGLC had trigger some discussion. In some = sense that's good since this=20 is what WGLCs are for. On the other hand it would be good to reach an agree= ment on the open issues.=20 From hannes.tschofenig@nsn.com Tue Jun 4 06:37:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D3A21F9DE2 for ; Tue, 4 Jun 2013 06:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pc8M+QxN0wUx for ; Tue, 4 Jun 2013 06:37:30 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6AC21F9A37 for ; Tue, 4 Jun 2013 05:06:36 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r54C6ZRZ015268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 4 Jun 2013 14:06:35 +0200 Received: from USCHHTC002.nsn-intra.net ([10.159.161.15]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r54C6Xun004713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Jun 2013 14:06:34 +0200 Received: from USCHHTC004.nsn-intra.net (10.159.161.17) by USCHHTC002.nsn-intra.net (10.159.161.15) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 4 Jun 2013 07:06:32 -0500 Received: from USCHMBX001.nsn-intra.net ([169.254.1.6]) by USCHHTC004.nsn-intra.net ([10.159.161.17]) with mapi id 14.03.0123.003; Tue, 4 Jun 2013 07:06:32 -0500 From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "OAuth@ietf.org" Thread-Topic: Review of the Dynamic Registration Draft Thread-Index: Ac5hFZGg59iSssXlQAmTL7tr4RW9MgABlBew Date: Tue, 4 Jun 2013 12:06:32 +0000 Message-ID: <1373E8CE237FCC43BCA36C6558612D2A9F1480@USCHMBX001.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3817 X-purgate-ID: 151667::1370347595-000017BA-AE8FDDB4/0-0/0-0 Subject: [OAUTH-WG] FW: Review of the Dynamic Registration Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:37:44 -0000 Re-send: my earlier mail seems to have gotten lost.=20 -----Original Message----- From: Tschofenig, Hannes (NSN - FI/Espoo)=20 Sent: Tuesday, June 04, 2013 2:21 PM To: 'OAuth@ietf.org' Subject: Review of the Dynamic Registration Draft Dear draft authors, Dear working group, I read through the dynamic registration draft and here a few observations I= have made:=20 * The 'Initial Access Token' is really more a developer identifier. If you = give it a different=20 name then it might be more intuitive for the reader since the current wordi= ng is a bit fuzzy.=20 For example, in Section 1.3 you only hint to the fact that this identifier = refers to the=20 developer later in the text.=20 * From the description I have problems understanding the value of the "Regi= stration Access Token".=20 I believe you can accomplish exactly the same security benefits if you just= use the client=20 credentials instead. Do I see this wrong?=20 * OAuth 2.0 supports a number of authorization grants and I have assumed th= at the dynamic=20 client registration would focus on the authorization code grant. To my surp= rise the=20 implicit grant also seems to be supported. The implicit grant has weak secu= rity properties=20 and it's usage should actually be discouraged. Why would you want to suppor= t the implicit=20 grant for the dynamic client registration?=20 * There is a lot of RFC 2119 language in the document but it is used in a w= ay that does not=20 relate to protocol interoperability. Every time you write SHOULD or MAY thi= nk about whether=20 a developer could write some useful code. Just to give you an example:=20 " client_name Human-readable name of the Client to be presented to the user. If omitted, the Authorization Server MAY display the raw "client_id" value to the user instead. " First, in this sentence what is presented to the user isn't really part of = protocol interoperability.=20 So, I wouldn't use RFC 2119 language here. What is necessary for protocol i= nteroperability is whether=20 the field is optional/mandatory to send by the client-side, and optional/ma= ndatory to understand on=20 the server-side. Additionally, do you think that an end user will likely se= e a lot of meaning in the=20 client_id, which is a random string. What is the end user supposed to use t= hat information for?=20 Another example:=20 " Extensions and profiles of this specification MAY expand this list, but Authorization Servers MUST accept or ignore all parameters on this list. The Authorization Server MUST ignore any additional parameters sent by the Client that it does not understand. " In the first sentence you don't want to use RFC 2119 language either. If th= ere are ways to extend the=20 functionality via registries then point to the sections that explain how to= extend it. The next two=20 sentences are confusing. It seems that you want to have any additional para= meter to be purely optional=20 for the authorization server to understand. That's fine but what does this = sentence then mean:=20 "Authorization Servers MUST accept or ignore all parameters on this list."? * An editorial issue: There is an excessive usage of capitalization in the = document. If you look=20 at previously published RFCs in the OAuth working group you will noticed th= at the RFC editor=20 changes those to lower-case. For example, just use authorization server ins= tead of Authorization=20 Server. Same for Client, Developer, etc. Ciao Hannes PS: I obviously noticed that the WGLC had trigger some discussion. In some = sense that's good since this=20 is what WGLCs are for. On the other hand it would be good to reach an agree= ment on the open issues.=20 From jricher@mitre.org Tue Jun 4 10:33:55 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9CD21F8FB6 for ; Tue, 4 Jun 2013 10:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.779 X-Spam-Level: X-Spam-Status: No, score=-5.779 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBKV6roMCmfI for ; Tue, 4 Jun 2013 10:33:49 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5EC21F9EE0 for ; Tue, 4 Jun 2013 09:00:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EF67E1F0351; Tue, 4 Jun 2013 12:00:33 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C1E341F038E; Tue, 4 Jun 2013 12:00:33 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 4 Jun 2013 12:00:33 -0400 Message-ID: <51AE0EF3.8040809@mitre.org> Date: Tue, 4 Jun 2013 11:59:47 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <1373E8CE237FCC43BCA36C6558612D2A9F1480@USCHMBX001.nsn-intra.net> In-Reply-To: <1373E8CE237FCC43BCA36C6558612D2A9F1480@USCHMBX001.nsn-intra.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: "OAuth@ietf.org" Subject: Re: [OAUTH-WG] FW: Review of the Dynamic Registration Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:33:55 -0000 On 06/04/2013 08:06 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Re-send: my earlier mail seems to have gotten lost. > > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, June 04, 2013 2:21 PM > To: 'OAuth@ietf.org' > Subject: Review of the Dynamic Registration Draft > > Dear draft authors, Dear working group, > > I read through the dynamic registration draft and here a few observations I have made: > > * The 'Initial Access Token' is really more a developer identifier. If you give it a different > name then it might be more intuitive for the reader since the current wording is a bit fuzzy. "Initial Access Token" is a name added in the latest draft to call it out as a separate object. I'd be happy to have a better name for it, but it's not a developer identifier, because: > For example, in Section 1.3 you only hint to the fact that this identifier refers to the > developer later in the text. This is because it might not refer to the developer at all. In practice, we've seen it tied to a developer, but it could be tied to an enterprise's application publishing system or any number of other things. At its root, it's an OAuth 2.0 access token that controls authorized access to the Client Registration Endpoint. However you want to get an OAuth 2.0 token is your own business and out of scope for the draft. > > * From the description I have problems understanding the value of the "Registration Access Token". > I believe you can accomplish exactly the same security benefits if you just use the client > credentials instead. Do I see this wrong? Yes, you've got it wrong. The lifecycles and targets of these two items are different, as explained in the client tokens and credentials section (1.3). The registration access token is issued by the registration endpoint and used at the client information endpoint. The client credentials are issued by the registration endpoint and used at the token endpoint. The former is required, the latter is optional. While it seems like you can just re-use the client credentials, this is only true if you have client credentials issued by the server, which isn't the case for public clients. There is still a use for public clients, though it's very true that clients that used to *have* to be public (such as native clients) can now register each instance on its own behalf using this protocol and they don't need to be public anymore. However, requiring public clients to have client credentials just to do registration doesn't make sense and is very difficult to implement. We know this because the OpenID Connect group *tried* to do this and it doesn't work. I would rather we learn from their well-documented mistake instead of trying to repeat it again. And there are still useful public clients, such as: > * OAuth 2.0 supports a number of authorization grants and I have assumed that the dynamic > client registration would focus on the authorization code grant. To my surprise the > implicit grant also seems to be supported. The implicit grant has weak security properties > and it's usage should actually be discouraged. Why would you want to support the implicit > grant for the dynamic client registration? The dynamic registration draft should support any and all authorization grants, why would it focus on just one? And the use case for a dynamic registration of an implicit grant is clear in the case where you have an implicit client talking to multiple authorization servers. It needs to get its client_id from each auth server in order to talk to them, otherwise you've got to come up with some other mechanism to publish an agreed-upon client_id for a public client across all auth servers. Why do that when you can just register at each one like you would with any other grant type? > > * There is a lot of RFC 2119 language in the document but it is used in a way that does not > relate to protocol interoperability. Every time you write SHOULD or MAY think about whether > a developer could write some useful code. Just to give you an example: > > " > client_name > Human-readable name of the Client to be presented to the user. If > omitted, the Authorization Server MAY display the raw "client_id" > value to the user instead. > " > > First, in this sentence what is presented to the user isn't really part of protocol interoperability. > So, I wouldn't use RFC 2119 language here. What is necessary for protocol interoperability is whether > the field is optional/mandatory to send by the client-side, and optional/mandatory to understand on > the server-side. Additionally, do you think that an end user will likely see a lot of meaning in the > client_id, which is a random string. What is the end user supposed to use that information for? It's a suggestion for consistent user experience at the authorization page and letting the developers of the applications on both ends know what a server might do with that particular field. If it's better for this to be non-normative, we can lowercase all of those. > > Another example: > " > Extensions and profiles of this specification MAY expand this list, > but Authorization Servers MUST accept or ignore all parameters on > this list. The Authorization Server MUST ignore any additional > parameters sent by the Client that it does not understand. > " > > In the first sentence you don't want to use RFC 2119 language either. If there are ways to extend the > functionality via registries then point to the sections that explain how to extend it. The next two > sentences are confusing. It seems that you want to have any additional parameter to be purely optional > for the authorization server to understand. That's fine but what does this sentence then mean: > "Authorization Servers MUST accept or ignore all parameters on this list."? That last bit's probably a wording problem, what I'm trying to say is that the server can't reject a message with one of the parameters on this list. This is for interoperability purposes -- you're allowed to at the very least send everything on this list to any server. Some servers can accept more, and some might require more and need to document that appropriately. If there's a better way to tie that together, let me know. > > * An editorial issue: There is an excessive usage of capitalization in the document. If you look > at previously published RFCs in the OAuth working group you will noticed that the RFC editor > changes those to lower-case. For example, just use authorization server instead of Authorization > Server. Same for Client, Developer, etc. I was trying to use the terminology as defined and used in RFC6749. I can lowercase those. > > Ciao > Hannes > > PS: I obviously noticed that the WGLC had trigger some discussion. In some sense that's good since this > is what WGLCs are for. On the other hand it would be good to reach an agreement on the open issues. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Tue Jun 4 10:34:53 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B2221F9BAF for ; Tue, 4 Jun 2013 10:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.915 X-Spam-Level: X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+56TTK06Hlj for ; Tue, 4 Jun 2013 10:34:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C568A21F9EE9 for ; Tue, 4 Jun 2013 09:03:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5C9131F036A; Tue, 4 Jun 2013 12:03:52 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4C3DE1F0377; Tue, 4 Jun 2013 12:03:52 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 4 Jun 2013 12:03:52 -0400 Message-ID: <51AE0FBA.1010805@mitre.org> Date: Tue, 4 Jun 2013 12:03:06 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Derek Atkins References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <519652C9.5010303@mitre.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:34:53 -0000 We used to have a mechanism for clients to rotate their client secret, but that was removed some drafts ago, after list discussion on its utility. -- Justin On 06/03/2013 10:00 PM, Derek Atkins wrote: > Justin Richer writes: > >> I think the concern here is that rotation of client credential is not >> something discussed before. Before we put it in the spec we should >> consider the reasons for doing it and what problems it solves. >> >> The client doesn't get to choose when its credentials get rotated. It used to >> be able to, but now it's purely the server's choice, including whether or not >> it wants to rotate things at all. I think this confusion can be cleared up >> with the explicit lifecycle discussion getting pulled out into one place. > From a security standpoint, either side should be able to rotate keys. > It should not be only one side's choice; either side should have the > option to refresh due to local policy (or worse, local knowledge of an > issue). > > -derek From jricher@mitre.org Tue Jun 4 10:46:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5FB21E80A5 for ; Tue, 4 Jun 2013 10:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWlD+NAI2ESw for ; Tue, 4 Jun 2013 10:46:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5986821F9F24 for ; Tue, 4 Jun 2013 09:46:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 65FED1F03CA; Tue, 4 Jun 2013 12:46:38 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 69B6A1F038C; Tue, 4 Jun 2013 12:46:33 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 4 Jun 2013 12:46:33 -0400 Message-ID: <51AE19BA.1090806@mitre.org> Date: Tue, 4 Jun 2013 12:45:46 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org> <519B9623.8030403@mitre.org> <13631B8F-D3FA-47E6-9176-812840BA507F@oracle.com> <1AB6F2B5-BBDE-476C-B30E-33510EAA024C@oracle.com> In-Reply-To: <1AB6F2B5-BBDE-476C-B30E-33510EAA024C@oracle.com> Content-Type: multipart/alternative; boundary="------------080405080203020503030403" X-Originating-IP: [129.83.31.56] Cc: Derek Atkins , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:46:49 -0000 --------------080405080203020503030403 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I agree with the goal of standardizing on identifying software instances, but I think it's out of scope to do so inside of dynamic registration when most dynamic registration use cases don't need it and won't use it. I think that you've got to define discovery, assertion contents, and a few other things in order to make it work and interoperable across different services. Do we really want to define assertion formats and server/client discovery and processing rules inside of dynamic registration? I really don't think that's beneficial, either to dynamic registration itself or to the problem that the software instance tracking is trying to solve. If this gets proposed as a separate document, I will support it and I will help work on it. Heck, I'll even help edit the thing (or things) if people want. But I strongly believe that it's a separate concern from dynamic client registration, and I think it needs to have its own proper discussion apart from that. -- Justin On 06/04/2013 02:28 AM, Phil Hunt wrote: > Yes. However the contents and format are out of scope. > > Phil > > On 2013-06-03, at 22:32, Torsten Lodderstedt > wrote: > >> Hi Phil, >> >> isn't the initial registration token such a credential, which allows >> to co-relate different instances of the same software? >> >> regards, >> Torsten. >> >> >> >> Phil Hunt > schrieb: >> >> Finally i believe the bb+ doesn't have the issue because they are solving with an initial authn credential that contains the same info. >> >> My feeling is that this functionality needs to be standardized one way or another. >> >> Phil >> >> On 2013-06-03, at 19:16, Derek Atkins > wrote: >> >> Phil, Phil Hunt > > writes: >> >> Not quite. I will call you. I am saying we are >> transitioning from the old public client model. The new >> model proposes quasi-confidential characteristics but in >> some respects is missing key information from the public >> m! odel. Namely that a group of clients are related and >> there have common behaviour and security characteristics. >> We need to add to the self-asserted model an assertion >> equiv to the old common client_id. That is all. I am NOT >> looking for a proof of application identity here. That is >> too far. But certainly what we define here can open that >> door. Phil >> >> I think I understand what you're saying here. In the "old >> way", a public client had a constant client_id amongst all >> instances of that public client, whereas in the "new way", a >> public client will have different client_ids amongst all >> instances of that client. You feel this is a loss, whereas it >> seems most people seem to feel this change is okay. Since you >> are effectively the lone dissenter on this one topic, let me >> ask you a question: What is a technical reason that you need >> to have a constant, assertion that would bind to! gether (in >> a non-authenticated way) multiple instances of a client? I >> believe that Justin has provides some attacks against this; >> so I'm trying to understand, (with my chair hat on), why you >> need this functionality? With my security-mafia hat on, I >> feel like the old way was bad, and I much prefer the newer >> way where each instance of a client gets its own ID and a >> locally-stored secret. -derek -- Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >> >> ------------------------------------------------------------------------ >> >> 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 --------------080405080203020503030403 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I agree with the goal of standardizing on identifying software instances, but I think it's out of scope to do so inside of dynamic registration when most dynamic registration use cases don't need it and won't use it. I think that you've got to define discovery, assertion contents, and a few other things in order to make it work and interoperable across different services. Do we really want to define assertion formats and server/client discovery and processing rules inside of dynamic registration? I really don't think that's beneficial, either to dynamic registration itself or to the problem that the software instance tracking is trying to solve.

If this gets proposed as a separate document, I will support it and I will help work on it. Heck, I'll even help edit the thing (or things) if people want. But I strongly believe that it's a separate concern from dynamic client registration, and I think it needs to have its own proper discussion apart from that.

-- Justin

On 06/04/2013 02:28 AM, Phil Hunt wrote:

Yes. However the contents and format are out of scope.

Phil

On 2013-06-03, at 22:32, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Phil,

isn't the initial registration token such a credential, which allows to co-relate different instances of the same software?

regards,
Torsten.

Phil Hunt <phil.hunt@oracle.com> schrieb:

Finally i believe the bb+ doesn't have the issue because they are solving with an initial authn credential that contains the same info. 

My feeling is that this functionality needs to be standardized one way or another. 

Phil

On 2013-06-03, at 19:16, Derek Atkins <derek@ihtfp.com> wrote:

Phil,

Phil Hunt <phil.hunt@oracle.com> writes:

Not quite. I will call you. 

I am saying we are transitioning from the old public client model. The new
model proposes quasi-confidential characteristics but in some respects is
missing key information from the public m!
 odel. 
Namely that a group of clients
are related and there have common behaviour and security characteristics. 

We need to add to the self-asserted model an assertion equiv to the old common
client_id. That is all. 

I am NOT looking for a proof of application identity here. That is too far.
But certainly what we define here can open that door. 

Phil
I think I understand what you're saying here.  In the "old way", a
public client had a constant client_id amongst all instances of that
public client, whereas in the "new way", a public client will have
different client_ids amongst all instances of that client.  You feel
this is a loss, whereas it seems most people seem to feel this change is
okay.

Since you are effectively the lone dissenter on this one topic, let me
ask you a question: What is a technical reason that you need to have a
constant, assertion that would bind to!
 gether
(in a non-authenticated
way) multiple instances of a client?

I believe that Justin has provides some attacks against this; so I'm
trying to understand, (with my chair hat on), why you need this
functionality?

With my security-mafia hat on, I feel like the old way was bad, and I
much prefer the newer way where each instance of a client gets its own
ID and a locally-stored secret.

-derek

-- 
Derek Atkins                 617-623-3745
derek@ihtfp.com             www.ihtfp.com
Computer and Internet Security Consultant

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

--------------080405080203020503030403-- From jricher@mitre.org Tue Jun 4 10:49:27 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007EE21F992C for ; Tue, 4 Jun 2013 10:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.086 X-Spam-Level: X-Spam-Status: No, score=-6.086 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6Wz3l7sq1yv for ; Tue, 4 Jun 2013 10:49:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3745321F9D32 for ; Tue, 4 Jun 2013 09:53:29 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D16F61F0802; Tue, 4 Jun 2013 12:53:28 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BF8451F078B; Tue, 4 Jun 2013 12:53:28 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 4 Jun 2013 12:53:28 -0400 Message-ID: <51AE1B5A.1010904@mitre.org> Date: Tue, 4 Jun 2013 12:52:42 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Donald F Coffin References: <51ABA293.4070700@cs.tcd.ie> <003e01ce6090$4d664c30$e832e490$@reminetworks.com> In-Reply-To: <003e01ce6090$4d664c30$e832e490$@reminetworks.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] TLS question from token revocation draft iesg evaluation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:49:27 -0000 This question will come up on other drafts as well, like Dynamic Registration and Introspection that I've been working on, so we should really decide what the language is going to be in order to be consistent. Would this be also filed as an errata or something on RFC6749/6750? (Honestly not sure what/if the process is.) I will say from the average app developer's perspective, though, that most people are just going to look to see if there's an "https" in the URL and call it done, so I'm personally not sure what a practical difference it will make how we specify things here. The people that care about TLS versions will already know to use 1.2 or whatever's the latest and greatest, and everyone else isn't going to check the version. However, I made this same argument back when this first came up in OAuth core and we still ended up having the TLS version language in there in the end. -- Justin On 06/03/2013 03:26 PM, Donald F Coffin wrote: > Stephen, > > I feel it should be MANDATORY to implement TLS1.2, especially since NIST is > in the process of deprecating TLS1.0 as a supported version. > > Best regards, > Don > Donald F. Coffin > Founder/CTO > > REMI Networks > 22751 El Prado Suite 6216 > Rancho Santa Margarita, CA 92688-3836 > > Phone: (949) 636-8571 > Email: donald.coffin@reminetworks.com > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Sunday, June 02, 2013 12:53 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] TLS question from token revocation draft iesg evaluation > > > Hiya, > > This draft has a couple of minor changes needed as a result of IESG review > (see [1]) but one question came up that I wanted to bring back to the WG to > see what you think. Any good answer should be fine btw, this isn't a case of > the insisting on stuff. > > The question is whether the WG think that the situation related to the > mandatory-to-implement TLS version has changed since that was last discussed > a couple of years ago. There have been changes in the implementation status > of TLS1.2 since then, mainly driven by the discovery of weaknesses with some > deployment choices for TLS1.0. > > So - should we stick with the TLS1.0 as MTI and TLS1.2 as a SHOULD implement > or can we now safely bump up to > TLS1.2 as MTI? > > And since its been a source of confusion here before, we're discussing > what's mandatory to *implement* not what's mandatory to *use*. > > Thanks, > S. > > PS: the other changes are mechanical so don't need to take up WG time but > feel free to comment to the list, chairs, authors, me, ... whatever. > > [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ballot/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From aanganes@mitre.org Tue Jun 4 11:29:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A082B21F99B7 for ; Tue, 4 Jun 2013 11:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcbXdFauqIrH for ; Tue, 4 Jun 2013 11:29:38 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 43C6F21F9995 for ; Tue, 4 Jun 2013 10:56:08 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BDFC01F1177 for ; Tue, 4 Jun 2013 13:56:07 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8E8F31F0370 for ; Tue, 4 Jun 2013 13:56:07 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.181]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Tue, 4 Jun 2013 13:56:07 -0400 From: "Anganes, Amanda L" To: "oauth@ietf.org" Thread-Topic: LC Review of draft-ietf-oauth-dyn-reg-12 Thread-Index: AQHOYUzJg7cZmyhkWk27sds8GAUNvw== Date: Tue, 4 Jun 2013 17:56:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.146.16.16] Content-Type: multipart/alternative; boundary="_000_CDD3A2758B98aanganesmitreorg_" MIME-Version: 1.0 Subject: [OAUTH-WG] LC Review of draft-ietf-oauth-dyn-reg-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:29:44 -0000 --_000_CDD3A2758B98aanganesmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable [[Apologies if you receive this twice, I accidentally sent this from one of= my other email addresses this morning (Outlook seems to have been confused= ).]] Hello, I have reviewed the Dynamic Registration draft and offer some comments belo= w: After section 1.2, I suggest adding a flow diagram (similar to those in the= core OAuth 2.0 spec), showing the interaction of the client/developer with= the respective endpoints, and the requests and responses involved. I think= this will make the spec easier to read. Inside the 3rd paragraph of section 1.3, there is text buried that talks ab= out client credential rotation (client_secret and Registration Access Token= ). I think this notion of secret rotation should be called out in its own p= aragraph or subsection and labeled as such. Suggested text (I'm not sure wh= ere it should go): Section X.X Client Credential Rotation The Authorization Server may rotate the Client's issued client_secret and/o= r Registration Access Token. The client_secret MAY be rotated at any time, = in which case the Client will likely discover that their secret has expired= via attempting and failing to make a request. The Registration Access Toke= n SHOULD only be rotated in response to an update or read request, in which= case the new Registration Access Token will be returned in the response ba= ck to the Client. The Client can check their current credentials at any tim= e by performing a READ or UPDATE operation at the Client Configuration Endp= oint. Section 3 Client Registration Endpoint This section should use the phrase "this endpoint may be open, or it may be= an OAuth 2.0 Protected Resource", rather than just stating that it may acc= ept an initial token. I *think* that the choice is an either/or for a given= server (ie, a server cannot offer both open and protected registration), b= ut that should be clarified as well. In the 4th paragraph, the final sentence ("As such, the Client Configuratio= n Endpoint MUST=85") refers to the Configuration endpoint, not the Registra= tion endpoint. The text is already in Section 4 so it should just be delete= d here. Section 3.1 Client Registration Request The lead-ups to the two example requests are phrased oddly. The difference = between the two sample requests is not whether the client has a token, it's= whether the endpoint is open or protected. Suggest changing them to "For e= xample, if the Client Registration Endpoint supports open registration, the= client could send the following request" and "Alternatively, if the endpoi= nt is an OAuth 2.0 protected resource, the client MUST include an OAuth 2.0= Access Token/the Initial Access Token in its request, presented as a Beare= r token using the Authorization header according to RFC6749." (My phrasing = at the end regarding how to present the AT may be off; point is that it sho= uld be called out.) Nits in section 7 Security Considerations: 2nd paragraph, first sentence: "=85requests to the *Client* Registration En= dpoint" 6th paragraph, first sentence: "=85the Registration Access Token should not= expire=85" I think this should be a SHOULD NOT? Same paragraph, 4th sentence has a non-capitolized "client" that should be = "Client" (although, after reading Hannes' review, maybe the capitalized ins= tances should all be lowercased instead). I also second Hannes' comment that the RFC 2119 language feels off througho= ut the spec, suggest doing a careful read to check those. Finally, to address the Initial Access Token / Registration Access Token di= scussion that has been ongoing: My initial response after reading this draft (and having followed the discu= ssion) was to say, remove the "Initial Access Token" term completely and in= stead just clarify the text to say that "the Client Registration Endpoint M= AY be an OAuth 2.0 protected resource, but the details of how a given clien= t or developer goes about acquiring an Access Token for use at this endpoin= t is out-of-scope". I spoke to Justin about this and he pointed out that th= is term was only added recently, and it was added because of confusion arou= nd how the Client Registration Endpoint was defined, and what it means to a= uthenticate to it. I don't think the new name/definition/explanation has he= lped; but the previous drafts were also missing the "OAuth 2.0 protected re= source" language. To be clear, I think this functionality is absolutely nec= essary, but we need to clarify its explanation On the other hand, the Registration Access Token seems very clear to me. I = think that term should be called out as a named entity, since it is 'specia= l' - it's not issued by a token endpoint, but by the Client Registration En= dpoint. I see a few options that might help: 1) Perhaps "Initial Access Token" is a bad name. Unfortunately, I think the= right names are "Registration Access Token" for accessing the Registration= Endpoint, and "Configuration Access Token" for accessing the Configuration= Endpoint. This would require changing code, since the configuration token = is returned in the Client Registration Response. 1.a) The examples in Appendix B only use the IAT for Developer authenticati= on/tracking (all clients registered using the same IAT can be traced to the= developer that was issued that particular token). Is that the only use cas= e? If there is always a developer in the loop in the protected case, then "= Developer Access Token" might be appropriate. This is less generic than the= suggestion above, but would not require changing code and might be an impr= ovement over what's there now. 2) Perhaps if the spec language were clarified and used the "OAuth 2.0 prot= ected resource" language, the Initial Access Token term could be removed fr= om the document entirely. I don't think the previous drafts got it right, b= ut I think we can do better than those explanations while still avoiding gi= ving a fancy name to something that is *just* an OAuth 2.0 Access Token. --Amanda --_000_CDD3A2758B98aanganesmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <66EEBDAFF6404D4193EDE604FB8FAC33@imc.mitre.org> Content-Transfer-Encoding: quoted-printable

[[Apologies if you receive this twice, I accidentally sent this from o= ne of my other email addresses this morning (Outlook seems to have been con= fused).]]

Hello,

I have reviewed the Dynamic Registration draft and offer some comments= below:

After section 1.2, I suggest adding a flow diagram (similar to those i= n the core OAuth 2.0 spec), showing the interaction of the client/developer= with the respective endpoints, and the requests and responses involved. I = think this will make the spec easier to read.

Inside the 3rd paragraph of section 1.3, there is text buried that tal= ks about client credential rotation (client_secret and Registration Access = Token). I think this notion of secret rotation should be called out in its = own paragraph or subsection and labeled as such. Suggested text (I'm not sure where it should go):

Sec= tion X.X Client Credential Rotation

The Authorization Server may rotate the Client's issued client_secret = and/or Registration Access Token. The client_secret MAY be rotated at any t= ime, in which case the Client will likely discover that their secret has ex= pired via attempting and failing to make a request. The Registration Access Token SHOULD only be rotated in= response to an update or read request, in which case the new Registration = Access Token will be returned in the response back to the Client. The Clien= t can check their current credentials at any time by performing a READ or UPDATE operation at the Client Configu= ration Endpoint.

Section 3 Client Registration Endpoint

This section should use the phrase "this endpoint may be open, or= it may be an OAuth 2.0 Protected Resource", rather than just stating = that it may accept an initial token. I *think* that the choice is an either/or for a given server (ie, a server cannot offer both open and protected regi= stration), but that should be clarified as well.

In the 4th paragraph, the final sentence ("As such, the Client Co= nfiguration Endpoint MUST=85") refers to the Configuration endpoint, n= ot the Registration endpoint. The text is already in Section 4 so it should= just be deleted here.

Section 3.1 Client Registration Request

The lead-ups to the two example requests are phrased oddly. The differ= ence between the two sample requests is not whether the client has a token,= it's whether the endpoint is open or protected. Suggest changing them to &= quot;For example, if the Client Registration Endpoint supports open registration, the client could send the following r= equest" and "Alternatively, if the endpoint is an OAuth 2.0 prote= cted resource, the client MUST include an OAuth 2.0 Access Token/the Initia= l Access Token in its request, presented as a Bearer token using the Authorization header according to RFC6749." = (My phrasing at the end regarding how to present the AT may be off; point i= s that it should be called out.)

Nits in section 7 Security Considerations:

2nd paragraph, first sentence: "=85requests to the *Client* Registration Endpoint"

6th paragraph, first sentence: "=85the Registration Access Token = should not expire=85" I think this should be a SHOULD NOT?

Same paragraph, 4th sentence has a non-capitolized "client" = that should be "Client" (although, after reading Hannes' review, = maybe the capitalized instances should all be lowercased instead).

I also second Hannes' comment that the RFC 2119 language feels off thr= oughout the spec, suggest doing a careful read to check those.

Finally, to address the Initial Access Token / Registration Access Tok= en discussion that has been ongoing:

My initial response after reading this draft (and having followed the = discussion) was to say, remove the "Initial Access Token" term co= mpletely and instead just clarify the text to say that "the Client Reg= istration Endpoint MAY be an OAuth 2.0 protected resource, but the details of how a given client or developer goes about ac= quiring an Access Token for use at this endpoint is out-of-scope". I s= poke to Justin about this and he pointed out that this term was only added = recently, and it was added because of confusion around how the Client Registration Endpoint was defined, and wha= t it means to authenticate to it. I don't think the new name/definition/exp= lanation has helped; but the previous drafts were also missing the "OA= uth 2.0 protected resource" language. To be clear, I think this functionality is absolutely necessary, but we ne= ed to clarify its explanation

On the other hand, the Registration Access Token seems very clear to m= e. I think that term should be called out as a named entity, since it is 's= pecial' - it's not issued by a token endpoint, but by the Client Registrati= on Endpoint.

I see a few options that might help:

1) Perhaps "Initial Access Token" is a bad name. Unfortunate= ly, I think the right names are "Registration Access Token" for a= ccessing the Registration Endpoint, and "Configuration Access Token&qu= ot; for accessing the Configuration Endpoint. This would require changing code, since the configuration token is returned in the Client Reg= istration Response.

1.a) The examples in Appendix B only use the IAT for Developer authent= ication/tracking (all clients registered using the same IAT can be traced t= o the developer that was issued that particular token). Is that the only us= e case? If there is always a developer in the loop in the protected case, then "Developer Access Token"= might be appropriate. This is less generic than the suggestion above, but = would not require changing code and might be an improvement over what's the= re now.

2) Perhaps if the spec language were clarified and used the "OAut= h 2.0 protected resource" language, the Initial Access Token term coul= d be removed from the document entirely. I don't think the previous drafts = got it right, but I think we can do better than those explanations while still avoiding giving a fancy name to someth= ing that is *just* an OAuth 2.0 = Access Token.

--Amanda

--_000_CDD3A2758B98aanganesmitreorg_-- From gffletch@aol.com Tue Jun 4 11:29:58 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54CC21F9A47 for ; Tue, 4 Jun 2013 11:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72zkR13qPD4n for ; Tue, 4 Jun 2013 11:29:54 -0700 (PDT) Received: from omr-m08.mx.aol.com (omr-m08.mx.aol.com [64.12.222.129]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7F621F9701 for ; Tue, 4 Jun 2013 10:56:35 -0700 (PDT) Received: from mtaout-ma05.r1000.mx.aol.com (mtaout-ma05.r1000.mx.aol.com [172.29.41.5]) by omr-m08.mx.aol.com (Outbound Mail Relay) with ESMTP id DEE977004C93D; Tue, 4 Jun 2013 13:56:34 -0400 (EDT) Received: from palantir.local (unknown [10.172.2.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 6A7F5E0000B2; Tue, 4 Jun 2013 13:56:33 -0400 (EDT) Message-ID: <51AE2A50.4030800@aol.com> Date: Tue, 04 Jun 2013 13:56:32 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Justin Richer References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org> <519B9623.8030403@mitre.org> <13631B8F-D3FA-47E6-9176-812840BA507F@oracle.com> <1AB6F2B5-BBDE-476C-B30E-33510EAA024C@oracle.com> <51AE19BA.1090806@mitre.org> In-Reply-To: <51AE19BA.1090806@mitre.org> Content-Type: multipart/alternative; boundary="------------000409080309080501020604" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1370368594; bh=p7BMjVlj72jNHrvsUBKwcz5Bi84iFqn3PEqMzOX/Kdk=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=n2SqI2d7vFdi6cnAWbzkFqDFXPYxE4L0i1ro0hhGJY57xP6E3YmHoQOi6Pb9XlxJb 79HhRxRgoHEilk+rXF5U7t/hPWTu21B9Vgci5HqX1KBR9dx1wNvllIFNY7/tP0R51q w2d96X+P9gvImBWMELQJmy/8C5lxcA4TOo4DTQDg= X-AOL-SCOLL-SCORE: 0:2:458576608:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d290551ae2a513ea5 X-AOL-IP: 10.172.2.235 Cc: Derek Atkins , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:29:58 -0000 This is a multi-part message in MIME format. --------------000409080309080501020604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 for leaving dyn reg as is and working on a profile that enables this more domain specific scenario. I agree with Phil and Justine that it's important... I just don't think it should be put in the core dyn reg spec. Thanks, George On 6/4/13 12:45 PM, Justin Richer wrote: > I agree with the goal of standardizing on identifying software > instances, but I think it's out of scope to do so inside of dynamic > registration when most dynamic registration use cases don't need it > and won't use it. I think that you've got to define discovery, > assertion contents, and a few other things in order to make it work > and interoperable across different services. Do we really want to > define assertion formats and server/client discovery and processing > rules inside of dynamic registration? I really don't think that's > beneficial, either to dynamic registration itself or to the problem > that the software instance tracking is trying to solve. > > If this gets proposed as a separate document, I will support it and I > will help work on it. Heck, I'll even help edit the thing (or things) > if people want. But I strongly believe that it's a separate concern > from dynamic client registration, and I think it needs to have its own > proper discussion apart from that. > > -- Justin > > On 06/04/2013 02:28 AM, Phil Hunt wrote: >> Yes. However the contents and format are out of scope. >> >> Phil >> >> On 2013-06-03, at 22:32, Torsten Lodderstedt > > wrote: >> >>> Hi Phil, >>> >>> isn't the initial registration token such a credential, which allows >>> to co-relate different instances of the same software? >>> >>> regards, >>> Torsten. >>> >>> >>> >>> Phil Hunt > schrieb: >>> >>> Finally i believe the bb+ doesn't have the issue because they are solving with an initial authn credential that contains the same info. >>> >>> My feeling is that this functionality needs to be standardized one way or another. >>> >>> Phil >>> >>> On 2013-06-03, at 19:16, Derek Atkins > wrote: >>> >>> Phil, Phil Hunt >> > writes: >>> >>> Not quite. I will call you. I am saying we are >>> transitioning from the old public client model. The new >>> model proposes quasi-confidential characteristics but in >>> some respects is missing key information from the public >>> m! odel. Namely that a group of clients are related and >>> there have common behaviour and security >>> characteristics. We need to add to the self-asserted >>> model an assertion equiv to the old common client_id. >>> That is all. I am NOT looking for a proof of application >>> identity here. That is too far. But certainly what we >>> define here can open that door. Phil >>> >>> I think I understand what you're saying here. In the "old >>> way", a public client had a constant client_id amongst all >>> instances of that public client, whereas in the "new way", a >>> public client will have different client_ids amongst all >>> instances of that client. You feel this is a loss, whereas >>> it seems most people seem to feel this change is okay. Since >>> you are effectively the lone dissenter on this one topic, >>> let me ask you a question: What is a technical reason that >>> you need to have a constant, assertion that would bind to! >>> gether (in a non-authenticated way) multiple instances of a >>> client? I believe that Justin has provides some attacks >>> against this; so I'm trying to understand, (with my chair >>> hat on), why you need this functionality? With my >>> security-mafia hat on, I feel like the old way was bad, and >>> I much prefer the newer way where each instance of a client >>> gets its own ID and a locally-stored secret. -derek -- Derek >>> Atkins 617-623-3745 derek@ihtfp.com >>> www.ihtfp.com Computer and Internet >>> Security Consultant >>> >>> ------------------------------------------------------------------------ >>> >>> 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 --------------000409080309080501020604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1 for leaving dyn reg as is and working on a profile that enables this more domain specific scenario. I agree with Phil and Justine that it's important... I just don't think it should be put in the core dyn reg spec.

Thanks,
George

On 6/4/13 12:45 PM, Justin Richer wrote:

I agree with the goal of standardizing on identifying software instances, but I think it's out of scope to do so inside of dynamic registration when most dynamic registration use cases don't need it and won't use it. I think that you've got to define discovery, assertion contents, and a few other things in order to make it work and interoperable across different services. Do we really want to define assertion formats and server/client discovery and processing rules inside of dynamic registration? I really don't think that's beneficial, either to dynamic registration itself or to the problem that the software instance tracking is trying to solve.

If this gets proposed as a separate document, I will support it and I will help work on it. Heck, I'll even help edit the thing (or things) if people want. But I strongly believe that it's a separate concern from dynamic client registration, and I think it needs to have its own proper discussion apart from that.

-- Justin

On 06/04/2013 02:28 AM, Phil Hunt wrote:
Yes. However the contents and format are out of scope.

Phil

On 2013-06-03, at 22:32, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Phil,

isn't the initial registration token such a credential, which allows to co-relate different instances of the same software?

regards,
Torsten.
Phil Hunt <phil.hunt@oracle.com> schrieb:
Finally i believe the bb+ doesn't have the issue because they are solving with an initial authn credential that contains the same info. 

My feeling is that this functionality needs to be standardized one way or another. 

Phil

On 2013-06-03, at 19:16, Derek Atkins <derek@ihtfp.com> wrote:

Phil,

Phil Hunt <phil.hunt@oracle.com> writes:

Not quite. I will call you. 

I am saying we are transitioning from the old public client model. The new
model proposes quasi-confidential characteristics but in some respects is
missing key information from the public m!
 odel. 
Namely that a group of clients
are related and there have common behaviour and security characteristics. 

We need to add to the self-asserted model an assertion equiv to the old common
client_id. That is all. 

I am NOT looking for a proof of application identity here. That is too far.
But certainly what we define here can open that door. 

Phil
I think I understand what you're saying here.  In the "old way", a
public client had a constant client_id amongst all instances of that
public client, whereas in the "new way", a public client will have
different client_ids amongst all instances of that client.  You feel
this is a loss, whereas it seems most people seem to feel this change is
okay.

Since you are effectively the lone dissenter on this one topic, let me
ask you a question: What is a technical reason that you need to have a
constant, assertion that would bind to!
 gether
(in a non-authenticated
way) multiple instances of a client?

I believe that Justin has provides some attacks against this; so I'm
trying to understand, (with my chair hat on), why you need this
functionality?

With my security-mafia hat on, I feel like the old way was bad, and I
much prefer the newer way where each instance of a client gets its own
ID and a locally-stored secret.

-derek

-- 
Derek Atkins                 617-623-3745
derek@ihtfp.com             www.ihtfp.com
Computer and Internet Security Consultant

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

--------------000409080309080501020604-- From aanganes@mitre.org Tue Jun 4 11:31:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3988A21F9BA2 for ; Tue, 4 Jun 2013 11:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGsGsVHBGIWv for ; Tue, 4 Jun 2013 11:31:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 02D2521F9948 for ; Tue, 4 Jun 2013 11:03:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 94EF31F0976 for ; Tue, 4 Jun 2013 14:03:14 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 78ECE1F0386 for ; Tue, 4 Jun 2013 14:03:14 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.181]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Tue, 4 Jun 2013 14:03:14 -0400 From: "Anganes, Amanda L" To: "oauth@ietf.org" Thread-Topic: LC Review of draft-ietf-oauth-dyn-reg-12 Thread-Index: AQHOYUzJg7cZmyhkWk27sds8GAUNv5kl2PQA Date: Tue, 4 Jun 2013 18:03:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.146.16.16] Content-Type: multipart/alternative; boundary="_000_CDD3A32C8B9Daanganesmitreorg_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] LC Review of draft-ietf-oauth-dyn-reg-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:31:50 -0000 --_000_CDD3A32C8B9Daanganesmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Note that this review applies to the latest spec edits from Justin's Github= , which can be found here: https://github.com/jricher/oauth-spec. The =9612= revision has not been published yet, but Justin asked me to review based o= ff of what was in the tracker, since it is more up-to-date. --Amanda From: , "Anganes, Amanda L" > Date: Tuesday, June 4, 2013 1:56 PM To: "oauth@ietf.org" > Subject: LC Review of draft-ietf-oauth-dyn-reg-12 [[Apologies if you receive this twice, I accidentally sent this from one of= my other email addresses this morning (Outlook seems to have been confused= ).]] Hello, I have reviewed the Dynamic Registration draft and offer some comments belo= w: After section 1.2, I suggest adding a flow diagram (similar to those in the= core OAuth 2.0 spec), showing the interaction of the client/developer with= the respective endpoints, and the requests and responses involved. I think= this will make the spec easier to read. Inside the 3rd paragraph of section 1.3, there is text buried that talks ab= out client credential rotation (client_secret and Registration Access Token= ). I think this notion of secret rotation should be called out in its own p= aragraph or subsection and labeled as such. Suggested text (I'm not sure wh= ere it should go): Section X.X Client Credential Rotation The Authorization Server may rotate the Client's issued client_secret and/o= r Registration Access Token. The client_secret MAY be rotated at any time, = in which case the Client will likely discover that their secret has expired= via attempting and failing to make a request. The Registration Access Toke= n SHOULD only be rotated in response to an update or read request, in which= case the new Registration Access Token will be returned in the response ba= ck to the Client. The Client can check their current credentials at any tim= e by performing a READ or UPDATE operation at the Client Configuration Endp= oint. Section 3 Client Registration Endpoint This section should use the phrase "this endpoint may be open, or it may be= an OAuth 2.0 Protected Resource", rather than just stating that it may acc= ept an initial token. I *think* that the choice is an either/or for a given= server (ie, a server cannot offer both open and protected registration), b= ut that should be clarified as well. In the 4th paragraph, the final sentence ("As such, the Client Configuratio= n Endpoint MUST=85") refers to the Configuration endpoint, not the Registra= tion endpoint. The text is already in Section 4 so it should just be delete= d here. Section 3.1 Client Registration Request The lead-ups to the two example requests are phrased oddly. The difference = between the two sample requests is not whether the client has a token, it's= whether the endpoint is open or protected. Suggest changing them to "For e= xample, if the Client Registration Endpoint supports open registration, the= client could send the following request" and "Alternatively, if the endpoi= nt is an OAuth 2.0 protected resource, the client MUST include an OAuth 2.0= Access Token/the Initial Access Token in its request, presented as a Beare= r token using the Authorization header according to RFC6749." (My phrasing = at the end regarding how to present the AT may be off; point is that it sho= uld be called out.) Nits in section 7 Security Considerations: 2nd paragraph, first sentence: "=85requests to the *Client* Registration En= dpoint" 6th paragraph, first sentence: "=85the Registration Access Token should not= expire=85" I think this should be a SHOULD NOT? Same paragraph, 4th sentence has a non-capitolized "client" that should be = "Client" (although, after reading Hannes' review, maybe the capitalized ins= tances should all be lowercased instead). I also second Hannes' comment that the RFC 2119 language feels off througho= ut the spec, suggest doing a careful read to check those. Finally, to address the Initial Access Token / Registration Access Token di= scussion that has been ongoing: My initial response after reading this draft (and having followed the discu= ssion) was to say, remove the "Initial Access Token" term completely and in= stead just clarify the text to say that "the Client Registration Endpoint M= AY be an OAuth 2.0 protected resource, but the details of how a given clien= t or developer goes about acquiring an Access Token for use at this endpoin= t is out-of-scope". I spoke to Justin about this and he pointed out that th= is term was only added recently, and it was added because of confusion arou= nd how the Client Registration Endpoint was defined, and what it means to a= uthenticate to it. I don't think the new name/definition/explanation has he= lped; but the previous drafts were also missing the "OAuth 2.0 protected re= source" language. To be clear, I think this functionality is absolutely nec= essary, but we need to clarify its explanation On the other hand, the Registration Access Token seems very clear to me. I = think that term should be called out as a named entity, since it is 'specia= l' - it's not issued by a token endpoint, but by the Client Registration En= dpoint. I see a few options that might help: 1) Perhaps "Initial Access Token" is a bad name. Unfortunately, I think the= right names are "Registration Access Token" for accessing the Registration= Endpoint, and "Configuration Access Token" for accessing the Configuration= Endpoint. This would require changing code, since the configuration token = is returned in the Client Registration Response. 1.a) The examples in Appendix B only use the IAT for Developer authenticati= on/tracking (all clients registered using the same IAT can be traced to the= developer that was issued that particular token). Is that the only use cas= e? If there is always a developer in the loop in the protected case, then "= Developer Access Token" might be appropriate. This is less generic than the= suggestion above, but would not require changing code and might be an impr= ovement over what's there now. 2) Perhaps if the spec language were clarified and used the "OAuth 2.0 prot= ected resource" language, the Initial Access Token term could be removed fr= om the document entirely. I don't think the previous drafts got it right, b= ut I think we can do better than those explanations while still avoiding gi= ving a fancy name to something that is *just* an OAuth 2.0 Access Token. --Amanda --_000_CDD3A32C8B9Daanganesmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8AFDCBC6A968B54CB57D38BA236D2B19@imc.mitre.org> Content-Transfer-Encoding: quoted-printable

Note that this review applies to the latest spec edits from Justin's G= ithub, which can be found here: https://github.com/jricher/oauth-spec. The =9612 revision h= as not been published yet, but Justin asked me to review based off of what was in the tracker, since it is more up-to-= date.

--Amanda

From: <Anganes>, "Angane= s, Amanda L" <aanganes@mitre.= org>
Date: Tuesday, June 4, 2013 1:56 PM=
To: "oauth@ietf.org" <oau= th@ietf.org>
Subject: LC Review of draft-ietf-oa= uth-dyn-reg-12

[[Apologies if you receive this twice, I accidentally sent this from o= ne of my other email addresses this morning (Outlook seems to have been con= fused).]]

Hello,

I have reviewed the Dynamic Registration draft and offer some comments= below:

Sec= tion X.X Client Credential Rotation

The Authorization Server may rotate the Client's issued client_secret = and/or Registration Access Token. The client_secret MAY be rotated at any t= ime, in which case the Client will likely discover that their secret has ex= pired via attempting and failing to make a request. The Registration Access Token SHOULD only be rotated in= response to an update or read request, in which case the new Registration = Access Token will be returned in the response back to the Client. The Clien= t can check their current credentials at any time by performing a READ or UPDATE operation at the Client Configu= ration Endpoint.

Section 3 Client Registration Endpoint

This section should use the phrase "this endpoint may be open, or= it may be an OAuth 2.0 Protected Resource", rather than just stating = that it may accept an initial token. I *think* that the choice is an either/or for a given server (ie, a server cannot offer both open and protected regi= stration), but that should be clarified as well.

In the 4th paragraph, the final sentence ("As such, the Client Co= nfiguration Endpoint MUST=85") refers to the Configuration endpoint, n= ot the Registration endpoint. The text is already in Section 4 so it should= just be deleted here.

Section 3.1 Client Registration Request

The lead-ups to the two example requests are phrased oddly. The differ= ence between the two sample requests is not whether the client has a token,= it's whether the endpoint is open or protected. Suggest changing them to &= quot;For example, if the Client Registration Endpoint supports open registration, the client could send the following r= equest" and "Alternatively, if the endpoint is an OAuth 2.0 prote= cted resource, the client MUST include an OAuth 2.0 Access Token/the Initia= l Access Token in its request, presented as a Bearer token using the Authorization header according to RFC6749." = (My phrasing at the end regarding how to present the AT may be off; point i= s that it should be called out.)

Nits in section 7 Security Considerations:

2nd paragraph, first sentence: "=85requests to the *Client* Registration Endpoint"

6th paragraph, first sentence: "=85the Registration Access Token = should not expire=85" I think this should be a SHOULD NOT?

Same paragraph, 4th sentence has a non-capitolized "client" = that should be "Client" (although, after reading Hannes' review, = maybe the capitalized instances should all be lowercased instead).

I also second Hannes' comment that the RFC 2119 language feels off thr= oughout the spec, suggest doing a careful read to check those.

Finally, to address the Initial Access Token / Registration Access Tok= en discussion that has been ongoing:

I see a few options that might help:

1) Perhaps "Initial Access Token" is a bad name. Unfortunate= ly, I think the right names are "Registration Access Token" for a= ccessing the Registration Endpoint, and "Configuration Access Token&qu= ot; for accessing the Configuration Endpoint. This would require changing code, since the configuration token is returned in the Client Reg= istration Response.

1.a) The examples in Appendix B only use the IAT for Developer authent= ication/tracking (all clients registered using the same IAT can be traced t= o the developer that was issued that particular token). Is that the only us= e case? If there is always a developer in the loop in the protected case, then "Developer Access Token"= might be appropriate. This is less generic than the suggestion above, but = would not require changing code and might be an improvement over what's the= re now.

2) Perhaps if the spec language were clarified and used the "OAut= h 2.0 protected resource" language, the Initial Access Token term coul= d be removed from the document entirely. I don't think the previous drafts = got it right, but I think we can do better than those explanations while still avoiding giving a fancy name to someth= ing that is *just* an OAuth 2.0 = Access Token.

--Amanda

--_000_CDD3A32C8B9Daanganesmitreorg_-- From gffletch@aol.com Tue Jun 4 11:32:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BE921F9C5A for ; Tue, 4 Jun 2013 11:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6eX2WzRso9Z for ; Tue, 4 Jun 2013 11:32:54 -0700 (PDT) Received: from omr-d02.mx.aol.com (omr-d02.mx.aol.com [205.188.109.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC2C21F9678 for ; Tue, 4 Jun 2013 11:10:18 -0700 (PDT) Received: from mtaout-da03.r1000.mx.aol.com (mtaout-da03.r1000.mx.aol.com [172.29.51.131]) by omr-d02.mx.aol.com (Outbound Mail Relay) with ESMTP id 6C0D070065983 for ; Tue, 4 Jun 2013 14:10:16 -0400 (EDT) Received: from palantir.local (unknown [10.172.2.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 67ADDE00019A; Tue, 4 Jun 2013 14:10:15 -0400 (EDT) Message-ID: <51AE2D85.4040101@aol.com> Date: Tue, 04 Jun 2013 14:10:13 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: George Fletcher , "oauth@ietf.org WG" References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org> <519B9623.8030403@mitre.org> <13631B8F-D3FA-47E6-9176-812840BA507F@oracle.com> <1AB6F2B5-BBDE-476C-B30E-33510EAA024C@oracle.com> <51AE19BA.1090806@mitre.org> <51AE2A50.4030800@aol.com> In-Reply-To: <51AE2A50.4030800@aol.com> Content-Type: multipart/alternative; boundary="------------070405050103060807020207" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1370369416; bh=oP2DF3QNo5wEUj3nwG2ZUaMNRtlgqMU2dk3nh52t3q4=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=c2m1tA7jvyVCSIJdom0TEL8skEC13pH57Jq1GM0O16FY7QLQXwSRALIxq9XUX6xe2 ZTj639myYmEq0LmMekoo+qSPKa8/iBeuBS70qHcB5xbZGgQkdsXf2XNeaSL0dJEgPT 8NdfDPq88I6r51dN6V2S4d+nIboxfqFDj1G4wn6E= X-AOL-SCOLL-SCORE: 0:2:466582368:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d338351ae2d862c8e X-AOL-IP: 10.172.2.235 Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:33:00 -0000 This is a multi-part message in MIME format. --------------070405050103060807020207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Argh! Typos (due to iPhone? no bad brain <-> hand connections). Sorry Justin! On 6/4/13 1:56 PM, George Fletcher wrote: > +1 for leaving dyn reg as is and working on a profile that enables > this more domain specific scenario. I agree with Phil and Justine that > it's important... I just don't think it should be put in the core dyn > reg spec. > > Thanks, > George > > On 6/4/13 12:45 PM, Justin Richer wrote: >> I agree with the goal of standardizing on identifying software >> instances, but I think it's out of scope to do so inside of dynamic >> registration when most dynamic registration use cases don't need it >> and won't use it. I think that you've got to define discovery, >> assertion contents, and a few other things in order to make it work >> and interoperable across different services. Do we really want to >> define assertion formats and server/client discovery and processing >> rules inside of dynamic registration? I really don't think that's >> beneficial, either to dynamic registration itself or to the problem >> that the software instance tracking is trying to solve. >> >> If this gets proposed as a separate document, I will support it and I >> will help work on it. Heck, I'll even help edit the thing (or things) >> if people want. But I strongly believe that it's a separate concern >> from dynamic client registration, and I think it needs to have its >> own proper discussion apart from that. >> >> -- Justin >> >> On 06/04/2013 02:28 AM, Phil Hunt wrote: >>> Yes. However the contents and format are out of scope. >>> >>> Phil >>> >>> On 2013-06-03, at 22:32, Torsten Lodderstedt >>> > wrote: >>> >>>> Hi Phil, >>>> >>>> isn't the initial registration token such a credential, which >>>> allows to co-relate different instances of the same software? >>>> >>>> regards, >>>> Torsten. >>>> >>>> >>>> >>>> Phil Hunt > >>>> schrieb: >>>> >>>> Finally i believe the bb+ doesn't have the issue because they are solving with an initial authn credential that contains the same info. >>>> >>>> My feeling is that this functionality needs to be standardized one way or another. >>>> >>>> Phil >>>> >>>> On 2013-06-03, at 19:16, Derek Atkins > wrote: >>>> >>>> Phil, Phil Hunt >>> > writes: >>>> >>>> Not quite. I will call you. I am saying we are >>>> transitioning from the old public client model. The new >>>> model proposes quasi-confidential characteristics but >>>> in some respects is missing key information from the >>>> public m! odel. Namely that a group of clients are >>>> related and there have common behaviour and security >>>> characteristics. We need to add to the self-asserted >>>> model an assertion equiv to the old common client_id. >>>> That is all. I am NOT looking for a proof of >>>> application identity here. That is too far. But >>>> certainly what we define here can open that door. Phil >>>> >>>> I think I understand what you're saying here. In the "old >>>> way", a public client had a constant client_id amongst all >>>> instances of that public client, whereas in the "new way", >>>> a public client will have different client_ids amongst all >>>> instances of that client. You feel this is a loss, whereas >>>> it seems most people seem to feel this change is okay. >>>> Since you are effectively the lone dissenter on this one >>>> topic, let me ask you a question: What is a technical >>>> reason that you need to have a constant, assertion that >>>> would bind to! gether (in a non-authenticated way) multiple >>>> instances of a client? I believe that Justin has provides >>>> some attacks against this; so I'm trying to understand, >>>> (with my chair hat on), why you need this functionality? >>>> With my security-mafia hat on, I feel like the old way was >>>> bad, and I much prefer the newer way where each instance of >>>> a client gets its own ID and a locally-stored secret. >>>> -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com >>>> www.ihtfp.com >>>> Computer and Internet Security >>>> Consultant >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> 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 > > --------------070405050103060807020207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Argh! Typos (due to iPhone? no bad brain <-> hand connections). Sorry Justin!

On 6/4/13 1:56 PM, George Fletcher wrote:

+1 for leaving dyn reg as is and working on a profile that enables this more domain specific scenario. I agree with Phil and Justine that it's important... I just don't think it should be put in the core dyn reg spec.

Thanks,
George

On 6/4/13 12:45 PM, Justin Richer wrote:
I agree with the goal of standardizing on identifying software instances, but I think it's out of scope to do so inside of dynamic registration when most dynamic registration use cases don't need it and won't use it. I think that you've got to define discovery, assertion contents, and a few other things in order to make it work and interoperable across different services. Do we really want to define assertion formats and server/client discovery and processing rules inside of dynamic registration? I really don't think that's beneficial, either to dynamic registration itself or to the problem that the software instance tracking is trying to solve.

If this gets proposed as a separate document, I will support it and I will help work on it. Heck, I'll even help edit the thing (or things) if people want. But I strongly believe that it's a separate concern from dynamic client registration, and I think it needs to have its own proper discussion apart from that.

-- Justin

On 06/04/2013 02:28 AM, Phil Hunt wrote:
Yes. However the contents and format are out of scope.

Phil

On 2013-06-03, at 22:32, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Phil,

isn't the initial registration token such a credential, which allows to co-relate different instances of the same software?

regards,
Torsten.
Phil Hunt <phil.hunt@oracle.com> schrieb:
Finally i believe the bb+ doesn't have the issue because they are solving with an initial authn credential that contains the same info. 

My feeling is that this functionality needs to be standardized one way or another. 

Phil

On 2013-06-03, at 19:16, Derek Atkins <derek@ihtfp.com> wrote:

Phil,

Phil Hunt <phil.hunt@oracle.com> writes:

Not quite. I will call you. 

I am saying we are transitioning from the old public client model. The new
model proposes quasi-confidential characteristics but in some respects is
missing key information from the public m!
 odel. 
Namely that a group of clients
are related and there have common behaviour and security characteristics. 

We need to add to the self-asserted model an assertion equiv to the old common
client_id. That is all. 

I am NOT looking for a proof of application identity here. That is too far.
But certainly what we define here can open that door. 

Phil
I think I understand what you're saying here.  In the "old way", a
public client had a constant client_id amongst all instances of that
public client, whereas in the "new way", a public client will have
different client_ids amongst all instances of that client.  You feel
this is a loss, whereas it seems most people seem to feel this change is
okay.

Since you are effectively the lone dissenter on this one topic, let me
ask you a question: What is a technical reason that you need to have a
constant, assertion that would bind to!
 gether
(in a non-authenticated
way) multiple instances of a client?

I believe that Justin has provides some attacks against this; so I'm
trying to understand, (with my chair hat on), why you need this
functionality?

With my security-mafia hat on, I feel like the old way was bad, and I
much prefer the newer way where each instance of a client gets its own
ID and a locally-stored secret.

-derek

-- 
Derek Atkins                 617-623-3745
derek@ihtfp.com             www.ihtfp.com
Computer and Internet Security Consultant

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

--------------070405050103060807020207-- From aanganes@mitre.org Tue Jun 4 11:35:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EE621F99D6 for ; Tue, 4 Jun 2013 11:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuH8fs6FHgra for ; Tue, 4 Jun 2013 11:35:08 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 30CF421F99A1 for ; Tue, 4 Jun 2013 11:17:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A86961F1177; Tue, 4 Jun 2013 14:17:19 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 75CC51F037D; Tue, 4 Jun 2013 14:17:19 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.181]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Tue, 4 Jun 2013 14:17:19 -0400 From: "Anganes, Amanda L" To: "Richer, Justin P." , Phil Hunt Thread-Topic: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 Thread-Index: AQHOYUuAX8HcemAtnkaGQB71DsIAlpkl3OUA Date: Tue, 4 Jun 2013 18:17:18 +0000 Message-ID: In-Reply-To: <51AE19BA.1090806@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.146.16.16] Content-Type: multipart/alternative; boundary="_000_CDD3A4ED8BA8aanganesmitreorg_" MIME-Version: 1.0 Cc: Derek Atkins , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:35:13 -0000 --_000_CDD3A4ED8BA8aanganesmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 The fact that there has been so much discussion around this topic seems lik= e a clear indicator to me that the group needs to carefully and precisely f= igure out the use cases and mechanisms needed to identify "application clas= ses" or "client instances" (or whatever they should be called), in a secure= and trustworthy manner. The security aspect is key here =96 otherwise we w= ill end up with a situation like all the kerfluffle over the Implicit Grant= and how it's not secure but everyone is using it (because it's easy) and i= t's bad for the OAuth 2.0 brand because it's not as secure. Phil previously wrote: I am NOT looking for a proof of application identity here. That is too far. But certainly what we define here can open that door. However, I think everyone else has made pretty convincing arguments as to w= hy that's not a door worth opening in *this* spec, and cracking it open by = just dropping in a self-asserted application ID could cause much more troub= le than it's worth. DynReg has clear extension points to add new parameters= if needed, but I agree with Justin that there are a lot of other things th= at need to be defined and specified beyond just adding an extra parameter. Let's get DynReg finished and then those that are interested can start work= on an extension to it, to fill in what's needed for client instance identi= fication. --Amanda From: Justin Richer > Date: Tuesday, June 4, 2013 12:45 PM To: Phil Hunt > Cc: Derek Atkins >, "oauth@ietf.org= " > Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last = call review of draft-ietf-oauth-dyn-reg-10 I agree with the goal of standardizing on identifying software instances, b= ut I think it's out of scope to do so inside of dynamic registration when m= ost dynamic registration use cases don't need it and won't use it. I think = that you've got to define discovery, assertion contents, and a few other th= ings in order to make it work and interoperable across different services. = Do we really want to define assertion formats and server/client discovery a= nd processing rules inside of dynamic registration? I really don't think th= at's beneficial, either to dynamic registration itself or to the problem th= at the software instance tracking is trying to solve. If this gets proposed as a separate document, I will support it and I will = help work on it. Heck, I'll even help edit the thing (or things) if people = want. But I strongly believe that it's a separate concern from dynamic clie= nt registration, and I think it needs to have its own proper discussion apa= rt from that. -- Justin On 06/04/2013 02:28 AM, Phil Hunt wrote: Yes. However the contents and format are out of scope. Phil On 2013-06-03, at 22:32, Torsten Lodderstedt > wrote: Hi Phil, isn't the initial registration token such a credential, which allows to co-= relate different instances of the same software? regards, Torsten. Phil Hunt > schrieb: Finally i believe the bb+ doesn't have the issue because they are solving w= ith an initial authn credential that contains the same info. My feeling is that this functionality needs to be standardized one way or a= nother. Phil On 2013-06-03, at 19:16, Derek Atkins > wrote: Phil, Phil Hunt > writes: Not quite. I will call you. I am saying we are transitioning from the old public client model. The new model proposes quasi-confidential characteristics but in some respects is missing key information from the public m! odel. Namely that a group of clients are related and there have common behaviour and security characteristics. We need to add to the self-asserted model an assertion equiv to the old com= mon client_id. That is all. I am NOT looking for a proof of application identity here. That is too far. But certainly what we define here can open that door. Phil I think I understand what you're saying here. In the "old way", a public client had a constant client_id amongst all instances of that public client, whereas in the "new way", a public client will have different client_ids amongst all instances of that client. You feel this is a loss, whereas it seems most people seem to feel this change is okay. Since you are effectively the lone dissenter on this one topic, let me ask you a question: What is a technical reason that you need to have a constant, assertion that would bind to! gether (in a non-authenticated way) multiple instances of a client? I believe that Justin has provides some attacks against this; so I'm trying to understand, (with my chair hat on), why you need this functionality? With my security-mafia hat on, I feel like the old way was bad, and I much prefer the newer way where each instance of a client gets its own ID and a locally-stored secret. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ________________________________ OAuth mailing list OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/= oauth _______________________________________________ OAuth mailing list OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/= oauth --_000_CDD3A4ED8BA8aanganesmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

The fact that there has been so much discussion around this topic seem= s like a clear indicator to me that the group needs to carefully and precis= ely figure out the use cases and mechanisms needed to identify "applic= ation classes" or "client instances" (or whatever they should be called), in a secure and trustworthy manner. T= he security aspect is key here =96 otherwise we will end up with a situatio= n like all the kerfluffle over the Implicit Grant and how it's not secure b= ut everyone is using it (because it's easy) and it's bad for the OAuth 2.0 brand because it's not as secure.&nbs= p;

Phil previously wrote:

I am NOT looking for a proof of applic=
ation identity here. That is too far.
But certainly what we define here can open that door.

However, I think everyone else has made pretty convincing arguments as= to why that's not a door worth opening in *this* spec, and cracking it open by just dropping in a self-ass= erted application ID could cause much more trouble than it's worth. DynReg has clear extension points to add new= parameters if needed, but I agree with Justin that there are a lot of othe= r things that need to be defined and specified beyond just adding an extra = parameter.

Let's get DynReg finished and then those that are interested can start= work on an extension to it, to fill in what's needed for client instance i= dentification.

--Amanda

From: Justin Richer <jricher@mitre.org>
Date: Tuesday, June 4, 2013 12:45 P= M
To: Phil Hunt <phil.hunt@oracle.com>
Cc: Derek Atkins <derek@ihtfp.com>, "oauth@ietf.org" <o= auth@ietf.org>
Subject: Re: [OAUTH-WG] Client Inst= ances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn= -reg-10

I agree with the goal of standard= izing on identifying software instances, but I think it's out of scope to d= o so inside of dynamic registration when most dynamic registration use case= s don't need it and won't use it. I think that you've got to define discovery, assertion contents, and a few o= ther things in order to make it work and interoperable across different ser= vices. Do we really want to define assertion formats and server/client disc= overy and processing rules inside of dynamic registration? I really don't think that's beneficial, either to= dynamic registration itself or to the problem that the software instance t= racking is trying to solve.

If this gets proposed as a separate document, I will support it and I will = help work on it. Heck, I'll even help edit the thing (or things) if people = want. But I strongly believe that it's a separate concern from dynamic clie= nt registration, and I think it needs to have its own proper discussion apart from that.

-- Justin

On 06/04/2013 02:28 AM, Phil Hunt wrote:

Yes. However the contents and format are out of scope.

Phil

On 2013-06-03, at 22:32, Torsten Lodderstedt <torsten@lodderstedt.net> w= rote:

Hi Phil,

isn't the initial registration token such a credential, which allows to co-= relate different instances of the same software?

regards,
Torsten.

Phil Hunt <phil.hunt@oracle.com> schrieb:

Finally i believe the bb+ doesn't have the is=
sue because they are solving with an initial authn credential that contains=
 the same info.=20

My feeling is that this functionality needs to be standardized one way or a=
nother.=20

Phil

On 2013-06-03, at 19:16, Derek Atkins <derek@ihtfp.com> wrote:

Phil,

Phil Hunt <phil.hunt@oracle.com> writes:

Not quite. I will call you.=
=20

I am saying we are transitioning from the old public client model. The new
model proposes quasi-confidential characteristics but in some respects is
missing key information from the public m!
 odel.=20
Namely that a group of clients
are related and there have common behaviour and security characteristics.=20

We need to add to the self-asserted model an assertion equiv to the old com=
mon
client_id. That is all.=20

I am NOT looking for a proof of application identity here. That is too far.
But certainly what we define here can open that door.=20

Phil
I think I understand what you're saying here.  In the "old way", =
a
public client had a constant client_id amongst all instances of that
public client, whereas in the "new way", a public client will hav=
e
different client_ids amongst all instances of that client.  You feel
this is a loss, whereas it seems most people seem to feel this change is
okay.

Since you are effectively the lone dissenter on this one topic, let me
ask you a question: What is a technical reason that you need to have a
constant, assertion that would bind to!
 gether
(in a non-authenticated
way) multiple instances of a client?

I believe that Justin has provides some attacks against this; so I'm
trying to understand, (with my chair hat on), why you need this
functionality?

With my security-mafia hat on, I feel like the old way was bad, and I
much prefer the newer way where each instance of a client gets its own
ID and a locally-stored secret.

-derek

--=20
Derek Atkins                 617-623-3745
derek@ihtfp.com=
             =
www.ihtfp.com
Computer and Internet Security Consultant

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

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

--_000_CDD3A4ED8BA8aanganesmitreorg_-- From jricher@mitre.org Tue Jun 4 11:42:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722C421F869F for ; Tue, 4 Jun 2013 11:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.143 X-Spam-Level: X-Spam-Status: No, score=-6.143 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKgLg4WXul8F for ; Tue, 4 Jun 2013 11:42:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 79E2521F9952 for ; Tue, 4 Jun 2013 11:35:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DF4CC1F1187; Tue, 4 Jun 2013 14:35:11 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BDEF41F1176; Tue, 4 Jun 2013 14:35:11 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 4 Jun 2013 14:35:11 -0400 Message-ID: <51AE3331.5080209@mitre.org> Date: Tue, 4 Jun 2013 14:34:25 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: George Fletcher References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org> <519B9623.8030403@mitre.org> <13631B8F-D3FA-47E6-9176-812840BA507F@oracle.com> <1AB6F2B5-BBDE-476C-B30E-33510EAA024C@oracle.com> <51AE19BA.1090806@mitre.org> <51AE2A50.4030800@aol.com> <51AE2D85.4040101@aol.com> In-Reply-To: <51AE2D85.4040101@aol.com> Content-Type: multipart/alternative; boundary="------------050009040906090103070606" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:42:46 -0000 --------------050009040906090103070606 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit No problem, Georgia. :) On 06/04/2013 02:10 PM, George Fletcher wrote: > Argh! Typos (due to iPhone? no bad brain <-> hand connections). Sorry > Justin! > > On 6/4/13 1:56 PM, George Fletcher wrote: >> +1 for leaving dyn reg as is and working on a profile that enables >> this more domain specific scenario. I agree with Phil and Justine >> that it's important... I just don't think it should be put in the >> core dyn reg spec. >> >> Thanks, >> George >> >> On 6/4/13 12:45 PM, Justin Richer wrote: >>> I agree with the goal of standardizing on identifying software >>> instances, but I think it's out of scope to do so inside of dynamic >>> registration when most dynamic registration use cases don't need it >>> and won't use it. I think that you've got to define discovery, >>> assertion contents, and a few other things in order to make it work >>> and interoperable across different services. Do we really want to >>> define assertion formats and server/client discovery and processing >>> rules inside of dynamic registration? I really don't think that's >>> beneficial, either to dynamic registration itself or to the problem >>> that the software instance tracking is trying to solve. >>> >>> If this gets proposed as a separate document, I will support it and >>> I will help work on it. Heck, I'll even help edit the thing (or >>> things) if people want. But I strongly believe that it's a separate >>> concern from dynamic client registration, and I think it needs to >>> have its own proper discussion apart from that. >>> >>> -- Justin >>> >>> On 06/04/2013 02:28 AM, Phil Hunt wrote: >>>> Yes. However the contents and format are out of scope. >>>> >>>> Phil >>>> >>>> On 2013-06-03, at 22:32, Torsten Lodderstedt >>>> > wrote: >>>> >>>>> Hi Phil, >>>>> >>>>> isn't the initial registration token such a credential, which >>>>> allows to co-relate different instances of the same software? >>>>> >>>>> regards, >>>>> Torsten. >>>>> >>>>> >>>>> >>>>> Phil Hunt > >>>>> schrieb: >>>>> >>>>> Finally i believe the bb+ doesn't have the issue because they are solving with an initial authn credential that contains the same info. >>>>> >>>>> My feeling is that this functionality needs to be standardized one way or another. >>>>> >>>>> Phil >>>>> >>>>> On 2013-06-03, at 19:16, Derek Atkins > wrote: >>>>> >>>>> Phil, Phil Hunt >>>> > writes: >>>>> >>>>> Not quite. I will call you. I am saying we are >>>>> transitioning from the old public client model. The >>>>> new model proposes quasi-confidential characteristics >>>>> but in some respects is missing key information from >>>>> the public m! odel. Namely that a group of clients are >>>>> related and there have common behaviour and security >>>>> characteristics. We need to add to the self-asserted >>>>> model an assertion equiv to the old common client_id. >>>>> That is all. I am NOT looking for a proof of >>>>> application identity here. That is too far. But >>>>> certainly what we define here can open that door. Phil >>>>> >>>>> I think I understand what you're saying here. In the "old >>>>> way", a public client had a constant client_id amongst all >>>>> instances of that public client, whereas in the "new way", >>>>> a public client will have different client_ids amongst all >>>>> instances of that client. You feel this is a loss, whereas >>>>> it seems most people seem to feel this change is okay. >>>>> Since you are effectively the lone dissenter on this one >>>>> topic, let me ask you a question: What is a technical >>>>> reason that you need to have a constant, assertion that >>>>> would bind to! gether (in a non-authenticated way) >>>>> multiple instances of a client? I believe that Justin has >>>>> provides some attacks against this; so I'm trying to >>>>> understand, (with my chair hat on), why you need this >>>>> functionality? With my security-mafia hat on, I feel like >>>>> the old way was bad, and I much prefer the newer way where >>>>> each instance of a client gets its own ID and a >>>>> locally-stored secret. -derek -- Derek Atkins 617-623-3745 >>>>> derek@ihtfp.com www.ihtfp.com >>>>> Computer and Internet Security >>>>> Consultant >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> 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 >> >> > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050009040906090103070606 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit No problem, Georgia. :)

On 06/04/2013 02:10 PM, George Fletcher wrote:

Argh! Typos (due to iPhone? no bad brain <-> hand connections). Sorry Justin!

On 6/4/13 1:56 PM, George Fletcher wrote:
+1 for leaving dyn reg as is and working on a profile that enables this more domain specific scenario. I agree with Phil and Justine that it's important... I just don't think it should be put in the core dyn reg spec.

Thanks,
George

On 6/4/13 12:45 PM, Justin Richer wrote:
I agree with the goal of standardizing on identifying software instances, but I think it's out of scope to do so inside of dynamic registration when most dynamic registration use cases don't need it and won't use it. I think that you've got to define discovery, assertion contents, and a few other things in order to make it work and interoperable across different services. Do we really want to define assertion formats and server/client discovery and processing rules inside of dynamic registration? I really don't think that's beneficial, either to dynamic registration itself or to the problem that the software instance tracking is trying to solve.

If this gets proposed as a separate document, I will support it and I will help work on it. Heck, I'll even help edit the thing (or things) if people want. But I strongly believe that it's a separate concern from dynamic client registration, and I think it needs to have its own proper discussion apart from that.

-- Justin

On 06/04/2013 02:28 AM, Phil Hunt wrote:
Yes. However the contents and format are out of scope.

Phil

On 2013-06-03, at 22:32, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Phil,

isn't the initial registration token such a credential, which allows to co-relate different instances of the same software?

regards,
Torsten.
Phil Hunt <phil.hunt@oracle.com> schrieb:
Finally i believe the bb+ doesn't have the issue because they are solving with an initial authn credential that contains the same info. 

My feeling is that this functionality needs to be standardized one way or another. 

Phil

On 2013-06-03, at 19:16, Derek Atkins <derek@ihtfp.com> wrote:

Phil,

Phil Hunt <phil.hunt@oracle.com> writes:

Not quite. I will call you. 

I am saying we are transitioning from the old public client model. The new
model proposes quasi-confidential characteristics but in some respects is
missing key information from the public m!
 odel. 
Namely that a group of clients
are related and there have common behaviour and security characteristics. 

We need to add to the self-asserted model an assertion equiv to the old common
client_id. That is all. 

I am NOT looking for a proof of application identity here. That is too far.
But certainly what we define here can open that door. 

Phil
I think I understand what you're saying here.  In the "old way", a
public client had a constant client_id amongst all instances of that
public client, whereas in the "new way", a public client will have
different client_ids amongst all instances of that client.  You feel
this is a loss, whereas it seems most people seem to feel this change is
okay.

Since you are effectively the lone dissenter on this one topic, let me
ask you a question: What is a technical reason that you need to have a
constant, assertion that would bind to!
 gether
(in a non-authenticated
way) multiple instances of a client?

I believe that Justin has provides some attacks against this; so I'm
trying to understand, (with my chair hat on), why you need this
functionality?

With my security-mafia hat on, I feel like the old way was bad, and I
much prefer the newer way where each instance of a client gets its own
ID and a locally-stored secret.

-derek

-- 
Derek Atkins                 617-623-3745
derek@ihtfp.com             www.ihtfp.com
Computer and Internet Security Consultant

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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------050009040906090103070606-- From phil.hunt@oracle.com Tue Jun 4 11:45:14 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5995F21F8F78 for ; Tue, 4 Jun 2013 11:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.737 X-Spam-Level: X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vxag-xS-PaY6 for ; Tue, 4 Jun 2013 11:45:09 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id B95B821F93D4 for ; Tue, 4 Jun 2013 11:43:32 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r54IhVCI007093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Jun 2013 18:43:32 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r54IhUwD016895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jun 2013 18:43:30 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r54IhTkm016876; Tue, 4 Jun 2013 18:43:30 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Jun 2013 11:43:29 -0700 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-E463989E-EF91-4A1D-BBC2-14CE69C8B76E Content-Transfer-Encoding: 7bit Message-Id: <1BF3B6CF-9CFC-4C91-A066-98871271FFF4@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Tue, 4 Jun 2013 11:43:25 -0700 To: "Anganes, Amanda L" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] LC Review of draft-ietf-oauth-dyn-reg-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:45:14 -0000 --Apple-Mail-E463989E-EF91-4A1D-BBC2-14CE69C8B76E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Those changes off git hub have not been shared with the group and are not ne= cessarily approved.=20 Phil On 2013-06-04, at 11:03, "Anganes, Amanda L" wrote: > Note that this review applies to the latest spec edits from Justin's Githu= b, which can be found here: https://github.com/jricher/oauth-spec. The =E2=80= =9312 revision has not been published yet, but Justin asked me to review bas= ed off of what was in the tracker, since it is more up-to-date. >=20 > --Amanda >=20 > From: , "Anganes, Amanda L" > Date: Tuesday, June 4, 2013 1:56 PM > To: "oauth@ietf.org" > Subject: LC Review of draft-ietf-oauth-dyn-reg-12 >=20 > [[Apologies if you receive this twice, I accidentally sent this from one o= f my other email addresses this morning (Outlook seems to have been confused= ).]] >=20 > Hello, >=20 > I have reviewed the Dynamic Registration draft and offer some comments bel= ow: >=20 > After section 1.2, I suggest adding a flow diagram (similar to those in th= e core OAuth 2.0 spec), showing the interaction of the client/developer with= the respective endpoints, and the requests and responses involved. I think t= his will make the spec easier to read.=20 >=20 > Inside the 3rd paragraph of section 1.3, there is text buried that talks a= bout client credential rotation (client_secret and Registration Access Token= ). I think this notion of secret rotation should be called out in its own pa= ragraph or subsection and labeled as such. Suggested text (I'm not sure whe= re it should go): >=20 > Section X.X Client Credential Rotation > The Authorization Server may rotate the Client's issued client_secret and/= or Registration Access Token. The client_secret MAY be rotated at any time, i= n which case the Client will likely discover that their secret has expired v= ia attempting and failing to make a request. The Registration Access Token S= HOULD only be rotated in response to an update or read request, in which cas= e the new Registration Access Token will be returned in the response back to= the Client. The Client can check their current credentials at any time by p= erforming a READ or UPDATE operation at the Client Configuration Endpoint. >=20 > Section 3 Client Registration Endpoint >=20 > This section should use the phrase "this endpoint may be open, or it may b= e an OAuth 2.0 Protected Resource", rather than just stating that it may acc= ept an initial token. I *think* that the choice is an either/or for a given= server (ie, a server cannot offer both open and protected registration), bu= t that should be clarified as well.=20 >=20 > In the 4th paragraph, the final sentence ("As such, the Client Configurati= on Endpoint MUST=E2=80=A6") refers to the Configuration endpoint, not the Re= gistration endpoint. The text is already in Section 4 so it should just be d= eleted here.=20 >=20 > Section 3.1 Client Registration Request >=20 > The lead-ups to the two example requests are phrased oddly. The difference= between the two sample requests is not whether the client has a token, it's= whether the endpoint is open or protected. Suggest changing them to "For ex= ample, if the Client Registration Endpoint supports open registration, the c= lient could send the following request" and "Alternatively, if the endpoint i= s an OAuth 2.0 protected resource, the client MUST include an OAuth 2.0 Acce= ss Token/the Initial Access Token in its request, presented as a Bearer toke= n using the Authorization header according to RFC6749." (My phrasing at the e= nd regarding how to present the AT may be off; point is that it should be ca= lled out.) >=20 > Nits in section 7 Security Considerations: >=20 > 2nd paragraph, first sentence: "=E2=80=A6requests to the *Client* Registra= tion Endpoint" >=20 > 6th paragraph, first sentence: "=E2=80=A6the Registration Access Token sho= uld not expire=E2=80=A6" I think this should be a SHOULD NOT?=20 > Same paragraph, 4th sentence has a non-capitolized "client" that should be= "Client" (although, after reading Hannes' review, maybe the capitalized ins= tances should all be lowercased instead).=20 >=20 > I also second Hannes' comment that the RFC 2119 language feels off through= out the spec, suggest doing a careful read to check those. >=20 > Finally, to address the Initial Access Token / Registration Access Token d= iscussion that has been ongoing: >=20 > My initial response after reading this draft (and having followed the disc= ussion) was to say, remove the "Initial Access Token" term completely and in= stead just clarify the text to say that "the Client Registration Endpoint MA= Y be an OAuth 2.0 protected resource, but the details of how a given client o= r developer goes about acquiring an Access Token for use at this endpoint is= out-of-scope". I spoke to Justin about this and he pointed out that this te= rm was only added recently, and it was added because of confusion around how= the Client Registration Endpoint was defined, and what it means to authenti= cate to it. I don't think the new name/definition/explanation has helped; bu= t the previous drafts were also missing the "OAuth 2.0 protected resource" l= anguage. To be clear, I think this functionality is absolutely necessary, bu= t we need to clarify its explanation >=20 > On the other hand, the Registration Access Token seems very clear to me. I= think that term should be called out as a named entity, since it is 'specia= l' - it's not issued by a token endpoint, but by the Client Registration End= point. >=20 > I see a few options that might help: >=20 > 1) Perhaps "Initial Access Token" is a bad name. Unfortunately, I think th= e right names are "Registration Access Token" for accessing the Registration= Endpoint, and "Configuration Access Token" for accessing the Configuration E= ndpoint. This would require changing code, since the configuration token is r= eturned in the Client Registration Response.=20 >=20 > 1.a) The examples in Appendix B only use the IAT for Developer authenticat= ion/tracking (all clients registered using the same IAT can be traced to the= developer that was issued that particular token). Is that the only use case= ? If there is always a developer in the loop in the protected case, then "De= veloper Access Token" might be appropriate. This is less generic than the su= ggestion above, but would not require changing code and might be an improvem= ent over what's there now. >=20 > 2) Perhaps if the spec language were clarified and used the "OAuth 2.0 pro= tected resource" language, the Initial Access Token term could be removed fr= om the document entirely. I don't think the previous drafts got it right, bu= t I think we can do better than those explanations while still avoiding givi= ng a fancy name to something that is *just* an OAuth 2.0 Access Token.=20 >=20 > --Amanda >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-E463989E-EF91-4A1D-BBC2-14CE69C8B76E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Those changes off git hub have not bee= n shared with the group and are not necessarily approved.

Phil<= /div>

On 2013-06-04, at 11:03, "Anganes, Amanda L" <aanganes@mitre.org> wrote:

Note that this review applies to the latest spec edits from Justin's Gi= thub, which can be found here: https://github.com/jricher/oauth-spec. The =E2=80=9312 revisio= n has not been published yet, but Justin asked me to review based off of what was in the tracker, since it is more up-to-d= ate.

--Amanda

From: <Anganes>, "Anganes, Ama= nda L" <aanganes@mitre.org><= br> Date: Tuesday, June 4, 2013 1:56 PM<= br> To: "oauth@ietf.org" <oauth@ietf.org<= /a>>
Subject: LC Review of draft-ietf-oau= th-dyn-reg-12

[[Apologies if you receive this twice, I accidentally sent this from on= e of my other email addresses this morning (Outlook seems to have been confu= sed).]]

Hello,

I have reviewed the Dynamic Registration draft and offer some comments b= elow:

After section 1.2, I suggest adding a flow diagram (similar to those in= the core OAuth 2.0 spec), showing the interaction of the client/developer w= ith the respective endpoints, and the requests and responses involved. I thi= nk this will make the spec easier to read.

Inside the 3rd paragraph of section 1.3, there is text buried that talk= s about client credential rotation (client_secret and Registration Access To= ken). I think this notion of secret rotation should be called out in its own= paragraph or subsection and labeled as such. Suggested text (I'm not sure where it should go):

Sect= ion X.X Client Credential Rotation

The Authorization Server may rotate the Client's issued client_secret a= nd/or Registration Access Token. The client_secret MAY be rotated at any tim= e, in which case the Client will likely discover that their secret has expir= ed via attempting and failing to make a request. The Registration Access Token SHOULD only be rotated in r= esponse to an update or read request, in which case the new Registration Acc= ess Token will be returned in the response back to the Client. The Client ca= n check their current credentials at any time by performing a READ or UPDATE operation at the Client Configur= ation Endpoint.

Section 3 Client Registration Endpoint

This section should use the phrase "this endpoint may be open, or it ma= y be an OAuth 2.0 Protected Resource", rather than just stating that it may a= ccept an initial token. I *think*= that the choice is an either/or for a given server (ie, a server cannot offer both open and protected regis= tration), but that should be clarified as well.

In the 4th paragraph, the final sentence ("As such, the Client Configur= ation Endpoint MUST=E2=80=A6") refers to the Configuration endpoint, not the= Registration endpoint. The text is already in Section 4 so it should just b= e deleted here.

Section 3.1 Client Registration Request

The lead-ups to the two example requests are phrased oddly. The differe= nce between the two sample requests is not whether the client has a token, i= t's whether the endpoint is open or protected. Suggest changing them to "For= example, if the Client Registration Endpoint supports open registration, the client could send the following re= quest" and "Alternatively, if the endpoint is an OAuth 2.0 protected resourc= e, the client MUST include an OAuth 2.0 Access Token/the Initial Access Toke= n in its request, presented as a Bearer token using the Authorization header according to RFC6749." (My ph= rasing at the end regarding how to present the AT may be off; point is that i= t should be called out.)

Nits in section 7 Security Considerations:

2nd paragraph, first sentence: "=E2=80=A6requests to the *Client* Registration Endpoint"

6th paragraph, first sentence: "=E2=80=A6the Registration Access Token s= hould not expire=E2=80=A6" I think this should be a SHOULD NOT?

Same paragraph, 4th sentence has a non-capitolized "client" that should= be "Client" (although, after reading Hannes' review, maybe the capitalized i= nstances should all be lowercased instead).

I also second Hannes' comment that the RFC 2119 language feels off thro= ughout the spec, suggest doing a careful read to check those.

Finally, to address the Initial Access Token / Registration Access Toke= n discussion that has been ongoing:

My initial response after reading this draft (and having followed the d= iscussion) was to say, remove the "Initial Access Token" term completely and= instead just clarify the text to say that "the Client Registration Endpoint= MAY be an OAuth 2.0 protected resource, but the details of how a given client or developer goes about acq= uiring an Access Token for use at this endpoint is out-of-scope". I spoke to= Justin about this and he pointed out that this term was only added recently= , and it was added because of confusion around how the Client Registration Endpoint was defined, and what= it means to authenticate to it. I don't think the new name/definition/expla= nation has helped; but the previous drafts were also missing the "OAuth 2.0 p= rotected resource" language. To be clear, I think this functionality is absolutely necessary, but we nee= d to clarify its explanation

On the other hand, the Registration Access Token seems very clear to me= . I think that term should be called out as a named entity, since it is 'spe= cial' - it's not issued by a token endpoint, but by the Client Registration E= ndpoint.

I see a few options that might help:

1) Perhaps "Initial Access Token" is a bad name. Unfortunately, I think= the right names are "Registration Access Token" for accessing the Registrat= ion Endpoint, and "Configuration Access Token" for accessing the Configurati= on Endpoint. This would require changing code, since the configuration token is returned in the Client Regi= stration Response.

1.a) The examples in Appendix B only use the IAT for Developer authenti= cation/tracking (all clients registered using the same IAT can be traced to t= he developer that was issued that particular token). Is that the only use ca= se? If there is always a developer in the loop in the protected case, then "Developer Access Token" might be a= ppropriate. This is less generic than the suggestion above, but would not re= quire changing code and might be an improvement over what's there now.
=

2) Perhaps if the spec language were clarified and used the "OAuth 2.0 p= rotected resource" language, the Initial Access Token term could be removed f= rom the document entirely. I don't think the previous drafts got it right, b= ut I think we can do better than those explanations while still avoiding giving a fancy name to somethi= ng that is *just* an OAuth 2.0 Ac= cess Token.

--Amanda

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth

= --Apple-Mail-E463989E-EF91-4A1D-BBC2-14CE69C8B76E-- From jricher@mitre.org Tue Jun 4 12:57:21 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755D821F93D2 for ; Tue, 4 Jun 2013 12:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AgZ51-ZjY16 for ; Tue, 4 Jun 2013 12:57:16 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D88DE21F9A97 for ; Tue, 4 Jun 2013 11:57:32 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BB1591F02A9; Tue, 4 Jun 2013 14:57:28 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AAF4B1F029C; Tue, 4 Jun 2013 14:57:28 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 4 Jun 2013 14:57:28 -0400 Message-ID: <51AE386A.2090308@mitre.org> Date: Tue, 4 Jun 2013 14:56:42 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <1BF3B6CF-9CFC-4C91-A066-98871271FFF4@oracle.com> In-Reply-To: <1BF3B6CF-9CFC-4C91-A066-98871271FFF4@oracle.com> Content-Type: multipart/alternative; boundary="------------030105020307070907080802" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] LC Review of draft-ietf-oauth-dyn-reg-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 19:57:21 -0000 --------------030105020307070907080802 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit That's correct, but they're all editorial (non-normative) in nature and I've been in communication with the other editors as well. Everyone is welcome to follow along with the editing process in github if they like. -- Justin On 06/04/2013 02:43 PM, Phil Hunt wrote: > Those changes off git hub have not been shared with the group and are > not necessarily approved. > > Phil > > On 2013-06-04, at 11:03, "Anganes, Amanda L" > wrote: > >> Note that this review applies to the latest spec edits from Justin's >> Github, which can be found here: >> https://github.com/jricher/oauth-spec. The --12 revision has not been >> published yet, but Justin asked me to review based off of what was in >> the tracker, since it is more up-to-date. >> >> --Amanda >> >> From: , "Anganes, Amanda L" > > >> Date: Tuesday, June 4, 2013 1:56 PM >> To: "oauth@ietf.org " > > >> Subject: LC Review of draft-ietf-oauth-dyn-reg-12 >> >> [[Apologies if you receive this twice, I accidentally sent this from >> one of my other email addresses this morning (Outlook seems to have >> been confused).]] >> >> Hello, >> >> I have reviewed the Dynamic Registration draft and offer some >> comments below: >> >> After section 1.2, I suggest adding a flow diagram (similar to those >> in the core OAuth 2.0 spec), showing the interaction of the >> client/developer with the respective endpoints, and the requests and >> responses involved. I think this will make the spec easier to read. >> >> Inside the 3rd paragraph of section 1.3, there is text buried that >> talks about client credential rotation (client_secret and >> Registration Access Token). I think this notion of secret rotation >> should be called out in its own paragraph or subsection and labeled >> as such. Suggested text (I'm not sure where it should go): >> >> Section X.X Client Credential Rotation >> >> The Authorization Server may rotate the Client's issued >> client_secret and/or Registration Access Token. The client_secret >> MAY be rotated at any time, in which case the Client will likely >> discover that their secret has expired via attempting and failing >> to make a request. The Registration Access Token SHOULD only be >> rotated in response to an update or read request, in which case >> the new Registration Access Token will be returned in the >> response back to the Client. The Client can check their current >> credentials at any time by performing a READ or UPDATE operation >> at the Client Configuration Endpoint. >> >> >> Section 3 Client Registration Endpoint >> >> This section should use the phrase "this endpoint may be open, or >> it may be an OAuth 2.0 Protected Resource", rather than just >> stating that it may accept an initial token. I *think* that the >> choice is an either/or for a given server (ie, a server cannot >> offer both open and protected registration), but that should be >> clarified as well. >> >> In the 4th paragraph, the final sentence ("As such, the Client >> Configuration Endpoint MUST...") refers to the Configuration >> endpoint, not the Registration endpoint. The text is already in >> Section 4 so it should just be deleted here. >> >> Section 3.1 Client Registration Request >> >> >> The lead-ups to the two example requests are phrased oddly. The >> difference between the two sample requests is not whether the >> client has a token, it's whether the endpoint is open or >> protected. Suggest changing them to "For example, if the Client >> Registration Endpoint supports open registration, the client >> could send the following request" and "Alternatively, if the >> endpoint is an OAuth 2.0 protected resource, the client MUST >> include an OAuth 2.0 Access Token/the Initial Access Token in its >> request, presented as a Bearer token using the Authorization >> header according to RFC6749." (My phrasing at the end regarding >> how to present the AT may be off; point is that it should be >> called out.) >> >> >> Nits in section 7 Security Considerations: >> >> 2nd paragraph, first sentence: "...requests to the >> *Client* Registration Endpoint" >> >> 6th paragraph, first sentence: "...the Registration Access Token >> should not expire..." I think this should be a SHOULD NOT? >> Same paragraph, 4th sentence has a non-capitolized "client" that >> should be "Client" (although, after reading Hannes' review, maybe >> the capitalized instances should all be lowercased instead). >> >> >> I also second Hannes' comment that the RFC 2119 language feels off >> throughout the spec, suggest doing a careful read to check those. >> >> Finally, to address the Initial Access Token / Registration Access >> Token discussion that has been ongoing: >> >> My initial response after reading this draft (and having followed the >> discussion) was to say, remove the "Initial Access Token" term >> completely and instead just clarify the text to say that "the Client >> Registration Endpoint MAY be an OAuth 2.0 protected resource, but the >> details of how a given client or developer goes about acquiring an >> Access Token for use at this endpoint is out-of-scope". I spoke to >> Justin about this and he pointed out that this term was only added >> recently, and it was added because of confusion around how the Client >> Registration Endpoint was defined, and what it means to authenticate >> to it. I don't think the new name/definition/explanation has helped; >> but the previous drafts were also missing the "OAuth 2.0 protected >> resource" language. To be clear, I think this functionality is >> absolutely necessary, but we need to clarify its explanation >> >> On the other hand, the Registration Access Token seems very clear to >> me. I think that term should be called out as a named entity, since >> it is 'special' - it's not issued by a token endpoint, but by the >> Client Registration Endpoint. >> >> I see a few options that might help: >> >> 1) Perhaps "Initial Access Token" is a bad name. Unfortunately, I >> think the right names are "Registration Access Token" for >> accessing the Registration Endpoint, and "Configuration Access >> Token" for accessing the Configuration Endpoint. This would >> require changing code, since the configuration token is returned >> in the Client Registration Response. >> >> >> 1.a) The examples in Appendix B only use the IAT for >> Developer authentication/tracking (all clients registered >> using the same IAT can be traced to the developer that was >> issued that particular token). Is that the only use case? If >> there is always a developer in the loop in the protected >> case, then "Developer Access Token" might be appropriate. >> This is less generic than the suggestion above, but would not >> require changing code and might be an improvement over what's >> there now. >> >> >> 2) Perhaps if the spec language were clarified and used the >> "OAuth 2.0 protected resource" language, the Initial Access Token >> term could be removed from the document entirely. I don't think >> the previous drafts got it right, but I think we can do better >> than those explanations while still avoiding giving a fancy name >> to something that is *just* an OAuth 2.0 Access Token. >> >> --Amanda >> >> >> _______________________________________________ >> 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 --------------030105020307070907080802 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit That's correct, but they're all editorial (non-normative) in nature and I've been in communication with the other editors as well.

Everyone is welcome to follow along with the editing process in github if they like.

-- Justin

On 06/04/2013 02:43 PM, Phil Hunt wrote:

Those changes off git hub have not been shared with the group and are not necessarily approved.

Phil

On 2013-06-04, at 11:03, "Anganes, Amanda L" <aanganes@mitre.org> wrote:

Note that this review applies to the latest spec edits from Justin's Github, which can be found here: https://github.com/jricher/oauth-spec. The –12 revision has not been published yet, but Justin asked me to review based off of what was in the tracker, since it is more up-to-date.

--Amanda

From: <Anganes>, "Anganes, Amanda L" <aanganes@mitre.org>
Date: Tuesday, June 4, 2013 1:56 PM
To: "oauth@ietf.org" <oauth@ietf.org>
Subject: LC Review of draft-ietf-oauth-dyn-reg-12

[[Apologies if you receive this twice, I accidentally sent this from one of my other email addresses this morning (Outlook seems to have been confused).]]

Hello,

I have reviewed the Dynamic Registration draft and offer some comments below:

After section 1.2, I suggest adding a flow diagram (similar to those in the core OAuth 2.0 spec), showing the interaction of the client/developer with the respective endpoints, and the requests and responses involved. I think this will make the spec easier to read.

Inside the 3rd paragraph of section 1.3, there is text buried that talks about client credential rotation (client_secret and Registration Access Token). I think this notion of secret rotation should be called out in its own paragraph or subsection and labeled as such. Suggested text (I'm not sure where it should go):

Section X.X Client Credential Rotation

The Authorization Server may rotate the Client's issued client_secret and/or Registration Access Token. The client_secret MAY be rotated at any time, in which case the Client will likely discover that their secret has expired via attempting and failing to make a request. The Registration Access Token SHOULD only be rotated in response to an update or read request, in which case the new Registration Access Token will be returned in the response back to the Client. The Client can check their current credentials at any time by performing a READ or UPDATE operation at the Client Configuration Endpoint.

Section 3 Client Registration Endpoint

This section should use the phrase "this endpoint may be open, or it may be an OAuth 2.0 Protected Resource", rather than just stating that it may accept an initial token. I *think* that the choice is an either/or for a given server (ie, a server cannot offer both open and protected registration), but that should be clarified as well.

In the 4th paragraph, the final sentence ("As such, the Client Configuration Endpoint MUST…") refers to the Configuration endpoint, not the Registration endpoint. The text is already in Section 4 so it should just be deleted here.

Section 3.1 Client Registration Request

The lead-ups to the two example requests are phrased oddly. The difference between the two sample requests is not whether the client has a token, it's whether the endpoint is open or protected. Suggest changing them to "For example, if the Client Registration Endpoint supports open registration, the client could send the following request" and "Alternatively, if the endpoint is an OAuth 2.0 protected resource, the client MUST include an OAuth 2.0 Access Token/the Initial Access Token in its request, presented as a Bearer token using the Authorization header according to RFC6749." (My phrasing at the end regarding how to present the AT may be off; point is that it should be called out.)

Nits in section 7 Security Considerations:

2nd paragraph, first sentence: "…requests to the *Client* Registration Endpoint"

6th paragraph, first sentence: "…the Registration Access Token should not expire…" I think this should be a SHOULD NOT?

Same paragraph, 4th sentence has a non-capitolized "client" that should be "Client" (although, after reading Hannes' review, maybe the capitalized instances should all be lowercased instead).

I also second Hannes' comment that the RFC 2119 language feels off throughout the spec, suggest doing a careful read to check those.

Finally, to address the Initial Access Token / Registration Access Token discussion that has been ongoing:

My initial response after reading this draft (and having followed the discussion) was to say, remove the "Initial Access Token" term completely and instead just clarify the text to say that "the Client Registration Endpoint MAY be an OAuth 2.0 protected resource, but the details of how a given client or developer goes about acquiring an Access Token for use at this endpoint is out-of-scope". I spoke to Justin about this and he pointed out that this term was only added recently, and it was added because of confusion around how the Client Registration Endpoint was defined, and what it means to authenticate to it. I don't think the new name/definition/explanation has helped; but the previous drafts were also missing the "OAuth 2.0 protected resource" language. To be clear, I think this functionality is absolutely necessary, but we need to clarify its explanation

On the other hand, the Registration Access Token seems very clear to me. I think that term should be called out as a named entity, since it is 'special' - it's not issued by a token endpoint, but by the Client Registration Endpoint.

I see a few options that might help:

1) Perhaps "Initial Access Token" is a bad name. Unfortunately, I think the right names are "Registration Access Token" for accessing the Registration Endpoint, and "Configuration Access Token" for accessing the Configuration Endpoint. This would require changing code, since the configuration token is returned in the Client Registration Response.

1.a) The examples in Appendix B only use the IAT for Developer authentication/tracking (all clients registered using the same IAT can be traced to the developer that was issued that particular token). Is that the only use case? If there is always a developer in the loop in the protected case, then "Developer Access Token" might be appropriate. This is less generic than the suggestion above, but would not require changing code and might be an improvement over what's there now.

2) Perhaps if the spec language were clarified and used the "OAuth 2.0 protected resource" language, the Initial Access Token term could be removed from the document entirely. I don't think the previous drafts got it right, but I think we can do better than those explanations while still avoiding giving a fancy name to something that is *just* an OAuth 2.0 Access Token.

--Amanda

_______________________________________________
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

--------------030105020307070907080802-- From jricher@mitre.org Tue Jun 4 12:57:30 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E507621F949D for ; Tue, 4 Jun 2013 12:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1reZmxaF5B48 for ; Tue, 4 Jun 2013 12:57:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D1E5A21F9C74 for ; Tue, 4 Jun 2013 12:45:39 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 483D61F0289 for ; Tue, 4 Jun 2013 15:45:39 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3A17C1F031F for ; Tue, 4 Jun 2013 15:45:39 -0400 (EDT) Received: from IMCMBX02.MITRE.ORG ([169.254.2.12]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0342.003; Tue, 4 Jun 2013 15:45:38 -0400 From: "Richer, Justin P." To: "Anganes, Amanda L" Thread-Topic: [OAUTH-WG] LC Review of draft-ietf-oauth-dyn-reg-12 Thread-Index: AQHOYUzJ9GUoAoQpNkKnX9uw4Utq9JkmOKCA Date: Tue, 4 Jun 2013 19:45:37 +0000 Message-ID: <727692BF-DAAF-480F-9B47-0FF1C495E230@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.112] Content-Type: multipart/alternative; boundary="_000_727692BFDAAF480F9B470FF1C495E230mitreorg_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] LC Review of draft-ietf-oauth-dyn-reg-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 19:57:31 -0000 --_000_727692BFDAAF480F9B470FF1C495E230mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Amanda, thanks for the review -- comments inline. On Jun 4, 2013, at 1:56 PM, "Anganes, Amanda L" > wrote: [[Apologies if you receive this twice, I accidentally sent this from one of= my other email addresses this morning (Outlook seems to have been confused= ).]] Hello, I have reviewed the Dynamic Registration draft and offer some comments belo= w: After section 1.2, I suggest adding a flow diagram (similar to those in the= core OAuth 2.0 spec), showing the interaction of the client/developer with= the respective endpoints, and the requests and responses involved. I think= this will make the spec easier to read. I think that this makes a lot of sense, and I'll add one to the next versio= n of the spec. This is what I've got to start with: +--------(A)- Initial Access Token | v +-----------+ +---------------+ | |--(B)- Client Registration Reqeust -->| Client | | | | Registration | | |<-(C)- Client Information Response ---| Endpoint | | | +---------------+ | | | | +---------------+ | Client or |--(D)- Read or Update Request ------->| | | Developer | | | | |<-(E)- Client Information Response ---| Client | | | | Configuration | | | | Endpoint | | | | | | |--(F)- Delete Request --------------->| | | | | | | |<-(G)- Delete Confirmation -----------| | +-----------+ +---------------+ (Apologies if that ascii art doesn't translate through my mail client.) Inside the 3rd paragraph of section 1.3, there is text buried that talks ab= out client credential rotation (client_secret and Registration Access Token= ). I think this notion of secret rotation should be called out in its own p= aragraph or subsection and labeled as such. Suggested text (I'm not sure wh= ere it should go): Section X.X Client Credential Rotation The Authorization Server may rotate the Client's issued client_secret and/o= r Registration Access Token. The client_secret MAY be rotated at any time, = in which case the Client will likely discover that their secret has expired= via attempting and failing to make a request. The Registration Access Toke= n SHOULD only be rotated in response to an update or read request, in which= case the new Registration Access Token will be returned in the response ba= ck to the Client. The Client can check their current credentials at any tim= e by performing a READ or UPDATE operation at the Client Configuration Endp= oint. This makes sense. I had tried to use =A71.3 to talk about this, but I can p= ull it out as a separate section, like a subsection to 1.3, and I'll incorp= orate some of your text. Section 3 Client Registration Endpoint This section should use the phrase "this endpoint may be open, or it may be= an OAuth 2.0 Protected Resource", rather than just stating that it may acc= ept an initial token. I *think* that the choice is an either/or for a given= server (ie, a server cannot offer both open and protected registration), b= ut that should be clarified as well. It's not an either/or choice, you could easily do both on the server and sw= itch your functionality based on whether or not there's an authentication t= oken in the request. There are plenty of OAuth-protected APIs that do this = today, where if you call without a token then you get public information, b= ut if you call with a token you get protected information. We want this to = follow the same pattern, so I'll work on the language there. In the 4th paragraph, the final sentence ("As such, the Client Configuratio= n Endpoint MUST=85") refers to the Configuration endpoint, not the Registra= tion endpoint. The text is already in Section 4 so it should just be delete= d here. Hm, looks like vestigial text from a very old revision where everything had= to go through a single endpoint (and we had an operation parameter). Section 3.1 Client Registration Request The lead-ups to the two example requests are phrased oddly. The difference = between the two sample requests is not whether the client has a token, it's= whether the endpoint is open or protected. Suggest changing them to "For e= xample, if the Client Registration Endpoint supports open registration, the= client could send the following request" and "Alternatively, if the endpoi= nt is an OAuth 2.0 protected resource, the client MUST include an OAuth 2.0= Access Token/the Initial Access Token in its request, presented as a Beare= r token using the Authorization header according to RFC6749." (My phrasing = at the end regarding how to present the AT may be off; point is that it sho= uld be called out.) Calling it out more explicitly as an OAuth 2.0 protected resource here (and= elsewhere) will help. Nits in section 7 Security Considerations: 2nd paragraph, first sentence: "=85requests to the *Client* Registration En= dpoint" Yup, my mistake, thanks. 6th paragraph, first sentence: "=85the Registration Access Token should not= expire=85" I think this should be a SHOULD NOT? Same paragraph, 4th sentence has a non-capitolized "client" that should be = "Client" (although, after reading Hannes' review, maybe the capitalized ins= tances should all be lowercased instead). I also second Hannes' comment that the RFC 2119 language feels off througho= ut the spec, suggest doing a careful read to check those. In general, this is an open question I have about where the appropriate use= of the 2119 words should go, and I'm hoping for feedback from people with = more spec-writing experience with this. Finally, to address the Initial Access Token / Registration Access Token di= scussion that has been ongoing: My initial response after reading this draft (and having followed the discu= ssion) was to say, remove the "Initial Access Token" term completely and in= stead just clarify the text to say that "the Client Registration Endpoint M= AY be an OAuth 2.0 protected resource, but the details of how a given clien= t or developer goes about acquiring an Access Token for use at this endpoin= t is out-of-scope". I spoke to Justin about this and he pointed out that th= is term was only added recently, and it was added because of confusion arou= nd how the Client Registration Endpoint was defined, and what it means to a= uthenticate to it. I don't think the new name/definition/explanation has he= lped; but the previous drafts were also missing the "OAuth 2.0 protected re= source" language. To be clear, I think this functionality is absolutely nec= essary, but we need to clarify its explanation I agree that a new name would be great -- I picked "Initial Access Token" b= ecause we needed to call it *something*, and Mike suggested that we call it= out in the Terminology section as an explicit term to give us a starting p= oint. I don't like the name as it is myself -- it's too generic, doesn't re= ally tell you what the token's for. Even in offline conversations about thi= s document over the last month, I've taken to just picking a random term to= use with my interlocutor in order to refer back to it as a concept. I comp= letely agree that the functionality is essential and we can do a better job= of explaining it. Naming things is hard, and I am very open to suggestions on a new name! Ple= ase suggest things! On the other hand, the Registration Access Token seems very clear to me. I = think that term should be called out as a named entity, since it is 'specia= l' - it's not issued by a token endpoint, but by the Client Registration En= dpoint. I see a few options that might help: 1) Perhaps "Initial Access Token" is a bad name. Unfortunately, I think the= right names are "Registration Access Token" for accessing the Registration= Endpoint, and "Configuration Access Token" for accessing the Configuration= Endpoint. This would require changing code, since the configuration token = is returned in the Client Registration Response. "Registration Access Token" is pretty baked in because that's the parameter= name (registration_access_token) that's returned from the registration end= point in the JSON object. I'm not comfortable with changing that at this st= age unless there's a very wide support for it from across the working group= . 1.a) The examples in Appendix B only use the IAT for Developer authenticati= on/tracking (all clients registered using the same IAT can be traced to the= developer that was issued that particular token). Is that the only use cas= e? If there is always a developer in the loop in the protected case, then "= Developer Access Token" might be appropriate. This is less generic than the= suggestion above, but would not require changing code and might be an impr= ovement over what's there now. I'm not very comfortable with tying the token explicitly to the developer b= ecause that implies that it's some kind of assertion. It might be an assert= ion but it might just be an OAuth token that's used in the build/deploy pro= cess to meter access to the registration endpoint. As Phil has suggested, a= nd I agree, the dynamic registration spec should be silent as to the conten= t and structure of the token, just like RFC6749/6750 is. 2) Perhaps if the spec language were clarified and used the "OAuth 2.0 prot= ected resource" language, the Initial Access Token term could be removed fr= om the document entirely. I don't think the previous drafts got it right, b= ut I think we can do better than those explanations while still avoiding gi= ving a fancy name to something that is *just* an OAuth 2.0 Access Token. The problem is that I've found that it's a *particular* OAuth 2 access toke= n, and it's distinct from the Registration Access Token. The Initial Access= Token might be a JWT, it might be a SAML blob, it might be a hex blob issu= ed locally (as Phil has suggested), and it might not be a bearer token at a= ll (if we can ever finish other token types in the WG). I think we need it = to be "an OAuth 2.0 Access Token optionally used for authorized calls to th= e Registration Endpoint" and leave it at that, but I do still think it need= s some kind of name. Thanks, -- Justin --Amanda _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_727692BFDAAF480F9B470FF1C495E230mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <75E9C578B9A0A5409770AC0E1706038C@imc.mitre.org> Content-Transfer-Encoding: quoted-printable Amanda, thanks for the review -- comments inline.

On Jun 4, 2013, at 1:56 PM, "Anganes, Amanda L" <aanganes@mitre.org> wrote:

[[Apologies if you receive this twice, I accidentally sent this from o= ne of my other email addresses this morning (Outlook seems to have been con= fused).]]

Hello,

I have reviewed the Dynamic Registration draft and offer some comments= below:

After section 1.2, I suggest adding a flow diagram (similar to those i= n the core OAuth 2.0 spec), showing the interaction of the client/developer= with the respective endpoints, and the requests and responses involved. I = think this will make the spec easier to read.

I think that this makes a lot of sense, and I'll add one to the next v= ersion of the spec. This is what I've got to start with:

+--------(A)= - Initial Access Token

+-----------+ &= nbsp; = +---------------+<= /div>

| = |--(B)- Client Registration Reqeust -->| Client &nbs= p; |

| = | &nb= sp; | Registration &= nbsp;|

| = |<-(C)- Client Information Response ---| Endpoint |<= /font>

| = | &nb= sp; +-----------= ----+

| = |

| = | &nb= sp; +-----------= ----+

| Client or |--(D)- Read or Update Re= quest ------->| |

| Developer | &n= bsp; = | &nbs= p; |

| = |<-(E)- Client Information Response ---| Client &nbs= p; |

| = | &nb= sp; | Configuration = |

| = | &nb= sp; | Endpoin= t |

| = | &nb= sp; | = |

| = |--(F)- Delete Request --------------->| &nb= sp; |

| = | &nb= sp; | = |

| = |<-(G)- Delete Confirmation -----------| &nb= sp; |

+-----------+ &= nbsp; = +---------------+<= /div>

(Apologies if that ascii art doesn't translate through my mail client.= )

Inside the 3rd paragraph of section 1.3, there is text buried that tal= ks about client credential rotation (client_secret and Registration Access = Token). I think this notion of secret rotation should be called out in its = own paragraph or subsection and labeled as such. Suggested text (I'm not sure where it should go):

Sec= tion X.X Client Credential Rotation

The Authorization Server may rotate the Client's issued client_secret = and/or Registration Access Token. The client_secret MAY be rotated at any t= ime, in which case the Client will likely discover that their secret has ex= pired via attempting and failing to make a request. The Registration Access Token SHOULD only be rotated in= response to an update or read request, in which case the new Registration = Access Token will be returned in the response back to the Client. The Clien= t can check their current credentials at any time by performing a READ or UPDATE operation at the Client Configu= ration Endpoint.

This makes sense. I had tried to use =A71.3 to talk about this, but I = can pull it out as a separate section, like a subsection to 1.3, and I'll i= ncorporate some of your text.

Section 3 Client Registration Endpoint

This section should use the phrase "this endpoint may be open, or= it may be an OAuth 2.0 Protected Resource", rather than just stating = that it may accept an initial token. I *think* that the choice is an either/or for a given server (ie, a server cannot offer both open and protected regi= stration), but that should be clarified as well.

It's not an either/or choice, you could easily do both on the server a= nd switch your functionality based on whether or not there's an authenticat= ion token in the request. There are plenty of OAuth-protected APIs that do = this today, where if you call without a token then you get public information, but if you call with a token you = get protected information. We want this to follow the same pattern, so I'll= work on the language there.

In the 4th paragraph, the final sentence ("As such, the Client Co= nfiguration Endpoint MUST=85") refers to the Configuration endpoint, n= ot the Registration endpoint. The text is already in Section 4 so it should= just be deleted here.

Hm, looks like vestigial text from a very old revision where everythin= g had to go through a single endpoint (and we had an operation parameter).<= /div>

Section 3.1 Client Registration Request

The lead-ups to the two example requests are phrased oddly. The differ= ence between the two sample requests is not whether the client has a token,= it's whether the endpoint is open or protected. Suggest changing them to &= quot;For example, if the Client Registration Endpoint supports open registration, the client could send the following r= equest" and "Alternatively, if the endpoint is an OAuth 2.0 prote= cted resource, the client MUST include an OAuth 2.0 Access Token/the Initia= l Access Token in its request, presented as a Bearer token using the Authorization header according to RFC6749." = (My phrasing at the end regarding how to present the AT may be off; point i= s that it should be called out.)

Calling it out more explicitly as an OAuth 2.0 protected resource here= (and elsewhere) will help.

Nits in section 7 Security Considerations:

2nd paragraph, first sentence: "=85requests to the *Client* Registration Endpoint"

Yup, my mistake, thanks.

6th paragraph, first sentence: "=85the Registration Access Token = should not expire=85" I think this should be a SHOULD NOT?

Same paragraph, 4th sentence has a non-capitolized "client" = that should be "Client" (although, after reading Hannes' review, = maybe the capitalized instances should all be lowercased instead).

I also second Hannes' comment that the RFC 2119 language feels off thr= oughout the spec, suggest doing a careful read to check those.

In general, this is an open question I have about where the appropriat= e use of the 2119 words should go, and I'm hoping for feedback from people = with more spec-writing experience with this.

Finally, to address the Initial Access Token / Registration Access Tok= en discussion that has been ongoing:

My initial response after reading this draft (and having followed the = discussion) was to say, remove the "Initial Access Token" term co= mpletely and instead just clarify the text to say that "the Client Reg= istration Endpoint MAY be an OAuth 2.0 protected resource, but the details of how a given client or developer goes about ac= quiring an Access Token for use at this endpoint is out-of-scope". I s= poke to Justin about this and he pointed out that this term was only added = recently, and it was added because of confusion around how the Client Registration Endpoint was defined, and wha= t it means to authenticate to it. I don't think the new name/definition/exp= lanation has helped; but the previous drafts were also missing the "OA= uth 2.0 protected resource" language. To be clear, I think this functionality is absolutely necessary, but we ne= ed to clarify its explanation

I agree that a new name would be great -- I picked "Initial Acces= s Token" because we needed to call it *something*, and Mike suggested = that we call it out in the Terminology section as an explicit term to give = us a starting point. I don't like the name as it is myself -- it's too generic, doesn't really tell you what the toke= n's for. Even in offline conversations about this document over the last mo= nth, I've taken to just picking a random term to use with my interlocutor i= n order to refer back to it as a concept. I completely agree that the functionality is essential and we can= do a better job of explaining it.

Naming things is hard, and I am very open to suggestions on a new name= ! Please suggest things!

On the other hand, the Registration Access Token seems very clear to m= e. I think that term should be called out as a named entity, since it is 's= pecial' - it's not issued by a token endpoint, but by the Client Registrati= on Endpoint.

I see a few options that might help:

1) Perhaps "Initial Access Token" is a bad name. Unfortunate= ly, I think the right names are "Registration Access Token" for a= ccessing the Registration Endpoint, and "Configuration Access Token&qu= ot; for accessing the Configuration Endpoint. This would require changing code, since the configuration token is returned in the Client Reg= istration Response.

"Registration Access Token" is pretty baked in because that'= s the parameter name (registration_access_token) that's returned from the r= egistration endpoint in the JSON object. I'm not comfortable with changing = that at this stage unless there's a very wide support for it from across the working group.

1.a) The examples in Appendix B only use the IAT for Developer authent= ication/tracking (all clients registered using the same IAT can be traced t= o the developer that was issued that particular token). Is that the only us= e case? If there is always a developer in the loop in the protected case, then "Developer Access Token"= might be appropriate. This is less generic than the suggestion above, but = would not require changing code and might be an improvement over what's the= re now.

I'm not very comfortable with tying the token explicitly to the develo= per because that implies that it's some kind of assertion. It might be an a= ssertion but it might just be an OAuth token that's used in the build/deplo= y process to meter access to the registration endpoint. As Phil has suggested, and I agree, the dynamic reg= istration spec should be silent as to the content and structure of the toke= n, just like RFC6749/6750 is.

2) Perhaps if the spec language were clarified and used the "OAut= h 2.0 protected resource" language, the Initial Access Token term coul= d be removed from the document entirely. I don't think the previous drafts = got it right, but I think we can do better than those explanations while still avoiding giving a fancy name to someth= ing that is *just* an OAuth 2.0 = Access Token.

The problem is that I've found that it's a *particular* OAuth 2 access= token, and it's distinct from the Registration Access Token. The Initial A= ccess Token might be a JWT, it might be a SAML blob, it might be a hex blob= issued locally (as Phil has suggested), and it might not be a bearer token at all (if we can ever finish other tok= en types in the WG). I think we need it to be "an OAuth 2.0 Access Tok= en optionally used for authorized calls to the Registration Endpoint" = and leave it at that, but I do still think it needs some kind of name.

Thanks,

-- Justin

--Amanda

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

--_000_727692BFDAAF480F9B470FF1C495E230mitreorg_-- From ve7jtb@ve7jtb.com Tue Jun 4 15:28:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DD021F99DE for ; Tue, 4 Jun 2013 15:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mgb4ndjZ8+iU for ; Tue, 4 Jun 2013 15:28:53 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 288FF21F99D8 for ; Tue, 4 Jun 2013 15:27:44 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id c10so4234216wiw.1 for ; Tue, 04 Jun 2013 15:27:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=nONptQrYOgaTByIafNoM6FRdm0ctkmnoKlcaiEDilg0=; b=fbNyuKUjWsEjHWwyKqg8gy6Ib0sefDN+WJ8G8iyIprpzI8mQu+Ji0hxbYM30+48Fa8 Vv3z6/zBCkJsyvjMQGn2S0Xuq4GdMseoGffmDKFpWLDxyJCejGC5ikVe1JDUd2MHryk/ Hi9vBEEdXrxz/d0+Q6UT2lya3rjfrQ1QK/yV2O0uBVU5e9rum7We87jkdwIx3IFp6Jlo hEIiJERAWBGvbHRjuwhnPWIOCLjtHy35FBefAm5Jhk/yWaJBetIKhEzocUNG1dSWVXAJ /zd+L5Du7DNz1VPJkUkH0Raa/ndtXXD3YO4fDQUNQY/pmh8t96ZG6tnsodQe+V3k/dMy NMxw== X-Received: by 10.180.205.177 with SMTP id lh17mr3599219wic.45.1370384863992; Tue, 04 Jun 2013 15:27:43 -0700 (PDT) Received: from [10.107.53.184] ([188.207.76.144]) by mx.google.com with ESMTPSA id k10sm5870733wia.4.2013.06.04.15.27.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 15:27:40 -0700 (PDT) References: <85AA2C66-108B-4276-92EE-2D7566E54990@oracle.com> <6AF52CCD-4D6B-4696-8465-3345FFFDBE9C@mitre.org> <8EFC7565-0E81-4688-9AEB-459E7503F609@mitre.org> <6D11C230-31F6-4206-8F29-B1F2BFB5C17E@oracle.com> <4E1F6AAD24975D4BA5B16804296739436773435C@TK5EX14MBXC283.redmond.corp.microsoft.com> <519A42B4.2020803@mitre.org> <2B22BE68-6903-4C5B-8B0F-A10EB5BA74FE@oracle.com> <519B7AA5.3070908@mitre.org> <519B9623.8030403@mitre.org> <13631B8F-D3FA-47E6-9176-812840BA507F@oracle.com> <1AB6F2B5-BBDE-476C-B30E-33510EAA024C@oracle.com> <51AE19BA.1090806@mitre.org> <51AE2A50.4030800@aol.com> Mime-Version: 1.0 (1.0) In-Reply-To: <51AE2A50.4030800@aol.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-F3C856E2-27F9-4E15-A610-79E1BC6C8431; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: John Bradley Date: Wed, 5 Jun 2013 00:27:36 +0200 To: George Fletcher X-Gm-Message-State: ALoCoQm/0rLVOc2l7ndTsr9wLUeVD4lqTHtFNcaDR/KR1eVfUhaCTk6r4NkGiE80EKcagxhGD28F Cc: Derek Atkins , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 22:28:54 -0000 --Apple-Mail-F3C856E2-27F9-4E15-A610-79E1BC6C8431 Content-Type: multipart/alternative; boundary=Apple-Mail-69B8D184-54F3-4247-B037-7995849316B9 Content-Transfer-Encoding: 7bit --Apple-Mail-69B8D184-54F3-4247-B037-7995849316B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 Sent from my iPhone On 2013-06-04, at 7:56 PM, George Fletcher wrote: > +1 for leaving dyn reg as is and working on a profile that enables this mo= re domain specific scenario. I agree with Phil and Justine that it's importa= nt... I just don't think it should be put in the core dyn reg spec. >=20 > Thanks, > George >=20 > On 6/4/13 12:45 PM, Justin Richer wrote: >> I agree with the goal of standardizing on identifying software instances,= but I think it's out of scope to do so inside of dynamic registration when m= ost dynamic registration use cases don't need it and won't use it. I t= hink that you've got to define discovery, assertion contents, and a few othe= r things in order to make it work and interoperable across different service= s. Do we really want to define assertion formats and server/client discovery= and processing rules inside of dynamic registration? I really don't think t= hat's beneficial, either to dynamic registration itself or to the problem th= at the software instance tracking is trying to solve.=20 >>=20 >> If this gets proposed as a separate document, I will support it and I wil= l help work on it. Heck, I'll even help edit the thing (or things) if people= want. But I strongly believe that it's a separate concern from dynami= c client registration, and I think it needs to have its own proper discussio= n apart from that. >>=20 >> -- Justin >>=20 >> On 06/04/2013 02:28 AM, Phil Hunt wrote: >>> Yes. However the contents and format are out of scope. =20 >>>=20 >>> Phil >>>=20 >>> On 2013-06-03, at 22:32, Torsten Lodderstedt w= rote: >>>=20 >>>> Hi Phil, >>>>=20 >>>> isn't the initial registration token such a credential, which allows to= co-relate different instances of the same software?=20 >>>>=20 >>>> regards,=20 >>>> Torsten. >>>>=20 >>>>=20 >>>>=20 >>>> Phil Hunt schrieb: >>>>>=20 >>>>> Finally i believe the bb+ doesn't have the issue because they are solv= ing with an initial authn credential that contains the same info.=20 >>>>>=20 >>>>> My feeling is that this functionality needs to be standardized one way= or another.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On 2013-06-03, at 19:16, Derek Atkins wrote: >>>>>=20 >>>>>> Phil, >>>>>>=20 >>>>>> Phil Hunt writes: >>>>>>=20 >>>>>>> Not quite. I will call you.=20 >>>>>>>=20 >>>>>>> I am saying we are transitioning from the old public client model. T= he new >>>>>>> model proposes quasi-confidential characteristics but in some respec= ts is >>>>>>> missing key information from the public m! >>>>>>> odel.=20 >>>>>>> Namely that a group of clients >>>>>>> are related and there have common behaviour and security characteris= tics.=20 >>>>>>>=20 >>>>>>> We need to add to the self-asserted model an assertion equiv to the o= ld common >>>>>>> client_id. That is all.=20 >>>>>>>=20 >>>>>>> I am NOT looking for a proof of application identity here. That is t= oo far. >>>>>>> But certainly what we define here can open that door.=20 >>>>>>>=20 >>>>>>> Phil >>>>>>=20 >>>>>> I think I understand what you're saying here. In the "old way", a >>>>>> public client had a constant client_id amongst all instances of that >>>>>> public client, whereas in the "new way", a public client will have >>>>>> different client_ids amongst all instances of that client. You feel >>>>>> this is a loss, whereas it seems most people seem to feel this change= is >>>>>> okay. >>>>>>=20 >>>>>> Since you are effectively the lone dissenter on this one topic, let m= e >>>>>> ask you a question: What is a technical reason that you need to have a= >>>>>> constant, assertion that would bind to! >>>>>> gether >>>>>> (in a non-authenticated >>>>>> way) multiple instances of a client? >>>>>>=20 >>>>>> I believe that Justin has provides some attacks against this; so I'm >>>>>> trying to understand, (with my chair hat on), why you need this >>>>>> functionality? >>>>>>=20 >>>>>> With my security-mafia hat on, I feel like the old way was bad, and I= >>>>>> much prefer the newer way where each instance of a client gets its ow= n >>>>>> ID and a locally-stored secret. >>>>>>=20 >>>>>> -derek >>>>>>=20 >>>>>> --=20 >>>>>> Derek Atkins 617-623-3745 >>>>>> derek@ihtfp.com www.ihtfp.com >>>>>> Computer and Internet Security Consultant >>>>>=20 >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-69B8D184-54F3-4247-B037-7995849316B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

+1

Sent from my iPhone

On 2013-06-04, at 7:56 PM, George Fletcher <gffletch@aol.com> wrote:

+1 for leaving dyn reg as is and working on a profile that enables this more domain specific scenario. I agree with Phil and Justine that it's important... I just don't think it should be put in the core dyn reg spec.

Thanks,
George

On 6/4/13 12:45 PM, Justin Richer wrote:
I agree with the goal of standardizing on identifying software instances, but I think it's out of scope to do so inside of dynamic registration when most dynamic registration use cases don't need it and won't use it. I think that you've got to define discovery, assertion contents, and a few other things in order to make it work and interoperable across different services. Do we really want to define assertion formats and server/client discovery and processing rules inside of dynamic registration? I really don't think that's beneficial, either to dynamic registration itself or to the problem that the software instance tracking is trying to solve.

If this gets proposed as a separate document, I will support it and I will help work on it. Heck, I'll even help edit the thing (or things) if people want. But I strongly believe that it's a separate concern from dynamic client registration, and I think it needs to have its own proper discussion apart from that.

-- Justin

On 06/04/2013 02:28 AM, Phil Hunt wrote:
Yes. However the contents and format are out of scope.

Phil

On 2013-06-03, at 22:32, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Phil,

isn't the initial registration token such a credential, which allows to co-relate different instances of the same software?

regards,
Torsten.
Phil Hunt <phil.hunt@oracle.com> schrieb:
Finally i believe the bb+ doesn't have the issue because they are solving with an initial authn credential that contains the same info. 

My feeling is that this functionality needs to be standardized one way or another. 

Phil

On 2013-06-03, at 19:16, Derek Atkins <derek@ihtfp.com> wrote:

Phil,

Phil Hunt <phil.hunt@oracle.com> writes:

Not quite. I will call you. 

I am saying we are transitioning from the old public client model. The new
model proposes quasi-confidential characteristics but in some respects is
missing key information from the public m!
 odel. 
Namely that a group of clients
are related and there have common behaviour and security characteristics. 

We need to add to the self-asserted model an assertion equiv to the old common
client_id. That is all. 

I am NOT looking for a proof of application identity here. That is too far.
But certainly what we define here can open that door. 

Phil
I think I understand what you're saying here.  In the "old way", a
public client had a constant client_id amongst all instances of that
public client, whereas in the "new way", a public client will have
different client_ids amongst all instances of that client.  You feel
this is a loss, whereas it seems most people seem to feel this change is
okay.

Since you are effectively the lone dissenter on this one topic, let me
ask you a question: What is a technical reason that you need to have a
constant, assertion that would bind to!
 gether
(in a non-authenticated
way) multiple instances of a client?

I believe that Justin has provides some attacks against this; so I'm
trying to understand, (with my chair hat on), why you need this
functionality?

With my security-mafia hat on, I feel like the old way was bad, and I
much prefer the newer way where each instance of a client gets its own
ID and a locally-stored secret.

-derek

-- 
Derek Atkins                 617-623-3745
derek@ihtfp.com             www.ihtfp.com
Computer and Internet Security Consultant

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

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

--Apple-Mail-69B8D184-54F3-4247-B037-7995849316B9-- --Apple-Mail-F3C856E2-27F9-4E15-A610-79E1BC6C8431 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYwNDIyMjczOVowIwYJKoZIhvcNAQkEMRYEFFWo IONz9oaPXfhl07Z+ZxJoU2zEMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBAHiSZObKcDXmU0nyUZ5FG6kaRLXI9krMWXP5 /Tsz0m7Do75qElzplEE/pQnpMSwgZ/smnaw7mHmfZqYWg+J5qELA/q+bw0Pb6rhdWXmQ8MYAVYmx ADO+Cs6LRemrY8IMjXcyIFb9CfmTIXTW0iXvk+eIN75KG9B8vCO3qq+5TK4b/ll4UY2QzWIz5pyR quiuM6y8q4teEo6NibyrPwSnxXWh26Me8xZLzOx7dm4Ls0Hs5VwvQBhqE2kxxle0jZSDn9ZydPUu zlmmhN5b614BqFtiHCl8JWGPaSmBTrVZZJNmzsgqTupgNZtcR37MyZBYXVA8aT8a3vDLLYVttpMJ wN4AAAAAAAA= --Apple-Mail-F3C856E2-27F9-4E15-A610-79E1BC6C8431-- From phil.hunt@oracle.com Tue Jun 4 16:11:24 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D8021F9649 for ; Tue, 4 Jun 2013 16:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.56 X-Spam-Level: X-Spam-Status: No, score=-5.56 tagged_above=-999 required=5 tests=[AWL=1.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3tEpkSc769U for ; Tue, 4 Jun 2013 16:11:18 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C2C3F21F8F83 for ; Tue, 4 Jun 2013 16:11:13 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r54NB4cr003160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 4 Jun 2013 23:11:05 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r54NB6iD012584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Jun 2013 23:11:06 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r54NB5YU012576 for ; Tue, 4 Jun 2013 23:11:06 GMT Received: from [192.168.1.89] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Jun 2013 16:11:02 -0700 MIME-Version: 1.0 Message-ID: <613FC93E-332D-4EE1-B0AA-28AEA5AD8ABD@oracle.com> Date: Tue, 4 Jun 2013 16:11:00 -0700 (PDT) From: Phil Hunt To: "oauth@ietf.org WG" X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [OAUTH-WG] Dynamic Registration and Resource API Targeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 23:11:24 -0000 How is targeting achieved in dynamic registration? Or in other words how = do we know what API is referred to within the scope? Is the = registration endpoint generic or to be matched with each resource API? For example, in google's manual registration system, they ask which APIs = the clients will access. This keeps scope from getting complex later on. I'm worried about attempting to overload scope for this purpose during = registration. I suppose if a client can only register for one API at a time, then the = usual OAuth2 techniques for targeting would apply. Phil @independentid www.independentid.com phil.hunt@oracle.com From ve7jtb@ve7jtb.com Wed Jun 5 00:58:19 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B6321F9A87 for ; Wed, 5 Jun 2013 00:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21CusT5pAhW3 for ; Wed, 5 Jun 2013 00:58:18 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 164AC21F9A97 for ; Wed, 5 Jun 2013 00:58:17 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id h10so865895eaj.15 for ; Wed, 05 Jun 2013 00:58:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=JzbxhRmc9UN9PaUmaDDCIlrS7hy+iX1dd8hITuvmAc8=; b=HM4FOs/tbMnwzYahNr8/gbC1pVgB/8Mjyw377rlStQCs5VIDYI6bW5rOgOEr3ar4bT BdEpT8kOo9/6CDoI+PpOzqsup4BTn8UK62DYLq+FjC+sNs45XZx1dJXHnMEkcu2y3nPV dBsjueDmQ1sytRJhhkH6viUXSIr4wm8yN8R4Kpt+Kni7rkYAhIsYxsDtE5nop/COyBJP 2BxCXj2QCaIGP1aXvvOWuLuaEX5hTEt/7ywaA5Wc5lIbgFCB7UP7p95BUQdJ1cJ2O7/y zQuZz5NbEQR8B0iiOMOrArkWqzsuAjPAF7CxMQsd/3yZHD5IPI4RodeK9MoL3JDIhMDt UquQ== X-Received: by 10.15.36.133 with SMTP id i5mr7166771eev.52.1370419096918; Wed, 05 Jun 2013 00:58:16 -0700 (PDT) Received: from [192.168.49.9] (217-195-236-114.dsl.easynet.nl. [217.195.236.114]) by mx.google.com with ESMTPSA id b14sm25061728ees.16.2013.06.05.00.58.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 00:58:15 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_09E99E26-B69E-4078-8155-350B85556C26"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: John Bradley In-Reply-To: <613FC93E-332D-4EE1-B0AA-28AEA5AD8ABD@oracle.com> Date: Wed, 5 Jun 2013 09:58:13 +0200 Message-Id:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

Same for the payload, spec

eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF= tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

my library

eyJpc3MiOiJqb2UiLCJle= HAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

Now the difference is probably given from the fact I did no= t take care in consideration carriage return in my input.

I am on= a huge JSON expert but what is the correct way to handle it?

Regards

Antonio

[0] http://tools= .ietf.org/html/draft-ietf-jose-json-web-signature-11#appendix-A.1

= = --_000_2481701B912B4B5B821CD86721A4C4C6adobecom_-- From Axel.Nennker@telekom.de Wed Jun 5 06:38:01 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEB621F9AA6 for ; Wed, 5 Jun 2013 06:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxSOOX+Z0THs for ; Wed, 5 Jun 2013 06:37:57 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id C5CFA21F91AB for ; Wed, 5 Jun 2013 06:37:42 -0700 (PDT) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 05 Jun 2013 15:37:40 +0200 Received: from HE100024.emea1.cds.t-internal.com (10.125.65.200) by HE101250.emea1.cds.t-internal.com (10.125.92.153) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 5 Jun 2013 15:37:40 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.97]) by HE100024.emea1.cds.t-internal.com ([2002:769:410c::769:410c]) with mapi; Wed, 5 Jun 2013 15:37:39 +0200 From: To: , Date: Wed, 5 Jun 2013 15:37:37 +0200 Thread-Topic: JWS encoding Appendix A Thread-Index: Ac5h8Gf6B9cMsXqnS4iUMhrVweZ0wgAANFzg Message-ID: References: <2481701B-912B-4B5B-821C-D86721A4C4C6@adobe.com> In-Reply-To: <2481701B-912B-4B5B-821C-D86721A4C4C6@adobe.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF40255A5BB872AHE111541eme_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] JWS encoding Appendix A X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:38:01 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF40255A5BB872AHE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Antonio, Please have a look at this https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncr= ypto/JcBaseTest.java#104 The \r\n is the important. Please make sure you have this byte representation of the payload. The following octet sequence contains the UTF-8 representation of the JWS Header: [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32, 34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125] Best regards Axel From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ntonio Sanso Sent: Wednesday, June 05, 2013 3:27 PM To: oauth@ietf.org WG Subject: [OAUTH-WG] JWS encoding Appendix A Hi *, while testing my encoding routine against JWS I spot a difference between m= y encoding and the one in the spec. More specifically I am referring to Appendix A.1.1 [0] of the JWS spec. Now it could easily be that the library I wrote is wrong but it works fine = with the encoding in the JWT spec for example. If somebody would like to give a look just for the record the encoding for = the header in the spec looks like \ eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 while for me would look like eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 Same for the payload, spec eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9= pc19yb290Ijp0cnVlfQ my library eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb29= 0Ijp0cnVlfQ Now the difference is probably given from the fact I did not take care in c= onsideration carriage return in my input. I am on a huge JSON expert but what is the correct way to handle it? Regards Antonio [0] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#append= ix-A.1 --_000_CE8995AB5D178F44A2154F5C9A97CAF40255A5BB872AHE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Antonio,<= o:p>

Please have a look at this=

https://code.google.com/p/jsoncrypto/source/browse/trunk/tests= rc/org/jsoncrypto/JcBaseTest.java#104

The= \r\n is the important.

Please make sure you = have this byte representation of the payload.

The= following octet sequence contains the UTF-8 representation of the

JWS Header:

&= nbsp;

[123, 34, 116, 121, 112, 34, 58, 34= , 74, 87, 84, 34, 44, 13, 10, 32,

34= , 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]<= /p>

Best re= gards

Axel

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of Antonio Sanso
Sent: Wednesday, June 05,= 2013 3:27 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG]= JWS encoding Appendix A

Hi *,

while= testing my encoding routine against JWS I spot a difference between my enc= oding and the one in the spec.

More specifically I = am referring to Appendix A.1.1 [0] of the JWS spec.

Now it could easily be that the library I wrote is w= rong but it works fine with the encoding in the JWT spec for example.<= /o:p>

If somebody would like to give a l= ook just for the record the encoding for the header in the spec looks like = \

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

while for me would look like

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

Same for the= payload, spec

eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MT= kzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ=

<= /div>

my library

eyJpc3MiO= iJqb2UiLCJleHAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVl= fQ

Now the difference is probably given from the fa= ct I did not take care in consideration carriage return in my input.

I am on a huge JSON expert but what= is the correct way to handle it?

Regards

Antonio

[0] http://tools.ietf.org/html/draft-ietf-= jose-json-web-signature-11#appendix-A.1

= --_000_CE8995AB5D178F44A2154F5C9A97CAF40255A5BB872AHE111541eme_-- From jricher@mitre.org Wed Jun 5 06:41:16 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CE621F9AF9; Wed, 5 Jun 2013 06:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.255 X-Spam-Level: X-Spam-Status: No, score=-5.255 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lffP03vkqsXi; Wed, 5 Jun 2013 06:41:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 32A5421F9AFB; Wed, 5 Jun 2013 06:41:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 625AE1F04AF; Wed, 5 Jun 2013 09:41:10 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 422B31F0269; Wed, 5 Jun 2013 09:41:10 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 5 Jun 2013 09:41:10 -0400 Message-ID: <51AF3FC6.7080501@mitre.org> Date: Wed, 5 Jun 2013 09:40:22 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: References: <2481701B-912B-4B5B-821C-D86721A4C4C6@adobe.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050000050409010803090807" X-Originating-IP: [129.83.31.56] Cc: oauth@ietf.org, "jose@ietf.org" Subject: Re: [OAUTH-WG] JWS encoding Appendix A X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:41:16 -0000 --------------050000050409010803090807 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Also, it's the JOSE working group, not OAuth, that's working on JWS. I've CC'd that group on this reply, further discussion (if needed) should probably take place there. -- Justin On 06/05/2013 09:37 AM, Axel.Nennker@telekom.de wrote: > > Antonio, > > Please have a look at this > > https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#104 > > The \r\n is the important. > > Please make sure you have this byte representation of the payload. > > The following octet sequence contains the UTF-8 representation of the > > JWS Header: > > [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32, > > 34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125] > > Best regards > > Axel > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Antonio Sanso > *Sent:* Wednesday, June 05, 2013 3:27 PM > *To:* oauth@ietf.org WG > *Subject:* [OAUTH-WG] JWS encoding Appendix A > > Hi *, > > while testing my encoding routine against JWS I spot a difference > between my encoding and the one in the spec. > > More specifically I am referring to Appendix A.1.1 [0] of the JWS spec. > > Now it could easily be that the library I wrote is wrong but it works > fine with the encoding in the JWT spec for example. > > If somebody would like to give a look just for the record the encoding > for the header in the spec looks like \ > > eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 > > while for me would look like > > eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 > > Same for the payload, spec > > eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ > > my library > > eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ > > Now the difference is probably given from the fact I did not take care > in consideration carriage return in my input. > > I am on a huge JSON expert but what is the correct way to handle it? > > Regards > > Antonio > > [0] > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#appendix-A.1 > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050000050409010803090807 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Also, it's the JOSE working group, not OAuth, that's working on JWS. I've CC'd that group on this reply, further discussion (if needed) should probably take place there.

-- Justin

On 06/05/2013 09:37 AM, Axel.Nennker@telekom.de wrote:

Antonio,

Please have a look at this

https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#104

The \r\n is the important.

Please make sure you have this byte representation of the payload.

The following octet sequence contains the UTF-8 representation of the

   JWS Header:

   [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32,

   34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]

Best regards

Axel

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Antonio Sanso
Sent: Wednesday, June 05, 2013 3:27 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] JWS encoding Appendix A

Hi *,

while testing my encoding routine against JWS I spot a difference between my encoding and the one in the spec.

More specifically I am referring to Appendix A.1.1 [0] of the JWS spec.

Now it could easily be that the library I wrote is wrong but it works fine with the encoding in the JWT spec for example.

If somebody would like to give a look just for the record the encoding for the header in the spec looks like \
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
while for me would look like
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

Same for the payload, spec

eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

my library

eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

Now the difference is probably given from the fact I did not take care in consideration carriage return in my input.

I am on a huge JSON expert but what is the correct way to handle it?

Regards

Antonio

[0] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#appendix-A.1
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------050000050409010803090807-- From asanso@adobe.com Wed Jun 5 06:43:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B63B21F9B20 for ; Wed, 5 Jun 2013 06:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.595 X-Spam-Level: X-Spam-Status: No, score=-4.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPEmSJsmP3NX for ; Wed, 5 Jun 2013 06:43:46 -0700 (PDT) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id 01B9B21F9AFB for ; Wed, 5 Jun 2013 06:43:37 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKUa9AiUtqgignjiKKfzMJkiRANfUZI6TE@postini.com; Wed, 05 Jun 2013 06:43:41 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.sea.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r55DhZAI018581; Wed, 5 Jun 2013 06:43:36 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r55DhZ6A001430; Wed, 5 Jun 2013 06:43:35 -0700 (PDT) Received: from eurhub01.eur.adobe.com (10.128.4.30) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 5 Jun 2013 06:43:34 -0700 Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurhub01.eur.adobe.com ([10.128.4.30]) with mapi; Wed, 5 Jun 2013 14:43:33 +0100 From: Antonio Sanso To: "" Date: Wed, 5 Jun 2013 14:43:30 +0100 Thread-Topic: JWS encoding Appendix A Thread-Index: Ac5h8qtXso+i3/DDQSusnIhbMfE1oA== Message-ID: References: <2481701B-912B-4B5B-821C-D86721A4C4C6@adobe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A9830F30A62A45E3B6CBBC8033A42A95adobecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JWS encoding Appendix A X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:43:52 -0000 --_000_A9830F30A62A45E3B6CBBC8033A42A95adobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks a lot Axel!! Regards Antonio On Jun 5, 2013, at 3:37 PM, > wrote: Antonio, Please have a look at this https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncr= ypto/JcBaseTest.java#104 The \r\n is the important. Please make sure you have this byte representation of the payload. The following octet sequence contains the UTF-8 representation of the JWS Header: [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32, 34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125] Best regards Axel From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Antonio Sanso Sent: Wednesday, June 05, 2013 3:27 PM To: oauth@ietf.org WG Subject: [OAUTH-WG] JWS encoding Appendix A Hi *, while testing my encoding routine against JWS I spot a difference between m= y encoding and the one in the spec. More specifically I am referring to Appendix A.1.1 [0] of the JWS spec. Now it could easily be that the library I wrote is wrong but it works fine = with the encoding in the JWT spec for example. If somebody would like to give a look just for the record the encoding for = the header in the spec looks like \ eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 while for me would look like eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 Same for the payload, spec eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9= pc19yb290Ijp0cnVlfQ my library eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb29= 0Ijp0cnVlfQ Now the difference is probably given from the fact I did not take care in c= onsideration carriage return in my input. I am on a huge JSON expert but what is the correct way to handle it? Regards Antonio [0] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#append= ix-A.1 --_000_A9830F30A62A45E3B6CBBC8033A42A95adobecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable = Thanks a lot Axel!!

Regards

Ant= onio

On Jun 5, 2013, at 3:37 PM, <Axel.Nennker@telekom.de> wrote:

Antonio,
https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc= /org/jsoncrypto/JcBaseTest.java#104

The \r\n is the i= mportant.

Please make sure you have this byte representatio= n of the payload.
The following octet sequence contains the UTF-= 8 representation of the
   JWS Header:

   [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84,= 34, 44, 13, 10, 32,
   34, 97, 108, 103, 34, 58, 34, = 72, 83, 50, 53, 54, 34, 125]

=
Best regards
A= xel

From: oauth-bounces@ietf.org&n= bsp;[mailto:oauth-bounces@ietf.org] On Behalf Of&nbs= p;Antonio Sanso
Sent: Wednesday, June 05, 2013 3:27 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] JWS encoding Appendix = A

Hi *,

while testing my encoding= routine against JWS I spot a difference between my encoding and the one in= the spec.

M= ore specifically I am referring to Appendix A.1.1 [0] of the JWS spec.=
Now it could easily be that the library I wrote is = wrong but it works fine with the encoding in the JWT spec for example.=
If somebody would like to give a look just for the = record the encoding for the header in the spec looks like \

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1Ni= J9
while for me would look like

eyJ0eXAiOiJKV1QiLCJhbGciOiJ= IUzI1NiJ9

Sa= me for the payload, spec

eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9= leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

my library

eyJpc3MiOiJqb2UiLCJleHAiOjE= zMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

Now the difference is proba= bly given from the fact I did not take care in consideration carriage retur= n in my input.
I am on a huge JSON expert but w= hat is the correct way to handle it?

Regards
&nb= sp;
Antonio
<= /o:p>

=
[0] http://tools.ietf.org/html/draft-ietf-jose-json-web-sign= ature-11#appendix-A.1

= --_000_A9830F30A62A45E3B6CBBC8033A42A95adobecom_-- From twbray@google.com Wed Jun 5 14:00:15 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD39721F8E12 for ; Wed, 5 Jun 2013 14:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaSra4aFJ5PM for ; Wed, 5 Jun 2013 14:00:13 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4C71A21F8E8C for ; Wed, 5 Jun 2013 14:00:12 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id ar20so2362249iec.7 for ; Wed, 05 Jun 2013 14:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/zJYCmehR2J4LCNjvqITBv4Rsxu540eELPe6sDTgE+8=; b=SUeGKWzJKMoRXXPn3a5KINE6Gfd5HMqvbTtzIqyF5gY0HDEs17v/SWCV65w53JX8dw QV8pSqJIqphusVFmjfI3LF/CZd/AgchG+m1/YfTnHdUBC9fQ8Zdiv4tNHG0nLuVCu5zR yyK5YxdphIxosFpC8NQlxoAOV+ZcHbiAtchK5Gt1M0GMvjk1g3kKAZz/F19ffFni3BDf D0+FkVXstHaIXlavVhunc4I3PIxanzXbb64gVnPe+dqVOBlYjrBDuosr96p8RDmcviEF D7d5Kp6meGWbmyVMEpcpTthg9paC/JaFPsZCXsm3snXicFWIaduvsxMYahq2skknSOUE PCdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=/zJYCmehR2J4LCNjvqITBv4Rsxu540eELPe6sDTgE+8=; b=oPvpICs/0uNNZnSPdjSyOm8tB2u4XaOdtWIGNhJjRCFfd5l9xvqAlt4bHp6a9nXFuk dK7I1sv9ebdBgcqTjwGFV4YWwvm3xFy6SNMxkyT9/8TMbqLTWTYUKI1Qv3ve8SoqeJ0J zgJN70mXtSoqSUVX177OEBvLeyfNgxYfURInxQfHUETYX3Vw24/qop5y2LkTCDesMiew dXxNnk5sDZDuHGjMM3hVEkxFiPr8XHuHYmYU6jeNGGUA7fSxVWX88bhSqxTCLUkbjZ8U lJuHnjIpY7aUDOiMEKOiF5PpRc7uQFvp5VG8BtDQqGlf8lNnIYNNAJJSdYlk3RuVmBxQ 9v1g== X-Received: by 10.50.40.34 with SMTP id u2mr4121086igk.16.1370466012448; Wed, 05 Jun 2013 14:00:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.23.103 with HTTP; Wed, 5 Jun 2013 13:59:42 -0700 (PDT) In-Reply-To: <004401ce5e3a$01854b70$048fe250$@reminetworks.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com> <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> From: Tim Bray Date: Wed, 5 Jun 2013 13:59:42 -0700 Message-ID: To: Donald F Coffin Content-Type: multipart/alternative; boundary=089e0122f84cd9b72904de6e7bec X-Gm-Message-State: ALoCoQlIqrPviDtaE+vn7r1Vgto5EbkceIe3gpD7bg1la97ebWCoX3UCi3Ew3uUgqw9LeC9fYBnVvrmsO4e5T/wMjyALCT+Wa7o1GGjrsGAKtTy6EtjyMzJsQCWVWSQQgEQ7ci9UecZKMNgNikSKDBt7Wr/scThSgHK3bDsOdSDKhk+V+HQ28HTmtCJy4/y9pZvqI4LCrmKr Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 21:00:16 -0000 --089e0122f84cd9b72904de6e7bec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FWIW, I just read the spec through with fresh eyes, and I found the explanation of the workflow in 1.4.2 very useful. - A developer manually registers and then is able to request =E2=80=9CIniti= al tokens=E2=80=9D tokens for a dynamic-app-registration-scope, - you use that =E2=80=9CInitial token=E2=80=9D token to register, in exchan= ge you get the client-id & so on, and also a a per-registration =E2=80=9CRegistration toke= n=E2=80=9D for updating that particular registration information - you fetch/update/delete your registration information with that registration token. The first part, where the developer registers & gets a token for a scope, is vanilla OAuth 2. (right?) The bit about getting an access token specific to that registration is a new flow (right?), but it seems convenient. From an OAuth 2 point of view, there's nothing special about how you get or use the Initial token, but giving it a special name makes explaining a plausible workflow easier. Having said that, I have trouble imagining the scenario where you'd use the 1.4.1 flow, but that may be because of my Google-centric worldview. And I=E2=80=99m not sure 1.4.3 adds any value at all. It just seems to be = a matter of different ways you could get and make use of the registration access token; and I'm sure there are various interesting combinations that haven't been thought of there. I'd just lose 1.4.3. -T On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin < donald.coffin@reminetworks.com> wrote: > See my comments inline [DFC]**** > > ** ** > > Best regards,**** > > Don**** > > Donald F. Coffin**** > > Founder/CTO**** > > ** ** > > REMI Networks**** > > 22751 El Prado Suite 6216**** > > Rancho Santa Margarita, CA 92688-3836**** > > ** ** > > Phone: (949) 636-8571**** > > Email: donald.coffin@reminetworks.com**** > > ** ** > > *From:* Justin Richer [mailto:jricher@mitre.org] > *Sent:* Friday, May 31, 2013 12:40 PM > *To:* Phil Hunt > *Cc:* Donald F Coffin; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] review comments on > draft-ietf-oauth-dyn-reg-11.txt**** > > ** ** > > I feel the need to clarify a couple erroneous things in Phil's statement: > > > * To be clear, Draft 11 has the same Registration Access Token system > that has been in place since draft 01, it is not inventing something new = at > the last minute as could be inferred from the statement below.**** > > [DFC] I agree with Justin. There is nothing new in draft 11 regarding > Registration Access Tokens that wasn=E2=80=99t in the initial draft. It = appears > because Phil hasn=E2=80=99t been following the proposed drafts until the = last call > he is now raising an issue no one in the WG saw as an issue. That=E2=80= =99s not to > say his point isn=E2=80=99t valid, but the discussion continues to go all= over the > map between =E2=80=9Clocal=E2=80=9D and =E2=80=9Cfederated=E2=80=9D token= s, usage of the RFC6749 =E2=80=9CToken=E2=80=9D > endpoint, etc. It would be great if all of Phil=E2=80=99s points could b= e > addressed in priority > without the threads becoming so convoluted no one is able to make sense o= r > even comprehend the point being discussed.**** > > > * DynReg is using an absolutely standard OAuth 2 Bearer token as the > Registration Access Token, it's just not coming from a Token Endpoint. > However, since an OAuth Protected Resource doesn't care where its tokens > come from so long as it can validate them, I don't see this as a problem = -- > this is a key point where Phil and I disagree.**** > > [DFC] I understand the disagreement, but I have not seen a proposal from > Phil that would describe the differences between the two perspectives oth= er > than to say that the Dynamic Registration should use the Token endpoint > defined in RFC6749, which does not discuss dynamic registration. Phil= =E2=80=99s > point as I understand it is that there should be no difference between an > access token used to access resource owner protected data and the > registration structure, which I do not agree with. As I said in the > previous > response, my users do NOT want to provide implied access to > resource owner protected data just because a client is creating a > registration with an AS. This would be the situation if the client > credential flow is used to register an application. Since our > implementation does NOT support the implicit flow, that use > case is one we have elected NOT to support.**** > > [DFC] I repeat my initial comment, this conversation has bee= n > a circular exchange now for the past few days without any appearance of a= n > alternative option to resolve the issues.**** > > > -- Justin**** > > On 05/31/2013 03:33 PM, Phil Hunt wrote:**** > > Don,**** > > ** ** > > I am not proposing any change in meaning. If registration acces token > issues by normal token server with scope registration everything is clear > as it is for any other protected API. Draft 11 invents a whole new system= . > I strongly disagree with this. > > Phil**** > > > On 2013-05-31, at 15:16, Donald F Coffin > wrote:**** > > For something that was agreed to be parked a few hours ago, there sure > seems to still be a lot of circular discussion. Should we ask a mediator > to intervene?**** > > **** > > FWIW I believe that is a significantly strong reason to differentiate an > access token that can access the registration information without having > the ability to access protected data. Especially given the implied > strength of the =E2=80=9Cclient credential=E2=80=9D obtained access token= . I have found it > extremely confusing to users when explaining the difference between an > access token obtained thorough an authorization code flow and a client > credential flow, simply because they are both called an =E2=80=9Caccess t= oken=E2=80=9D. > Changing the meaning of an access token obtained through the client > credential flow to mean it has the ability to update a registration, when= a > user may not want it to have access to protected data will only increase > both the complexity of the access tokens as well as make their usage hard= er > to explain to non-technical individuals who have to understand the > differences between the access tokens obtained through the various flows.= * > *** > > **** > > Just my two cents.**** > > **** > > Best regards,**** > > Don**** > > Donald F. Coffin**** > > Founder/CTO**** > > **** > > REMI Networks**** > > 22751 El Prado Suite 6216**** > > Rancho Santa Margarita, CA 92688-3836**** > > **** > > Phone: (949) 636-8571**** > > Email: donald.coffin@reminetworks.com**** > > **** > > *From:* Phil Hunt [mailto:phil.hunt@oracle.com ] > *Sent:* Friday, May 31, 2013 11:11 AM > *To:* Justin Richer > *Cc:* oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] review comments on > draft-ietf-oauth-dyn-reg-11.txt**** > > **** > > To be clear. **** > > **** > > It is two separate issues. **** > > **** > > 1. Anonymous clients can easily be handled through policy config. **** > > **** > > 2. Support for implicit clients needs to be discussed. The current > proposal creates large negative value for the service provider and most > would never allow in current form. Yes it gives each execution instance a > new id, but that isnt what sp's want. It is a huge attack and management > headache. Eliminate or propose a different solution. > > Phil**** > > > On 2013-05-31, at 13:58, Justin Richer wrote:**** > > I'm not willing to write out an entire class of clients from this spec, > especially when we have stated use cases for them doing dynamic > registration. > > I'm sorry, but your proposed solution will simply not work. > > -- Justin**** > > On 05/31/2013 01:56 PM, Phil Hunt wrote:**** > > Well the only client that wouldn't have a credential is an implicit > client. An implicit client is transient and so would never update. > > Besides, as i have stated, implicit clients should not use dyn reg. **** > > > Phil**** > > > On 2013-05-31, at 13:41, Justin Richer wrote:**** > > But the outstanding question is: how do you get the access token to acces= s > the created resource (IE: the Registration Access Token)? You can't use t= he > client_credentials flow for a client with no credentials! > > -- Justin > > > **** > > On 05/31/2013 12:58 PM, Phil Hunt wrote:**** > > Yes. I specified the trivial solution to anonymous clients earlier.**** > > **** > > Even simpler. You don't need an access token to create a new resource. Yo= u > just need one to access one. That is just basic security config. **** > > > Phil**** > > > On 2013-05-31, at 12:34, Justin Richer wrote:**** > > I agree that we are going in circles, since I just was going to bring up > my counter argument of "what about clients with no credentials?" again, > which *still* isn't addressed by what you suggest doing, below. I also > believe that getting rid of the Registration Access Token but using some > other token method would actually make the spec larger, though I'd be gla= d > to review a concrete counter-proposal if you'd like to write one. And the > fact that OIDC is doing it this way, and considered but rejected the way > that you're describing, should say something to the WG here about whether > or not this is the right choice. Rough consensus and running code, after > all. > > Regardless, I agree to park this issue and leave the text as is. We'll > move to the next draft in the last call process shortly, as I have a > handful of non-normative editorial changes that I need to make, thanks to > feedback from a few folks. > > Again, thanks for your thorough review, Phil, and I look forward to futur= e > feedback. > > -- Justin**** > > On 05/31/2013 12:28 PM, Phil Hunt wrote:**** > > I disagree. **** > > **** > > There is absolutely no need for a registration access token. **** > > **** > > Get rid of it and just use access tokens as per 6749. If you can't follow > 6749 and need new issuing methods, what are others to say regarding > inventing new methods?**** > > **** > > I have not heard a good reason for the special process or one good enough > to warrant a new method for issuing an access token. Does the broader gro= up > realize this is what the spec says?**** > > **** > > Yes, i heard a lot saying OIDC does it this way. But that is a political > reason, not a technical reason. Still, compatibility is always a strong > objective. Even so, oidc could keep using their method just fine. There = is > no obligation here to do the same. **** > > **** > > The only reason so far was expiry of client creds. Well, why not require > the client to update prior to expiry? It makes no sense to have another > token with longer expiry. B'sides, even expired the client can re-registe= r > from scratch. **** > > **** > > Why force the client to persist multiple tokens and creds? That is far fa= r > too complex. **** > > **** > > Finally if you get rid of registration access token the spec size will > drop roughly in half IMO. This suggests simplicity to me. **** > > **** > > Apologies for my rant. Maybe we should park this for now. We are going in > circles. > > Phil**** > > > On 2013-05-31, at 11:25, Justin Richer wrote:**** > > Phil, > > We *can* keep it straight just fine, but I just need you to be clear abou= t > which part you're objecting to because the answers are different. Please > use the terms as defined in the document so that we all know which > component we're talking about. I'm sure you'd agree than in specification > work such as this, precision of language and labels is key for > communication between parties. This is precisely why there's a Terminolog= y > section right up front, so that when I say "Registration Access Token" yo= u > can know that I mean a very specific thing, and when I say "Initial > Registration Token" I mean a very different specific thing. So I'm asking > you, please, use the defined terms so that we can avoid this unnecessary > confusion. > > But anyway, what you're talking about below, "the token the client uses t= o > update is profile" *IS* the Registration Access Token. That's all that th= at > token is used for. You're not asking for it to go away, you're asking for > it to come from the Token Endpoint instead of the response from the > Registration Endpoint. I don't see how the client *can* get it from the > normal token process without jumping through specialized hoops to make th= at > happen. I've implemented the draft the way that it is right now, both > client and server side, and it works. Others have implemented it, too. > We've done interop testing, and it works. This is a proven pattern and fr= om > where I sit there is both rough consensus and running code. > > I believe that I've already pointed out how the solutions you've proposed > so far won't work in practice, for various reasons, many of which have > already been brought up and discussed previously. If you have another way > for the client to get its Registration Access Token, please propose it; b= ut > I haven't seen anything yet that will fly. > > -- Justin**** > > On 05/31/2013 11:10 AM, Phil Hunt wrote:**** > > Justin,**** > > **** > > This is my primary objection! We can't keep it straight. Their should be > no such thing as a registrstion access token! Just the token the client > obtains to update its profile through the normal token request process. > > Phil**** > > > On 2013-05-31, at 10:55, Justin Richer wrote:**** > > Which token are you referring to here? > > If it's the Initial Registration Token, then you could get that through > the normal token server no problem. (The lifecycle writeups don't call th= is > out explicitly but I would be willing to do so.) Or you could get it > elsewhere. Doesn't matter, just like it doesn't matter with any other > OAuth2 protected resource. > > If it's the Registration Access Token, then having the token come from th= e > token endpoint would require a lot more work and complexity on behalf of > both of the client and server. Either you end up with public clients > getting secrets they shouldn't need or with granting clients access to th= e > client_credentials flow when they shouldn't actually have it. Plus it add= s > extra round trips which don't buy you anything. > > -- Justin**** > > On 05/31/2013 10:15 AM, Phil Hunt wrote:**** > > The preference is to have the access token for registration issued by the > normal token server rather then by the registration endpoint. **** > > **** > > In the current draft it is obtained through a unique process and must > outlive the client. **** > > > Phil**** > > > On 2013-05-30, at 19:47, "Richer, Justin P." wrote:**= * > * > > I don't understand any of the comments below -- it already *is* an OAuth2 > protected resource without any special handling. Your access tokens can b= e > short-lived, long-lived, federated, structured, random blobs ... totally > doesn't matter. They are access tokens being used to access a normal > protected resource. Full stop. > > Anything else is out of scope. The lifecycle discussions at the beginning > are merely examples of some ways you *could* use it and are non-normative > and non-exhaustive. > > You seem to be asking for something that's already in the draft. > > -- Justin**** > ------------------------------ > > *From:* Phil Hunt [phil.hunt@oracle.com] > *Sent:* Thursday, May 30, 2013 7:31 PM > *To:* Richer, Justin P. > *Cc:* John Bradley; oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] review comments on > draft-ietf-oauth-dyn-reg-11.txt**** > > > > Phil**** > > > On 2013-05-30, at 16:11, "Richer, Justin P." wrote:**= * > * > > Comments inline, marked by [JR].**** > ------------------------------ > > *From:* Phil Hunt [phil.hunt@oracle.com] > *Sent:* Thursday, May 30, 2013 5:25 PM > *To:* Richer, Justin P. > *Cc:* John Bradley; oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] review comments on > draft-ietf-oauth-dyn-reg-11.txt**** > > See below.**** > > Phil**** > > **** > > @independentid**** > > www.independentid.com**** > > phil.hunt@oracle.com**** > > **** > > **** > > **** > > On 2013-05-30, at 2:09 PM, Justin Richer wrote:**** > > > > > **** > > OK, I think see part of the hang up. I have not seen the scenario that yo= u > describe, where you trade a 3rd party token for a "local" token. I have > seen where access tokens are federated directly at the PR. (Introspection > lets you do some good things with that pattern.) **** > > **** > > **** > > **** > > ** ** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e0122f84cd9b72904de6e7bec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWIW, I just read the spec through with fresh eyes, and I = found the explanation of the workflow in 1.4.2 very useful. =C2=A0

=
- A developer manually registers and then is able to request =E2=80=9C= Initial tokens=E2=80=9D tokens for a dynamic-app-registration-scope,=C2=A0<= /div>
- you use that =E2=80=9CInitial token=E2=80=9D token to register, in e= xchange you get the client-id & so on, and also a a per-registration = =E2=80=9CRegistration token=E2=80=9D for updating that particular registrat= ion information
- you fetch/update/delete your registration infor= mation with that registration token.

The first part, where the developer registers & get= s a token for a scope, is vanilla OAuth 2. (right?) =C2=A0The bit about get= ting an access token specific to that registration is a new flow (right?), = but it seems convenient. =C2=A0 From an OAuth 2 point of view, there's = nothing special about how you get or use the Initial token, but giving it a= special name makes explaining a plausible workflow easier. =C2=A0

Having said that, I have trouble imagining the scenario= where you'd use the 1.4.1 flow, but that may be because of my Google-c= entric worldview.=C2=A0

And I=E2=80=99m not sure 1= .4.3 adds any value at all. =C2=A0It just seems to be a matter of different= ways you could get and make use of the registration access token; and I= 9;m sure there are various interesting combinations that haven't been t= hought of there. =C2=A0I'd just lose 1.4.3.

=C2=A0-T

On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin <donald.coffin@reminetworks.com> wrote:

See my comme= nts inline [DFC]

=C2=A0
Best regards,

Don
Donald F. Coffin=

Founder/CTO
=C2=A0

REMI Networks
<= p class=3D"MsoNormal">22751 El Prado Suite 6216<= /span>

Rancho Santa Margarita, CA=C2=A0 92688-= 3836
=C2= =A0

Phone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) 636-8571

Email:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 donald.coffin@reminetworks.com=

=C2=A0
<= div>

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, May 31, 2013 12:40 PM
To: Phil Hunt
Cc= : Donald F Coffin; = oauth@ietf.org

Subject: Re: [OAU= TH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
=C2=A0
I feel the need to clarify a = couple erroneous things in Phil's statement:

<= br>=C2=A0 * To be clear, Draft 11 has the same Registration Access Token sy= stem that has been in place since draft 01, it is not inventing something n= ew at the last minute as could be inferred from the statement below.

[DFC] =C2=A0I agree with Justin.=C2=A0 There i= s nothing new in draft 11 regarding Registration Access Tokens that wasn=E2= =80=99t in the initial draft.=C2=A0 It appears because Phil hasn=E2=80=99t = been following the proposed drafts until the last call he is now raising an= issue no one in the WG saw as an issue.=C2=A0 That=E2=80=99s not to say hi= s point isn=E2=80=99t valid, but the discussion continues to go all over th= e map between =E2=80=9Clocal=E2=80=9D and =E2=80=9Cfederated=E2=80=9D token= s, usage of the RFC6749 =E2=80=9CToken=E2=80=9D endpoint, etc.=C2=A0 It wou= ld be great if all of Phil=E2=80=99s points could be addressed in priority<= br> without the threads becoming so convoluted no one is able to make sense or = even comprehend the point being discussed.

=C2=A0 = * DynReg is using an absolutely standard OAuth 2 Bearer token as the Regist= ration Access Token, it's just not coming from a Token Endpoint. Howeve= r, since an OAuth Protected Resource doesn't care where its tokens come= from so long as it can validate them, I don't see this as a problem --= this is a key point where Phil and I disagree.

[DFC] =C2=A0I understand the disagreement, but I= have not seen a proposal from Phil that would describe the differences bet= ween the two perspectives other than to say that the Dynamic Registration s= hould use the Token endpoint defined in RFC6749, which does not=C2=A0=C2=A0= =C2=A0 discuss dynamic registration.=C2=A0 Phil=E2=80=99s point as I unders= tand it is that there should be no difference between an access token used = to access resource owner protected data and the registration structure, whi= ch I do not agree with.=C2=A0 As I said in the previous
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 response= , my users do NOT want to provide implied access to resource owner protecte= d data just because a client is creating a registration with an AS.=C2=A0 T= his would be the situation if the client credential flow is used to registe= r an application.=C2=A0 Since our
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 implemen= tation does NOT support the implicit flow, that use case is one we have ele= cted NOT to support.
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [DFC]=C2=A0 I repeat my= initial comment, this conversation has been a circular exchange now for th= e past few days without any appearance of an alternative option to resolve = the issues.

=C2=A0-- Justin
On 05/31= /2013 03:33 PM, Phil Hunt wrote:

Don,
=C2=A0
I am not= proposing any change in meaning. If registration acces token issues by nor= mal token server with scope registration everything is clear as it is for a= ny other protected API. Draft 11 invents a whole new system. I strongly dis= agree with this.

Phil

On 2013-05-31, at 15:16, Donald F Coffin <donald.coffin@rem= inetworks.com> wrote:

For something that was agreed to be parked a few hours ago, there = sure seems to still be a lot of circular discussion.=C2=A0 Should we ask a = mediator to intervene?

=C2=A0
FWIW I believe t= hat is a significantly strong reason to differentiate an access token that = can access the registration information without having the ability to acces= s protected data.=C2=A0 Especially given the implied strength of the =E2=80= =9Cclient credential=E2=80=9D obtained access token.=C2=A0 I have found it = extremely confusing to users when explaining the difference between an acce= ss token obtained thorough an authorization code flow and a client credenti= al flow, simply because they are both called an =E2=80=9Caccess token=E2=80= =9D.=C2=A0 Changing the meaning of an access token obtained through the cli= ent credential flow to mean it has the ability to update a registration, wh= en a user may not want it to have access to protected data will only increa= se both the complexity of the access tokens as well as make their usage har= der to explain to non-technical individuals who have to understand the diff= erences between the access tokens obtained through the various flows.

=C2=A0
Just my two cent= s.

=C2=A0
Best r= egards,

Don
Donald F. Coffin

Founder/CTO
= =C2=A0

REMI Networks
22751 El Prado Suite 6216

Rancho Santa Margarita, CA=C2=A0 92688-3836
=C2=A0

Phone:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (949) 636-8571
Emai= l:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 donald.coffin@reminetworks.com
=C2=A0
From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Friday, May 31, 2013 11:11 AM
To: Justin Richer
<= b>Cc: oauth@ietf.or= g WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oa= uth-dyn-reg-11.txt

=C2=A0
To be clear.=C2=A0
=C2=A0
It is two = separate issues.=C2=A0

=C2=A0
1. Anonymous clients can easily be handled through policy = config.=C2=A0
=C2=A0<= /u>

2. Support for implicit clients needs to be dis= cussed. The current proposal creates large negative value for the service p= rovider and most would never allow in current form. Yes it gives each execu= tion instance a new id, but that isnt what sp's want. It is a huge atta= ck and management headache. Eliminate or propose a different solution.=C2= =A0

Phil

On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org> wrote:=

I'm not willing to wri= te out an entire class of clients from this spec, especially when we have s= tated use cases for them doing dynamic registration.

I'm sorry, but your proposed solution will simply not work.

= =C2=A0-- Justin
On 05/31/2013 = 01:56 PM, Phil Hunt wrote:

Well the only client that wouldn't have a c= redential is an implicit client. An implicit client is transient and so wou= ld never update.=C2=A0

Besides, as i have stated, implicit clients s= hould not use dyn reg.=C2=A0

Phil

On 2013-05-31, at 13:= 41, Justin Richer <jricher@mitre.org> wrote:

But the outstanding questi= on is: how do you get the access token to access the created resource (IE: = the Registration Access Token)? You can't use the client_credentials fl= ow for a client with no credentials!

=C2=A0-- Justin

On 05/31/2013 12:58 PM, Phil Hunt wrote:
Yes. I specified the trivial solution to anonymous clients earlier.

=C2=A0
Even simpler. You don't need an access token to create= a new resource. You just need one to access one. That is just basic securi= ty config.=C2=A0

Phil

On 2013-05-31, at 12:= 34, Justin Richer <jricher@mitre.org> wrote:

I agree that we are going = in circles, since I just was going to bring up my counter argument of "= ;what about clients with no credentials?" again, which *still* isn'= ;t addressed by what you suggest doing, below. I also believe that getting = rid of the Registration Access Token but using some other token method woul= d actually make the spec larger, though I'd be glad to review a concret= e counter-proposal if you'd like to write one. And the fact that OIDC i= s doing it this way, and considered but rejected the way that you're de= scribing, should say something to the WG here about whether or not this is = the right choice. Rough consensus and running code, after all.

Regardless, I agree to park this issue and leave the text as is. We'= ;ll move to the next draft in the last call process shortly, as I have a ha= ndful of non-normative editorial changes that I need to make, thanks to fee= dback from a few folks.

Again, thanks for your thorough review, Phil, and I look forward to fut= ure feedback.

=C2=A0-- Justin
On 05/31/2013 12:28 PM, Phil Hunt wrote:

I disagree.=C2=A0
<= p class=3D"MsoNormal">=C2=A0
There is absolutely no need for a registration access token.=C2=A0<= /u>

=C2=A0
Get rid of it and just use access tokens as per 6749. If you can= 't follow 6749 and need new issuing methods, what are others to say reg= arding inventing new methods?

=C2=A0
I have not heard a good reason for the special process or = one good enough to warrant a new method for issuing an access token. Does t= he broader group realize this is what the spec says?

=C2=A0
Yes, i heard a lot saying OIDC does it this way. But that = is a political reason, not a technical reason. Still, compatibility is alwa= ys a strong objective. =C2=A0Even so, oidc could keep using their method ju= st fine. There is no obligation here to do the same.=C2=A0
=C2=A0
The only reason so far was expiry of client creds. Well, w= hy not require the client to update prior to expiry? It makes no sense to h= ave another token with longer expiry. B'sides, even expired the client = can re-register from scratch.=C2=A0

=C2=A0
Why force the client to persist multiple tokens and creds?= That is far far too complex.=C2=A0
=C2=A0
Finally if you ge= t rid of registration access token the spec size will drop roughly in half = IMO. This suggests simplicity to me.=C2=A0
=C2=A0
Apologies for my = rant. Maybe we should park this for now. We are going in circles.=C2=A0
=
Phil

On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org> wrote:
Phil,

We *can* keep it straight just fine, but I just need you to be= clear about which part you're objecting to because the answers are dif= ferent. Please use the terms as defined in the document so that we all know= which component we're talking about. I'm sure you'd agree than= in specification work such as this, precision of language and labels is ke= y for communication between parties. This is precisely why there's a Te= rminology section right up front, so that when I say "Registration Acc= ess Token" you can know that I mean a very specific thing, and when I = say "Initial Registration Token" I mean a very different specific= thing. So I'm asking you, please, use the defined terms so that we can= avoid this unnecessary confusion.

But anyway, what you're talking about below, "the token the cl= ient uses to update is profile" *IS* the Registration Access Token. Th= at's all that that token is used for. You're not asking for it to g= o away, you're asking for it to come from the Token Endpoint instead of= the response from the Registration Endpoint. I don't see how the clien= t *can* get it from the normal token process without jumping through specia= lized hoops to make that happen. I've implemented the draft the way tha= t it is right now, both client and server side, and it works. Others have i= mplemented it, too. We've done interop testing, and it works. This is a= proven pattern and from where I sit there is both rough consensus and runn= ing code.

I believe that I've already pointed out how the solutions you'v= e proposed so far won't work in practice, for various reasons, many of = which have already been brought up and discussed previously. If you have an= other way for the client to get its Registration Access Token, please propo= se it; but I haven't seen anything yet that will fly.

=C2=A0-- Justin
On 05/31/2= 013 11:10 AM, Phil Hunt wrote:
Justin,

=C2=A0
This is my primary objection! We can't keep it straigh= t. Their should be no such thing as a registrstion access token! =C2=A0Just= the token the client obtains to update its profile through the normal toke= n request process.=C2=A0

Phil

On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org> wrote:=

Which token are you referr= ing to here?

If it's the Initial Registration Token, then you co= uld get that through the normal token server no problem. (The lifecycle wri= teups don't call this out explicitly but I would be willing to do so.) = Or you could get it elsewhere. Doesn't matter, just like it doesn't= matter with any other OAuth2 protected resource.

If it's the Registration Access Token, then having the token come f= rom the token endpoint would require a lot more work and complexity on beha= lf of both of the client and server. Either you end up with public clients = getting secrets they shouldn't need or with granting clients access to = the client_credentials flow when they shouldn't actually have it. Plus = it adds extra round trips which don't buy you anything.

=C2=A0-- Justin
On 05/31/2= 013 10:15 AM, Phil Hunt wrote:
The prefe= rence is to have the access token for registration issued by the normal tok= en server rather then by the registration endpoint.=C2=A0

=C2=A0
In the current draft it is obtained through a unique proce= ss and must outlive the client.=C2=A0

Phil

On 2013-05-30, at 19:47, "Richer, Justin P." = <jricher@mitre.or= g> wrote:

=
I don'= ;t understand any of the comments below -- it already *is* an OAuth2 protec= ted resource without any special handling. Your access tokens can be short-= lived, long-lived, federated, structured, random blobs ... totally doesn= 9;t matter. They are access tokens being used to access a normal protected = resource. Full stop.

Anything else is out of scope. The lifecycle discussions at the beginni= ng are merely examples of some ways you *could* use it and are non-normativ= e and non-exhaustive.

You seem to be asking for something that's= already in the draft.

=C2=A0-- Justin
From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 7:31 PM
To: Richer, Justin P.=
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review commen= ts on draft-ietf-oauth-dyn-reg-11.txt

Phil
=

On 2013-05-3= 0, at 16:11, "Richer, Justin P." <jricher@mitre.org> wrote:
=
Comments inline, marked by [JR].

=
From: Phil Hunt [= phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 5:25 PM
To: Richer, Justin P.=
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review commen= ts on draft-ietf-oauth-dyn-reg-11.txt

See below.
Phil

=C2=A0=
@independentid

www.independentid.com<= /u>

phil.hunt@oracle.com

=C2=A0
=
=C2=A0

=C2=A0
On 2013-05-30, at 2:09 PM, Justin Richer wrote:

OK, I think see part of the hang up. I have not seen the scenario th= at you describe, where you trade a 3rd party token for a "local" = token. I have seen where access tokens are federated directly at the PR. (I= ntrospection lets you do some good things with that pattern.)

=
=C2=A0

=C2=A0
=C2=A0

=C2= =A0

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

--089e0122f84cd9b72904de6e7bec-- From twbray@google.com Wed Jun 5 14:01:15 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1885021F8F78 for ; Wed, 5 Jun 2013 14:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHKPJal+cdy1 for ; Wed, 5 Jun 2013 14:01:13 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9B43E21F8EAD for ; Wed, 5 Jun 2013 14:01:12 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so5155334ied.28 for ; Wed, 05 Jun 2013 14:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=aohSZ6p414+8VkZ7Rsuyeoxqp2l+Wf4AdDf1m3bK4K4=; b=FdUeYDUEWD3RMDianfnpIQHJaJHc20QjZdp6NZac53exXm1r+mJPdLu3nf2VWA3zWe V9JCphIyBn1YllJP9bPoX50sonDTJufYffdoHEpzcaSyCmTezAhmGoXvk7bDCtkiCsUb eyhkDLsvJAFjuY6PQWnDnKSF1qmx7LB/qBRKby+uqMe9Biyv+/KnWN1qZX0urlMbChvq F3qw7GzXeuQ+N5LyZVSRqvtK0YOLr4FJTR8eqnBL+J6U1dkWnl7pBAZyYvgcPfTEDNGR 4jJr0xE3wd9ceNHmjhrbfAlLW8Ur2nzeT2N17q8G0aXvNcOJw2OSRJ2sjOTrQIGvTITg fNCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=aohSZ6p414+8VkZ7Rsuyeoxqp2l+Wf4AdDf1m3bK4K4=; b=airCILeDNqwYed1NJzDbyt5/LR/C90MQBvdohfEIpj7xbNXUJ2iwY2sKOX6l8+Q78i sboDS0LyVabrq3xikqOsm2JneTlqE3W+RfHcAtdegfxH6bKQLwWdX+i0NRRv9AF9WaMz p6WDDxXiCPWOCWzz6WRvk+a0dzn9LueYRAu8HtRZov94MlvaelCc5oSqIfOMiz9asD1s 9xNkFGTF9U0L4mAxq7JRzi0SI78PJHv2VOpYj9osKOL4QKopqSvNpGmCqxw41rAHsO/2 6hxd/2+nkJU7GMnjXh1rACVfAW060aqfURLnb8GFxnoDV4U+f4g96alAATr0VPWpo8lz tnvA== X-Received: by 10.50.85.51 with SMTP id e19mr4168922igz.106.1370466069583; Wed, 05 Jun 2013 14:01:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.23.103 with HTTP; Wed, 5 Jun 2013 14:00:39 -0700 (PDT) From: Tim Bray Date: Wed, 5 Jun 2013 14:00:39 -0700 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=089e0149bbb841858f04de6e7ff5 X-Gm-Message-State: ALoCoQlmxPcvOJMW5abVbKGEwvH9AaJjxrtve0urGZEU5886DBeAu++LnT0euHCuVW2h1fBt4G9eTBkIMCF+86IojtuI8RP+Q71x10rg/WHgMAip32m1qIfbamYGH/GyKcuVNm9IdiWa85+Hqx/g8XAgYj4dXDkH5FQmYp73IL2wKl2j+w0LUxqaUAjDet4Am1qaP8VimNMy Subject: [OAUTH-WG] draft-ietf-oauth-dyn-reg-11 section 4.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 21:01:15 -0000 --089e0149bbb841858f04de6e7ff5 Content-Type: text/plain; charset=UTF-8 Section 4.1. Forming the Client Configuration Endpoint URL Why not discard the last three paragraphs? Server side implementers have a problem in how to create a client-config endpoint & remember what it applies to. I can think of several different ways you could approach this, the spec guidance is superfluous. --089e0149bbb841858f04de6e7ff5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Section 4.1. =C2=A0Forming the Client Configuration E= ndpoint URL

Why not discard the last three par= agraphs? Server side implementers have a problem in how to create a client-= config endpoint & remember what it applies to. I can think of several d= ifferent ways you could approach this, the spec guidance is superfluous.

--089e0149bbb841858f04de6e7ff5-- From James.H.Manger@team.telstra.com Wed Jun 5 20:20:14 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B2121F905F for ; Wed, 5 Jun 2013 20:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.698 X-Spam-Level: * X-Spam-Status: No, score=1.698 tagged_above=-999 required=5 tests=[HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4v2EMTUc96y for ; Wed, 5 Jun 2013 20:20:08 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADBE21F9017 for ; Wed, 5 Jun 2013 20:19:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,811,1363093200"; d="scan'208";a="139945777" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 06 Jun 2013 13:19:55 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7097"; a="136390078" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcdvi.tcif.telstra.com.au with ESMTP; 06 Jun 2013 13:19:55 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Thu, 6 Jun 2013 13:19:54 +1000 From: "Manger, James H" To: Tim Bray Date: Thu, 6 Jun 2013 13:19:53 +1000 Thread-Topic: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt Thread-Index: Ac5iL79BM7YjzA27Rz+zRJyRJaehgwAMcRwA Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B105C72@WSMSG3153V.srv.dir.telstra.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com> <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 03:20:14 -0000 VGltIEJyYXkgd3JvdGU6DQo+IEZXSVcsIEkganVzdCByZWFkIHRoZSBzcGVjIHRocm91Z2ggd2l0 aCBmcmVzaCBleWVzLCBhbmQgSSBmb3VuZCB0aGUgZXhwbGFuYXRpb24gb2YgdGhlIHdvcmtmbG93 IGluIDEuNC4yIHZlcnkgdXNlZnVsLiDCoA0KPg0KPiAtIEEgZGV2ZWxvcGVyIG1hbnVhbGx5IHJl Z2lzdGVycyBhbmQgdGhlbiBpcyBhYmxlIHRvIHJlcXVlc3Qg4oCcSW5pdGlhbCB0b2tlbnPigJ0g dG9rZW5zIGZvciBhIGR5bmFtaWMtYXBwLXJlZ2lzdHJhdGlvbi1zY29wZSzCoA0KPiAtIHlvdSB1 c2UgdGhhdCDigJxJbml0aWFsIHRva2Vu4oCdIHRva2VuIHRvIHJlZ2lzdGVyLCBpbiBleGNoYW5n ZSB5b3UgZ2V0IHRoZSBjbGllbnQtaWQgJiBzbyBvbiwgYW5kIGFsc28gYSBhIHBlci1yZWdpc3Ry YXRpb24g4oCcUmVnaXN0cmF0aW9uIHRva2Vu4oCdIGZvciB1cGRhdGluZyB0aGF0IHBhcnRpY3Vs YXIgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9uDQo+IC0geW91IGZldGNoL3VwZGF0ZS9kZWxldGUg eW91ciByZWdpc3RyYXRpb24gaW5mb3JtYXRpb24gd2l0aCB0aGF0IHJlZ2lzdHJhdGlvbiB0b2tl bi4NCj4NCj4gVGhlIGZpcnN0IHBhcnQsIHdoZXJlIHRoZSBkZXZlbG9wZXIgcmVnaXN0ZXJzICYg Z2V0cyBhIHRva2VuIGZvciBhIHNjb3BlLCBpcyB2YW5pbGxhIE9BdXRoIDIuIChyaWdodD8pDQoN Cldyb25nPyBUaGlzIGRvZXNuJ3Qgc291bmQgbGlrZSBpdCBoYXMgYW55IHRlY2huaWNhbCBjb25u ZWN0aW9uIHRvIE9BdXRoIDIuIEl0IGlzIGEgZGV2ZWxvcGVyIGJyb3dzaW5nIHRvIGEgc2Vydmlj ZSBwb3J0YWw7IHByZXN1bWFibHkgbG9nZ2luZyBpbiB3aXRoIGEgcGFzc3dvcmQsIHBlcmhhcHMg d2l0aCBhIDJuZCBmYWN0b3IgKG5vIE9BdXRoIGhlcmUpOyBhbmQgbWFudWFsbHkgY29weWluZyBh IGNyZWRlbnRpYWwgdGhhdCBjYW4gYmUgdXNlZCB3aXRoIHRoZSAnQkVBUkVSJyBIVFRQIEF1dGhl bnRpY2F0aW9uIG1lY2hhbmlzbS4gVGhlcmUgaXMgbm8gYXBwIG9yY2hlc3RyYXRpbmcgdGhlIGlu dGVyYWN0aW9uICh0aGUgZGV2ZWxvcGVyIGp1c3QgYnJvd3NlZCB0byB0aGUgcG9ydGFsKTsgdGhl cmUgaXMgbm8gcHJvZ3JhbW1hdGljIGV4Y2hhbmdlIG9mIG9uZSBhcHAgY3JlZGVudGlhbCBmb3Ig YW5vdGhlciBhdCBhbiBBUyB0b2tlbiBlbmRwb2ludC4gVGhlIG9ubHkgdGVjaG5pY2FsIGNvbm5l Y3Rpb24gdG8gT0F1dGggMiBpcyB0aGF0IHRoZSAnQkVBUkVSJyBIVFRQIGF1dGhlbnRpY2F0aW9u IG1lY2hhbmlzbSBpcyBicmFuZGVkICJPQXV0aCAyIiBmb3IgbWFya2V0aW5nKD8pIHJlYXNvbnMu DQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From twbray@google.com Wed Jun 5 20:23:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E861021F91AB for ; Wed, 5 Jun 2013 20:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5NsGL72d2bI for ; Wed, 5 Jun 2013 20:23:40 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 464E621F911B for ; Wed, 5 Jun 2013 20:23:40 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id at1so1909003iec.9 for ; Wed, 05 Jun 2013 20:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zAPxCwaq/L6xsCGiy/gNDzMzpI6lP1tFBcrtySXKEnA=; b=Ezx2OSmmURU5n2LZ9vy+7UB0tjLGVZi/rkVfPxxHPwxKI1HMHxSYBT7v0zS8LJQnEd U3ES3SKzGRji0/56XZi4z0sy4ojWhPzZU+Br4ul+1nw1aXioScvMf6zx8/atIjtGaY8z M/JFwOLC7YVeHCS89xbJN8ZkPL0Aidr6vwRN+pIWxaeV7zC1iOFigB3dhyRXQ6FYjCtW g61fc7E15dpUlzIa0Eg0aG2hrgzLemsE1iH6sarWtoWmD+LshgJQCZzCTKd9AxEE9wuY ugrtYG1wFDCq9glqVL3U+RAUWDo2cd9VNRoGcCKVeXRfk9iQoLEXrWDr/wx+5aoqP9s0 YZEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=zAPxCwaq/L6xsCGiy/gNDzMzpI6lP1tFBcrtySXKEnA=; b=fcz67tRKOubNYZEBwsF6Nw+VTzZLNFQxuB2/Mygctt3mg67sm514lUrm+38BRS66m0 /hakL9Ok6gqj26lmNa2gLtSOzjv9vf4JMwqXbxF/SDMyspjOAMD6gSZOMgdkPMxs0y42 QpmgGJp3u6kVFWXCjHVP2qyIc02L09lMTi8G2Yky+AFAn6WK3i+EDmjrtcTvnZCPo3wt C6jDeaJGsGmehYIx9nzciyc+ULSYnRN2IUh0gsyNHME5ev4dPODvsKHERTEZISRKD+go F1SovzH1lx0lLQndT9o8B6ybi36grfRyqsvk09F4Gecfhfnqfi7Q2BTvMgnbzwBwG41b s65g== X-Received: by 10.50.49.5 with SMTP id q5mr4680736ign.106.1370489019840; Wed, 05 Jun 2013 20:23:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.23.103 with HTTP; Wed, 5 Jun 2013 20:23:09 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B105C72@WSMSG3153V.srv.dir.telstra.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com> <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <255B9BB34FB7D647A506DC292726F6E1151B105C72@WSMSG3153V.srv.dir.telstra.com> From: Tim Bray Date: Wed, 5 Jun 2013 20:23:09 -0700 Message-ID: To: "Manger, James H" Content-Type: multipart/alternative; boundary=047d7bdc180232a1f304de73d7c9 X-Gm-Message-State: ALoCoQkgsohNswpGa8Rl2FsntRVEt0TQz0LfLvTcJFU15CFzgcmi8lCgL84KGW3SaxgJWp/OAT+iCz0fgrdOnpAOV6CT21Y3I5uEDFoVJHsbFuIPgRQDV6rmhnfosezxUROoq1XYgbcYwK3gIpbZtw6FoHaLZ3GNPiQlWqyzIvrcFaT0LcDoMd4uikU9lgfbwl6BKRL7doPt Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 03:23:41 -0000 --047d7bdc180232a1f304de73d7c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m really missing something. You start out with a scope you want = a token for for, you get redirected for authentication, it comes back and you do a code flow or a browser flow and you end up getting an access token. Smells like OAuth 2 to me. -T On Wed, Jun 5, 2013 at 8:19 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Tim Bray wrote: > > FWIW, I just read the spec through with fresh eyes, and I found the > explanation of the workflow in 1.4.2 very useful. > > > > - A developer manually registers and then is able to request =E2=80=9CI= nitial > tokens=E2=80=9D tokens for a dynamic-app-registration-scope, > > - you use that =E2=80=9CInitial token=E2=80=9D token to register, in ex= change you get > the client-id & so on, and also a a per-registration =E2=80=9CRegistratio= n token=E2=80=9D > for updating that particular registration information > > - you fetch/update/delete your registration information with that > registration token. > > > > The first part, where the developer registers & gets a token for a > scope, is vanilla OAuth 2. (right?) > > Wrong? This doesn't sound like it has any technical connection to OAuth 2= . > It is a developer browsing to a service portal; presumably logging in wit= h > a password, perhaps with a 2nd factor (no OAuth here); and manually copyi= ng > a credential that can be used with the 'BEARER' HTTP Authentication > mechanism. There is no app orchestrating the interaction (the developer > just browsed to the portal); there is no programmatic exchange of one app > credential for another at an AS token endpoint. The only technical > connection to OAuth 2 is that the 'BEARER' HTTP authentication mechanism = is > branded "OAuth 2" for marketing(?) reasons. > > -- > James Manger > --047d7bdc180232a1f304de73d7c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I=E2=80=99m really missing something. =C2=A0You start out = with a scope you want a token for for, you get redirected for authenticatio= n, it comes back and you do a code flow or a browser flow and you end up ge= tting an access token. =C2=A0Smells like OAuth 2 to me. =C2=A0-T

On Wed, Jun 5= , 2013 at 8:19 PM, Manger, James H <James.H.Manger@team.tels= tra.com> wrote:

Tim Bray wrote:
> FWIW, I just read the spec through with fresh eyes, and I found the ex= planation of the workflow in 1.4.2 very useful. =C2=A0
>
> - A developer manually registers and then is able to request =E2=80=9C= Initial tokens=E2=80=9D tokens for a dynamic-app-registration-scope,=C2=A0<= br> > - you use that =E2=80=9CInitial token=E2=80=9D token to register, in e= xchange you get the client-id & so on, and also a a per-registration = =E2=80=9CRegistration token=E2=80=9D for updating that particular registrat= ion information
> - you fetch/update/delete your registration information with that regi= stration token.
>
> The first part, where the developer registers & gets a token for a= scope, is vanilla OAuth 2. (right?)

Wrong? This doesn't sound like it has any technical connection to= OAuth 2. It is a developer browsing to a service portal; presumably loggin= g in with a password, perhaps with a 2nd factor (no OAuth here); and manual= ly copying a credential that can be used with the 'BEARER' HTTP Aut= hentication mechanism. There is no app orchestrating the interaction (the d= eveloper just browsed to the portal); there is no programmatic exchange of = one app credential for another at an AS token endpoint. The only technical = connection to OAuth 2 is that the 'BEARER' HTTP authentication mech= anism is branded "OAuth 2" for marketing(?) reasons.

--
James Manger

--047d7bdc180232a1f304de73d7c9-- From James.H.Manger@team.telstra.com Wed Jun 5 20:43:04 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D170D21F93BA for ; Wed, 5 Jun 2013 20:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOGOLNujdClM for ; Wed, 5 Jun 2013 20:42:57 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 10EC821F9302 for ; Wed, 5 Jun 2013 20:42:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,811,1363093200"; d="scan'208,217";a="133920822" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 06 Jun 2013 13:42:56 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7097"; a="142286246" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipccni.tcif.telstra.com.au with ESMTP; 06 Jun 2013 13:42:55 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Thu, 6 Jun 2013 13:42:55 +1000 From: "Manger, James H" To: Tim Bray Date: Thu, 6 Jun 2013 13:42:54 +1000 Thread-Topic: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt Thread-Index: Ac5iZT8e4I0vf2RNThqDHhLDMZvHNgAAFUSQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B105CF2@WSMSG3153V.srv.dir.telstra.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com> <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <255B9BB34FB7D647A506DC292726F6E1151B105C72@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1151B105CF2WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 03:43:04 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1151B105CF2WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91ciDigJxmaXJzdCBwYXJ04oCdIHdoZXJlIGEgZGV2ZWxvcGVyIGdldHMgYW4gaW5pdGlhbCB0 b2tlbiBzb3VuZHMgbGlrZSBhIHRhc2sgYSBkZXZlbG9wZXIgZG9lcyB1c2luZyBvbmx5IGEgc3Rh bmRhcmQgd2ViIGJyb3dzZXIsIGtub3dpbmcgdGhlaXIgZGV2ZWxvcGVyIHBhc3N3b3JkLiBUaGVy ZSBpcyBubyBPQXV0aCBoZXJlOyB0aGVyZSBpcyBubyBhcHAgaW50ZXJhY3RpbmcgKGp1c3QgYSBo dW1hbiBhdCBhIGJyb3dzZXIpLg0KDQpQZXJoYXBzIEkgc2hvdWxkIG5vdCBoYXZlIGp1bXBlZCBp bnRvIHRoaXMgdGhyZWFkIGFzIEkgaGF2ZSBub3QgYmVlbiBkZWx2aW5nIGRlZXAgaW50byByZWdp c3RyYXRpb24uIEkgZ3Vlc3MgaXQgaXMgY29uY2VpdmFibGUgdGhhdCBhIGZhbmN5IGFwcCBkZXZl bG9wbWVudCBzdWl0ZSBpcyBhY3RpbmcgYXMgYW4gT0F1dGggY2xpZW50OiBkaXJlY3RpbmcgdGhl IGRldmVsb3BlciB0byB0aGUgQVMgdG8gYXV0aG9yaXplIHRoZSBkZXZlbG9wbWVudCBzdWl0ZSB0 byBjb250YWN0IHRoZSByZWdpc3RyYXRpb24g4oCccHJvdGVjdGVkIHJlc291cmNl4oCdIG9uIHRo ZSBkZXZlbG9wZXJzIGJlaGFsZi4gT25jZSBhdXRob3JpemVkLCB0aGUgZGV2ZWxvcG1lbnQgc3Vp dGUgY29sbGVjdHMgYSB0b2tlbiBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludC4gVGhhdCB0b2tlbiBp cyB0aGUg4oCcaW5pdGlhbCBhY2Nlc3MgdG9rZW7igJ0uIFRoYXQgd291bGQgYmUgT0F1dGggMiBm b3IgdGhlIGZpcnN0IHBhcnQuDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCkZyb206IFRpbSBCcmF5IFtt YWlsdG86dHdicmF5QGdvb2dsZS5jb21dDQpTZW50OiBUaHVyc2RheSwgNiBKdW5lIDIwMTMgMToy MyBQTQ0KVG86IE1hbmdlciwgSmFtZXMgSA0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW09BVVRILVdHXSByZXZpZXcgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVn LTExLnR4dA0KDQpJ4oCZbSByZWFsbHkgbWlzc2luZyBzb21ldGhpbmcuICBZb3Ugc3RhcnQgb3V0 IHdpdGggYSBzY29wZSB5b3Ugd2FudCBhIHRva2VuIGZvciBmb3IsIHlvdSBnZXQgcmVkaXJlY3Rl ZCBmb3IgYXV0aGVudGljYXRpb24sIGl0IGNvbWVzIGJhY2sgYW5kIHlvdSBkbyBhIGNvZGUgZmxv dyBvciBhIGJyb3dzZXIgZmxvdyBhbmQgeW91IGVuZCB1cCBnZXR0aW5nIGFuIGFjY2VzcyB0b2tl bi4gIFNtZWxscyBsaWtlIE9BdXRoIDIgdG8gbWUuICAtVA0KDQpPbiBXZWQsIEp1biA1LCAyMDEz IGF0IDg6MTkgUE0sIE1hbmdlciwgSmFtZXMgSCA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJh LmNvbTxtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4+IHdyb3RlOg0KVGlt IEJyYXkgd3JvdGU6DQo+IEZXSVcsIEkganVzdCByZWFkIHRoZSBzcGVjIHRocm91Z2ggd2l0aCBm cmVzaCBleWVzLCBhbmQgSSBmb3VuZCB0aGUgZXhwbGFuYXRpb24gb2YgdGhlIHdvcmtmbG93IGlu IDEuNC4yIHZlcnkgdXNlZnVsLg0KPg0KPiAtIEEgZGV2ZWxvcGVyIG1hbnVhbGx5IHJlZ2lzdGVy cyBhbmQgdGhlbiBpcyBhYmxlIHRvIHJlcXVlc3Qg4oCcSW5pdGlhbCB0b2tlbnPigJ0gdG9rZW5z IGZvciBhIGR5bmFtaWMtYXBwLXJlZ2lzdHJhdGlvbi1zY29wZSwNCj4gLSB5b3UgdXNlIHRoYXQg 4oCcSW5pdGlhbCB0b2tlbuKAnSB0b2tlbiB0byByZWdpc3RlciwgaW4gZXhjaGFuZ2UgeW91IGdl dCB0aGUgY2xpZW50LWlkICYgc28gb24sIGFuZCBhbHNvIGEgYSBwZXItcmVnaXN0cmF0aW9uIOKA nFJlZ2lzdHJhdGlvbiB0b2tlbuKAnSBmb3IgdXBkYXRpbmcgdGhhdCBwYXJ0aWN1bGFyIHJlZ2lz dHJhdGlvbiBpbmZvcm1hdGlvbg0KPiAtIHlvdSBmZXRjaC91cGRhdGUvZGVsZXRlIHlvdXIgcmVn aXN0cmF0aW9uIGluZm9ybWF0aW9uIHdpdGggdGhhdCByZWdpc3RyYXRpb24gdG9rZW4uDQo+DQo+ IFRoZSBmaXJzdCBwYXJ0LCB3aGVyZSB0aGUgZGV2ZWxvcGVyIHJlZ2lzdGVycyAmIGdldHMgYSB0 b2tlbiBmb3IgYSBzY29wZSwgaXMgdmFuaWxsYSBPQXV0aCAyLiAocmlnaHQ/KQ0KV3Jvbmc/IFRo aXMgZG9lc24ndCBzb3VuZCBsaWtlIGl0IGhhcyBhbnkgdGVjaG5pY2FsIGNvbm5lY3Rpb24gdG8g T0F1dGggMi4gSXQgaXMgYSBkZXZlbG9wZXIgYnJvd3NpbmcgdG8gYSBzZXJ2aWNlIHBvcnRhbDsg cHJlc3VtYWJseSBsb2dnaW5nIGluIHdpdGggYSBwYXNzd29yZCwgcGVyaGFwcyB3aXRoIGEgMm5k IGZhY3RvciAobm8gT0F1dGggaGVyZSk7IGFuZCBtYW51YWxseSBjb3B5aW5nIGEgY3JlZGVudGlh bCB0aGF0IGNhbiBiZSB1c2VkIHdpdGggdGhlICdCRUFSRVInIEhUVFAgQXV0aGVudGljYXRpb24g bWVjaGFuaXNtLiBUaGVyZSBpcyBubyBhcHAgb3JjaGVzdHJhdGluZyB0aGUgaW50ZXJhY3Rpb24g KHRoZSBkZXZlbG9wZXIganVzdCBicm93c2VkIHRvIHRoZSBwb3J0YWwpOyB0aGVyZSBpcyBubyBw cm9ncmFtbWF0aWMgZXhjaGFuZ2Ugb2Ygb25lIGFwcCBjcmVkZW50aWFsIGZvciBhbm90aGVyIGF0 IGFuIEFTIHRva2VuIGVuZHBvaW50LiBUaGUgb25seSB0ZWNobmljYWwgY29ubmVjdGlvbiB0byBP QXV0aCAyIGlzIHRoYXQgdGhlICdCRUFSRVInIEhUVFAgYXV0aGVudGljYXRpb24gbWVjaGFuaXNt IGlzIGJyYW5kZWQgIk9BdXRoIDIiIGZvciBtYXJrZXRpbmcoPykgcmVhc29ucy4NCg0KLS0NCkph bWVzIE1hbmdlcg0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E1151B105CF2WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGlu az1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+WW91ciDigJxmaXJzdCBwYXJ04oCdIHdoZXJlIGEgZGV2ZWxvcGVy IGdldHMgYW4gaW5pdGlhbCB0b2tlbiBzb3VuZHMgbGlrZSBhIHRhc2sgYSBkZXZlbG9wZXIgZG9l cyB1c2luZyBvbmx5IGEgc3RhbmRhcmQgd2ViIGJyb3dzZXIsIGtub3dpbmcgdGhlaXIgZGV2ZWxv cGVyIHBhc3N3b3JkLiBUaGVyZSBpcyBubyBPQXV0aCBoZXJlOyB0aGVyZSBpcyBubyBhcHAgaW50 ZXJhY3RpbmcgKGp1c3QgYSBodW1hbiBhdCBhIGJyb3dzZXIpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ UGVyaGFwcyBJIHNob3VsZCBub3QgaGF2ZSBqdW1wZWQgaW50byB0aGlzIHRocmVhZCBhcyBJIGhh dmUgbm90IGJlZW4gZGVsdmluZyBkZWVwIGludG8gcmVnaXN0cmF0aW9uLiBJIGd1ZXNzIGl0IGlz IGNvbmNlaXZhYmxlIHRoYXQgYSBmYW5jeSBhcHAgZGV2ZWxvcG1lbnQgc3VpdGUgaXMgYWN0aW5n IGFzIGFuIE9BdXRoIGNsaWVudDogZGlyZWN0aW5nIHRoZSBkZXZlbG9wZXIgdG8gdGhlIEFTIHRv IGF1dGhvcml6ZSB0aGUgZGV2ZWxvcG1lbnQgc3VpdGUgdG8gY29udGFjdCB0aGUgcmVnaXN0cmF0 aW9uIOKAnHByb3RlY3RlZCByZXNvdXJjZeKAnSBvbiB0aGUgZGV2ZWxvcGVycyBiZWhhbGYuIE9u Y2UgYXV0aG9yaXplZCwgdGhlIGRldmVsb3BtZW50IHN1aXRlIGNvbGxlY3RzIGEgdG9rZW4gZnJv bSB0aGUgdG9rZW4gZW5kcG9pbnQuIFRoYXQgdG9rZW4gaXMgdGhlIOKAnGluaXRpYWwgYWNjZXNz IHRva2Vu4oCdLiBUaGF0IHdvdWxkIGJlIE9BdXRoIDIgZm9yIHRoZSBmaXJzdCBwYXJ0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFRpbSBCcmF5IFttYWlsdG86dHdicmF5QGdvb2dsZS5j b21dIDxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIDYgSnVuZSAyMDEzIDE6MjMgUE08YnI+PGI+ VG86PC9iPiBNYW5nZXIsIEphbWVzIEg8YnI+PGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj48 Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gcmV2aWV3IGNvbW1lbnRzIG9uIGRyYWZ0LWll dGYtb2F1dGgtZHluLXJlZy0xMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPknigJltIHJlYWxseSBtaXNzaW5nIHNvbWV0aGluZy4gJm5ic3A7WW91IHN0YXJ0IG91 dCB3aXRoIGEgc2NvcGUgeW91IHdhbnQgYSB0b2tlbiBmb3IgZm9yLCB5b3UgZ2V0IHJlZGlyZWN0 ZWQgZm9yIGF1dGhlbnRpY2F0aW9uLCBpdCBjb21lcyBiYWNrIGFuZCB5b3UgZG8gYSBjb2RlIGZs b3cgb3IgYSBicm93c2VyIGZsb3cgYW5kIHlvdSBlbmQgdXAgZ2V0dGluZyBhbiBhY2Nlc3MgdG9r ZW4uICZuYnNwO1NtZWxscyBsaWtlIE9BdXRoIDIgdG8gbWUuICZuYnNwOy1UPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIu MHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBXZWQs IEp1biA1LCAyMDEzIGF0IDg6MTkgUE0sIE1hbmdlciwgSmFtZXMgSCAmbHQ7PGEgaHJlZj0ibWFp bHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20iIHRhcmdldD0iX2JsYW5rIj5KYW1l cy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5UaW0g QnJheSB3cm90ZTo8YnI+Jmd0OyBGV0lXLCBJIGp1c3QgcmVhZCB0aGUgc3BlYyB0aHJvdWdoIHdp dGggZnJlc2ggZXllcywgYW5kIEkgZm91bmQgdGhlIGV4cGxhbmF0aW9uIG9mIHRoZSB3b3JrZmxv dyBpbiAxLjQuMiB2ZXJ5IHVzZWZ1bC4gJm5ic3A7PGJyPiZndDs8YnI+Jmd0OyAtIEEgZGV2ZWxv cGVyIG1hbnVhbGx5IHJlZ2lzdGVycyBhbmQgdGhlbiBpcyBhYmxlIHRvIHJlcXVlc3Qg4oCcSW5p dGlhbCB0b2tlbnPigJ0gdG9rZW5zIGZvciBhIGR5bmFtaWMtYXBwLXJlZ2lzdHJhdGlvbi1zY29w ZSwmbmJzcDs8YnI+Jmd0OyAtIHlvdSB1c2UgdGhhdCDigJxJbml0aWFsIHRva2Vu4oCdIHRva2Vu IHRvIHJlZ2lzdGVyLCBpbiBleGNoYW5nZSB5b3UgZ2V0IHRoZSBjbGllbnQtaWQgJmFtcDsgc28g b24sIGFuZCBhbHNvIGEgYSBwZXItcmVnaXN0cmF0aW9uIOKAnFJlZ2lzdHJhdGlvbiB0b2tlbuKA nSBmb3IgdXBkYXRpbmcgdGhhdCBwYXJ0aWN1bGFyIHJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbjxi cj4mZ3Q7IC0geW91IGZldGNoL3VwZGF0ZS9kZWxldGUgeW91ciByZWdpc3RyYXRpb24gaW5mb3Jt YXRpb24gd2l0aCB0aGF0IHJlZ2lzdHJhdGlvbiB0b2tlbi48YnI+Jmd0Ozxicj4mZ3Q7IFRoZSBm aXJzdCBwYXJ0LCB3aGVyZSB0aGUgZGV2ZWxvcGVyIHJlZ2lzdGVycyAmYW1wOyBnZXRzIGEgdG9r ZW4gZm9yIGEgc2NvcGUsIGlzIHZhbmlsbGEgT0F1dGggMi4gKHJpZ2h0Pyk8bzpwPjwvbzpwPjwv cD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+V3Jvbmc/IFRoaXMgZG9lc24ndCBzb3VuZCBsaWtl IGl0IGhhcyBhbnkgdGVjaG5pY2FsIGNvbm5lY3Rpb24gdG8gT0F1dGggMi4gSXQgaXMgYSBkZXZl bG9wZXIgYnJvd3NpbmcgdG8gYSBzZXJ2aWNlIHBvcnRhbDsgcHJlc3VtYWJseSBsb2dnaW5nIGlu IHdpdGggYSBwYXNzd29yZCwgcGVyaGFwcyB3aXRoIGEgMm5kIGZhY3RvciAobm8gT0F1dGggaGVy ZSk7IGFuZCBtYW51YWxseSBjb3B5aW5nIGEgY3JlZGVudGlhbCB0aGF0IGNhbiBiZSB1c2VkIHdp dGggdGhlICdCRUFSRVInIEhUVFAgQXV0aGVudGljYXRpb24gbWVjaGFuaXNtLiBUaGVyZSBpcyBu byBhcHAgb3JjaGVzdHJhdGluZyB0aGUgaW50ZXJhY3Rpb24gKHRoZSBkZXZlbG9wZXIganVzdCBi cm93c2VkIHRvIHRoZSBwb3J0YWwpOyB0aGVyZSBpcyBubyBwcm9ncmFtbWF0aWMgZXhjaGFuZ2Ug b2Ygb25lIGFwcCBjcmVkZW50aWFsIGZvciBhbm90aGVyIGF0IGFuIEFTIHRva2VuIGVuZHBvaW50 LiBUaGUgb25seSB0ZWNobmljYWwgY29ubmVjdGlvbiB0byBPQXV0aCAyIGlzIHRoYXQgdGhlICdC RUFSRVInIEhUVFAgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGlzIGJyYW5kZWQgJnF1b3Q7T0F1 dGggMiZxdW90OyBmb3IgbWFya2V0aW5nKD8pIHJlYXNvbnMuPGJyPjxicj4tLTxicj5KYW1lcyBN YW5nZXI8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E1151B105CF2WSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Wed Jun 5 21:06:28 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC77211E80E4 for ; Wed, 5 Jun 2013 21:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.004 X-Spam-Level: * X-Spam-Status: No, score=1.004 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1qclBWbaHA0 for ; Wed, 5 Jun 2013 21:06:22 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8AC21F84D4 for ; Wed, 5 Jun 2013 21:06:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,812,1363093200"; d="scan'208,217";a="139421643" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 06 Jun 2013 14:06:21 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7097"; a="136803557" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcbvi.tcif.telstra.com.au with ESMTP; 06 Jun 2013 14:06:21 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Thu, 6 Jun 2013 14:06:20 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Thu, 6 Jun 2013 14:06:19 +1000 Thread-Topic: draft-ietf-oauth-dyn-reg and bearer tokens Thread-Index: Ac5iL79BM7YjzA27Rz+zRJyRJaehgwANR/oQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B105DA5@WSMSG3153V.srv.dir.telstra.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A7ADAE.4070005@mitre.org> <62636DE9-80BD-4B83-817B-3E6622434FD0@oracle.com> <51A7C00B.6050409@mitre.org> <78BAEE23-FB66-4BA5-A1A5-5626D22AA014@oracle.com> <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1151B105DA5WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 04:06:29 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1151B105DA5WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QkVBUkVSIHRva2VucyBkb21pbmF0ZSBPQXV0aCAyIGRlcGxveW1lbnRzIHRvZGF5LCBidXQgT0F1 dGggMiBpcyBkZWxpYmVyYXRlbHkgZXh0ZW5zaWJsZSB0byBzdXBwb3J0IG90aGVyIHNvcnRzIG9m IGNyZWRlbnRpYWxzIChlZyBNQUMgYXV0aGVudGljYXRpb24pLg0KDQpXaHkgaXMgZHJhZnQtaWV0 Zi1vYXV0aC1keW4tcmVnIGhhcmR3aXJlZCB0byBvbmx5IHN1cHBvcnQgQkVBUkVSIHRva2Vucz8N Cg0KMS4zLiDigJxSZWdpc3RyYXRpb24gVG9rZW5zIGFuZCBDcmVkZW50aWFsc+KAnSBzYXlzOg0K DQogIOKAnFRoZSBJbml0aWFsIEFjY2VzcyBUb2tlbiDigKYgaXMgYW4gT0F1dGggMi4wIEJlYXJl ciBUb2tlbuKAnQ0KDQogIOKAnFRoZSBSZWdpc3RyYXRpb24gQWNjZXNzIFRva2VuIOKApiBpcyBh biBPQXV0aCAyLjAgQmVhcmVyIFRva2Vu4oCdDQoNCkdvb2dsZeKAmXMgVExTIENoYW5uZWxJRHMg W2RyYWZ0LWJhbGZhbnotdGxzLWNoYW5uZWxpZF0sIGZvciBpbnN0YW5jZSwgd291bGQgYmUgYSBm YW50YXN0aWMgZml0IGZvciBsaW5raW5nIHRoZSBmaXJzdCByZWdpc3RyYXRpb24gcmVxdWVzdCB3 aXRoIGFueSBzdWJzZXF1ZW50IHJlZ2lzdHJhdGlvbiBtb2RpZmljYXRpb25zLiBUaGUgUmVnaXN0 cmF0aW9uIEFjY2VzcyBUb2tlbiB3b3VsZCBiZSBhbm5veWluZyBsZWdhY3kgYmFnZ2FnZSBpbiB0 aGF0IHNpdHVhdGlvbi4NCg0KDQpJdCBzZWVtcyB0aGF0IHRoZSBSZWdpc3RyYXRpb24gQWNjZXNz IFRva2VuIGlzIG9ubHkgZXZlciB1c2VkIGF0IGEgc2luZ2xlIFVSSTogcmVnaXN0cmF0aW9uX2Ns aWVudF91cmkuIFRoYXQgc291bmRzIGxpa2UgdGhlIHBlcmZlY3Qgc2l0dWF0aW9uIHRvIHVzZSBh IOKAnGNhcGFiaWxpdHkgVVJJ4oCdLCBlZmZlY3RpdmVseSBwdXR0aW5nIHRoZSB0b2tlbiBpbiB0 aGUgVVJJLiBBbnlvbmUgY29uc2lkZXJlZCBkb2luZyB0aGF0PyBJdCBzaG91bGQgc2lnbmlmaWNh bnRseSBzaW1wbGlmeSB0aGUgc3BlYy4NCg0KLS0NCkphbWVzIE1hbmdlcg0K --_000_255B9BB34FB7D647A506DC292726F6E1151B105DA5WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwv aGVhZD48Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1X b3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QkVB UkVSIHRva2VucyBkb21pbmF0ZSBPQXV0aCAyIGRlcGxveW1lbnRzIHRvZGF5LCBidXQgT0F1dGgg MiBpcyBkZWxpYmVyYXRlbHkgZXh0ZW5zaWJsZSB0byBzdXBwb3J0IG90aGVyIHNvcnRzIG9mIGNy ZWRlbnRpYWxzIChlZyBNQUMgYXV0aGVudGljYXRpb24pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2h5 IGlzIGRyYWZ0LWlldGYtb2F1dGgtZHluLXJlZyBoYXJkd2lyZWQgdG8gb25seSBzdXBwb3J0IEJF QVJFUiB0b2tlbnM/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4xLjMuIOKAnFJlZ2lzdHJhdGlvbiBUb2tl bnMgYW5kIENyZWRlbnRpYWxz4oCdIHNheXM6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoCDigJxUaGUg SW5pdGlhbCBBY2Nlc3MgVG9rZW4g4oCmIGlzIGFuIE9BdXRoIDIuMCBCZWFyZXIgVG9rZW7igJ08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPsKgIOKAnFRoZSBSZWdpc3RyYXRpb24gQWNjZXNzIFRva2VuIOKA piBpcyBhbiBPQXV0aCAyLjAgQmVhcmVyIFRva2Vu4oCdPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Hb29n bGXigJlzIFRMUyBDaGFubmVsSURzIFtkcmFmdC1iYWxmYW56LXRscy1jaGFubmVsaWRdLCBmb3Ig aW5zdGFuY2UsIHdvdWxkIGJlIGEgZmFudGFzdGljIGZpdCBmb3IgbGlua2luZyB0aGUgZmlyc3Qg cmVnaXN0cmF0aW9uIHJlcXVlc3Qgd2l0aCBhbnkgc3Vic2VxdWVudCByZWdpc3RyYXRpb24gbW9k aWZpY2F0aW9ucy4gVGhlIFJlZ2lzdHJhdGlvbiBBY2Nlc3MgVG9rZW4gd291bGQgYmUgYW5ub3lp bmcgbGVnYWN5IGJhZ2dhZ2UgaW4gdGhhdCBzaXR1YXRpb24uPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+SXQgc2VlbXMgdGhhdCB0aGUgUmVnaXN0cmF0aW9uIEFjY2VzcyBUb2tlbiBp cyBvbmx5IGV2ZXIgdXNlZCBhdCBhIHNpbmdsZSBVUkk6IHJlZ2lzdHJhdGlvbl9jbGllbnRfdXJp LiBUaGF0IHNvdW5kcyBsaWtlIHRoZSBwZXJmZWN0IHNpdHVhdGlvbiB0byB1c2UgYSDigJxjYXBh YmlsaXR5IFVSSeKAnSwgZWZmZWN0aXZlbHkgcHV0dGluZyB0aGUgdG9rZW4gaW4gdGhlIFVSSS4g QW55b25lIGNvbnNpZGVyZWQgZG9pbmcgdGhhdD8gSXQgc2hvdWxkIHNpZ25pZmljYW50bHkgc2lt cGxpZnkgdGhlIHNwZWMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E1151B105DA5WSMSG3153Vsrv_-- From hannes.tschofenig@nsn.com Wed Jun 5 23:08:26 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B3521F973A for ; Wed, 5 Jun 2013 23:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atwWWP6FN06X for ; Wed, 5 Jun 2013 23:08:21 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C621321F9711 for ; Wed, 5 Jun 2013 23:08:15 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r5668CD5013205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Jun 2013 08:08:13 +0200 Received: from USCHHTC001.nsn-intra.net ([10.159.161.14]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r56689LD025833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 08:08:11 +0200 Received: from USCHMBX001.nsn-intra.net ([169.254.1.6]) by USCHHTC001.nsn-intra.net ([10.159.161.14]) with mapi id 14.03.0123.003; Thu, 6 Jun 2013 01:08:08 -0500 From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Manger, James H"

= --__137054069601641636abhmt101.oracle.com-- From jricher@mitre.org Thu Jun 6 10:48:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CF821F9A80 for ; Thu, 6 Jun 2013 10:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj24vmS2g8ON for ; Thu, 6 Jun 2013 10:48:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 847D821F9A79 for ; Thu, 6 Jun 2013 10:47:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 355541F041C; Thu, 6 Jun 2013 13:47:54 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 05C52226004A; Thu, 6 Jun 2013 13:47:54 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 6 Jun 2013 13:47:53 -0400 Message-ID: <51B0CB18.5090003@mitre.org> Date: Thu, 6 Jun 2013 13:47:04 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <51B0BDA2.7010705@mitre.org> <7B00614C-6B25-4951-B004-C17932432D17@oracle.com> <51B0C6D4.804000!> <9@mitre.org> <51B0C8A0.2020306@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050007050005000608040809" X-Originating-IP: [129.83.31.56] Cc: Donald F Coffin , "oauth@ietf.org" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:48:05 -0000 --------------050007050005000608040809 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Because anonymous *registration* and public client *access* to the token endpoint are two different things. -- Justin On 06/06/2013 01:43 PM, Phil Hunt wrote: > *why* will the 6749 standard flows (specifically 4.4) not work? > > The registration endpoint can allow anonymous access to permit > anonymous registration. > > This means the configuration endpoints can use normal access tokens > obtained through RFC6749 section 4.4 (Client Auth) flows. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-06-06, at 10:36 AM, Justin Richer wrote: > >> ... because it already *is* a REST protected API. It's protected with >> the Registration Access Token. Which is an OAuth 2.0 Bearer token. >> >> The *only* difference is how you get the token, which has nothing to >> do with the REST protected API that it's protecting. >> >> -- Justin >> >> On 06/06/2013 01:35 PM, Phil Hunt wrote: >>> Nobody has explained why using a normal REST protected API won't >>> work. You keep saying that and that you won't go back. But that >>> doesn't explain the issue. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2013-06-06, at 10:28 AM, Justin Richer wrote: >>> >>>> I feel we're still just going in circles with these arguments, but >>>> my comments are inline: >>>> >>>> On 06/06/2013 01:17 PM, Phil Hunt wrote: >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2013-06-06, at 9:49 AM, Justin Richer wrote: >>>>> >>>>>> Tim, thanks for your review! Comments inline. >>>>>> >>>>>> On 06/05/2013 04:59 PM, Tim Bray wrote: >>>>>>> FWIW, I just read the spec through with fresh eyes, and I found >>>>>>> the explanation of the workflow in 1.4.2 very useful. >>>>>>> >>>>>>> - A developer manually registers and then is able to request >>>>>>> �Initial tokens� tokens for a dynamic-app-registration-scope, >>>>>>> - you use that �Initial token� token to register, in exchange >>>>>>> you get the client-id & so on, and also a a per-registration >>>>>>> �Registration token� for updating that particular registration >>>>>>> information >>>>>>> - you fetch/update/delete your registration information with >>>>>>> that registration token. >>>>>>> >>>>>>> The first part, where the developer registers & gets a token for >>>>>>> a scope, is vanilla OAuth 2. (right?) >>>>>> >>>>>> Yes, it can be vanilla Oauth2 or it can be the developer (or >>>>>> someone) getting a token through some other means, like browsing >>>>>> to a developer portal and getting a Bearer token. I've edited the >>>>>> example in 1.4.3 in the latest (unpublished) text so that the >>>>>> developer is literally doing OAuth2 to get the initial token. >>>>>> It's important to note that this could be any flavor of OAuth2 >>>>>> token, though Bearer tokens are of course the most common. >>>>>> >>>>>>> The bit about getting an access token specific to that >>>>>>> registration is a new flow (right?), but it seems convenient. >>>>>> >>>>>> Right, it's a new way to get a bearer token so that you can use >>>>>> it at the protected resource. We wanted to re-use the token >>>>>> endpoint for this, but couldn't come up with a reasonable way of >>>>>> doing so (as has been discussed on the list. >>>>> >>>>> [PH] We still greatly disagree on this. >>>>> >>>>> *Use the normal token issuing process.* One reason given was what >>>>> about anonymous clients? The answer is, they don't have to do >>>>> anything. Remember that you have defined TWO endpoints. The >>>>> "registration endpoint" and the "configuration endpoint". A >>>>> server accepting anonymous registration simply accepts anonymous >>>>> access at the "registration endpoint". Clients wanting to update >>>>> their profiles do the normal client token request flow to the >>>>> token endpoint to obtain a normal access token useable at the >>>>> "configuration endpoint". >>>>> >>>> >>>> [JR] But then you're opening up the client_credentials flow to >>>> anonymous clients, or you've got to be able to lock down >>>> client_credentials as a flow to only a special (service-specific) >>>> scope for client configuration purposes. This, I think, is much >>>> more complicated to implement and much more error prone. I don't >>>> think it's even possible in the software stack we're building on >>>> top of. And furthermore, you're not letting public clients >>>> dynamically register anymore, since you'd be forcing everyone to >>>> have a client secret. Your dynamic public clients would have to >>>> save the client secret but know to only use it at the registration >>>> endpoint, and not the token endpoint where they're used to. This >>>> way, it's clear. You get a token that you use at a given endpoint, >>>> the end. >>>> >>>>> As soon as you do this, other things simplify. >>>>> >>>>> 1. No need to keep "registration access token" around >>>>> indefinitely. It's just an access token. In fact it is only >>>>> needed for minutes since it will likely only be used to read or >>>>> update profiles or to perform client initiated credential rotation. >>>> >>>> [JR] You *can* throw away your registration access tokens if you >>>> want to, or have them expire, if you want to limit the lifespan of >>>> your clients. It's only the security considerations section that >>>> suggests against expiring the tokens, and for good reason. But it's >>>> your choice to change that if you don't want longstanding read/edit >>>> access to a client's configuration. >>>> >>>>> 2. No need to have a special token issuing method. Creating a new >>>>> issuing process suggests that the WG can't drink its own koolaid. >>>>> Because at the first seeming challenge, the WG create a new flow. >>>>> How do we expect implementers to behave? >>>> >>>> [JR] That particular koolaid wasn't the right drink here, to >>>> stretch your analogy. Bearer tokens were, which is also the group's >>>> koolaid. We tried to go down the road you suggest and it was a dead >>>> end. Why do you think it will work better this time? And I'd like >>>> to point out a decision from several years ago now to separate the >>>> notion of "how you get a token" from "how you use a token" in >>>> OAuth2. OAuth1 had all of these rolled in together, and deployment >>>> experience showed us that people didn't really want to use it that >>>> way. People want components that make sense on their own that let >>>> you build systems like this that also make sense. >>>> >>>> Forced uniformity isn't necessarily a good thing. >>>> >>>>> 3. The registration/configuration API is JUST a normal OAuth2 >>>>> protected API. >>>> >>>> [JR] It already is. Protected resources don't care where you get >>>> your tokens from, just that you have them, so from that perspective >>>> it is just a protected resource. Our implementation here literally >>>> just looks for the token on the way in in the auth layer and makes >>>> sure it's got a special service-specific scope that handles >>>> registration. >>>> >>>>> >>>>> If the draft drops "registration access tokens", a lot of the text >>>>> in the draft disappears. The whole spec is much simpler. >>>> >>>> [JR] Much simpler, perhaps, but much less functional and useful. >>>> And honestly, not much of the text actually goes away. Most of the >>>> draft isn't about dealing with the registration access token, it's >>>> about dealing with the client metadata and the RESTful protocol for >>>> managing that. The registration access token is a mechanism for >>>> doing so. >>>> >>>>> >>>>>> >>>>>>> From an OAuth 2 point of view, there's nothing special about >>>>>>> how you get or use the Initial token, but giving it a special >>>>>>> name makes explaining a plausible workflow easier. >>>>>> >>>>>> Right, and I've admitted that "Initial Access Token" a crappy >>>>>> name, but I haven't heard a better suggestion yet. >>>>>> >>>>>>> >>>>>>> Having said that, I have trouble imagining the scenario where >>>>>>> you'd use the 1.4.1 flow, but that may be because of my >>>>>>> Google-centric worldview. >>>>>> >>>>>> Could be -- but if Google wants to be an open-registration >>>>>> identity provider (like it has been with OpenID 2.0), it will >>>>>> need to handle this flow as well. This is the client acting on >>>>>> its own behalf, showing up and saying "hi, I'm a client!" and >>>>>> that's that. I think this is a very important case for >>>>>> interoperability of dynamic registration. >>>>>> >>>>>>> >>>>>>> And I�m not sure 1.4.3 adds any value at all. It just seems to >>>>>>> be a matter of different ways you could get and make use of the >>>>>>> registration access token; and I'm sure there are various >>>>>>> interesting combinations that haven't been thought of there. >>>>>>> I'd just lose 1.4.3. >>>>>>> >>>>>> >>>>>> 1.4.3 in -11 is too close to 1.4.2, so what I've done in the >>>>>> current working text is make the initial process of getting the >>>>>> Initial Access Token different (the developer now uses OAuth2 to >>>>>> configure their build environment). The *real* important >>>>>> difference that's being shown here, though, is that the client >>>>>> doesn't call the registration endpoint, the developer (and their >>>>>> build environment) does. So yes, it's exactly all about how you >>>>>> get and use the registration access token. There are plenty of >>>>>> other ways to do it as well, so that's why this section was a >>>>>> non-normative set of examples. To facilitate that understanding, >>>>>> I've moved it to an appendix in the working copy of draft -12. >>>>>> >>>>>> Thanks, >>>>>> -- Justin >>>>>> >>>>>>> -T >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> See my comments inline [DFC] >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Don >>>>>>> >>>>>>> Donald F. Coffin >>>>>>> >>>>>>> Founder/CTO >>>>>>> >>>>>>> >>>>>>> REMI Networks >>>>>>> >>>>>>> 22751 El Prado Suite 6216 >>>>>>> >>>>>>> Rancho Santa Margarita, CA 92688-3836 >>>>>>> >>>>>>> >>>>>>> Phone: (949) 636-8571 >>>>>>> >>>>>>> Email: donald.coffin@reminetworks.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:*Justin Richer [mailto:jricher@mitre.org >>>>>>> ] >>>>>>> *Sent:* Friday, May 31, 2013 12:40 PM >>>>>>> *To:* Phil Hunt >>>>>>> *Cc:* Donald F Coffin; oauth@ietf.org >>>>>>> >>>>>>> >>>>>>> *Subject:* Re: [OAUTH-WG] review comments on >>>>>>> draft-ietf-oauth-dyn-reg-11.txt >>>>>>> >>>>>>> I feel the need to clarify a couple erroneous things in >>>>>>> Phil's statement: >>>>>>> >>>>>>> >>>>>>> >>>>>>> * To be clear, Draft 11 has the same Registration Access >>>>>>> Token system that has been in place since draft 01, it is >>>>>>> not inventing something new at the last minute as could be >>>>>>> inferred from the statement below. >>>>>>> >>>>>>> [DFC] I agree with Justin. There is nothing new in draft >>>>>>> 11 regarding Registration Access Tokens that wasn�t in the >>>>>>> initial draft. It appears because Phil hasn�t been >>>>>>> following the proposed drafts until the last call he is now >>>>>>> raising an issue no one in the WG saw as an issue. That�s >>>>>>> not to say his point isn�t valid, but the discussion >>>>>>> continues to go all over the map between �local� and >>>>>>> �federated� tokens, usage of the RFC6749 �Token� endpoint, >>>>>>> etc. It would be great if all of Phil�s points could be >>>>>>> addressed in priority >>>>>>> without the threads becoming so convoluted no one is able to >>>>>>> make sense or even comprehend the point being discussed. >>>>>>> >>>>>>> >>>>>>> * DynReg is using an absolutely standard OAuth 2 Bearer >>>>>>> token as the Registration Access Token, it's just not coming >>>>>>> from a Token Endpoint. However, since an OAuth Protected >>>>>>> Resource doesn't care where its tokens come from so long as >>>>>>> it can validate them, I don't see this as a problem -- this >>>>>>> is a key point where Phil and I disagree. >>>>>>> >>>>>>> [DFC] I understand the disagreement, but I have not seen a >>>>>>> proposal from Phil that would describe the differences >>>>>>> between the two perspectives other than to say that the >>>>>>> Dynamic Registration should use the Token endpoint defined >>>>>>> in RFC6749, which does not discuss dynamic registration. >>>>>>> Phil�s point as I understand it is that there should be no >>>>>>> difference between an access token used to access resource >>>>>>> owner protected data and the registration structure, which I >>>>>>> do not agree with. As I said in the previous >>>>>>> response, my users do NOT want to provide implied access to >>>>>>> resource owner protected data just because a client is >>>>>>> creating a registration with an AS. This would be the >>>>>>> situation if the client credential flow is used to register >>>>>>> an application. Since our >>>>>>> implementation does NOT support the implicit flow, that use >>>>>>> case is one we have elected NOT to support. >>>>>>> >>>>>>> [DFC] I repeat my initial comment, this >>>>>>> conversation has been a circular exchange now for the past >>>>>>> few days without any appearance of an alternative option to >>>>>>> resolve the issues. >>>>>>> >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> On 05/31/2013 03:33 PM, Phil Hunt wrote: >>>>>>> >>>>>>> Don, >>>>>>> >>>>>>> >>>>>>> I am not proposing any change in meaning. If >>>>>>> registration acces token issues by normal token server >>>>>>> with scope registration everything is clear as it is for >>>>>>> any other protected API. Draft 11 invents a whole new >>>>>>> system. I strongly disagree with this. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> On 2013-05-31, at 15:16, Donald F Coffin >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> For something that was agreed to be parked a few >>>>>>> hours ago, there sure seems to still be a lot of >>>>>>> circular discussion. Should we ask a mediator to >>>>>>> intervene? >>>>>>> >>>>>>> >>>>>>> FWIW I believe that is a significantly strong reason >>>>>>> to differentiate an access token that can access the >>>>>>> registration information without having the ability >>>>>>> to access protected data. Especially given the >>>>>>> implied strength of the �client credential� obtained >>>>>>> access token. I have found it extremely confusing to >>>>>>> users when explaining the difference between an >>>>>>> access token obtained thorough an authorization code >>>>>>> flow and a client credential flow, simply because >>>>>>> they are both called an �access token�. Changing the >>>>>>> meaning of an access token obtained through the >>>>>>> client credential flow to mean it has the ability to >>>>>>> update a registration, when a user may not want it >>>>>>> to have access to protected data will only increase >>>>>>> both the complexity of the access tokens as well as >>>>>>> make their usage harder to explain to non-technical >>>>>>> individuals who have to understand the differences >>>>>>> between the access tokens obtained through the >>>>>>> various flows. >>>>>>> >>>>>>> >>>>>>> Just my two cents. >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Don >>>>>>> >>>>>>> Donald F. Coffin >>>>>>> >>>>>>> Founder/CTO >>>>>>> >>>>>>> >>>>>>> REMI Networks >>>>>>> >>>>>>> 22751 El Prado Suite 6216 >>>>>>> >>>>>>> Rancho Santa Margarita, CA 92688-3836 >>>>>>> >>>>>>> >>>>>>> Phone: (949) 636-8571 >>>>>>> >>>>>>> Email: donald.coffin@reminetworks.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:*Phil Hunt [mailto:phil.hunt@oracle.com] >>>>>>> *Sent:* Friday, May 31, 2013 11:11 AM >>>>>>> *To:* Justin Richer >>>>>>> *Cc:* oauth@ietf.org WG >>>>>>> *Subject:* Re: [OAUTH-WG] review comments on >>>>>>> draft-ietf-oauth-dyn-reg-11.txt >>>>>>> >>>>>>> >>>>>>> To be clear. >>>>>>> >>>>>>> >>>>>>> It is two separate issues. >>>>>>> >>>>>>> >>>>>>> 1. Anonymous clients can easily be handled through >>>>>>> policy config. >>>>>>> >>>>>>> >>>>>>> 2. Support for implicit clients needs to be >>>>>>> discussed. The current proposal creates large >>>>>>> negative value for the service provider and most >>>>>>> would never allow in current form. Yes it gives each >>>>>>> execution instance a new id, but that isnt what sp's >>>>>>> want. It is a huge attack and management headache. >>>>>>> Eliminate or propose a different solution. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> On 2013-05-31, at 13:58, Justin Richer >>>>>>> > wrote: >>>>>>> >>>>>>> I'm not willing to write out an entire class of >>>>>>> clients from this spec, especially when we have >>>>>>> stated use cases for them doing dynamic >>>>>>> registration. >>>>>>> >>>>>>> I'm sorry, but your proposed solution will >>>>>>> simply not work. >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> On 05/31/2013 01:56 PM, Phil Hunt wrote: >>>>>>> >>>>>>> Well the only client that wouldn't have a >>>>>>> credential is an implicit client. An >>>>>>> implicit client is transient and so would >>>>>>> never update. >>>>>>> >>>>>>> Besides, as i have stated, implicit clients >>>>>>> should not use dyn reg. >>>>>>> >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> On 2013-05-31, at 13:41, Justin Richer >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> But the outstanding question is: how do >>>>>>> you get the access token to access the >>>>>>> created resource (IE: the Registration >>>>>>> Access Token)? You can't use the >>>>>>> client_credentials flow for a client >>>>>>> with no credentials! >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> >>>>>>> On 05/31/2013 12:58 PM, Phil Hunt wrote: >>>>>>> >>>>>>> Yes. I specified the trivial >>>>>>> solution to anonymous clients earlier. >>>>>>> >>>>>>> >>>>>>> Even simpler. You don't need an >>>>>>> access token to create a new >>>>>>> resource. You just need one to >>>>>>> access one. That is just basic >>>>>>> security config. >>>>>>> >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> On 2013-05-31, at 12:34, Justin >>>>>>> Richer >>>>>> > wrote: >>>>>>> >>>>>>> I agree that we are going in >>>>>>> circles, since I just was going >>>>>>> to bring up my counter argument >>>>>>> of "what about clients with no >>>>>>> credentials?" again, which >>>>>>> *still* isn't addressed by what >>>>>>> you suggest doing, below. I also >>>>>>> believe that getting rid of the >>>>>>> Registration Access Token but >>>>>>> using some other token method >>>>>>> would actually make the spec >>>>>>> larger, though I'd be glad to >>>>>>> review a concrete >>>>>>> counter-proposal if you'd like >>>>>>> to write one. And the fact that >>>>>>> OIDC is doing it this way, and >>>>>>> considered but rejected the way >>>>>>> that you're describing, should >>>>>>> say something to the WG here >>>>>>> about whether or not this is the >>>>>>> right choice. Rough consensus >>>>>>> and running code, after all. >>>>>>> >>>>>>> Regardless, I agree to park this >>>>>>> issue and leave the text as is. >>>>>>> We'll move to the next draft in >>>>>>> the last call process shortly, >>>>>>> as I have a handful of >>>>>>> non-normative editorial changes >>>>>>> that I need to make, thanks to >>>>>>> feedback from a few folks. >>>>>>> >>>>>>> Again, thanks for your thorough >>>>>>> review, Phil, and I look forward >>>>>>> to future feedback. >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> On 05/31/2013 12:28 PM, Phil >>>>>>> Hunt wrote: >>>>>>> >>>>>>> I disagree. >>>>>>> >>>>>>> >>>>>>> There is absolutely no need >>>>>>> for a registration access >>>>>>> token. >>>>>>> >>>>>>> >>>>>>> Get rid of it and just use >>>>>>> access tokens as per 6749. >>>>>>> If you can't follow 6749 and >>>>>>> need new issuing methods, >>>>>>> what are others to say >>>>>>> regarding inventing new methods? >>>>>>> >>>>>>> >>>>>>> I have not heard a good >>>>>>> reason for the special >>>>>>> process or one good enough >>>>>>> to warrant a new method for >>>>>>> issuing an access token. >>>>>>> Does the broader group >>>>>>> realize this is what the >>>>>>> spec says? >>>>>>> >>>>>>> >>>>>>> Yes, i heard a lot saying >>>>>>> OIDC does it this way. But >>>>>>> that is a political reason, >>>>>>> not a technical reason. >>>>>>> Still, compatibility is >>>>>>> always a strong objective. >>>>>>> Even so, oidc could keep >>>>>>> using their method just >>>>>>> fine. There is no obligation >>>>>>> here to do the same. >>>>>>> >>>>>>> >>>>>>> The only reason so far was >>>>>>> expiry of client creds. >>>>>>> Well, why not require the >>>>>>> client to update prior to >>>>>>> expiry? It makes no sense to >>>>>>> have another token with >>>>>>> longer expiry. B'sides, even >>>>>>> expired the client can >>>>>>> re-register from scratch. >>>>>>> >>>>>>> >>>>>>> Why force the client to >>>>>>> persist multiple tokens and >>>>>>> creds? That is far far too >>>>>>> complex. >>>>>>> >>>>>>> >>>>>>> Finally if you get rid of >>>>>>> registration access token >>>>>>> the spec size will drop >>>>>>> roughly in half IMO. This >>>>>>> suggests simplicity to me. >>>>>>> >>>>>>> >>>>>>> Apologies for my rant. Maybe >>>>>>> we should park this for now. >>>>>>> We are going in circles. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> On 2013-05-31, at 11:25, >>>>>>> Justin Richer >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Phil, >>>>>>> >>>>>>> We *can* keep it >>>>>>> straight just fine, but >>>>>>> I just need you to be >>>>>>> clear about which part >>>>>>> you're objecting to >>>>>>> because the answers are >>>>>>> different. Please use >>>>>>> the terms as defined in >>>>>>> the document so that we >>>>>>> all know which component >>>>>>> we're talking about. I'm >>>>>>> sure you'd agree than in >>>>>>> specification work such >>>>>>> as this, precision of >>>>>>> language and labels is >>>>>>> key for communication >>>>>>> between parties. This is >>>>>>> precisely why there's a >>>>>>> Terminology section >>>>>>> right up front, so that >>>>>>> when I say "Registration >>>>>>> Access Token" you can >>>>>>> know that I mean a very >>>>>>> specific thing, and when >>>>>>> I say "Initial >>>>>>> Registration Token" I >>>>>>> mean a very different >>>>>>> specific thing. So I'm >>>>>>> asking you, please, use >>>>>>> the defined terms so >>>>>>> that we can avoid this >>>>>>> unnecessary confusion. >>>>>>> >>>>>>> But anyway, what you're >>>>>>> talking about below, >>>>>>> "the token the client >>>>>>> uses to update is >>>>>>> profile" *IS* the >>>>>>> Registration Access >>>>>>> Token. That's all that >>>>>>> that token is used for. >>>>>>> You're not asking for it >>>>>>> to go away, you're >>>>>>> asking for it to come >>>>>>> from the Token Endpoint >>>>>>> instead of the response >>>>>>> from the Registration >>>>>>> Endpoint. I don't see >>>>>>> how the client *can* get >>>>>>> it from the normal token >>>>>>> process without jumping >>>>>>> through specialized >>>>>>> hoops to make that >>>>>>> happen. I've implemented >>>>>>> the draft the way that >>>>>>> it is right now, both >>>>>>> client and server side, >>>>>>> and it works. Others >>>>>>> have implemented it, >>>>>>> too. We've done interop >>>>>>> testing, and it works. >>>>>>> This is a proven pattern >>>>>>> and from where I sit >>>>>>> there is both rough >>>>>>> consensus and running code. >>>>>>> >>>>>>> I believe that I've >>>>>>> already pointed out how >>>>>>> the solutions you've >>>>>>> proposed so far won't >>>>>>> work in practice, for >>>>>>> various reasons, many of >>>>>>> which have already been >>>>>>> brought up and discussed >>>>>>> previously. If you have >>>>>>> another way for the >>>>>>> client to get its >>>>>>> Registration Access >>>>>>> Token, please propose >>>>>>> it; but I haven't seen >>>>>>> anything yet that will fly. >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> On 05/31/2013 11:10 AM, >>>>>>> Phil Hunt wrote: >>>>>>> >>>>>>> Justin, >>>>>>> >>>>>>> >>>>>>> This is my primary >>>>>>> objection! We can't >>>>>>> keep it straight. >>>>>>> Their should be no >>>>>>> such thing as a >>>>>>> registrstion access >>>>>>> token! Just the >>>>>>> token the client >>>>>>> obtains to update >>>>>>> its profile through >>>>>>> the normal token >>>>>>> request process. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> On 2013-05-31, at >>>>>>> 10:55, Justin Richer >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Which token are >>>>>>> you referring to >>>>>>> here? >>>>>>> >>>>>>> If it's the >>>>>>> Initial >>>>>>> Registration >>>>>>> Token, then you >>>>>>> could get that >>>>>>> through the >>>>>>> normal token >>>>>>> server no >>>>>>> problem. (The >>>>>>> lifecycle >>>>>>> writeups don't >>>>>>> call this out >>>>>>> explicitly but I >>>>>>> would be willing >>>>>>> to do so.) Or >>>>>>> you could get it >>>>>>> elsewhere. >>>>>>> Doesn't matter, >>>>>>> just like it >>>>>>> doesn't matter >>>>>>> with any other >>>>>>> OAuth2 protected >>>>>>> resource. >>>>>>> >>>>>>> If it's the >>>>>>> Registration >>>>>>> Access Token, >>>>>>> then having the >>>>>>> token come from >>>>>>> the token >>>>>>> endpoint would >>>>>>> require a lot >>>>>>> more work and >>>>>>> complexity on >>>>>>> behalf of both >>>>>>> of the client >>>>>>> and server. >>>>>>> Either you end >>>>>>> up with public >>>>>>> clients getting >>>>>>> secrets they >>>>>>> shouldn't need >>>>>>> or with granting >>>>>>> clients access >>>>>>> to the >>>>>>> client_credentials >>>>>>> flow when they >>>>>>> shouldn't >>>>>>> actually have >>>>>>> it. Plus it adds >>>>>>> extra round >>>>>>> trips which >>>>>>> don't buy you >>>>>>> anything. >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> On 05/31/2013 >>>>>>> 10:15 AM, Phil >>>>>>> Hunt wrote: >>>>>>> >>>>>>> The >>>>>>> preference >>>>>>> is to have >>>>>>> the access >>>>>>> token for >>>>>>> registration >>>>>>> issued by >>>>>>> the normal >>>>>>> token server >>>>>>> rather then >>>>>>> by the >>>>>>> registration >>>>>>> endpoint. >>>>>>> >>>>>>> >>>>>>> In the >>>>>>> current >>>>>>> draft it is >>>>>>> obtained >>>>>>> through a >>>>>>> unique >>>>>>> process and >>>>>>> must outlive >>>>>>> the client. >>>>>>> >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> On >>>>>>> 2013-05-30, >>>>>>> at 19:47, >>>>>>> "Richer, >>>>>>> Justin P." >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> I don't >>>>>>> understand >>>>>>> any of >>>>>>> the >>>>>>> comments >>>>>>> below -- >>>>>>> it >>>>>>> already >>>>>>> *is* an >>>>>>> OAuth2 >>>>>>> protected resource >>>>>>> without >>>>>>> any >>>>>>> special >>>>>>> handling. Your >>>>>>> access >>>>>>> tokens >>>>>>> can be >>>>>>> short-lived, >>>>>>> long-lived, >>>>>>> federated, >>>>>>> structured, >>>>>>> random >>>>>>> blobs >>>>>>> ... >>>>>>> totally >>>>>>> doesn't >>>>>>> matter. >>>>>>> They are >>>>>>> access >>>>>>> tokens >>>>>>> being >>>>>>> used to >>>>>>> access a >>>>>>> normal >>>>>>> protected resource. >>>>>>> Full stop. >>>>>>> >>>>>>> Anything >>>>>>> else is >>>>>>> out of >>>>>>> scope. >>>>>>> The >>>>>>> lifecycle discussions >>>>>>> at the >>>>>>> beginning are >>>>>>> merely >>>>>>> examples >>>>>>> of some >>>>>>> ways you >>>>>>> *could* >>>>>>> use it >>>>>>> and are >>>>>>> non-normative >>>>>>> and >>>>>>> non-exhaustive. >>>>>>> >>>>>>> You seem >>>>>>> to be >>>>>>> asking >>>>>>> for >>>>>>> something that's >>>>>>> already >>>>>>> in the >>>>>>> draft. >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> *From:*Phil >>>>>>> Hunt >>>>>>> [phil.hunt@oracle.com >>>>>>> ] >>>>>>> *Sent:* >>>>>>> Thursday, May >>>>>>> 30, 2013 >>>>>>> 7:31 PM >>>>>>> *To:* >>>>>>> Richer, >>>>>>> Justin P. >>>>>>> *Cc:* >>>>>>> John >>>>>>> Bradley; >>>>>>> oauth@ietf.org >>>>>>> >>>>>>> WG >>>>>>> *Subject:* >>>>>>> Re: >>>>>>> [OAUTH-WG] >>>>>>> review >>>>>>> comments >>>>>>> on >>>>>>> draft-ietf-oauth-dyn-reg-11.txt >>>>>>> >>>>>>> >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> On >>>>>>> 2013-05-30, >>>>>>> at >>>>>>> 16:11, >>>>>>> "Richer, >>>>>>> Justin >>>>>>> P." >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Comments >>>>>>> inline, >>>>>>> marked >>>>>>> by [JR]. >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> *From:*Phil >>>>>>> Hunt >>>>>>> [phil.hunt@oracle.com >>>>>>> ] >>>>>>> *Sent:* >>>>>>> Thursday, >>>>>>> May >>>>>>> 30, >>>>>>> 2013 >>>>>>> 5:25 PM >>>>>>> *To:* Richer, >>>>>>> Justin >>>>>>> P. >>>>>>> *Cc:* John >>>>>>> Bradley; >>>>>>> oauth@ietf.org >>>>>>> >>>>>>> WG >>>>>>> *Subject:* >>>>>>> Re: >>>>>>> [OAUTH-WG] >>>>>>> review >>>>>>> comments >>>>>>> on >>>>>>> draft-ietf-oauth-dyn-reg-11.txt >>>>>>> >>>>>>> See >>>>>>> below. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> @independentid >>>>>>> >>>>>>> www.independentid.com >>>>>>> >>>>>>> >>>>>>> phil.hunt@oracle.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On >>>>>>> 2013-05-30, >>>>>>> at >>>>>>> 2:09 >>>>>>> PM, >>>>>>> Justin >>>>>>> Richer >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> OK, >>>>>>> I >>>>>>> think see >>>>>>> part >>>>>>> of >>>>>>> the >>>>>>> hang >>>>>>> up. >>>>>>> I >>>>>>> have >>>>>>> not >>>>>>> seen >>>>>>> the >>>>>>> scenario >>>>>>> that >>>>>>> you >>>>>>> describe, >>>>>>> where you >>>>>>> trade a >>>>>>> 3rd >>>>>>> party token >>>>>>> for >>>>>>> a >>>>>>> "local" >>>>>>> token. >>>>>>> I >>>>>>> have >>>>>>> seen >>>>>>> where access >>>>>>> tokens >>>>>>> are >>>>>>> federated >>>>>>> directly >>>>>>> at >>>>>>> the >>>>>>> PR. >>>>>>> (Introspection >>>>>>> lets >>>>>>> you >>>>>>> do >>>>>>> some >>>>>>> good >>>>>>> things >>>>>>> with >>>>>>> that >>>>>>> pattern.) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --------------050007050005000608040809 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Because anonymous *registration* and public client *access* to the token endpoint are two different things.

�-- Justin

On 06/06/2013 01:43 PM, Phil Hunt wrote:

*why* will the 6749 standard flows (specifically 4.4) not work?

The registration endpoint can allow anonymous access to permit anonymous registration.

This means the configuration endpoints can use normal access tokens obtained through RFC6749 section 4.4 (Client Auth) flows.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:36 AM, Justin Richer wrote:

... because it already *is* a REST protected API. It's protected with the Registration Access Token. Which is an OAuth 2.0 Bearer token.

The *only* difference is how you get the token, which has nothing to do with the REST protected API that it's protecting.

�-- Justin

On 06/06/2013 01:35 PM, Phil Hunt wrote:

Nobody has explained why using a normal REST protected API won't work. You keep saying that and that you won't go back. �But that doesn't explain the issue.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:28 AM, Justin Richer wrote:

I feel we're still just going in circles with these arguments, but my comments are inline:

On 06/06/2013 01:17 PM, Phil Hunt wrote:

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 9:49 AM, Justin Richer wrote:

Tim, thanks for your review! Comments inline.

On 06/05/2013 04:59 PM, Tim Bray wrote:

FWIW, I just read the spec through with fresh eyes, and I found the explanation of the workflow in 1.4.2 very useful. �

- A developer manually registers and then is able to request �Initial tokens� tokens for a dynamic-app-registration-scope,�

- you use that �Initial token� token to register, in exchange you get the client-id & so on, and also a a per-registration �Registration token� for updating that particular registration information

- you fetch/update/delete your registration information with that registration token.

The first part, where the developer registers & gets a token for a scope, is vanilla OAuth 2. (right?)�

Yes, it can be vanilla Oauth2 or it can be the developer (or someone) getting a token through some other means, like browsing to a developer portal and getting a Bearer token. I've edited the example in 1.4.3 in the latest (unpublished) text so that the developer is literally doing OAuth2 to get the initial token. It's important to note that this could be any flavor of OAuth2 token, though Bearer tokens are of course the most common.

The bit about getting an access token specific to that registration is a new flow (right?), but it seems convenient.

Right, it's a new way to get a bearer token so that you can use it at the protected resource. We wanted to re-use the token endpoint for this, but couldn't come up with a reasonable way of doing so (as has been discussed on the list.

[PH] We still greatly disagree on this.

*Use the normal token issuing process.* �One reason given was what about anonymous clients? �The answer is, they don't have to do anything. Remember that you have defined TWO endpoints. �The "registration endpoint" and the "configuration endpoint". �A server accepting anonymous registration simply accepts anonymous access at the "registration endpoint". �Clients wanting to update their profiles do the normal client token request flow to the token endpoint to obtain a normal access token useable at the "configuration endpoint".

[JR] But then you're opening up the client_credentials flow to anonymous clients, or you've got to be able to lock down client_credentials as a flow to only a special (service-specific) scope for client configuration purposes. This, I think, is much more complicated to implement and much more error prone. I don't think it's even possible in the software stack we're building on top of. And furthermore, you're not letting public clients dynamically register anymore, since you'd be forcing everyone to have a client secret. Your dynamic public clients would have to save the client secret but know to only use it at the registration endpoint, and not the token endpoint where they're used to. This way, it's clear. You get a token that you use at a given endpoint, the end.

As soon as you do this, other things simplify.

1. �No need to keep "registration access token" around indefinitely. It's just an access token. �In fact it is only needed for minutes since it will likely only be used to read or update profiles or to perform client initiated credential rotation.

[JR] You *can* throw away your registration access tokens if you want to, or have them expire, if you want to limit the lifespan of your clients. It's only the security considerations section that suggests against expiring the tokens, and for good reason. But it's your choice to change that if you don't want longstanding read/edit access to a client's configuration.

2. �No need to have a special token issuing method.�Creating a new issuing process suggests that the WG can't drink its own koolaid. �Because at the first seeming challenge, the WG create a new flow. How do we expect implementers to behave?

[JR] That particular koolaid wasn't the right drink here, to stretch your analogy. Bearer tokens were, which is also the group's koolaid. We tried to go down the road you suggest and it was a dead end. Why do you think it will work better this time? And I'd like to point out a decision from several years ago now to separate the notion of "how you get a token" from "how you use a token" in OAuth2. OAuth1 had all of these rolled in together, and deployment experience showed us that people didn't really want to use it that way. People want components that make sense on their own that let you build systems like this that also make sense.

Forced uniformity isn't necessarily a good thing.

3. �The registration/configuration API is JUST a normal OAuth2 protected API.

[JR] It already is. Protected resources don't care where you get your tokens from, just that you have them, so from that perspective it is just a protected resource. Our implementation here literally just looks for the token on the way in in the auth layer and makes sure it's got a special service-specific scope that handles registration.

If the draft drops "registration access tokens", a lot of the text in the draft disappears. �The whole spec is much simpler.

[JR] Much simpler, perhaps, but much less functional and useful. And honestly, not much of the text actually goes away. Most of the draft isn't about dealing with the registration access token, it's about dealing with the client metadata and the RESTful protocol for managing that. The registration access token is a mechanism for doing so.

� From an OAuth 2 point of view, there's nothing special about how you get or use the Initial token, but giving it a special name makes explaining a plausible workflow easier.�

Right, and I've admitted that "Initial Access Token" a crappy name, but I haven't heard a better suggestion yet.

Having said that, I have trouble imagining the scenario where you'd use the 1.4.1 flow, but that may be because of my Google-centric worldview.

Could be -- but if Google wants to be an open-registration identity provider (like it has been with OpenID 2.0), it will need to handle this flow as well. This is the client acting on its own behalf, showing up and saying "hi, I'm a client!" and that's that. I think this is a very important case for interoperability of dynamic registration.

And I�m not sure 1.4.3 adds any value at all. �It just seems to be a matter of different ways you could get and make use of the registration access token; and I'm sure there are various interesting combinations that haven't been thought of there. �I'd just lose 1.4.3.

1.4.3 in -11 is too close to 1.4.2, so what I've done in the current working text is make the initial process of getting the Initial Access Token different (the developer now uses OAuth2 to configure their build environment). The *real* important difference that's being shown here, though, is that the client doesn't call the registration endpoint, the developer (and their build environment) does. So yes, it's exactly all about how you get and use the registration access token. There are plenty of other ways to do it as well, so that's why this section was a non-normative set of examples. To facilitate that understanding, I've moved it to an appendix in the working copy of draft -12.

Thanks,
�-- Justin

�-T

On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin <donald.coffin@reminetworks.com> wrote:

See my comments inline [DFC]

�

Best regards,

Don

Donald F. Coffin

Founder/CTO

�

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA� 92688-3836

�

Phone:�� (949) 636-8571

Email:�� donald.coffin@reminetworks.com

�

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, May 31, 2013 12:40 PM
To: Phil Hunt
Cc: Donald F Coffin; oauth@ietf.org

Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

�

I feel the need to clarify a couple erroneous things in Phil's statement:

� * To be clear, Draft 11 has the same Registration Access Token system that has been in place since draft 01, it is not inventing something new at the last minute as could be inferred from the statement below.

[DFC] �I agree with Justin.� There is nothing new in draft 11 regarding Registration Access Tokens that wasn�t in the initial draft.� It appears because Phil hasn�t been following the proposed drafts until the last call he is now raising an issue no one in the WG saw as an issue.� That�s not to say his point isn�t valid, but the discussion continues to go all over the map between �local� and �federated� tokens, usage of the RFC6749 �Token� endpoint, etc.� It would be great if all of Phil�s points could be addressed in priority
without the threads becoming so convoluted no one is able to make sense or even comprehend the point being discussed.

� * DynReg is using an absolutely standard OAuth 2 Bearer token as the Registration Access Token, it's just not coming from a Token Endpoint. However, since an OAuth Protected Resource doesn't care where its tokens come from so long as it can validate them, I don't see this as a problem -- this is a key point where Phil and I disagree.

[DFC] �I understand the disagreement, but I have not seen a proposal from Phil that would describe the differences between the two perspectives other than to say that the Dynamic Registration should use the Token endpoint defined in RFC6749, which does not�� discuss dynamic registration.� Phil�s point as I understand it is that there should be no difference between an access token used to access resource owner protected data and the registration structure, which I do not agree with.� As I said in the previous
�� response, my users do NOT want to provide implied access to resource owner protected data just because a client is creating a registration with an AS.� This would be the situation if the client credential flow is used to register an application.� Since our
�� implementation does NOT support the implicit flow, that use case is one we have elected NOT to support.

�� [DFC]� I repeat my initial comment, this conversation has been a circular exchange now for the past few days without any appearance of an alternative option to resolve the issues.

�-- Justin

On 05/31/2013 03:33 PM, Phil Hunt wrote:

Don,

�

I am not proposing any change in meaning. If registration acces token issues by normal token server with scope registration everything is clear as it is for any other protected API. Draft 11 invents a whole new system. I strongly disagree with this.

Phil

On 2013-05-31, at 15:16, Donald F Coffin <donald.coffin@reminetworks.com> wrote:

For something that was agreed to be parked a few hours ago, there sure seems to still be a lot of circular discussion.� Should we ask a mediator to intervene?

�

FWIW I believe that is a significantly strong reason to differentiate an access token that can access the registration information without having the ability to access protected data.� Especially given the implied strength of the �client credential� obtained access token.� I have found it extremely confusing to users when explaining the difference between an access token obtained thorough an authorization code flow and a client credential flow, simply because they are both called an �access token�.� Changing the meaning of an access token obtained through the client credential flow to mean it has the ability to update a registration, when a user may not want it to have access to protected data will only increase both the complexity of the access tokens as well as make their usage harder to explain to non-technical individuals who have to understand the differences between the access tokens obtained through the various flows.

�

Just my two cents.

�

Best regards,

Don

Donald F. Coffin

Founder/CTO

�

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA� 92688-3836

�

Phone:�� (949) 636-8571

Email:�� donald.coffin@reminetworks.com

�

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Friday, May 31, 2013 11:11 AM
To: Justin Richer
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

�

To be clear.�

�

It is two separate issues.�

�

1. Anonymous clients can easily be handled through policy config.�

�

2. Support for implicit clients needs to be discussed. The current proposal creates large negative value for the service provider and most would never allow in current form. Yes it gives each execution instance a new id, but that isnt what sp's want. It is a huge attack and management headache. Eliminate or propose a different solution.�

Phil

On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org> wrote:

I'm not willing to write out an entire class of clients from this spec, especially when we have stated use cases for them doing dynamic registration.

I'm sorry, but your proposed solution will simply not work.

�-- Justin

On 05/31/2013 01:56 PM, Phil Hunt wrote:

Well the only client that wouldn't have a credential is an implicit client. An implicit client is transient and so would never update.�

Besides, as i have stated, implicit clients should not use dyn reg.�

Phil

On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org> wrote:

But the outstanding question is: how do you get the access token to access the created resource (IE: the Registration Access Token)? You can't use the client_credentials flow for a client with no credentials!

�-- Justin

On 05/31/2013 12:58 PM, Phil Hunt wrote:

Yes. I specified the trivial solution to anonymous clients earlier.

�

Even simpler. You don't need an access token to create a new resource. You just need one to access one. That is just basic security config.�

Phil

On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org> wrote:

I agree that we are going in circles, since I just was going to bring up my counter argument of "what about clients with no credentials?" again, which *still* isn't addressed by what you suggest doing, below. I also believe that getting rid of the Registration Access Token but using some other token method would actually make the spec larger, though I'd be glad to review a concrete counter-proposal if you'd like to write one. And the fact that OIDC is doing it this way, and considered but rejected the way that you're describing, should say something to the WG here about whether or not this is the right choice. Rough consensus and running code, after all.

Regardless, I agree to park this issue and leave the text as is. We'll move to the next draft in the last call process shortly, as I have a handful of non-normative editorial changes that I need to make, thanks to feedback from a few folks.

Again, thanks for your thorough review, Phil, and I look forward to future feedback.

�-- Justin

On 05/31/2013 12:28 PM, Phil Hunt wrote:

I disagree.�

�

There is absolutely no need for a registration access token.�

�

Get rid of it and just use access tokens as per 6749. If you can't follow 6749 and need new issuing methods, what are others to say regarding inventing new methods?

�

I have not heard a good reason for the special process or one good enough to warrant a new method for issuing an access token. Does the broader group realize this is what the spec says?

�

Yes, i heard a lot saying OIDC does it this way. But that is a political reason, not a technical reason. Still, compatibility is always a strong objective. �Even so, oidc could keep using their method just fine. There is no obligation here to do the same.�

�

The only reason so far was expiry of client creds. Well, why not require the client to update prior to expiry? It makes no sense to have another token with longer expiry. B'sides, even expired the client can re-register from scratch.�

�

Why force the client to persist multiple tokens and creds? That is far far too complex.�

�

Finally if you get rid of registration access token the spec size will drop roughly in half IMO. This suggests simplicity to me.�

�

Apologies for my rant. Maybe we should park this for now. We are going in circles.�

Phil

On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org> wrote:

Phil,

We *can* keep it straight just fine, but I just need you to be clear about which part you're objecting to because the answers are different. Please use the terms as defined in the document so that we all know which component we're talking about. I'm sure you'd agree than in specification work such as this, precision of language and labels is key for communication between parties. This is precisely why there's a Terminology section right up front, so that when I say "Registration Access Token" you can know that I mean a very specific thing, and when I say "Initial Registration Token" I mean a very different specific thing. So I'm asking you, please, use the defined terms so that we can avoid this unnecessary confusion.

But anyway, what you're talking about below, "the token the client uses to update is profile" *IS* the Registration Access Token. That's all that that token is used for. You're not asking for it to go away, you're asking for it to come from the Token Endpoint instead of the response from the Registration Endpoint. I don't see how the client *can* get it from the normal token process without jumping through specialized hoops to make that happen. I've implemented the draft the way that it is right now, both client and server side, and it works. Others have implemented it, too. We've done interop testing, and it works. This is a proven pattern and from where I sit there is both rough consensus and running code.

I believe that I've already pointed out how the solutions you've proposed so far won't work in practice, for various reasons, many of which have already been brought up and discussed previously. If you have another way for the client to get its Registration Access Token, please propose it; but I haven't seen anything yet that will fly.

�-- Justin

On 05/31/2013 11:10 AM, Phil Hunt wrote:

Justin,

�

This is my primary objection! We can't keep it straight. Their should be no such thing as a registrstion access token! �Just the token the client obtains to update its profile through the normal token request process.�

Phil

On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org> wrote:

Which token are you referring to here?

If it's the Initial Registration Token, then you could get that through the normal token server no problem. (The lifecycle writeups don't call this out explicitly but I would be willing to do so.) Or you could get it elsewhere. Doesn't matter, just like it doesn't matter with any other OAuth2 protected resource.

If it's the Registration Access Token, then having the token come from the token endpoint would require a lot more work and complexity on behalf of both of the client and server. Either you end up with public clients getting secrets they shouldn't need or with granting clients access to the client_credentials flow when they shouldn't actually have it. Plus it adds extra round trips which don't buy you anything.

�-- Justin

On 05/31/2013 10:15 AM, Phil Hunt wrote:

The preference is to have the access token for registration issued by the normal token server rather then by the registration endpoint.�

�

In the current draft it is obtained through a unique process and must outlive the client.�

Phil

On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org> wrote:

I don't understand any of the comments below -- it already *is* an OAuth2 protected resource without any special handling. Your access tokens can be short-lived, long-lived, federated, structured, random blobs ... totally doesn't matter. They are access tokens being used to access a normal protected resource. Full stop.

Anything else is out of scope. The lifecycle discussions at the beginning are merely examples of some ways you *could* use it and are non-normative and non-exhaustive.

You seem to be asking for something that's already in the draft.

�-- Justin

From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 7:31 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

Phil

On 2013-05-30, at 16:11, "Richer, Justin P." <jricher@mitre.org> wrote:

Comments inline, marked by [JR].

From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 5:25 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

See below.

Phil

�

@independentid

www.independentid.com

phil.hunt@oracle.com

�

�

�

On 2013-05-30, at 2:09 PM, Justin Richer wrote:

OK, I think see part of the hang up. I have not seen the scenario that you describe, where you trade a 3rd party token for a "local" token. I have seen where access tokens are federated directly at the PR. (Introspection lets you do some good things with that pattern.)

�

�

�

�

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

--------------050007050005000608040809-- From phil.hunt@oracle.com Thu Jun 6 10:48:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC6921F9AA3 for ; Thu, 6 Jun 2013 10:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ91Yfj+rVtJ for ; Thu, 6 Jun 2013 10:48:29 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0F83F21F9A7A for ; Thu, 6 Jun 2013 10:48:29 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r56HmPdr032265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Jun 2013 17:48:28 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r56HmOuo027350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 17:48:24 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r56HmNNu010914; Thu, 6 Jun 2013 17:48:24 GMT Received: from [192.168.1.89] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Jun 2013 10:48:23 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_629652F2-6B26-4454-8238-A732C8BC942F" From: Phil Hunt In-Reply-To: <51B0C8CE.6070309@mitre.org> Date: Thu, 6 Jun 2013 10:48:21 -0700 Message-Id: References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <255B9BB34FB7D647A506DC292726F6E1151B105DA5@WSMSG3153V.srv.dir.telstra.com> <1373E8CE237FCC43BCA36C6558612D2A9F26D0@USCHMBX001.nsn-intra.net> <919FB49B-2705-42E4-B5C3-B433C3F81C7F@ve7jtb.com> <9209089C-5B60-4212-88EA-376855DBCEA0@oracle.com> <51B0C14D.5020306@mitre.org> <1CCDB2B8-CAD9-4827-8113-F92537F70375@oracle.com> <51B0C8CE.6070309@! mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:48:34 -0000 --Apple-Mail=_629652F2-6B26-4454-8238-A732C8BC942F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is why this to-MAY-to vs. to-MAH-to distinction around is the = initial access token an authorization token is important. The purpose for the initial access token is dramatically different then = normal access tokens. This is for "registration" and does not = constitute authentication or authorization. Therefore, in this case, I do not believe that defining access tokens in = the broader sense makes this issue clearer. Registration is a very specific process different than authorization. This might be a good paper to look at so the group understands why I am = differentiating authorization from what is happening with initial = access: http://tools.ietf.org/html/draft-hallambaker-httpauth-00 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-06-06, at 10:37 AM, Justin Richer wrote: > Interoperability of the processing of OAuth tokens is a separate issue = that needs to be solved not just for registration. When it is solved in = the wider case, Registration as-is will inherit the solution. >=20 > So today, if you're using an Initial Access Token (which is optional), = then you're locked to whatever process you want to use to = verify/validate that token. Since it's just an OAuth token, you've got a = number of things that you can do (assertions, introspection, magic). >=20 > I'd rather we solve the *real* cross-domain issue in the wider case = than just try to cram something into registration. >=20 > -- Justin >=20 > On 06/06/2013 01:33 PM, Phil Hunt wrote: >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-06-06, at 10:05 AM, Justin Richer wrote: >>=20 >>>=20 >>> On 06/06/2013 11:20 AM, Phil Hunt wrote: >>>> As I've said before the initial auth token should nothing to do = with auth. It is simply an assertion given to the developer to = distribute in order to pass on signed claims about the software.=20 >>>=20 >>> Phil, as I and several others have explained previously, that's not = true at all. It's a token that gives authorization to the registration = endpoint. The fact that you can use it as an assertion to pass along = signed claims is an artifact of it being an OAuth token and an OAuth = token is an opaque string. Please read through the dynamic registration = draft again -- it says absolutely nothing about assertions, signatures, = or claims with regard to this token. >> It depends which case you are using. If the developer is talking to = a single deployment domain and obtains an initial access token and then = ships it with all clients, then sure. In this scenario, the contents = are totally controlled by the local domain. >>=20 >> I agree. In this case, you don't care about inter-op. The whole = environment is siloed. But then, if this is your case, I'm not sure why = this draft is at the IETF. >>=20 >> The interoperability case is where a third party generates that = assertion and the deployment domain has to decide to accept it. So you = are a developer and you want to build a client for a Microsoft or Oracle = app. You want to be able to ship that to your customers. You register = with the appropriate publisher and they give you a signed assertion that = can be used as the "Initial Access Token". This token is then = accepted by the deployment domain and then it decides if it trusts the = signer or not. >>=20 >> =3D=3D=3D> For this to work, the contents and format of that token = MUST be defined. Otherwise how could we ensure a Microsoft signed = assertion would be accepted by a PingIdentity OAuth server? Or any = other combination of implementations from different vendors/communities? >>=20 >>>=20 >>>>=20 >>>> Bearer or not bearer is a distraction. The fact that the contents = and format of this token is out of scope leaves a HUGE interop gap.=20 >>>=20 >>> The fact that some of us (myself included) are *using* this token to = carry this kind of information is out of scope for the basic = registration spec. I completely agree that there's value in defining = this stuff, but as a separate and complementary spec from registration. >>=20 >> [PH] I was reacting to John Bradley's assertion that the spec was = narrowly defined with interop in mind. Yet this mechanism is a key = factor being used to share information about the software. >>=20 >>>=20 >>>>=20 >>>> Finally never-mind bearer bias, how are client credentials rotated = interoperably if the only thing rotated is client_secret? >>>=20 >>> *any* parameter on the client, including the = registration_access_token and any extension parameters, can be rotated = on any call to the Read or Update methods (except for client_id). So if = you've got another mechanism for doing client authentication, you can = rotate that, too. >>>=20 >>>>=20 >>>> I would say the spec only works for client secrets and/or = all-in-one domain where there is no interop.=20 >>>=20 >>> Considering I've personally used it across domains and without = client secrets (using jwks_uri to register public keys), I have to = empirically disagree with that statement. >>>=20 >>> -- Justin >>>=20 >>>>=20 >>>> Phil >>>>=20 >>>> On 2013-06-06, at 1:53, John Bradley wrote: >>>>=20 >>>>> There are a couple of reasons. =20 >>>>>=20 >>>>> One criticism Hannes and others make of OAuth specs is they are = not tightly profiled enough to be interoperable without further out of = band configuration and profiling. >>>>>=20 >>>>> Making registration work with minimal ambiguity was a priority for = Connect and that has carried over. >>>>>=20 >>>>> I am not opposed to having this extended at some point in the = future, once we have a second token type. The new token type should be = available to do updates as well. >>>>>=20 >>>>> The problem is that starting down the HoK route potentially = requires a registered client that may need to be registered to do the = registration. =20 >>>>> I think that is best left to another spec to sort out the possible = turtles. >>>>>=20 >>>>> So the default needs to be bearer tokens unless registration is = extended by another profile. >>>>>=20 >>>>> John B. >>>>> On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" = wrote: >>>>>=20 >>>>>> Because bearer tokens have a stable RFC-numbered spec and are = widely implemented and the registration flow as documented seems like it = should work? -T >>>>>> =20 >>>>>> That=92s the answer for why there is support for bearer tokens = but it is not the answer to why that=92s the only supported mechanism. >>>>>> If we want to support stronger security mechanisms (which the = group has decided to work on already) then we need to have a story on = how to support the other mechanisms as well . >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >=20 --Apple-Mail=_629652F2-6B26-4454-8238-A732C8BC942F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 This = is why this to-MAY-to vs. to-MAH-to distinction around is the initial = access token an authorization token is important.

The = purpose for the initial access token is dramatically different then = normal access tokens. This is for "registration" and does not = constitute authentication or = authorization.

Therefore, in this case, I do = not believe that defining access tokens in the broader sense makes this = issue clearer.

Registration is a very specific = process different than authorization.

This = might be a good paper to look at so the group understands why I am = differentiating authorization from what is happening with initial = access:
http://t= ools.ietf.org/html/draft-hallambaker-httpauth-00

<= div>

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2013-06-06, at 10:37 AM, Justin Richer wrote:

=20 =20
Interoperability of the processing of OAuth tokens is a separate issue that needs to be solved not just for registration. When it is solved in the wider case, Registration as-is will inherit the solution.

So today, if you're using an Initial Access Token (which is optional), then you're locked to whatever process you want to use to verify/validate that token. Since it's just an OAuth token, you've got a number of things that you can do (assertions, introspection, magic).

I'd rather we solve the *real* cross-domain issue in the wider case than just try to cram something into registration.

-- Justin

On 06/06/2013 01:33 PM, Phil Hunt wrote:

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:05 AM, Justin Richer wrote:

On 06/06/2013 11:20 AM, Phil Hunt wrote:

As I've said before the initial auth token should nothing to do with auth. It is simply an assertion given to the developer to distribute in order to pass on signed claims about the software.

Phil, as I and several others have explained previously, that's not true at all. It's a token that gives authorization to the registration endpoint. The fact that you can use it as an assertion to pass along signed claims is an artifact of it being an OAuth token and an OAuth token is an opaque string. Please read through the dynamic registration draft again -- it says absolutely nothing about assertions, signatures, or claims with regard to this = token.

It depends which case you are using. If the developer = is talking to a single deployment domain and obtains an initial access token and then ships it with all clients, then sure. In this scenario, the contents are totally controlled by = the local domain.

I agree. In this case, you don't care about inter-op. The whole environment is siloed. But then, if this is your = case, I'm not sure why this draft is at the IETF.

The interoperability case is where a third party generates that assertion and the deployment domain has to decide to accept it. So you are a developer and you want to build = a client for a Microsoft or Oracle app. You want to be = able to ship that to your customers. You register with the appropriate publisher and they give you a signed assertion that can be used as the "Initial Access Token". This token is = then accepted by the deployment domain and then it decides if it trusts the signer or not.

=3D=3D=3D> For this to work, the contents and format of = that token MUST be defined. Otherwise how could we ensure a Microsoft signed assertion would be accepted by a PingIdentity OAuth server? Or any other combination of = implementations from different vendors/communities?

Bearer or not bearer is a distraction. The fact that the contents and format of this token is out of scope leaves a HUGE interop gap.

The fact that some of us (myself included) are *using* this token to carry this kind of information is out of scope for the basic registration spec. I completely agree that there's value in defining this stuff, but as a separate and complementary spec from registration.

[PH] I was reacting to John Bradley's assertion that the spec was narrowly defined with interop in mind. Yet this mechanism is a key factor being used to share information about the = software.

Finally never-mind bearer bias, how are client credentials rotated interoperably if the only thing rotated is client_secret?

*any* parameter on the client, including the registration_access_token and any extension parameters, can be rotated on any call to the Read or Update methods (except for client_id). So if you've got another mechanism for doing client authentication, you can rotate that, too.

I would say the spec only works for client secrets and/or all-in-one domain where there is no interop.

Considering I've personally used it across domains and without client secrets (using jwks_uri to register public keys), I have to empirically disagree with that = statement.

-- Justin

Phil

On 2013-06-06, at 1:53, John Bradley <ve7jtb@ve7jtb.com> wrote:

There are a couple of reasons.

One criticism Hannes and others make of OAuth specs is they are not tightly profiled enough to be interoperable without further out of band configuration and profiling.

Making registration work with minimal ambiguity was a priority for Connect and that has carried over.

I am not opposed to having this extended at some point in the future, once we have a second token type. The new token type should be available = to do updates as well.

The problem is that starting down the HoK route potentially requires a registered client that may need to be registered to do the registration. =

I think that is best left to another spec to sort out the possible turtles.

So the default needs to be bearer tokens unless registration is extended by another profile.

John B.

On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>= ; wrote:

Because bearer tokens have a stable RFC-numbered spec and are widely implemented and the registration flow as documented seems like it should work? = -T

=
_______________________________________________
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

= --Apple-Mail=_629652F2-6B26-4454-8238-A732C8BC942F-- From jricher@mitre.org Thu Jun 6 10:49:24 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D5221F9AE2 for ; Thu, 6 Jun 2013 10:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzibl4S+INsN for ; Thu, 6 Jun 2013 10:49:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4274021F9AA2 for ; Thu, 6 Jun 2013 10:49:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E23D9226006E; Thu, 6 Jun 2013 13:49:18 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CD17D226004A; Thu, 6 Jun 2013 13:49:18 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 6 Jun 2013 13:49:18 -0400 Message-ID: <51B0CB6D.7060004@mitre.org> Date: Thu, 6 Jun 2013 13:48:29 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <255B9BB34FB7D647A506DC292726F6E1151B105DA5@WSMSG3153V.srv.dir.telstra.com> <1373E8CE237FCC43BCA36C6558612D2A9F26D0@USCHMBX001.nsn-intra.net> <919FB49B-2705-42E4-B5C3-B433C3F81C7F@ve7jtb.com> <9209089C-5B60-4212-88EA-376855DBCEA0@oracle.com> <51B0C14D.5020306@mitre.org> <1CCDB2B8-CAD9-4827-8113-F92537F70375@oracle.com> <51B0C8CE.6070309@! mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010600070709040202010904" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:49:24 -0000 --------------010600070709040202010904 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit I thought we were talking about the registration access token, not the initial access token? -- Justin On 06/06/2013 01:48 PM, Phil Hunt wrote: > This is why this to-MAY-to vs. to-MAH-to distinction around is the > initial access token an authorization token is important. > > The purpose for the initial access token is dramatically different > then normal access tokens. This is for "registration" and does not > constitute authentication or authorization. > > Therefore, in this case, I do not believe that defining access tokens > in the broader sense makes this issue clearer. > > Registration is a very specific process different than authorization. > > This might be a good paper to look at so the group understands why I > am differentiating authorization from what is happening with initial > access: > http://tools.ietf.org/html/draft-hallambaker-httpauth-00 > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-06-06, at 10:37 AM, Justin Richer wrote: > >> Interoperability of the processing of OAuth tokens is a separate >> issue that needs to be solved not just for registration. When it is >> solved in the wider case, Registration as-is will inherit the solution. >> >> So today, if you're using an Initial Access Token (which is >> optional), then you're locked to whatever process you want to use to >> verify/validate that token. Since it's just an OAuth token, you've >> got a number of things that you can do (assertions, introspection, >> magic). >> >> I'd rather we solve the *real* cross-domain issue in the wider case >> than just try to cram something into registration. >> >> -- Justin >> >> On 06/06/2013 01:33 PM, Phil Hunt wrote: >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2013-06-06, at 10:05 AM, Justin Richer wrote: >>> >>>> >>>> On 06/06/2013 11:20 AM, Phil Hunt wrote: >>>>> As I've said before the initial auth token should nothing to do >>>>> with auth. It is simply an assertion given to the developer to >>>>> distribute in order to pass on signed claims about the software. >>>> >>>> Phil, as I and several others have explained previously, that's not >>>> true at all. It's a token that gives authorization to the >>>> registration endpoint. The fact that you can use it as an assertion >>>> to pass along signed claims is an artifact of it being an OAuth >>>> token and an OAuth token is an opaque string. Please read through >>>> the dynamic registration draft again -- it says absolutely nothing >>>> about assertions, signatures, or claims with regard to this token. >>> It depends which case you are using. If the developer is talking to >>> a single deployment domain and obtains an initial access token and >>> then ships it with all clients, then sure. In this scenario, the >>> contents are totally controlled by the local domain. >>> >>> I agree. In this case, you don't care about inter-op. The whole >>> environment is siloed. But then, if this is your case, I'm not sure >>> why this draft is at the IETF. >>> >>> The interoperability case is where a third party generates that >>> assertion and the deployment domain has to decide to accept it. So >>> you are a developer and you want to build a client for a Microsoft >>> or Oracle app. You want to be able to ship that to your customers. >>> You register with the appropriate publisher and they give you a >>> signed assertion that can be used as the "Initial Access Token". >>> This token is then accepted by the deployment domain and then it >>> decides if it trusts the signer or not. >>> >>> ===> For this to work, the contents and format of that token MUST be >>> defined. Otherwise how could we ensure a Microsoft signed >>> assertion would be accepted by a PingIdentity OAuth server? Or any >>> other combination of implementations from different vendors/communities? >>> >>>> >>>>> >>>>> Bearer or not bearer is a distraction. The fact that the contents >>>>> and format of this token is out of scope leaves a HUGE interop gap. >>>> >>>> The fact that some of us (myself included) are *using* this token >>>> to carry this kind of information is out of scope for the basic >>>> registration spec. I completely agree that there's value in >>>> defining this stuff, but as a separate and complementary spec from >>>> registration. >>> >>> [PH] I was reacting to John Bradley's assertion that the spec was >>> narrowly defined with interop in mind. Yet this mechanism is a key >>> factor being used to share information about the software. >>> >>>> >>>>> >>>>> Finally never-mind bearer bias, how are client credentials >>>>> rotated interoperably if the only thing rotated is client_secret? >>>> >>>> *any* parameter on the client, including the >>>> registration_access_token and any extension parameters, can be >>>> rotated on any call to the Read or Update methods (except for >>>> client_id). So if you've got another mechanism for doing client >>>> authentication, you can rotate that, too. >>>> >>>>> >>>>> I would say the spec only works for client secrets and/or >>>>> all-in-one domain where there is no interop. >>>> >>>> Considering I've personally used it across domains and without >>>> client secrets (using jwks_uri to register public keys), I have to >>>> empirically disagree with that statement. >>>> >>>> -- Justin >>>> >>>>> >>>>> Phil >>>>> >>>>> On 2013-06-06, at 1:53, John Bradley >>>> > wrote: >>>>> >>>>>> There are a couple of reasons. >>>>>> >>>>>> One criticism Hannes and others make of OAuth specs is they are >>>>>> not tightly profiled enough to be interoperable without further >>>>>> out of band configuration and profiling. >>>>>> >>>>>> Making registration work with minimal ambiguity was a priority >>>>>> for Connect and that has carried over. >>>>>> >>>>>> I am not opposed to having this extended at some point in the >>>>>> future, once we have a second token type. The new token type >>>>>> should be available to do updates as well. >>>>>> >>>>>> The problem is that starting down the HoK route potentially >>>>>> requires a registered client that may need to be registered to do >>>>>> the registration. >>>>>> I think that is best left to another spec to sort out the >>>>>> possible turtles. >>>>>> >>>>>> So the default needs to be bearer tokens unless registration is >>>>>> extended by another profile. >>>>>> >>>>>> John B. >>>>>> On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" >>>>>> > wrote: >>>>>> >>>>>>> Because bearer tokens have a stable RFC-numbered spec and are >>>>>>> widely implemented and the registration flow as documented seems >>>>>>> like it should work? -T >>>>>>> That�s the answer for why there is support for bearer tokens but >>>>>>> it is not the answer to why that�s the only supported mechanism. >>>>>>> If we want to support stronger security mechanisms (which the >>>>>>> group has decided to work on already) then we need to have a >>>>>>> story on how to support the other mechanisms as well . >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>> >> > --------------010600070709040202010904 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit I thought we were talking about the registration access token, not the initial access token?

�-- Justin

On 06/06/2013 01:48 PM, Phil Hunt wrote:

This is why this to-MAY-to vs. to-MAH-to distinction around is the initial access token an authorization token is important.

The purpose for the initial access token is dramatically different then normal access tokens. �This is for "registration" and does not constitute authentication or authorization.

Therefore, in this case, I do not believe that defining access tokens in the broader sense makes this issue clearer.

Registration is a very specific process different than authorization.

This might be a good paper to look at so the group understands why I am differentiating authorization from what is happening with initial access:

http://tools.ietf.org/html/draft-hallambaker-httpauth-00

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:37 AM, Justin Richer wrote:

Interoperability of the processing of OAuth tokens is a separate issue that needs to be solved not just for registration. When it is solved in the wider case, Registration as-is will inherit the solution.

So today, if you're using an Initial Access Token (which is optional), then you're locked to whatever process you want to use to verify/validate that token. Since it's just an OAuth token, you've got a number of things that you can do (assertions, introspection, magic).

I'd rather we solve the *real* cross-domain issue in the wider case than just try to cram something into registration.

�-- Justin

On 06/06/2013 01:33 PM, Phil Hunt wrote:

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:05 AM, Justin Richer wrote:

On 06/06/2013 11:20 AM, Phil Hunt wrote:

As I've said before the initial auth token should nothing to do with auth. It is simply an assertion given to the developer to distribute in order to pass on signed claims about the software.

Phil, as I and several others have explained previously, that's not true at all. It's a token that gives authorization to the registration endpoint. The fact that you can use it as an assertion to pass along signed claims is an artifact of it being an OAuth token and an OAuth token is an opaque string. Please read through the dynamic registration draft again -- it says absolutely nothing about assertions, signatures, or claims with regard to this token.

It depends which case you are using. �If the developer is talking to a single deployment domain and obtains an initial access token and then ships it with all clients, then sure. �In this scenario, the contents are totally controlled by the local domain.

I agree. In this case, you don't care about inter-op. The whole environment is siloed. �But then, if this is your case, I'm not sure why this draft is at the IETF.

The interoperability case is where a third party generates that assertion and the deployment domain has to decide to accept it. �So you are a developer and you want to build a client for a Microsoft or Oracle app. �You want to be able to ship that to your customers. You register with the appropriate publisher and they give you a signed assertion that can be used as the "Initial Access Token". � �This token is then accepted by the deployment domain and then it decides if it trusts the signer or not.

===> For this to work, the contents and format of that token MUST be defined. � Otherwise how could we ensure a Microsoft signed assertion would be accepted by a PingIdentity OAuth server? �Or any other combination of implementations from different vendors/communities?

Bearer or not bearer is a distraction. The fact that the contents and format of this token is out of scope leaves a HUGE interop gap.

The fact that some of us (myself included) are *using* this token to carry this kind of information is out of scope for the basic registration spec. I completely agree that there's value in defining this stuff, but as a separate and complementary spec from registration.

[PH] I was reacting to John Bradley's assertion that the spec was narrowly defined with interop in mind. Yet this mechanism is a key factor being used to share information about the software.

Finally never-mind bearer bias, how are �client credentials rotated interoperably if the only thing rotated is client_secret?

*any* parameter on the client, including the registration_access_token and any extension parameters, can be rotated on any call to the Read or Update methods (except for client_id). So if you've got another mechanism for doing client authentication, you can rotate that, too.

I would say the spec only works for client secrets and/or all-in-one domain where there is no interop.

Considering I've personally used it across domains and without client secrets (using jwks_uri to register public keys), I have to empirically disagree with that statement.

�-- Justin

Phil

On 2013-06-06, at 1:53, John Bradley <ve7jtb@ve7jtb.com> wrote:

There are a couple of reasons. � �

One criticism Hannes and others make of OAuth specs is they are not tightly profiled enough to be interoperable without further out of band configuration and profiling.

Making registration work with minimal ambiguity was a priority for Connect and that has carried over.

I am not opposed to having this extended at some point in the future, once we have a second token type. � The new token type should be available to do updates as well.

The problem is that starting down the HoK route potentially requires a registered client that may need to be registered to do the registration. ��

I think that is best left to another spec to sort out the possible turtles.

So the default needs to be bearer tokens unless registration is extended by another profile.

John B.

On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> wrote:

Because bearer tokens have a stable RFC-numbered spec and are widely implemented and the registration flow as documented seems like it should work? �-T

�

That�s the answer for why there is support for bearer tokens but it is not the answer to why that�s the only supported mechanism.

If we want to support stronger security mechanisms (which the group has decided to work on already) then we need to have a story on how to support the other mechanisms as well .

_______________________________________________
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

--------------010600070709040202010904-- From phil.hunt@oracle.com Thu Jun 6 10:49:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA3D21F9AE3 for ; Thu, 6 Jun 2013 10:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.032 X-Spam-Level: X-Spam-Status: No, score=-6.032 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUVXENfMgxeC for ; Thu, 6 Jun 2013 10:49:43 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4A05C21F9AFA for ; Thu, 6 Jun 2013 10:49:42 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r56HnbC5029237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Jun 2013 17:49:38 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r56Hndsf000493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 17:49:39 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r56Hnc5c015370; Thu, 6 Jun 2013 17:49:38 GMT Received: from [192.168.1.89] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Jun 2013 10:49:34 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_15411714-A265-4905-815E-61C6C32E326D" From: Phil Hunt In-Reply-To: <51B0CB18.5090003@mitre.org> Date: Thu, 6 Jun 2013 10:49:33 -0700 Message-Id: References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <51B0BDA2.7010705@mitre.org> <7B00614C-6B25-4951-B004-C17932432D17@oracle.com> <51B0C6D4.804000!> <9@mitre.org> <51B0C8A0.2020306@mitre.org> <51B0CB18.50! 90003@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Donald F Coffin , "oauth@ietf.org" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:49:49 -0000 --Apple-Mail=_15411714-A265-4905-815E-61C6C32E326D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Huh? There's no need for public clients to access the token endpoint as they = can register anonymously. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-06-06, at 10:47 AM, Justin Richer wrote: > Because anonymous *registration* and public client *access* to the = token endpoint are two different things. >=20 > -- Justin >=20 > On 06/06/2013 01:43 PM, Phil Hunt wrote: >> *why* will the 6749 standard flows (specifically 4.4) not work? >>=20 >> The registration endpoint can allow anonymous access to permit = anonymous registration. >>=20 >> This means the configuration endpoints can use normal access tokens = obtained through RFC6749 section 4.4 (Client Auth) flows. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-06-06, at 10:36 AM, Justin Richer wrote: >>=20 >>> ... because it already *is* a REST protected API. It's protected = with the Registration Access Token. Which is an OAuth 2.0 Bearer token.=20= >>>=20 >>> The *only* difference is how you get the token, which has nothing to = do with the REST protected API that it's protecting. >>>=20 >>> -- Justin >>>=20 >>> On 06/06/2013 01:35 PM, Phil Hunt wrote: >>>> Nobody has explained why using a normal REST protected API won't = work. You keep saying that and that you won't go back. But that doesn't = explain the issue. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-06-06, at 10:28 AM, Justin Richer wrote: >>>>=20 >>>>> I feel we're still just going in circles with these arguments, but = my comments are inline: >>>>>=20 >>>>> On 06/06/2013 01:17 PM, Phil Hunt wrote: >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-06-06, at 9:49 AM, Justin Richer wrote: >>>>>>=20 >>>>>>> Tim, thanks for your review! Comments inline. >>>>>>>=20 >>>>>>> On 06/05/2013 04:59 PM, Tim Bray wrote: >>>>>>>> FWIW, I just read the spec through with fresh eyes, and I found = the explanation of the workflow in 1.4.2 very useful. =20 >>>>>>>>=20 >>>>>>>> - A developer manually registers and then is able to request = =93Initial tokens=94 tokens for a dynamic-app-registration-scope,=20 >>>>>>>> - you use that =93Initial token=94 token to register, in = exchange you get the client-id & so on, and also a a per-registration = =93Registration token=94 for updating that particular registration = information >>>>>>>> - you fetch/update/delete your registration information with = that registration token. >>>>>>>>=20 >>>>>>>> The first part, where the developer registers & gets a token = for a scope, is vanilla OAuth 2. (right?) =20 >>>>>>>=20 >>>>>>> Yes, it can be vanilla Oauth2 or it can be the developer (or = someone) getting a token through some other means, like browsing to a = developer portal and getting a Bearer token. I've edited the example in = 1.4.3 in the latest (unpublished) text so that the developer is = literally doing OAuth2 to get the initial token. It's important to note = that this could be any flavor of OAuth2 token, though Bearer tokens are = of course the most common. >>>>>>>=20 >>>>>>>> The bit about getting an access token specific to that = registration is a new flow (right?), but it seems convenient. >>>>>>>=20 >>>>>>> Right, it's a new way to get a bearer token so that you can use = it at the protected resource. We wanted to re-use the token endpoint for = this, but couldn't come up with a reasonable way of doing so (as has = been discussed on the list. >>>>>>=20 >>>>>> [PH] We still greatly disagree on this. >>>>>>=20 >>>>>> *Use the normal token issuing process.* One reason given was = what about anonymous clients? The answer is, they don't have to do = anything. Remember that you have defined TWO endpoints. The = "registration endpoint" and the "configuration endpoint". A server = accepting anonymous registration simply accepts anonymous access at the = "registration endpoint". Clients wanting to update their profiles do = the normal client token request flow to the token endpoint to obtain a = normal access token useable at the "configuration endpoint". >>>>>>=20 >>>>>=20 >>>>> [JR] But then you're opening up the client_credentials flow to = anonymous clients, or you've got to be able to lock down = client_credentials as a flow to only a special (service-specific) scope = for client configuration purposes. This, I think, is much more = complicated to implement and much more error prone. I don't think it's = even possible in the software stack we're building on top of. And = furthermore, you're not letting public clients dynamically register = anymore, since you'd be forcing everyone to have a client secret. Your = dynamic public clients would have to save the client secret but know to = only use it at the registration endpoint, and not the token endpoint = where they're used to. This way, it's clear. You get a token that you = use at a given endpoint, the end. >>>>>=20 >>>>>> As soon as you do this, other things simplify. >>>>>>=20 >>>>>> 1. No need to keep "registration access token" around = indefinitely. It's just an access token. In fact it is only needed for = minutes since it will likely only be used to read or update profiles or = to perform client initiated credential rotation. >>>>>=20 >>>>> [JR] You *can* throw away your registration access tokens if you = want to, or have them expire, if you want to limit the lifespan of your = clients. It's only the security considerations section that suggests = against expiring the tokens, and for good reason. But it's your choice = to change that if you don't want = longstanding read/edit access to a client's configuration. >>>>>=20 >>>>>> 2. No need to have a special token issuing method. Creating a = new issuing process suggests that the WG can't drink its own koolaid. = Because at the first seeming challenge, the WG create a new flow. How do = we expect implementers to behave? >>>>>=20 >>>>> [JR] That particular koolaid wasn't the right drink here, to = stretch your analogy. Bearer tokens were, which is also the group's = koolaid. We tried to go down the road you suggest and it was a dead end. = Why do you think it will work better this time? And I'd like to point = out a decision from several years ago now to separate the notion of "how = you get a token" from "how you use a token" in OAuth2. OAuth1 had all of = these rolled in together, and deployment experience showed us that = people didn't really want to use it that way. People want components = that make sense on their own that let you build systems like this that = also make sense. >>>>>=20 >>>>> Forced uniformity isn't necessarily a good thing. >>>>>=20 >>>>>> 3. The registration/configuration API is JUST a normal OAuth2 = protected API. >>>>>=20 >>>>> [JR] It already is. Protected resources don't care where you get = your tokens from, just that you have them, so from that perspective it = is just a protected resource. Our implementation here literally just = looks for the token on the way in in the auth layer and makes sure it's = got a special service-specific scope that handles registration.=20 >>>>>=20 >>>>>>=20 >>>>>> If the draft drops "registration access tokens", a lot of the = text in the draft disappears. The whole spec is much simpler. >>>>>=20 >>>>> [JR] Much simpler, perhaps, but much less functional and useful. = And honestly, not much of the text actually goes away. Most of the draft = isn't about dealing with the registration access token, it's about = dealing with the client metadata and the RESTful protocol for managing = that. The registration access token is a mechanism for doing so. >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>> =46rom an OAuth 2 point of view, there's nothing special = about how you get or use the Initial token, but giving it a special name = makes explaining a plausible workflow easier. =20 >>>>>>>=20 >>>>>>> Right, and I've admitted that "Initial Access Token" a crappy = name, but I haven't heard a better suggestion yet.=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Having said that, I have trouble imagining the scenario where = you'd use the 1.4.1 flow, but that may be because of my Google-centric = worldview.=20 >>>>>>>=20 >>>>>>> Could be -- but if Google wants to be an open-registration = identity provider (like it has been with OpenID 2.0), it will need to = handle this flow as well. This is the client acting on its own behalf, = showing up and saying "hi, I'm a client!" and that's that. I think this = is a very important case for interoperability of dynamic registration. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> And I=92m not sure 1.4.3 adds any value at all. It just seems = to be a matter of different ways you could get and make use of the = registration access token; and I'm sure there are various interesting = combinations that haven't been thought of there. I'd just lose 1.4.3. >>>>>>>>=20 >>>>>>>=20 >>>>>>> 1.4.3 in -11 is too close to 1.4.2, so what I've done in the = current working text is make the initial process of getting the Initial = Access Token different (the developer now uses OAuth2 to configure their = build environment). The *real* important difference that's being shown = here, though, is that the client doesn't call the registration endpoint, = the developer (and their build environment) does. So yes, it's exactly = all about how you get and use the registration access token. There are = plenty of other ways to do it as well, so that's why this section was a = non-normative set of examples. To facilitate that understanding, I've = moved it to an appendix in the working copy of draft -12. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> -- Justin >>>>>>>=20 >>>>>>>> -T >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin = wrote: >>>>>>>> See my comments inline [DFC] >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Don >>>>>>>>=20 >>>>>>>> Donald F. Coffin >>>>>>>>=20 >>>>>>>> Founder/CTO >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> REMI Networks >>>>>>>>=20 >>>>>>>> 22751 El Prado Suite 6216 >>>>>>>>=20 >>>>>>>> Rancho Santa Margarita, CA 92688-3836 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Phone: (949) 636-8571 >>>>>>>>=20 >>>>>>>> Email: donald.coffin@reminetworks.com >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> From: Justin Richer [mailto:jricher@mitre.org]=20 >>>>>>>> Sent: Friday, May 31, 2013 12:40 PM >>>>>>>> To: Phil Hunt >>>>>>>> Cc: Donald F Coffin; oauth@ietf.org >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt >>>>>>>> =20 >>>>>>>> I feel the need to clarify a couple erroneous things in Phil's = statement: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> * To be clear, Draft 11 has the same Registration Access = Token system that has been in place since draft 01, it is not inventing = something new at the last minute as could be inferred from the statement = below. >>>>>>>> [DFC] I agree with Justin. There is nothing new in draft 11 = regarding Registration Access Tokens that wasn=92t in the initial draft. = It appears because Phil hasn=92t been following the proposed drafts = until the last call he is now raising an issue no one in the WG saw as = an issue. That=92s not to say his point isn=92t valid, but the = discussion continues to go all over the map between =93local=94 and = =93federated=94 tokens, usage of the RFC6749 =93Token=94 endpoint, etc. = It would be great if all of Phil=92s points could be addressed in = priority >>>>>>>> without the threads becoming so convoluted no one is able to = make sense or even comprehend the point being discussed. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> * DynReg is using an absolutely standard OAuth 2 Bearer token = as the Registration Access Token, it's just not coming from a Token = Endpoint. However, since an OAuth Protected Resource doesn't care where = its tokens come from so long as it can validate them, I don't see this = as a problem -- this is a key point where Phil and I disagree. >>>>>>>>=20 >>>>>>>> [DFC] I understand the disagreement, but I have not seen a = proposal from Phil that would describe the differences between the two = perspectives other than to say that the Dynamic Registration should use = the Token endpoint defined in RFC6749, which does not discuss dynamic = registration. Phil=92s point as I understand it is that there should be = no difference between an access token used to access resource owner = protected data and the registration structure, which I do not agree = with. As I said in the previous >>>>>>>> response, my users do NOT want to provide implied = access to resource owner protected data just because a client is = creating a registration with an AS. This would be the situation if the = client credential flow is used to register an application. Since our >>>>>>>> implementation does NOT support the implicit flow, = that use case is one we have elected NOT to support. >>>>>>>>=20 >>>>>>>> [DFC] I repeat my initial comment, this = conversation has been a circular exchange now for the past few days = without any appearance of an alternative option to resolve the issues. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>> On 05/31/2013 03:33 PM, Phil Hunt wrote: >>>>>>>>=20 >>>>>>>> Don, >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> I am not proposing any change in meaning. If registration acces = token issues by normal token server with scope registration everything = is clear as it is for any other protected API. Draft 11 invents a whole = new system. I strongly disagree with this. >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-31, at 15:16, Donald F Coffin = wrote: >>>>>>>>=20 >>>>>>>> For something that was agreed to be parked a few hours ago, = there sure seems to still be a lot of circular discussion. Should we = ask a mediator to intervene? >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> FWIW I believe that is a significantly strong reason to = differentiate an access token that can access the registration = information without having the ability to access protected data. = Especially given the implied strength of the =93client credential=94 = obtained access token. I have found it extremely confusing to users = when explaining the difference between an access token obtained thorough = an authorization code flow and a client credential flow, simply because = they are both called an =93access token=94. Changing the meaning of an = access token obtained through the client credential flow to mean it has = the ability to update a registration, when a user may not want it to = have access to protected data will only increase both the complexity of = the access tokens as well as make their usage harder to explain to = non-technical individuals who have to understand the = differences between the access = tokens obtained through the various flows. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Just my two cents. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Don >>>>>>>>=20 >>>>>>>> Donald F. Coffin >>>>>>>>=20 >>>>>>>> Founder/CTO >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> REMI Networks >>>>>>>>=20 >>>>>>>> 22751 El Prado Suite 6216 >>>>>>>>=20 >>>>>>>> Rancho Santa Margarita, CA 92688-3836 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Phone: (949) 636-8571 >>>>>>>>=20 >>>>>>>> Email: donald.coffin@reminetworks.com >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >>>>>>>> Sent: Friday, May 31, 2013 11:11 AM >>>>>>>> To: Justin Richer >>>>>>>> Cc: oauth@ietf.org WG >>>>>>>> Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> To be clear.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> It is two separate issues.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> 1. Anonymous clients can easily be handled through policy = config.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> 2. Support for implicit clients needs to be discussed. The = current proposal creates large negative value for the service provider = and most would never allow in current form. Yes it gives each execution = instance a new id, but that isnt what sp's want. It is a huge attack and = management headache. Eliminate or propose a = different solution.=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-31, at 13:58, Justin Richer = wrote: >>>>>>>>=20 >>>>>>>> I'm not willing to write out an entire class of clients from = this spec, especially when we have = stated use cases for them doing dynamic = registration. >>>>>>>>=20 >>>>>>>> I'm sorry, but your proposed solution will simply not work. >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>> On 05/31/2013 01:56 PM, Phil Hunt wrote: >>>>>>>>=20 >>>>>>>> Well the only client that wouldn't have a credential is an = implicit client. An implicit client is transient and so would never = update.=20 >>>>>>>>=20 >>>>>>>> Besides, as i have stated, implicit clients should not use dyn = reg.=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-31, at 13:41, Justin Richer = wrote: >>>>>>>>=20 >>>>>>>> But the outstanding question is: how do you get the access = token to access the created resource (IE: the Registration Access = Token)? You can't use the client_credentials flow for a client with no = credentials! >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 05/31/2013 12:58 PM, Phil Hunt wrote: >>>>>>>>=20 >>>>>>>> Yes. I specified the trivial solution to anonymous clients = earlier. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Even simpler. You don't need an access token = to create a new resource. You = just need one to access one. That is just basic security config.=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-31, at 12:34, Justin Richer = wrote: >>>>>>>>=20 >>>>>>>> I agree that we are going in circles, since I just was going to = bring up my counter argument of "what about clients with no = credentials?" again, which *still* isn't addressed by what you suggest = doing, below. I also believe that getting rid of the Registration Access = Token but using some other token method would actually make the spec = larger, though I'd be glad to review a concrete counter-proposal if = you'd like to write one. And the fact that OIDC is doing it this way, = and considered but rejected the way that you're describing, should say = something to the WG here about whether or not this is the right choice. = Rough consensus and running code, after all. >>>>>>>>=20 >>>>>>>> Regardless, I agree to park this issue and leave the text as = is. We'll move to the next draft in the last call process shortly, as I = have a handful = of non-normative editorial changes that I need to make, thanks to = feedback from a few folks. >>>>>>>>=20 >>>>>>>> Again, thanks for your thorough = review, Phil, and I look forward to future = feedback. >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>> On 05/31/2013 12:28 PM, Phil Hunt wrote: >>>>>>>>=20 >>>>>>>> I disagree.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> There is absolutely no need for a registration access token.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Get rid of it and just use access tokens as per 6749. If you = can't follow = 6749 and need new issuing methods, what are others to say regarding = inventing new = methods? >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> I have not heard = a good reason for the special process or one good enough to = warrant a new method for issuing an access token. Does the broader group = realize this is what the spec says? >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Yes, i heard a lot = saying OIDC does it this way. But that is a political = reason, not a technical reason. Still, compatibility is always a strong = objective. Even so, oidc could keep using their = method just fine. There is no = obligation here to do the same.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> The only reason so far was expiry = of client creds. Well, why not require the = client to update prior to expiry? It makes no sense to have another = token with longer expiry. B'sides, even expired the client can = re-register from scratch.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Why force the client to persist multiple tokens and creds? That = is far far too complex.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Finally if you get rid of registration = access token the spec size will drop = roughly in half IMO. This suggests simplicity to me.=20 >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> Apologies for my rant. Maybe we should park this for now. We = are going in circles.=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-31, at 11:25, Justin Richer = wrote: >>>>>>>>=20 >>>>>>>> Phil, >>>>>>>>=20 >>>>>>>> We *can* keep = it straight just fine, but I just need = you to be = clear about which part you're objecting to = because the = answers are = different. Please use the = terms as defined in the = document so = that we all know which = component we're talking = about. I'm sure you'd = agree than in specification = work such as this, = precision of language and = labels is key for communication = between = parties. This is precisely why there's a = Terminology section right = up front, so = that when I say "Registration = Access Token" you can know = that I mean a = very specific = thing, and = when I say "Initial Registration = Token" I mean = a very different specific = thing. So I'm asking = you, please, use = the defined = terms so that we can avoid = this = unnecessary confusion. >>>>>>>>=20 >>>>>>>> But anyway, = what you're talking about below, "the = token the = client uses to update is = profile" *IS* the = Registration = Access Token. That's all that that = token is used = for. You're not asking for it to go away, = you're asking = for it to come = from the Token = Endpoint instead of the = response from the = Registration = Endpoint. I = don't see how = the client *can* get it from the = normal token = process without jumping = through = specialized = hoops to make = that happen. I've = implemented = the draft the = way that it is = right now, both client and = server side, and it works. Others have = implemented = it, too. We've = done interop = testing, and = it works. This is a proven = pattern and = from where I sit there is = both rough = consensus and = running code. >>>>>>>>=20 >>>>>>>> I believe that I've already pointed out how the = solutions you've = proposed so = far won't work in practice, for = various reasons, many of which have = already been = brought up and = discussed = previously. If you have = another way for the client to get its = Registration = Access Token, please propose = it; but I haven't seen = anything yet that will fly. >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>> On = 05/31/2013 = 11:10 AM, Phil Hunt wrote: >>>>>>>>=20 >>>>>>>> Justin, >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> This is my primary objection! We can't keep it straight. Their = should be no such thing as a registrstion access token! Just the token = the client obtains to update its profile through the normal token = request process. >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-31, at 10:55, Justin Richer = wrote: >>>>>>>>=20 >>>>>>>> Which token are you referring to here? >>>>>>>>=20 >>>>>>>> If it's the Initial Registration Token, then you could get that = through the normal token server no problem. (The lifecycle writeups = don't call this out explicitly but I would be willing to do so.) Or you = could get it elsewhere. Doesn't matter, just like it doesn't matter with = any other OAuth2 protected resource. >>>>>>>>=20 >>>>>>>> If it's the Registration Access Token, then having the token = come from the token endpoint would require a lot more work and = complexity on behalf of both of the client and server. Either you end up = with public clients getting secrets they shouldn't need or with granting = clients access to the client_credentials flow when they shouldn't = actually have it. Plus it adds extra round trips which don't buy you = anything. >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>> On 05/31/2013 10:15 AM, Phil Hunt wrote: >>>>>>>>=20 >>>>>>>> The preference is to have the access token for registration = issued by the normal token server rather then by the registration = endpoint. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> In the current draft it is obtained through a unique process = and must outlive the client. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-30, at 19:47, "Richer, Justin P." = wrote: >>>>>>>>=20 >>>>>>>> I don't understand any of the comments below -- it already *is* = an OAuth2 protected resource without any special handling. Your access = tokens can be short-lived, long-lived, federated, structured, random = blobs ... totally doesn't matter. They are access tokens being used to = access a normal protected resource. Full stop. >>>>>>>>=20 >>>>>>>> Anything else is out of scope. The lifecycle discussions at the = beginning are merely examples of some ways you *could* use it and are = non-normative and non-exhaustive. >>>>>>>>=20 >>>>>>>> You seem to be asking for something that's already in the = draft. >>>>>>>>=20 >>>>>>>> -- Justin >>>>>>>>=20 >>>>>>>> From: Phil Hunt [phil.hunt@oracle.com] >>>>>>>> Sent: Thursday, May 30, 2013 7:31 PM >>>>>>>> To: Richer, Justin P. >>>>>>>> Cc: John Bradley; oauth@ietf.org WG >>>>>>>> Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-05-30, at 16:11, "Richer, Justin P." = wrote: >>>>>>>>=20 >>>>>>>> Comments inline, marked by [JR]. >>>>>>>>=20 >>>>>>>> From: Phil Hunt [phil.hunt@oracle.com] >>>>>>>> Sent: Thursday, May 30, 2013 5:25 PM >>>>>>>> To: Richer, Justin P. >>>>>>>> Cc: John Bradley; oauth@ietf.org WG >>>>>>>> Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>=20 >>>>>>>> See below. >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> @independentid >>>>>>>>=20 >>>>>>>> www.independentid.com >>>>>>>>=20 >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> OK, I think see part of the hang up. I have not seen the = scenario that you describe, where you trade a 3rd party token for a = "local" token. I have seen where access tokens are federated directly at = the PR. (Introspection lets you do some good things with that pattern.) >>>>>>>>=20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> =20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_15411714-A265-4905-815E-61C6C32E326D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2013-06-06, at 10:47 AM, Justin Richer wrote:

=20 =20
Because anonymous *registration* and public client *access* to the token endpoint are two different things.

-- Justin

On 06/06/2013 01:43 PM, Phil Hunt wrote:

*why* will the 6749 standard flows (specifically 4.4) not work?

The registration endpoint can allow anonymous access to permit anonymous registration.

This means the configuration endpoints can use normal access tokens obtained through RFC6749 section 4.4 (Client Auth) = flows.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:36 AM, Justin Richer = wrote:

... because = it already *is* a REST protected API. It's protected with the Registration Access Token. Which is an OAuth 2.0 Bearer token.

The *only* difference is how you get the token, which has nothing to do with the REST protected API that it's protecting.

-- Justin

On 06/06/2013 01:35 PM, Phil Hunt wrote:

Nobody has explained why using a normal REST protected API won't work. You keep saying that and that you won't go back. But that doesn't explain the issue.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:28 AM, Justin Richer wrote:

I = feel we're still just going in circles with these arguments, but my comments are inline:

On 06/06/2013 01:17 PM, Phil Hunt wrote:

Phil

=
@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 9:49 AM, Justin Richer wrote:

Tim, thanks for your review! Comments inline.

On 06/05/2013 04:59 PM, Tim Bray wrote:

FWIW, I just read the spec through with fresh eyes, and I found the explanation of the workflow in 1.4.2 very useful.

- A developer manually registers and then is able to request =93Initial = tokens=94 tokens for a = dynamic-app-registration-scope,

- you use that =93Initial token=94 token to register, = in exchange you get the client-id & so on, and also a a per-registration =93Registration token=94 for updating that particular registration = information

- you fetch/update/delete your registration information with that registration token.

The first part, where the developer registers & gets a token for a scope, is vanilla OAuth 2. = (right?)

Yes, it can be vanilla Oauth2 or it can be the developer (or someone) getting a token through some other means, like browsing to a developer portal and getting a Bearer token. I've edited the example in 1.4.3 in the latest (unpublished) text so that the developer is literally doing OAuth2 to get the initial token. It's important to note that this could be any flavor of OAuth2 token, though Bearer tokens are of course the most common.

The bit about getting an access token specific to that registration is a new flow (right?), but it seems convenient.

Right, it's a new way to get a bearer token so that you can use it at the protected resource. We wanted to re-use the token endpoint for this, but couldn't come up with a reasonable way of doing so (as has been discussed on the list.

[PH] We still greatly disagree on = this.

*Use the normal token issuing process.* One reason given was = what about anonymous clients? The = answer is, they don't have to do anything. Remember that you have defined TWO endpoints. The "registration endpoint" and = the "configuration endpoint". A server accepting anonymous registration simply accepts anonymous access at the "registration endpoint". Clients wanting to update their profiles do the normal client token request flow to the token endpoint to obtain a normal access token useable at the "configuration endpoint".

[JR] But then you're opening up the client_credentials flow to anonymous clients, or you've got to be able to lock down client_credentials as a flow to only a special (service-specific) scope for client configuration purposes. This, I think, is much more complicated to implement and much more error prone. I don't think it's even possible in the software stack we're building on top of. And furthermore, you're not letting public clients dynamically register anymore, since you'd be forcing everyone to have a client secret. Your dynamic public clients would have to save the client secret but know to only use it at the registration endpoint, and not the token endpoint where they're used to. This way, it's clear. You get a token that you use at a given endpoint, the end.

As soon as you do this, other things simplify.

1. No need to keep = "registration access token" around indefinitely. It's just an access token. In fact it = is only needed for minutes since it will likely only be used to read or update profiles or to perform client initiated credential rotation.

[JR] You *can* throw away your registration access tokens if you want to, or have them expire, if you want to limit the lifespan of your clients. It's only the security considerations section that suggests against expiring the tokens, and for good reason. But it's your choice to change that if you don't want longstanding read/edit access to a client's configuration.

2. No need to have a special = token issuing method. Creating a new = issuing process suggests that the WG can't drink its own koolaid. Because at the = first seeming challenge, the WG create a new flow. How do we expect implementers to behave?

[JR] That particular koolaid wasn't the right drink here, to stretch your analogy. Bearer tokens were, which is also the group's koolaid. We tried to go down the road you suggest and it was a dead end. Why do you think it will work better this time? And I'd like to point out a decision from several years ago now to separate the notion of "how you get a token" from "how you use a token" in OAuth2. OAuth1 had all of these rolled in together, and deployment experience showed us that people didn't really want to use it that way. People want components that make sense on their own that let you build systems like this that also make sense.

Forced uniformity isn't necessarily a good thing.

3. The = registration/configuration API is JUST a normal OAuth2 protected API.

[JR] It already is. Protected resources don't care where you get your tokens from, just that you have them, so from that perspective it is just a protected resource. Our implementation here literally just looks for the token on the way in in the auth layer and makes sure it's got a special service-specific scope that handles registration.

If the draft drops "registration access tokens", a lot of the text in the draft disappears. The whole spec = is much simpler.

[JR] Much simpler, perhaps, but much less functional and useful. And honestly, not much of the text actually goes away. Most of the draft isn't about dealing with the registration access token, it's about dealing with the client metadata and the RESTful protocol for managing that. The registration access token is a mechanism for doing so.

=46rom an OAuth 2 = point of view, there's nothing special about how you get or use the Initial token, but giving it a special name makes explaining a plausible workflow easier.

Right, and I've admitted that "Initial Access Token" a crappy name, but I haven't heard a better suggestion yet.

Having said that, I have trouble imagining the scenario where you'd use the 1.4.1 flow, but that may be because of my Google-centric worldview.

Could be -- but if Google wants to be an open-registration identity provider (like it has been with OpenID 2.0), it will need to handle this flow as well. This is the client acting on its own behalf, showing up and saying "hi, I'm a client!" and that's that. I think this is a very important case for interoperability of dynamic registration.

And I=92m not sure 1.4.3 adds any value at all. = It just seems to be a matter of different ways you could get and make use of the registration access token; and I'm sure there are various interesting combinations that haven't been thought of there. = I'd just lose 1.4.3.

1.4.3 in -11 is too close to 1.4.2, so what I've done in the current working text is make the initial process of getting the Initial Access Token different (the developer now uses OAuth2 to configure their build environment). The *real* important difference that's being shown here, though, is that the client doesn't call the registration endpoint, the developer (and their build environment) does. So yes, it's exactly all about how you get and use the registration access token. There are plenty of other ways to do it as well, so that's why this section was a non-normative set of examples. To facilitate that understanding, I've moved it to an appendix in the working copy of draft -12.

Thanks,
-- Justin

-T

On = Fri, May 31, 2013 at 1:04 PM, Donald F Coffin <donald.coffin@reminetworks.com> wrote:

See my comments inline [DFC]

Best = regards,
Don
Donald F. = Coffin
Founder/CTO

REMI = Networks
22751 El Prado Suite = 6216
Rancho Santa Margarita, CA = 92688-3836

Phone:      (949) = 636-8571
Email:       donald.coffin@reminetworks.com

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, May 31, 2013 12:40 = PM
To: Phil Hunt
Cc: Donald F Coffin; oauth@ietf.org

= Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

I feel the need to clarify a couple erroneous things in Phil's statement:

* To be clear, = Draft 11 has the same Registration Access Token system that has been in place since draft 01, it is not inventing something new at the last minute as could be inferred from the statement below.
[DFC] I agree with Justin. There = is nothing new in draft 11 regarding Registration Access Tokens that wasn=92t in the initial draft. It = appears because Phil hasn=92t been following the proposed drafts until the last call he is now raising an issue no one in the WG saw as an = issue. That=92s not to say his point isn=92t valid, but the discussion continues to go all over the map between =93local=94= and =93federated=94 tokens, usage of the RFC6749 =93Token=94 endpoint, etc. = It would be great if all of Phil=92s = points could be addressed in priority
without the threads becoming so convoluted no one is able to make sense or even comprehend the point being = discussed.

* DynReg is = using an absolutely standard OAuth 2 Bearer token as the Registration Access Token, it's just not coming from a Token Endpoint. However, since an OAuth Protected Resource doesn't care where its tokens come from so long as it can validate them, I don't see this as a problem -- this is a key point where Phil and I disagree.

[DFC] I understand = the disagreement, but I have not seen a proposal from Phil that would describe the differences between the two perspectives other than to say that the Dynamic Registration should use the Token endpoint defined in RFC6749, which does = not    discuss dynamic registration. Phil=92s point as I understand it is that there should be no difference between an access token used to access resource owner protected data and the registration structure, which I do not agree = with. As I said in the previous
=             response, my users do NOT want to provide implied access to resource owner protected data just because a client is creating a registration with an AS. This would = be the situation if the client credential flow is used to register an application. = Since our
=             implementation does NOT support the implicit flow, that use case is one we have elected NOT to = support.
        = ;    [DFC] I repeat my initial comment, this conversation has been a circular exchange now for the past few days without any appearance of an alternative option to resolve the issues.

-- = Justin

On 05/31/2013 03:33 PM, Phil Hunt wrote:

Don,

I am not proposing any change in meaning. If registration acces token issues by normal token server with scope registration everything is clear as it is for any other protected API. Draft 11 invents a whole new system. I strongly disagree with this.

Phil

On 2013-05-31, at 15:16, Donald F Coffin <donald.coffin@reminetworks.com> wrote:

For = something that was agreed to be parked a few hours ago, there sure seems to still be a lot of circular = discussion. Should we ask a mediator to = intervene?

<= br class=3D"webkit-block-placeholder">
FWIW I = believe that is a significantly strong reason to differentiate an access token that can access the registration information without having the ability to access protected data. Especially given the implied strength of the =93client credential=94 obtained access = token. I have found it extremely confusing to users when explaining the difference between an access token obtained thorough an authorization code flow and a client credential flow, simply because they are both called an =93access token=94. Changing the meaning of an access token obtained through the client credential flow to mean it has the ability to update a registration, when a user may not want it to have access to protected data will only increase both the complexity of the access tokens as well as make their usage harder to explain to non-technical individuals who have to understand the differences between the access tokens obtained through the various = flows.

<= br class=3D"webkit-block-placeholder">
Just my two = cents.

<= br class=3D"webkit-block-placeholder">

Best = regards,
Don
Donald = F. = Coffin
Founder/C= TO

REMI = Networks
22751 = El Prado Suite = 6216
Rancho Santa Margarita, = CA = 92688-3836

Phone:&nb= sp;     (949) = 636-8571
Email:&nb= sp;      donald.coffin@reminetworks.com

<= br class=3D"webkit-block-placeholder">

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Friday, May 31, 2013 11:11 AM
To: Justin = Richer
Cc: oauth@ietf.org WG
= Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt

To be = clear.

It is two separate = issues.

1. Anonymous clients can easily be handled through policy = config.

2. Support for implicit clients needs to be discussed. The current proposal creates large negative value for the service provider and most would never allow in current form. Yes it gives each execution instance a new id, but that isnt what sp's want. It is a huge attack and management headache. Eliminate or propose a different = solution.

Phil

On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org> wrote:

I'm not willing to = write out an entire class of clients from this spec, especially when we have stated use cases for them doing dynamic = registration.

I'm sorry, but your proposed solution will simply not work.

-- = Justin

On 05/31/2013 01:56 PM, Phil Hunt = wrote:

Well the only client that wouldn't have a credential is an implicit client. An implicit client is transient and so would never = update.

Besides, as i have stated, implicit clients should not use dyn reg.

Phil

On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org> wrote:

But the outstanding = question is: how do you get the access token to access the created resource (IE: the Registration Access Token)? You can't use the = client_credentials flow for a client with no = credentials!

-- = Justin

On 05/31/2013 12:58 PM, Phil Hunt = wrote:

Yes. I specified the trivial solution to anonymous clients earlier.

Even simpler. You don't need an access token to create a new resource. You just need one to access one. That is just basic security = config.

Phil

On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org> wrote:

I agree that we are = going in circles, since I just was going to bring up my counter argument of "what about clients with no credentials?" again, which *still* isn't addressed by what you suggest doing, below. I also believe that getting rid of the Registration Access Token but using some other token method would actually make the spec larger, though I'd be glad to review a concrete = counter-proposal if you'd like to write one. And the fact that OIDC is doing it this way, and considered but rejected the way that you're describing, should say something to the WG here about whether or not this is the right choice. Rough consensus and running code, after all.

Regardless, I agree to park this issue and leave the text as is. We'll move to the next draft in the last call process shortly, as I have a handful of non-normative editorial changes that I need to make, thanks to feedback from a few = folks.

Again, thanks for your thorough review, Phil, and I look forward to future feedback.

-- = Justin

On 05/31/2013 12:28 PM, Phil Hunt = wrote:

I = disagree.

There is absolutely no need for a registration access = token.

Get rid of it and just use access tokens as per 6749. If you can't follow 6749 and need new issuing methods, what are others to say regarding inventing new methods?

I have not heard a good reason for the special process or one good enough to warrant a new method for issuing an access token. Does the broader group realize this is what the spec says?

Yes, i heard a lot saying OIDC does it this way. But that is a political reason, not a technical reason. Still, compatibility is always a strong objective. Even so, = oidc could keep using their method just fine. There is no obligation here to do the = same.

The only reason so far was expiry of client creds. Well, why not require the client to update prior to expiry? It makes no sense to have another token with longer expiry. B'sides, even expired the client can re-register from = scratch.

Why force the client to persist multiple tokens and creds? That is far far too = complex.

=

Finally if you get rid of registration access token the spec size will drop roughly in half IMO. This suggests simplicity to me.

=

Apologies for my rant. Maybe we should park this for now. We are going in = circles.

Phil

On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org> wrote:

Phil,

We *can* keep it straight just fine, but I just need you to be clear about which part you're objecting to because the answers are different. Please use the terms as defined in the document so that we all know which component we're talking about. I'm sure you'd agree than in specification work such as this, precision of language and labels is key for communication between parties. This is precisely why there's a Terminology section right up front, so that when I say "Registration Access Token" you can know that I mean a very specific thing, and when I say "Initial Registration Token" I mean a very different specific thing. So I'm asking you, please, use the defined terms so that we can avoid this unnecessary confusion.

But anyway, what you're talking about below, "the token the client uses to update is profile" *IS* the Registration Access Token. That's all that that token is used for. You're not asking for it to go away, you're asking for it to come from the Token Endpoint instead of the response from the Registration Endpoint. I don't see how the client *can* get it from the normal token process without jumping through specialized hoops to make that happen. I've implemented the draft the way that it is right now, both client and server side, and it works. Others have implemented it, too. We've done interop testing, and it works. This is a proven pattern and from where I sit there is both rough consensus and running = code.

I believe that I've already pointed out how the solutions you've proposed so far won't work in practice, for various reasons, many of which have already been brought up and discussed previously. If you have another way for the client to get its Registration Access Token, please propose it; but I haven't seen anything yet that will = fly.

-- = Justin

On 05/31/2013 11:10 AM, Phil Hunt = wrote:

Justin,

This is my primary objection! We can't keep it straight. Their should be no such thing as a registrstion access token! Just the token the client obtains to update its profile through the normal token request = process.

Phil

On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org> wrote:

Which token are you = referring to here?

If it's the Initial Registration Token, then you could get that through the normal token server no problem. (The lifecycle writeups don't call this out explicitly but I would be willing to do so.) Or you could get it elsewhere. Doesn't matter, just like it doesn't matter with any other OAuth2 protected resource.

If it's the Registration Access Token, then having the token come from the token endpoint would require a lot more work and complexity on behalf of both of the client and server. Either you end up with public clients getting secrets they shouldn't need or with granting clients access to the = client_credentials flow when they shouldn't actually have it. Plus it adds extra round trips which don't buy you anything.

-- = Justin

On 05/31/2013 10:15 AM, Phil Hunt = wrote:

The preference is to have the access token for registration issued by the normal token server rather then by the registration = endpoint.

In the current draft it is obtained through a unique process and must outlive the = client.

Phil

On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org> wrote:

I don't understand any of the comments below -- it already *is* an OAuth2 protected resource without any special handling. Your access tokens can be short-lived, long-lived, federated, structured, random blobs ... totally doesn't matter. They are access tokens being used to access a normal protected resource. Full stop.

Anything else is out of scope. The lifecycle discussions at the beginning are merely examples of some ways you *could* use it and are non-normative and = non-exhaustive.

You seem to be asking for something that's already in the = draft.

-- = Justin

From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 7:31 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
= Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt

Phil

On 2013-05-30, at 16:11, "Richer, Justin P." <jricher@mitre.org> wrote:

Comments inline, marked by = [JR].

From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 5:25 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
= Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt

See below.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-05-30, at 2:09 PM, Justin Richer wrote:

OK, I think see part of the hang up. I have not seen the scenario that you describe, where you trade a 3rd party token for a "local" token. I have seen where access tokens are federated directly at the PR. (Introspection lets you do some good things with that pattern.)

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

= --Apple-Mail=_15411714-A265-4905-815E-61C6C32E326D-- From jricher@mitre.org Thu Jun 6 10:50:59 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8F221F9B12 for ; Thu, 6 Jun 2013 10:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYidhC6ESNeW for ; Thu, 6 Jun 2013 10:50:54 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 966D521F9B08 for ; Thu, 6 Jun 2013 10:50:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AC25D1F0269; Thu, 6 Jun 2013 13:50:46 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7D4F4226004A; Thu, 6 Jun 2013 13:50:46 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 6 Jun 2013 13:50:46 -0400 Message-ID: <51B0CBC5.5090509@mitre.org> Date: Thu, 6 Jun 2013 13:49:57 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <51B0BDA2.7010705@mitre.org> <7B00614C-6B25-4951-B004-C17932432D17@oracle.com> <51B0C6D4.804000!> <9@mitre.org> <51B0C8A0.2020306@mitre.org> <51B0CB18.50! 90003@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060604070208090309030200" X-Originating-IP: [129.83.31.56] Cc: Donald F Coffin , "oauth@ietf.org" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:50:59 -0000 --------------060604070208090309030200 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Then how do they get their equivalent of a registration access token to manage their configurations? The draft proposes that they get this token right from the registration endpoint. You're proposing that they get this from the token endpoint. The initial access token isn't even in play here. -- Justin On 06/06/2013 01:49 PM, Phil Hunt wrote: > Huh? > > There's no need for public clients to access the token endpoint as > they can register anonymously. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-06-06, at 10:47 AM, Justin Richer wrote: > >> Because anonymous *registration* and public client *access* to the >> token endpoint are two different things. >> >> -- Justin >> >> On 06/06/2013 01:43 PM, Phil Hunt wrote: >>> *why* will the 6749 standard flows (specifically 4.4) not work? >>> >>> The registration endpoint can allow anonymous access to permit >>> anonymous registration. >>> >>> This means the configuration endpoints can use normal access tokens >>> obtained through RFC6749 section 4.4 (Client Auth) flows. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2013-06-06, at 10:36 AM, Justin Richer wrote: >>> >>>> ... because it already *is* a REST protected API. It's protected >>>> with the Registration Access Token. Which is an OAuth 2.0 Bearer >>>> token. >>>> >>>> The *only* difference is how you get the token, which has nothing >>>> to do with the REST protected API that it's protecting. >>>> >>>> -- Justin >>>> >>>> On 06/06/2013 01:35 PM, Phil Hunt wrote: >>>>> Nobody has explained why using a normal REST protected API won't >>>>> work. You keep saying that and that you won't go back. But that >>>>> doesn't explain the issue. >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2013-06-06, at 10:28 AM, Justin Richer wrote: >>>>> >>>>>> I feel we're still just going in circles with these arguments, >>>>>> but my comments are inline: >>>>>> >>>>>> On 06/06/2013 01:17 PM, Phil Hunt wrote: >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2013-06-06, at 9:49 AM, Justin Richer wrote: >>>>>>> >>>>>>>> Tim, thanks for your review! Comments inline. >>>>>>>> >>>>>>>> On 06/05/2013 04:59 PM, Tim Bray wrote: >>>>>>>>> FWIW, I just read the spec through with fresh eyes, and I >>>>>>>>> found the explanation of the workflow in 1.4.2 very useful. >>>>>>>>> >>>>>>>>> - A developer manually registers and then is able to request >>>>>>>>> �Initial tokens� tokens for a dynamic-app-registration-scope, >>>>>>>>> - you use that �Initial token� token to register, in exchange >>>>>>>>> you get the client-id & so on, and also a a per-registration >>>>>>>>> �Registration token� for updating that particular registration >>>>>>>>> information >>>>>>>>> - you fetch/update/delete your registration information with >>>>>>>>> that registration token. >>>>>>>>> >>>>>>>>> The first part, where the developer registers & gets a token >>>>>>>>> for a scope, is vanilla OAuth 2. (right?) >>>>>>>> >>>>>>>> Yes, it can be vanilla Oauth2 or it can be the developer (or >>>>>>>> someone) getting a token through some other means, like >>>>>>>> browsing to a developer portal and getting a Bearer token. I've >>>>>>>> edited the example in 1.4.3 in the latest (unpublished) text so >>>>>>>> that the developer is literally doing OAuth2 to get the initial >>>>>>>> token. It's important to note that this could be any flavor of >>>>>>>> OAuth2 token, though Bearer tokens are of course the most common. >>>>>>>> >>>>>>>>> The bit about getting an access token specific to that >>>>>>>>> registration is a new flow (right?), but it seems convenient. >>>>>>>> >>>>>>>> Right, it's a new way to get a bearer token so that you can use >>>>>>>> it at the protected resource. We wanted to re-use the token >>>>>>>> endpoint for this, but couldn't come up with a reasonable way >>>>>>>> of doing so (as has been discussed on the list. >>>>>>> >>>>>>> [PH] We still greatly disagree on this. >>>>>>> >>>>>>> *Use the normal token issuing process.* One reason given was >>>>>>> what about anonymous clients? The answer is, they don't have to >>>>>>> do anything. Remember that you have defined TWO endpoints. The >>>>>>> "registration endpoint" and the "configuration endpoint". A >>>>>>> server accepting anonymous registration simply accepts anonymous >>>>>>> access at the "registration endpoint". Clients wanting to >>>>>>> update their profiles do the normal client token request flow to >>>>>>> the token endpoint to obtain a normal access token useable at >>>>>>> the "configuration endpoint". >>>>>>> >>>>>> >>>>>> [JR] But then you're opening up the client_credentials flow to >>>>>> anonymous clients, or you've got to be able to lock down >>>>>> client_credentials as a flow to only a special (service-specific) >>>>>> scope for client configuration purposes. This, I think, is much >>>>>> more complicated to implement and much more error prone. I don't >>>>>> think it's even possible in the software stack we're building on >>>>>> top of. And furthermore, you're not letting public clients >>>>>> dynamically register anymore, since you'd be forcing everyone to >>>>>> have a client secret. Your dynamic public clients would have to >>>>>> save the client secret but know to only use it at the >>>>>> registration endpoint, and not the token endpoint where they're >>>>>> used to. This way, it's clear. You get a token that you use at a >>>>>> given endpoint, the end. >>>>>> >>>>>>> As soon as you do this, other things simplify. >>>>>>> >>>>>>> 1. No need to keep "registration access token" around >>>>>>> indefinitely. It's just an access token. In fact it is only >>>>>>> needed for minutes since it will likely only be used to read or >>>>>>> update profiles or to perform client initiated credential rotation. >>>>>> >>>>>> [JR] You *can* throw away your registration access tokens if you >>>>>> want to, or have them expire, if you want to limit the lifespan >>>>>> of your clients. It's only the security considerations section >>>>>> that suggests against expiring the tokens, and for good reason. >>>>>> But it's your choice to change that if you don't want >>>>>> longstanding read/edit access to a client's configuration. >>>>>> >>>>>>> 2. No need to have a special token issuing method. Creating a >>>>>>> new issuing process suggests that the WG can't drink its own >>>>>>> koolaid. Because at the first seeming challenge, the WG create >>>>>>> a new flow. How do we expect implementers to behave? >>>>>> >>>>>> [JR] That particular koolaid wasn't the right drink here, to >>>>>> stretch your analogy. Bearer tokens were, which is also the >>>>>> group's koolaid. We tried to go down the road you suggest and it >>>>>> was a dead end. Why do you think it will work better this time? >>>>>> And I'd like to point out a decision from several years ago now >>>>>> to separate the notion of "how you get a token" from "how you use >>>>>> a token" in OAuth2. OAuth1 had all of these rolled in together, >>>>>> and deployment experience showed us that people didn't really >>>>>> want to use it that way. People want components that make sense >>>>>> on their own that let you build systems like this that also make >>>>>> sense. >>>>>> >>>>>> Forced uniformity isn't necessarily a good thing. >>>>>> >>>>>>> 3. The registration/configuration API is JUST a normal OAuth2 >>>>>>> protected API. >>>>>> >>>>>> [JR] It already is. Protected resources don't care where you get >>>>>> your tokens from, just that you have them, so from that >>>>>> perspective it is just a protected resource. Our implementation >>>>>> here literally just looks for the token on the way in in the auth >>>>>> layer and makes sure it's got a special service-specific scope >>>>>> that handles registration. >>>>>> >>>>>>> >>>>>>> If the draft drops "registration access tokens", a lot of the >>>>>>> text in the draft disappears. The whole spec is much simpler. >>>>>> >>>>>> [JR] Much simpler, perhaps, but much less functional and useful. >>>>>> And honestly, not much of the text actually goes away. Most of >>>>>> the draft isn't about dealing with the registration access token, >>>>>> it's about dealing with the client metadata and the RESTful >>>>>> protocol for managing that. The registration access token is a >>>>>> mechanism for doing so. >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> From an OAuth 2 point of view, there's nothing special about >>>>>>>>> how you get or use the Initial token, but giving it a special >>>>>>>>> name makes explaining a plausible workflow easier. >>>>>>>> >>>>>>>> Right, and I've admitted that "Initial Access Token" a crappy >>>>>>>> name, but I haven't heard a better suggestion yet. >>>>>>>> >>>>>>>>> >>>>>>>>> Having said that, I have trouble imagining the scenario where >>>>>>>>> you'd use the 1.4.1 flow, but that may be because of my >>>>>>>>> Google-centric worldview. >>>>>>>> >>>>>>>> Could be -- but if Google wants to be an open-registration >>>>>>>> identity provider (like it has been with OpenID 2.0), it will >>>>>>>> need to handle this flow as well. This is the client acting on >>>>>>>> its own behalf, showing up and saying "hi, I'm a client!" and >>>>>>>> that's that. I think this is a very important case for >>>>>>>> interoperability of dynamic registration. >>>>>>>> >>>>>>>>> >>>>>>>>> And I�m not sure 1.4.3 adds any value at all. It just seems >>>>>>>>> to be a matter of different ways you could get and make use of >>>>>>>>> the registration access token; and I'm sure there are various >>>>>>>>> interesting combinations that haven't been thought of there. >>>>>>>>> I'd just lose 1.4.3. >>>>>>>>> >>>>>>>> >>>>>>>> 1.4.3 in -11 is too close to 1.4.2, so what I've done in the >>>>>>>> current working text is make the initial process of getting the >>>>>>>> Initial Access Token different (the developer now uses OAuth2 >>>>>>>> to configure their build environment). The *real* important >>>>>>>> difference that's being shown here, though, is that the client >>>>>>>> doesn't call the registration endpoint, the developer (and >>>>>>>> their build environment) does. So yes, it's exactly all about >>>>>>>> how you get and use the registration access token. There are >>>>>>>> plenty of other ways to do it as well, so that's why this >>>>>>>> section was a non-normative set of examples. To facilitate that >>>>>>>> understanding, I've moved it to an appendix in the working copy >>>>>>>> of draft -12. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -- Justin >>>>>>>> >>>>>>>>> -T >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> See my comments inline [DFC] >>>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Don >>>>>>>>> >>>>>>>>> Donald F. Coffin >>>>>>>>> >>>>>>>>> Founder/CTO >>>>>>>>> >>>>>>>>> >>>>>>>>> REMI Networks >>>>>>>>> >>>>>>>>> 22751 El Prado Suite 6216 >>>>>>>>> >>>>>>>>> Rancho Santa Margarita, CA 92688-3836 >>>>>>>>> >>>>>>>>> >>>>>>>>> Phone: (949) 636-8571 >>>>>>>>> >>>>>>>>> Email: donald.coffin@reminetworks.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *From:*Justin Richer [mailto:jricher@mitre.org >>>>>>>>> ] >>>>>>>>> *Sent:* Friday, May 31, 2013 12:40 PM >>>>>>>>> *To:* Phil Hunt >>>>>>>>> *Cc:* Donald F Coffin; oauth@ietf.org >>>>>>>>> >>>>>>>>> >>>>>>>>> *Subject:* Re: [OAUTH-WG] review comments on >>>>>>>>> draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>> >>>>>>>>> I feel the need to clarify a couple erroneous things in >>>>>>>>> Phil's statement: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> * To be clear, Draft 11 has the same Registration Access >>>>>>>>> Token system that has been in place since draft 01, it is >>>>>>>>> not inventing something new at the last minute as could be >>>>>>>>> inferred from the statement below. >>>>>>>>> >>>>>>>>> [DFC] I agree with Justin. There is nothing new in draft >>>>>>>>> 11 regarding Registration Access Tokens that wasn�t in the >>>>>>>>> initial draft. It appears because Phil hasn�t been >>>>>>>>> following the proposed drafts until the last call he is >>>>>>>>> now raising an issue no one in the WG saw as an issue. >>>>>>>>> That�s not to say his point isn�t valid, but the >>>>>>>>> discussion continues to go all over the map between >>>>>>>>> �local� and �federated� tokens, usage of the RFC6749 >>>>>>>>> �Token� endpoint, etc. It would be great if all of Phil�s >>>>>>>>> points could be addressed in priority >>>>>>>>> without the threads becoming so convoluted no one is able >>>>>>>>> to make sense or even comprehend the point being discussed. >>>>>>>>> >>>>>>>>> >>>>>>>>> * DynReg is using an absolutely standard OAuth 2 Bearer >>>>>>>>> token as the Registration Access Token, it's just not >>>>>>>>> coming from a Token Endpoint. However, since an OAuth >>>>>>>>> Protected Resource doesn't care where its tokens come from >>>>>>>>> so long as it can validate them, I don't see this as a >>>>>>>>> problem -- this is a key point where Phil and I disagree. >>>>>>>>> >>>>>>>>> [DFC] I understand the disagreement, but I have not seen >>>>>>>>> a proposal from Phil that would describe the differences >>>>>>>>> between the two perspectives other than to say that the >>>>>>>>> Dynamic Registration should use the Token endpoint defined >>>>>>>>> in RFC6749, which does not discuss dynamic registration. >>>>>>>>> Phil�s point as I understand it is that there should be no >>>>>>>>> difference between an access token used to access resource >>>>>>>>> owner protected data and the registration structure, which >>>>>>>>> I do not agree with. As I said in the previous >>>>>>>>> response, my users do NOT want to provide implied access >>>>>>>>> to resource owner protected data just because a client is >>>>>>>>> creating a registration with an AS. This would be the >>>>>>>>> situation if the client credential flow is used to >>>>>>>>> register an application. Since our >>>>>>>>> implementation does NOT support the implicit flow, that >>>>>>>>> use case is one we have elected NOT to support. >>>>>>>>> >>>>>>>>> [DFC] I repeat my initial comment, this conversation has >>>>>>>>> been a circular exchange now for the past few days without >>>>>>>>> any appearance of an alternative option to resolve the issues. >>>>>>>>> >>>>>>>>> >>>>>>>>> -- Justin >>>>>>>>> >>>>>>>>> On 05/31/2013 03:33 PM, Phil Hunt wrote: >>>>>>>>> >>>>>>>>> Don, >>>>>>>>> >>>>>>>>> >>>>>>>>> I am not proposing any change in meaning. If >>>>>>>>> registration acces token issues by normal token server >>>>>>>>> with scope registration everything is clear as it is >>>>>>>>> for any other protected API. Draft 11 invents a whole >>>>>>>>> new system. I strongly disagree with this. >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-05-31, at 15:16, Donald F Coffin >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> For something that was agreed to be parked a few >>>>>>>>> hours ago, there sure seems to still be a lot of >>>>>>>>> circular discussion. Should we ask a mediator to >>>>>>>>> intervene? >>>>>>>>> >>>>>>>>> >>>>>>>>> FWIW I believe that is a significantly strong >>>>>>>>> reason to differentiate an access token that can >>>>>>>>> access the registration information without having >>>>>>>>> the ability to access protected data. Especially >>>>>>>>> given the implied strength of the �client >>>>>>>>> credential� obtained access token. I have found it >>>>>>>>> extremely confusing to users when explaining the >>>>>>>>> difference between an access token obtained >>>>>>>>> thorough an authorization code flow and a client >>>>>>>>> credential flow, simply because they are both >>>>>>>>> called an �access token�. Changing the meaning of >>>>>>>>> an access token obtained through the client >>>>>>>>> credential flow to mean it has the ability to >>>>>>>>> update a registration, when a user may not want it >>>>>>>>> to have access to protected data will only >>>>>>>>> increase both the complexity of the access tokens >>>>>>>>> as well as make their usage harder to explain to >>>>>>>>> non-technical individuals who have to understand >>>>>>>>> the differences between the access tokens obtained >>>>>>>>> through the various flows. >>>>>>>>> >>>>>>>>> >>>>>>>>> Just my two cents. >>>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Don >>>>>>>>> >>>>>>>>> Donald F. Coffin >>>>>>>>> >>>>>>>>> Founder/CTO >>>>>>>>> >>>>>>>>> >>>>>>>>> REMI Networks >>>>>>>>> >>>>>>>>> 22751 El Prado Suite 6216 >>>>>>>>> >>>>>>>>> Rancho Santa Margarita, CA 92688-3836 >>>>>>>>> >>>>>>>>> >>>>>>>>> Phone: (949) 636-8571 >>>>>>>>> >>>>>>>>> Email: donald.coffin@reminetworks.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *From:*Phil Hunt [mailto:phil.hunt@oracle.com] >>>>>>>>> *Sent:* Friday, May 31, 2013 11:11 AM >>>>>>>>> *To:* Justin Richer >>>>>>>>> *Cc:* oauth@ietf.org WG >>>>>>>>> *Subject:* Re: [OAUTH-WG] review comments on >>>>>>>>> draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> To be clear. >>>>>>>>> >>>>>>>>> >>>>>>>>> It is two separate issues. >>>>>>>>> >>>>>>>>> >>>>>>>>> 1. Anonymous clients can easily be handled through >>>>>>>>> policy config. >>>>>>>>> >>>>>>>>> >>>>>>>>> 2. Support for implicit clients needs to be >>>>>>>>> discussed. The current proposal creates large >>>>>>>>> negative value for the service provider and most >>>>>>>>> would never allow in current form. Yes it gives >>>>>>>>> each execution instance a new id, but that isnt >>>>>>>>> what sp's want. It is a huge attack and management >>>>>>>>> headache. Eliminate or propose a different solution. >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-05-31, at 13:58, Justin Richer >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> I'm not willing to write out an entire class >>>>>>>>> of clients from this spec, especially when we >>>>>>>>> have stated use cases for them doing dynamic >>>>>>>>> registration. >>>>>>>>> >>>>>>>>> I'm sorry, but your proposed solution will >>>>>>>>> simply not work. >>>>>>>>> >>>>>>>>> -- Justin >>>>>>>>> >>>>>>>>> On 05/31/2013 01:56 PM, Phil Hunt wrote: >>>>>>>>> >>>>>>>>> Well the only client that wouldn't have a >>>>>>>>> credential is an implicit client. An >>>>>>>>> implicit client is transient and so would >>>>>>>>> never update. >>>>>>>>> >>>>>>>>> Besides, as i have stated, implicit >>>>>>>>> clients should not use dyn reg. >>>>>>>>> >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-05-31, at 13:41, Justin Richer >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> But the outstanding question is: how >>>>>>>>> do you get the access token to access >>>>>>>>> the created resource (IE: the >>>>>>>>> Registration Access Token)? You can't >>>>>>>>> use the client_credentials flow for a >>>>>>>>> client with no credentials! >>>>>>>>> >>>>>>>>> -- Justin >>>>>>>>> >>>>>>>>> >>>>>>>>> On 05/31/2013 12:58 PM, Phil Hunt wrote: >>>>>>>>> >>>>>>>>> Yes. I specified the trivial >>>>>>>>> solution to anonymous clients earlier. >>>>>>>>> >>>>>>>>> >>>>>>>>> Even simpler. You don't need an >>>>>>>>> access token to create a new >>>>>>>>> resource. You just need one to >>>>>>>>> access one. That is just basic >>>>>>>>> security config. >>>>>>>>> >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-05-31, at 12:34, Justin >>>>>>>>> Richer >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> I agree that we are going in >>>>>>>>> circles, since I just was >>>>>>>>> going to bring up my counter >>>>>>>>> argument of "what about >>>>>>>>> clients with no credentials?" >>>>>>>>> again, which *still* isn't >>>>>>>>> addressed by what you suggest >>>>>>>>> doing, below. I also believe >>>>>>>>> that getting rid of the >>>>>>>>> Registration Access Token but >>>>>>>>> using some other token method >>>>>>>>> would actually make the spec >>>>>>>>> larger, though I'd be glad to >>>>>>>>> review a concrete >>>>>>>>> counter-proposal if you'd like >>>>>>>>> to write one. And the fact >>>>>>>>> that OIDC is doing it this >>>>>>>>> way, and considered but >>>>>>>>> rejected the way that you're >>>>>>>>> describing, should say >>>>>>>>> something to the WG here about >>>>>>>>> whether or not this is the >>>>>>>>> right choice. Rough consensus >>>>>>>>> and running code, after all. >>>>>>>>> >>>>>>>>> Regardless, I agree to park >>>>>>>>> this issue and leave the text >>>>>>>>> as is. We'll move to the next >>>>>>>>> draft in the last call process >>>>>>>>> shortly, as I have a handful >>>>>>>>> of non-normative editorial >>>>>>>>> changes that I need to make, >>>>>>>>> thanks to feedback from a few >>>>>>>>> folks. >>>>>>>>> >>>>>>>>> Again, thanks for your >>>>>>>>> thorough review, Phil, and I >>>>>>>>> look forward to future feedback. >>>>>>>>> >>>>>>>>> -- Justin >>>>>>>>> >>>>>>>>> On 05/31/2013 12:28 PM, Phil >>>>>>>>> Hunt wrote: >>>>>>>>> >>>>>>>>> I disagree. >>>>>>>>> >>>>>>>>> >>>>>>>>> There is absolutely no >>>>>>>>> need for a registration >>>>>>>>> access token. >>>>>>>>> >>>>>>>>> >>>>>>>>> Get rid of it and just use >>>>>>>>> access tokens as per 6749. >>>>>>>>> If you can't follow 6749 >>>>>>>>> and need new issuing >>>>>>>>> methods, what are others >>>>>>>>> to say regarding inventing >>>>>>>>> new methods? >>>>>>>>> >>>>>>>>> >>>>>>>>> I have not heard a good >>>>>>>>> reason for the special >>>>>>>>> process or one good enough >>>>>>>>> to warrant a new method >>>>>>>>> for issuing an access >>>>>>>>> token. Does the broader >>>>>>>>> group realize this is what >>>>>>>>> the spec says? >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, i heard a lot saying >>>>>>>>> OIDC does it this way. But >>>>>>>>> that is a political >>>>>>>>> reason, not a technical >>>>>>>>> reason. Still, >>>>>>>>> compatibility is always a >>>>>>>>> strong objective. Even >>>>>>>>> so, oidc could keep using >>>>>>>>> their method just fine. >>>>>>>>> There is no obligation >>>>>>>>> here to do the same. >>>>>>>>> >>>>>>>>> >>>>>>>>> The only reason so far was >>>>>>>>> expiry of client creds. >>>>>>>>> Well, why not require the >>>>>>>>> client to update prior to >>>>>>>>> expiry? It makes no sense >>>>>>>>> to have another token with >>>>>>>>> longer expiry. B'sides, >>>>>>>>> even expired the client >>>>>>>>> can re-register from scratch. >>>>>>>>> >>>>>>>>> >>>>>>>>> Why force the client to >>>>>>>>> persist multiple tokens >>>>>>>>> and creds? That is far far >>>>>>>>> too complex. >>>>>>>>> >>>>>>>>> >>>>>>>>> Finally if you get rid of >>>>>>>>> registration access token >>>>>>>>> the spec size will drop >>>>>>>>> roughly in half IMO. This >>>>>>>>> suggests simplicity to me. >>>>>>>>> >>>>>>>>> >>>>>>>>> Apologies for my rant. >>>>>>>>> Maybe we should park this >>>>>>>>> for now. We are going in >>>>>>>>> circles. >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-05-31, at 11:25, >>>>>>>>> Justin Richer >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Phil, >>>>>>>>> >>>>>>>>> We *can* keep it >>>>>>>>> straight just fine, >>>>>>>>> but I just need you to >>>>>>>>> be clear about which >>>>>>>>> part you're objecting >>>>>>>>> to because the answers >>>>>>>>> are different. Please >>>>>>>>> use the terms as >>>>>>>>> defined in the >>>>>>>>> document so that we >>>>>>>>> all know which >>>>>>>>> component we're >>>>>>>>> talking about. I'm >>>>>>>>> sure you'd agree than >>>>>>>>> in specification work >>>>>>>>> such as this, >>>>>>>>> precision of language >>>>>>>>> and labels is key for >>>>>>>>> communication between >>>>>>>>> parties. This is >>>>>>>>> precisely why there's >>>>>>>>> a Terminology section >>>>>>>>> right up front, so >>>>>>>>> that when I say >>>>>>>>> "Registration Access >>>>>>>>> Token" you can know >>>>>>>>> that I mean a very >>>>>>>>> specific thing, and >>>>>>>>> when I say "Initial >>>>>>>>> Registration Token" I >>>>>>>>> mean a very different >>>>>>>>> specific thing. So I'm >>>>>>>>> asking you, please, >>>>>>>>> use the defined terms >>>>>>>>> so that we can avoid >>>>>>>>> this unnecessary >>>>>>>>> confusion. >>>>>>>>> >>>>>>>>> But anyway, what >>>>>>>>> you're talking about >>>>>>>>> below, "the token the >>>>>>>>> client uses to update >>>>>>>>> is profile" *IS* the >>>>>>>>> Registration Access >>>>>>>>> Token. That's all that >>>>>>>>> that token is used >>>>>>>>> for. You're not asking >>>>>>>>> for it to go away, >>>>>>>>> you're asking for it >>>>>>>>> to come from the Token >>>>>>>>> Endpoint instead of >>>>>>>>> the response from the >>>>>>>>> Registration Endpoint. >>>>>>>>> I don't see how the >>>>>>>>> client *can* get it >>>>>>>>> from the normal token >>>>>>>>> process without >>>>>>>>> jumping through >>>>>>>>> specialized hoops to >>>>>>>>> make that happen. I've >>>>>>>>> implemented the draft >>>>>>>>> the way that it is >>>>>>>>> right now, both client >>>>>>>>> and server side, and >>>>>>>>> it works. Others have >>>>>>>>> implemented it, too. >>>>>>>>> We've done interop >>>>>>>>> testing, and it works. >>>>>>>>> This is a proven >>>>>>>>> pattern and from where >>>>>>>>> I sit there is both >>>>>>>>> rough consensus and >>>>>>>>> running code. >>>>>>>>> >>>>>>>>> I believe that I've >>>>>>>>> already pointed out >>>>>>>>> how the solutions >>>>>>>>> you've proposed so far >>>>>>>>> won't work in >>>>>>>>> practice, for various >>>>>>>>> reasons, many of which >>>>>>>>> have already been >>>>>>>>> brought up and >>>>>>>>> discussed previously. >>>>>>>>> If you have another >>>>>>>>> way for the client to >>>>>>>>> get its Registration >>>>>>>>> Access Token, please >>>>>>>>> propose it; but I >>>>>>>>> haven't seen anything >>>>>>>>> yet that will fly. >>>>>>>>> >>>>>>>>> -- Justin >>>>>>>>> >>>>>>>>> On 05/31/2013 11:10 >>>>>>>>> AM, Phil Hunt wrote: >>>>>>>>> >>>>>>>>> Justin, >>>>>>>>> >>>>>>>>> >>>>>>>>> This is my primary >>>>>>>>> objection! We >>>>>>>>> can't keep it >>>>>>>>> straight. Their >>>>>>>>> should be no such >>>>>>>>> thing as a >>>>>>>>> registrstion >>>>>>>>> access token! >>>>>>>>> Just the token >>>>>>>>> the client obtains >>>>>>>>> to update its >>>>>>>>> profile through >>>>>>>>> the normal token >>>>>>>>> request process. >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-05-31, at >>>>>>>>> 10:55, Justin >>>>>>>>> Richer >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Which token >>>>>>>>> are you >>>>>>>>> referring to here? >>>>>>>>> >>>>>>>>> If it's the >>>>>>>>> Initial >>>>>>>>> Registration >>>>>>>>> Token, then >>>>>>>>> you could get >>>>>>>>> that through >>>>>>>>> the normal >>>>>>>>> token server >>>>>>>>> no problem. >>>>>>>>> (The lifecycle >>>>>>>>> writeups don't >>>>>>>>> call this out >>>>>>>>> explicitly but >>>>>>>>> I would be >>>>>>>>> willing to do >>>>>>>>> so.) Or you >>>>>>>>> could get it >>>>>>>>> elsewhere. >>>>>>>>> Doesn't >>>>>>>>> matter, just >>>>>>>>> like it >>>>>>>>> doesn't matter >>>>>>>>> with any other >>>>>>>>> OAuth2 >>>>>>>>> protected >>>>>>>>> resource. >>>>>>>>> >>>>>>>>> If it's the >>>>>>>>> Registration >>>>>>>>> Access Token, >>>>>>>>> then having >>>>>>>>> the token come >>>>>>>>> from the token >>>>>>>>> endpoint would >>>>>>>>> require a lot >>>>>>>>> more work and >>>>>>>>> complexity on >>>>>>>>> behalf of both >>>>>>>>> of the client >>>>>>>>> and server. >>>>>>>>> Either you end >>>>>>>>> up with public >>>>>>>>> clients >>>>>>>>> getting >>>>>>>>> secrets they >>>>>>>>> shouldn't need >>>>>>>>> or with >>>>>>>>> granting >>>>>>>>> clients access >>>>>>>>> to the >>>>>>>>> client_credentials >>>>>>>>> flow when they >>>>>>>>> shouldn't >>>>>>>>> actually have >>>>>>>>> it. Plus it >>>>>>>>> adds extra >>>>>>>>> round trips >>>>>>>>> which don't >>>>>>>>> buy you anything. >>>>>>>>> >>>>>>>>> -- Justin >>>>>>>>> >>>>>>>>> On 05/31/2013 >>>>>>>>> 10:15 AM, Phil >>>>>>>>> Hunt wrote: >>>>>>>>> >>>>>>>>> The >>>>>>>>> preference >>>>>>>>> is to have >>>>>>>>> the access >>>>>>>>> token for >>>>>>>>> registration >>>>>>>>> issued by >>>>>>>>> the normal >>>>>>>>> token >>>>>>>>> server >>>>>>>>> rather >>>>>>>>> then by >>>>>>>>> the >>>>>>>>> registration >>>>>>>>> endpoint. >>>>>>>>> >>>>>>>>> >>>>>>>>> In the >>>>>>>>> current >>>>>>>>> draft it >>>>>>>>> is >>>>>>>>> obtained >>>>>>>>> through a >>>>>>>>> unique >>>>>>>>> process >>>>>>>>> and must >>>>>>>>> outlive >>>>>>>>> the client. >>>>>>>>> >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>> On >>>>>>>>> 2013-05-30, at >>>>>>>>> 19:47, >>>>>>>>> "Richer, >>>>>>>>> Justin P." >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I >>>>>>>>> don't >>>>>>>>> understand >>>>>>>>> any of >>>>>>>>> the >>>>>>>>> comments >>>>>>>>> below >>>>>>>>> -- it >>>>>>>>> already *is* >>>>>>>>> an >>>>>>>>> OAuth2 >>>>>>>>> protected >>>>>>>>> resource >>>>>>>>> without any >>>>>>>>> special handling. >>>>>>>>> Your >>>>>>>>> access >>>>>>>>> tokens >>>>>>>>> can be >>>>>>>>> short-lived, >>>>>>>>> long-lived, >>>>>>>>> federated, >>>>>>>>> structured, >>>>>>>>> random >>>>>>>>> blobs >>>>>>>>> ... >>>>>>>>> totally doesn't >>>>>>>>> matter. They >>>>>>>>> are >>>>>>>>> access >>>>>>>>> tokens >>>>>>>>> being >>>>>>>>> used >>>>>>>>> to >>>>>>>>> access >>>>>>>>> a >>>>>>>>> normal >>>>>>>>> protected >>>>>>>>> resource. >>>>>>>>> Full stop. >>>>>>>>> >>>>>>>>> Anything >>>>>>>>> else >>>>>>>>> is out >>>>>>>>> of >>>>>>>>> scope. >>>>>>>>> The >>>>>>>>> lifecycle >>>>>>>>> discussions >>>>>>>>> at the >>>>>>>>> beginning >>>>>>>>> are >>>>>>>>> merely >>>>>>>>> examples >>>>>>>>> of >>>>>>>>> some >>>>>>>>> ways >>>>>>>>> you >>>>>>>>> *could* use >>>>>>>>> it and >>>>>>>>> are >>>>>>>>> non-normative >>>>>>>>> and >>>>>>>>> non-exhaustive. >>>>>>>>> >>>>>>>>> You >>>>>>>>> seem >>>>>>>>> to be >>>>>>>>> asking >>>>>>>>> for >>>>>>>>> something >>>>>>>>> that's >>>>>>>>> already in >>>>>>>>> the draft. >>>>>>>>> >>>>>>>>> -- Justin >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> *From:*Phil >>>>>>>>> Hunt >>>>>>>>> [phil.hunt@oracle.com >>>>>>>>> ] >>>>>>>>> *Sent:* Thursday, >>>>>>>>> May >>>>>>>>> 30, >>>>>>>>> 2013 >>>>>>>>> 7:31 PM >>>>>>>>> *To:* >>>>>>>>> Richer, Justin >>>>>>>>> P. >>>>>>>>> *Cc:* >>>>>>>>> John >>>>>>>>> Bradley; >>>>>>>>> oauth@ietf.org >>>>>>>>> >>>>>>>>> WG >>>>>>>>> *Subject:* >>>>>>>>> Re: >>>>>>>>> [OAUTH-WG] >>>>>>>>> review >>>>>>>>> comments >>>>>>>>> on >>>>>>>>> draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>> On >>>>>>>>> 2013-05-30, >>>>>>>>> at >>>>>>>>> 16:11, >>>>>>>>> "Richer, >>>>>>>>> Justin >>>>>>>>> P." >>>>>>>>> >>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Comments >>>>>>>>> inline, >>>>>>>>> marked >>>>>>>>> by >>>>>>>>> [JR]. >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> *From:*Phil >>>>>>>>> Hunt >>>>>>>>> [phil.hunt@oracle.com >>>>>>>>> ] >>>>>>>>> *Sent:* >>>>>>>>> Thursday, >>>>>>>>> May 30, >>>>>>>>> 2013 >>>>>>>>> 5:25 >>>>>>>>> PM >>>>>>>>> *To:* >>>>>>>>> Richer, >>>>>>>>> Justin >>>>>>>>> P. >>>>>>>>> *Cc:* >>>>>>>>> John >>>>>>>>> Bradley; >>>>>>>>> oauth@ietf.org >>>>>>>>> >>>>>>>>> WG >>>>>>>>> *Subject:* >>>>>>>>> Re: [OAUTH-WG] >>>>>>>>> review >>>>>>>>> comments >>>>>>>>> on >>>>>>>>> draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>> >>>>>>>>> See below. >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>> @independentid >>>>>>>>> >>>>>>>>> www.independentid.com >>>>>>>>> >>>>>>>>> >>>>>>>>> phil.hunt@oracle.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On >>>>>>>>> 2013-05-30, >>>>>>>>> at >>>>>>>>> 2:09 >>>>>>>>> PM, Justin >>>>>>>>> Richer >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> OK, I >>>>>>>>> think >>>>>>>>> see part >>>>>>>>> of >>>>>>>>> the hang >>>>>>>>> up. I >>>>>>>>> have >>>>>>>>> not seen >>>>>>>>> the scenario >>>>>>>>> that >>>>>>>>> you describe, >>>>>>>>> where >>>>>>>>> you trade >>>>>>>>> a >>>>>>>>> 3rd party >>>>>>>>> token >>>>>>>>> for a >>>>>>>>> "local" >>>>>>>>> token. >>>>>>>>> I >>>>>>>>> have >>>>>>>>> seen >>>>>>>>> where >>>>>>>>> access >>>>>>>>> tokens >>>>>>>>> are federated >>>>>>>>> directly >>>>>>>>> at >>>>>>>>> the PR. >>>>>>>>> (Introspection >>>>>>>>> lets >>>>>>>>> you do >>>>>>>>> some >>>>>>>>> good >>>>>>>>> things >>>>>>>>> with >>>>>>>>> that >>>>>>>>> pattern.) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --------------060604070208090309030200 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Then how do they get their equivalent of a registration access token to manage their configurations?

The draft proposes that they get this token right from the registration endpoint. You're proposing that they get this from the token endpoint.

The initial access token isn't even in play here.

�-- Justin

On 06/06/2013 01:49 PM, Phil Hunt wrote:

Huh?

There's no need for public clients to access the token endpoint as they can register anonymously.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:47 AM, Justin Richer wrote:

Because anonymous *registration* and public client *access* to the token endpoint are two different things.

�-- Justin

On 06/06/2013 01:43 PM, Phil Hunt wrote:

*why* will the 6749 standard flows (specifically 4.4) not work?

The registration endpoint can allow anonymous access to permit anonymous registration.

This means the configuration endpoints can use normal access tokens obtained through RFC6749 section 4.4 (Client Auth) flows.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:36 AM, Justin Richer wrote:

... because it already *is* a REST protected API. It's protected with the Registration Access Token. Which is an OAuth 2.0 Bearer token.

The *only* difference is how you get the token, which has nothing to do with the REST protected API that it's protecting.

�-- Justin

On 06/06/2013 01:35 PM, Phil Hunt wrote:

Nobody has explained why using a normal REST protected API won't work. You keep saying that and that you won't go back. �But that doesn't explain the issue.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:28 AM, Justin Richer wrote:

I feel we're still just going in circles with these arguments, but my comments are inline:

On 06/06/2013 01:17 PM, Phil Hunt wrote:

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 9:49 AM, Justin Richer wrote:

Tim, thanks for your review! Comments inline.

On 06/05/2013 04:59 PM, Tim Bray wrote:

FWIW, I just read the spec through with fresh eyes, and I found the explanation of the workflow in 1.4.2 very useful. �

- A developer manually registers and then is able to request �Initial tokens� tokens for a dynamic-app-registration-scope,�

- you use that �Initial token� token to register, in exchange you get the client-id & so on, and also a a per-registration �Registration token� for updating that particular registration information

- you fetch/update/delete your registration information with that registration token.

The first part, where the developer registers & gets a token for a scope, is vanilla OAuth 2. (right?)�

Yes, it can be vanilla Oauth2 or it can be the developer (or someone) getting a token through some other means, like browsing to a developer portal and getting a Bearer token. I've edited the example in 1.4.3 in the latest (unpublished) text so that the developer is literally doing OAuth2 to get the initial token. It's important to note that this could be any flavor of OAuth2 token, though Bearer tokens are of course the most common.

The bit about getting an access token specific to that registration is a new flow (right?), but it seems convenient.

Right, it's a new way to get a bearer token so that you can use it at the protected resource. We wanted to re-use the token endpoint for this, but couldn't come up with a reasonable way of doing so (as has been discussed on the list.

[PH] We still greatly disagree on this.

*Use the normal token issuing process.* �One reason given was what about anonymous clients? �The answer is, they don't have to do anything. Remember that you have defined TWO endpoints. �The "registration endpoint" and the "configuration endpoint". �A server accepting anonymous registration simply accepts anonymous access at the "registration endpoint". �Clients wanting to update their profiles do the normal client token request flow to the token endpoint to obtain a normal access token useable at the "configuration endpoint".

[JR] But then you're opening up the client_credentials flow to anonymous clients, or you've got to be able to lock down client_credentials as a flow to only a special (service-specific) scope for client configuration purposes. This, I think, is much more complicated to implement and much more error prone. I don't think it's even possible in the software stack we're building on top of. And furthermore, you're not letting public clients dynamically register anymore, since you'd be forcing everyone to have a client secret. Your dynamic public clients would have to save the client secret but know to only use it at the registration endpoint, and not the token endpoint where they're used to. This way, it's clear. You get a token that you use at a given endpoint, the end.

As soon as you do this, other things simplify.

1. �No need to keep "registration access token" around indefinitely. It's just an access token. �In fact it is only needed for minutes since it will likely only be used to read or update profiles or to perform client initiated credential rotation.

[JR] You *can* throw away your registration access tokens if you want to, or have them expire, if you want to limit the lifespan of your clients. It's only the security considerations section that suggests against expiring the tokens, and for good reason. But it's your choice to change that if you don't want longstanding read/edit access to a client's configuration.

2. �No need to have a special token issuing method.�Creating a new issuing process suggests that the WG can't drink its own koolaid. �Because at the first seeming challenge, the WG create a new flow. How do we expect implementers to behave?

[JR] That particular koolaid wasn't the right drink here, to stretch your analogy. Bearer tokens were, which is also the group's koolaid. We tried to go down the road you suggest and it was a dead end. Why do you think it will work better this time? And I'd like to point out a decision from several years ago now to separate the notion of "how you get a token" from "how you use a token" in OAuth2. OAuth1 had all of these rolled in together, and deployment experience showed us that people didn't really want to use it that way. People want components that make sense on their own that let you build systems like this that also make sense.

Forced uniformity isn't necessarily a good thing.

3. �The registration/configuration API is JUST a normal OAuth2 protected API.

[JR] It already is. Protected resources don't care where you get your tokens from, just that you have them, so from that perspective it is just a protected resource. Our implementation here literally just looks for the token on the way in in the auth layer and makes sure it's got a special service-specific scope that handles registration.

If the draft drops "registration access tokens", a lot of the text in the draft disappears. �The whole spec is much simpler.

[JR] Much simpler, perhaps, but much less functional and useful. And honestly, not much of the text actually goes away. Most of the draft isn't about dealing with the registration access token, it's about dealing with the client metadata and the RESTful protocol for managing that. The registration access token is a mechanism for doing so.

� From an OAuth 2 point of view, there's nothing special about how you get or use the Initial token, but giving it a special name makes explaining a plausible workflow easier.�

Right, and I've admitted that "Initial Access Token" a crappy name, but I haven't heard a better suggestion yet.

Having said that, I have trouble imagining the scenario where you'd use the 1.4.1 flow, but that may be because of my Google-centric worldview.

Could be -- but if Google wants to be an open-registration identity provider (like it has been with OpenID 2.0), it will need to handle this flow as well. This is the client acting on its own behalf, showing up and saying "hi, I'm a client!" and that's that. I think this is a very important case for interoperability of dynamic registration.

And I�m not sure 1.4.3 adds any value at all. �It just seems to be a matter of different ways you could get and make use of the registration access token; and I'm sure there are various interesting combinations that haven't been thought of there. �I'd just lose 1.4.3.

1.4.3 in -11 is too close to 1.4.2, so what I've done in the current working text is make the initial process of getting the Initial Access Token different (the developer now uses OAuth2 to configure their build environment). The *real* important difference that's being shown here, though, is that the client doesn't call the registration endpoint, the developer (and their build environment) does. So yes, it's exactly all about how you get and use the registration access token. There are plenty of other ways to do it as well, so that's why this section was a non-normative set of examples. To facilitate that understanding, I've moved it to an appendix in the working copy of draft -12.

Thanks,
�-- Justin

�-T

On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin <donald.coffin@reminetworks.com> wrote:

See my comments inline [DFC]

�

Best regards,

Don

Donald F. Coffin

Founder/CTO

�

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA� 92688-3836

�

Phone:�� (949) 636-8571

Email:�� donald.coffin@reminetworks.com

�

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, May 31, 2013 12:40 PM
To: Phil Hunt
Cc: Donald F Coffin; oauth@ietf.org

Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

�

I feel the need to clarify a couple erroneous things in Phil's statement:

� * To be clear, Draft 11 has the same Registration Access Token system that has been in place since draft 01, it is not inventing something new at the last minute as could be inferred from the statement below.

[DFC] �I agree with Justin.� There is nothing new in draft 11 regarding Registration Access Tokens that wasn�t in the initial draft.� It appears because Phil hasn�t been following the proposed drafts until the last call he is now raising an issue no one in the WG saw as an issue.� That�s not to say his point isn�t valid, but the discussion continues to go all over the map between �local� and �federated� tokens, usage of the RFC6749 �Token� endpoint, etc.� It would be great if all of Phil�s points could be addressed in priority
without the threads becoming so convoluted no one is able to make sense or even comprehend the point being discussed.

� * DynReg is using an absolutely standard OAuth 2 Bearer token as the Registration Access Token, it's just not coming from a Token Endpoint. However, since an OAuth Protected Resource doesn't care where its tokens come from so long as it can validate them, I don't see this as a problem -- this is a key point where Phil and I disagree.

[DFC] �I understand the disagreement, but I have not seen a proposal from Phil that would describe the differences between the two perspectives other than to say that the Dynamic Registration should use the Token endpoint defined in RFC6749, which does not�� discuss dynamic registration.� Phil�s point as I understand it is that there should be no difference between an access token used to access resource owner protected data and the registration structure, which I do not agree with.� As I said in the previous
�� response, my users do NOT want to provide implied access to resource owner protected data just because a client is creating a registration with an AS.� This would be the situation if the client credential flow is used to register an application.� Since our
�� implementation does NOT support the implicit flow, that use case is one we have elected NOT to support.

�� [DFC]� I repeat my initial comment, this conversation has been a circular exchange now for the past few days without any appearance of an alternative option to resolve the issues.

�-- Justin

On 05/31/2013 03:33 PM, Phil Hunt wrote:

Don,

�

I am not proposing any change in meaning. If registration acces token issues by normal token server with scope registration everything is clear as it is for any other protected API. Draft 11 invents a whole new system. I strongly disagree with this.

Phil

On 2013-05-31, at 15:16, Donald F Coffin <donald.coffin@reminetworks.com> wrote:

For something that was agreed to be parked a few hours ago, there sure seems to still be a lot of circular discussion.� Should we ask a mediator to intervene?

�

FWIW I believe that is a significantly strong reason to differentiate an access token that can access the registration information without having the ability to access protected data.� Especially given the implied strength of the �client credential� obtained access token.� I have found it extremely confusing to users when explaining the difference between an access token obtained thorough an authorization code flow and a client credential flow, simply because they are both called an �access token�.� Changing the meaning of an access token obtained through the client credential flow to mean it has the ability to update a registration, when a user may not want it to have access to protected data will only increase both the complexity of the access tokens as well as make their usage harder to explain to non-technical individuals who have to understand the differences between the access tokens obtained through the various flows.

�

Just my two cents.

�

Best regards,

Don

Donald F. Coffin

Founder/CTO

�

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA� 92688-3836

�

Phone:�� (949) 636-8571

Email:�� donald.coffin@reminetworks.com

�

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Friday, May 31, 2013 11:11 AM
To: Justin Richer
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

�

To be clear.�

�

It is two separate issues.�

�

1. Anonymous clients can easily be handled through policy config.�

�

2. Support for implicit clients needs to be discussed. The current proposal creates large negative value for the service provider and most would never allow in current form. Yes it gives each execution instance a new id, but that isnt what sp's want. It is a huge attack and management headache. Eliminate or propose a different solution.�

Phil

On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org> wrote:

I'm not willing to write out an entire class of clients from this spec, especially when we have stated use cases for them doing dynamic registration.

I'm sorry, but your proposed solution will simply not work.

�-- Justin

On 05/31/2013 01:56 PM, Phil Hunt wrote:

Well the only client that wouldn't have a credential is an implicit client. An implicit client is transient and so would never update.�

Besides, as i have stated, implicit clients should not use dyn reg.�

Phil

On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org> wrote:

But the outstanding question is: how do you get the access token to access the created resource (IE: the Registration Access Token)? You can't use the client_credentials flow for a client with no credentials!

�-- Justin

On 05/31/2013 12:58 PM, Phil Hunt wrote:

Yes. I specified the trivial solution to anonymous clients earlier.

�

Even simpler. You don't need an access token to create a new resource. You just need one to access one. That is just basic security config.�

Phil

On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org> wrote:

I agree that we are going in circles, since I just was going to bring up my counter argument of "what about clients with no credentials?" again, which *still* isn't addressed by what you suggest doing, below. I also believe that getting rid of the Registration Access Token but using some other token method would actually make the spec larger, though I'd be glad to review a concrete counter-proposal if you'd like to write one. And the fact that OIDC is doing it this way, and considered but rejected the way that you're describing, should say something to the WG here about whether or not this is the right choice. Rough consensus and running code, after all.

Regardless, I agree to park this issue and leave the text as is. We'll move to the next draft in the last call process shortly, as I have a handful of non-normative editorial changes that I need to make, thanks to feedback from a few folks.

Again, thanks for your thorough review, Phil, and I look forward to future feedback.

�-- Justin

On 05/31/2013 12:28 PM, Phil Hunt wrote:

I disagree.�

�

There is absolutely no need for a registration access token.�

�

Get rid of it and just use access tokens as per 6749. If you can't follow 6749 and need new issuing methods, what are others to say regarding inventing new methods?

�

I have not heard a good reason for the special process or one good enough to warrant a new method for issuing an access token. Does the broader group realize this is what the spec says?

�

Yes, i heard a lot saying OIDC does it this way. But that is a political reason, not a technical reason. Still, compatibility is always a strong objective. �Even so, oidc could keep using their method just fine. There is no obligation here to do the same.�

�

The only reason so far was expiry of client creds. Well, why not require the client to update prior to expiry? It makes no sense to have another token with longer expiry. B'sides, even expired the client can re-register from scratch.�

�

Why force the client to persist multiple tokens and creds? That is far far too complex.�

�

Finally if you get rid of registration access token the spec size will drop roughly in half IMO. This suggests simplicity to me.�

�

Apologies for my rant. Maybe we should park this for now. We are going in circles.�

Phil

On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org> wrote:

Phil,

We *can* keep it straight just fine, but I just need you to be clear about which part you're objecting to because the answers are different. Please use the terms as defined in the document so that we all know which component we're talking about. I'm sure you'd agree than in specification work such as this, precision of language and labels is key for communication between parties. This is precisely why there's a Terminology section right up front, so that when I say "Registration Access Token" you can know that I mean a very specific thing, and when I say "Initial Registration Token" I mean a very different specific thing. So I'm asking you, please, use the defined terms so that we can avoid this unnecessary confusion.

But anyway, what you're talking about below, "the token the client uses to update is profile" *IS* the Registration Access Token. That's all that that token is used for. You're not asking for it to go away, you're asking for it to come from the Token Endpoint instead of the response from the Registration Endpoint. I don't see how the client *can* get it from the normal token process without jumping through specialized hoops to make that happen. I've implemented the draft the way that it is right now, both client and server side, and it works. Others have implemented it, too. We've done interop testing, and it works. This is a proven pattern and from where I sit there is both rough consensus and running code.

I believe that I've already pointed out how the solutions you've proposed so far won't work in practice, for various reasons, many of which have already been brought up and discussed previously. If you have another way for the client to get its Registration Access Token, please propose it; but I haven't seen anything yet that will fly.

�-- Justin

On 05/31/2013 11:10 AM, Phil Hunt wrote:

Justin,

�

This is my primary objection! We can't keep it straight. Their should be no such thing as a registrstion access token! �Just the token the client obtains to update its profile through the normal token request process.�

Phil

On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org> wrote:

Which token are you referring to here?

If it's the Initial Registration Token, then you could get that through the normal token server no problem. (The lifecycle writeups don't call this out explicitly but I would be willing to do so.) Or you could get it elsewhere. Doesn't matter, just like it doesn't matter with any other OAuth2 protected resource.

If it's the Registration Access Token, then having the token come from the token endpoint would require a lot more work and complexity on behalf of both of the client and server. Either you end up with public clients getting secrets they shouldn't need or with granting clients access to the client_credentials flow when they shouldn't actually have it. Plus it adds extra round trips which don't buy you anything.

�-- Justin

On 05/31/2013 10:15 AM, Phil Hunt wrote:

The preference is to have the access token for registration issued by the normal token server rather then by the registration endpoint.�

�

In the current draft it is obtained through a unique process and must outlive the client.�

Phil

On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org> wrote:

I don't understand any of the comments below -- it already *is* an OAuth2 protected resource without any special handling. Your access tokens can be short-lived, long-lived, federated, structured, random blobs ... totally doesn't matter. They are access tokens being used to access a normal protected resource. Full stop.

Anything else is out of scope. The lifecycle discussions at the beginning are merely examples of some ways you *could* use it and are non-normative and non-exhaustive.

You seem to be asking for something that's already in the draft.

�-- Justin

From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 7:31 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

Phil

On 2013-05-30, at 16:11, "Richer, Justin P." <jricher@mitre.org> wrote:

Comments inline, marked by [JR].

From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 5:25 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

See below.

Phil

�

@independentid

www.independentid.com

phil.hunt@oracle.com

�

�

�

On 2013-05-30, at 2:09 PM, Justin Richer wrote:

OK, I think see part of the hang up. I have not seen the scenario that you describe, where you trade a 3rd party token for a "local" token. I have seen where access tokens are federated directly at the PR. (Introspection lets you do some good things with that pattern.)

�

�

�

�

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

--------------060604070208090309030200-- From phil.hunt@oracle.com Thu Jun 6 10:51:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2876321F9B12 for ; Thu, 6 Jun 2013 10:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REzSupeIt-Hr for ; Thu, 6 Jun 2013 10:50:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id AD09E21F9B07 for ; Thu, 6 Jun 2013 10:50:54 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r56HorPA002611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Jun 2013 17:50:54 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r56HoqaR002961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 17:50:52 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r56HoqDe000723; Thu, 6 Jun 2013 17:50:52 GMT Received: from [192.168.1.89] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Jun 2013 10:50:51 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_1EACAAF5-D501-4C39-9D78-9B3AEB438B6E" From: Phil Hunt In-Reply-To: <51B0CB6D.7060004@mitre.org> Date: Thu, 6 Jun 2013 10:50:48 -0700 Message-Id: References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <255B9BB34FB7D647A506DC292726F6E1151B105DA5@WSMSG3153V.srv.dir.telstra.com> <1373E8CE237FCC43BCA36C6558612D2A9F26D0@USCHMBX001.nsn-intra.net> <919FB49B-2705-42E4-B5C3-B433C3F81C7F@ve7jtb.com> <9209089C-5B60-4212-88EA-376855DBCEA0@oracle.com> <51B0C14D.5020306@mitre.org> <1CCDB2B8-CAD9-4827-8113-F92537F70375@oracle.com> <51B0C8CE.6070309@!> <51B0CB6D.7060! 004@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:51:07 -0000 --Apple-Mail=_1EACAAF5-D501-4C39-9D78-9B3AEB438B6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We have two separate discussions going on. 8-) Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-06-06, at 10:48 AM, Justin Richer wrote: > I thought we were talking about the registration access token, not the = initial access token? >=20 > -- Justin >=20 > On 06/06/2013 01:48 PM, Phil Hunt wrote: >> This is why this to-MAY-to vs. to-MAH-to distinction around is the = initial access token an authorization token is important. >>=20 >> The purpose for the initial access token is dramatically different = then normal access tokens. This is for "registration" and does not = constitute authentication or authorization. >>=20 >> Therefore, in this case, I do not believe that defining access tokens = in the broader sense makes this issue clearer. >>=20 >> Registration is a very specific process different than authorization. >>=20 >> This might be a good paper to look at so the group understands why I = am differentiating authorization from what is happening with initial = access: >> http://tools.ietf.org/html/draft-hallambaker-httpauth-00 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-06-06, at 10:37 AM, Justin Richer wrote: >>=20 >>> Interoperability of the processing of OAuth tokens is a separate = issue that needs to be solved not just for registration. When it is = solved in the wider case, Registration as-is will inherit the solution. >>>=20 >>> So today, if you're using an Initial Access Token (which is = optional), then you're locked to whatever process you want to use to = verify/validate that token. Since it's just an OAuth token, you've got a = number of things that you can do (assertions, introspection, magic). >>>=20 >>> I'd rather we solve the *real* cross-domain issue in the wider case = than just try to cram something into registration. >>>=20 >>> -- Justin >>>=20 >>> On 06/06/2013 01:33 PM, Phil Hunt wrote: >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-06-06, at 10:05 AM, Justin Richer wrote: >>>>=20 >>>>>=20 >>>>> On 06/06/2013 11:20 AM, Phil Hunt wrote: >>>>>> As I've said before the initial auth token should nothing to do = with auth. It is simply an assertion given to the developer to = distribute in order to pass on signed claims about the software.=20 >>>>>=20 >>>>> Phil, as I and several others have explained previously, that's = not true at all. It's a token that gives authorization to the = registration endpoint. The fact that you can use it as an assertion to = pass along signed claims is an artifact of it being an OAuth token and = an OAuth token is an opaque string. Please read through the dynamic = registration draft again -- it says absolutely nothing about assertions, = signatures, or claims with regard to this token. >>>> It depends which case you are using. If the developer is talking = to a single deployment domain and obtains an initial access token and = then ships it with all clients, then sure. In this scenario, the = contents are totally controlled by the local domain. >>>>=20 >>>> I agree. In this case, you don't care about inter-op. The whole = environment is siloed. But then, if this is your case, I'm not sure why = this draft is at the IETF. >>>>=20 >>>> The interoperability case is where a third party generates that = assertion and the deployment domain has to decide to accept it. So you = are a developer and you want to build a client for a Microsoft or Oracle = app. You want to be able to ship that to your customers. You register = with the appropriate publisher and they give you a signed assertion that = can be used as the "Initial Access Token". This token is then = accepted by the deployment domain and then it decides if it trusts the = signer or not. >>>>=20 >>>> =3D=3D=3D> For this to work, the contents and format of that token = MUST be defined. Otherwise how could we ensure a Microsoft signed = assertion would be accepted by a PingIdentity OAuth server? Or any = other combination of implementations from different vendors/communities? >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Bearer or not bearer is a distraction. The fact that the contents = and format of this token is out of scope leaves a HUGE interop gap.=20 >>>>>=20 >>>>> The fact that some of us (myself included) are *using* this token = to carry this kind of information is out of scope for the basic = registration spec. I completely agree that there's value in defining = this stuff, but as a separate and complementary spec from registration. >>>>=20 >>>> [PH] I was reacting to John Bradley's assertion that the spec was = narrowly defined with interop in mind. Yet this mechanism is a key = factor being used to share information about the software. >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Finally never-mind bearer bias, how are client credentials = rotated interoperably if the only thing rotated is client_secret? >>>>>=20 >>>>> *any* parameter on the client, including the = registration_access_token and any extension parameters, can be rotated = on any call to the Read or Update methods (except for client_id). So if = you've got another mechanism for doing client authentication, you can = rotate that, too. >>>>>=20 >>>>>>=20 >>>>>> I would say the spec only works for client secrets and/or = all-in-one domain where there is no interop.=20 >>>>>=20 >>>>> Considering I've personally used it across domains and without = client secrets (using jwks_uri to register public keys), I have to = empirically disagree with that statement. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> On 2013-06-06, at 1:53, John Bradley wrote: >>>>>>=20 >>>>>>> There are a couple of reasons. =20 >>>>>>>=20 >>>>>>> One criticism Hannes and others make of OAuth specs is they are = not tightly profiled enough to be interoperable without further out of = band configuration and profiling. >>>>>>>=20 >>>>>>> Making registration work with minimal ambiguity was a priority = for Connect and that has carried over. >>>>>>>=20 >>>>>>> I am not opposed to having this extended at some point in the = future, once we have a second token type. The new token type should be = available to do updates as well. >>>>>>>=20 >>>>>>> The problem is that starting down the HoK route potentially = requires a registered client that may need to be registered to do the = registration. =20 >>>>>>> I think that is best left to another spec to sort out the = possible turtles. >>>>>>>=20 >>>>>>> So the default needs to be bearer tokens unless registration is = extended by another profile. >>>>>>>=20 >>>>>>> John B. >>>>>>> On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - = FI/Espoo)" wrote: >>>>>>>=20 >>>>>>>> Because bearer tokens have a stable RFC-numbered spec and are = widely implemented and the registration flow as documented seems like it = should work? -T >>>>>>>> =20 >>>>>>>> That=92s the answer for why there is support for bearer tokens = but it is not the answer to why that=92s the only supported mechanism. >>>>>>>> If we want to support stronger security mechanisms (which the = group has decided to work on already) then we need to have a story on = how to support the other mechanisms as well . >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_1EACAAF5-D501-4C39-9D78-9B3AEB438B6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 We = have two separate discussions going on. 8-)

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2013-06-06, at 10:48 AM, Justin Richer wrote:

=20 =20
I thought we were talking about the registration access token, not the initial access token?

-- Justin

On 06/06/2013 01:48 PM, Phil Hunt wrote:

This is why this to-MAY-to vs. to-MAH-to distinction around is the initial access token an authorization token is important.

The purpose for the initial access token is dramatically different then normal access tokens. This is for = "registration" and does not constitute authentication or authorization.

Therefore, in this case, I do not believe that defining access tokens in the broader sense makes this issue = clearer.

Registration is a very specific process different than authorization.

This might be a good paper to look at so the group understands why I am differentiating authorization from what is happening with initial access:

http://t= ools.ietf.org/html/draft-hallambaker-httpauth-00

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:37 AM, Justin Richer wrote:

Interoperability = of the processing of OAuth tokens is a separate issue that needs to be solved not just for registration. When it is solved in the wider case, Registration as-is will inherit the solution.

So today, if you're using an Initial Access Token (which is optional), then you're locked to whatever process you want to use to verify/validate that token. Since it's just an OAuth token, you've got a number of things that you can do (assertions, introspection, magic).

I'd rather we solve the *real* cross-domain issue in the wider case than just try to cram something into registration.

-- Justin

On 06/06/2013 01:33 PM, = Phil Hunt wrote:

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:05 AM, Justin Richer = wrote:

On 06/06/2013 11:20 AM, Phil Hunt wrote:

As I've said before the initial auth token should nothing to do with auth. It is simply an assertion given to the developer to distribute in order to pass on signed claims about the software.

Phil, as I and several others have explained previously, that's not true at all. It's a token that gives authorization to the registration endpoint. The fact that you can use it as an assertion to pass along signed claims is an artifact of it being an OAuth token and an OAuth token is an opaque string. Please read through the dynamic registration draft again -- it says absolutely nothing about assertions, signatures, or claims with regard to this token.

It depends which case you are using. If the developer is talking to a single deployment domain and obtains an initial access token and then ships it with all clients, then sure. In this = scenario, the contents are totally controlled by the local domain.

I agree. In this case, you don't care about inter-op. The whole environment is siloed. But then, if this is your case, I'm not sure why this draft is at the IETF.

The interoperability case is where a third party generates that assertion and the deployment domain has to decide to accept it. So you are a = developer and you want to build a client for a Microsoft or Oracle app. You want to be able to ship that = to your customers. You register with the appropriate publisher and they give you a signed assertion that can be used as the "Initial Access Token". = This token is then accepted by the deployment domain and then it decides if it trusts the signer or = not.

=3D=3D=3D> For this to work, the contents and = format of that token MUST be defined. Otherwise how = could we ensure a Microsoft signed assertion would be accepted by a PingIdentity OAuth server? Or = any other combination of implementations from different vendors/communities?

Bearer or not bearer is a distraction. The fact that the contents and format of this token is out of scope leaves a HUGE interop gap.

The fact that some of us (myself included) are *using* this token to carry this kind of information is out of scope for the basic registration spec. I completely agree that there's value in defining this stuff, but as a separate and complementary spec from registration.

[PH] I was reacting to John Bradley's assertion that the spec was narrowly defined with interop in mind. Yet this mechanism is a key factor being used to share information about the software.

Finally never-mind bearer bias, how are client credentials rotated interoperably = if the only thing rotated is client_secret?

*any* parameter on the client, including the registration_access_token and any extension parameters, can be rotated on any call to the Read or Update methods (except for client_id). So if you've got another mechanism for doing client authentication, you can rotate that, too.

I would say the spec only works for client secrets and/or all-in-one domain where there is no interop.

Considering I've personally used it across domains and without client secrets (using jwks_uri to register public keys), I have to empirically disagree with that statement.

-- Justin

Phil

On 2013-06-06, at 1:53, John Bradley <ve7jtb@ve7jtb.com> wrote:

There are a couple of reasons.

One criticism Hannes and others make of OAuth specs is they are not tightly profiled enough to be interoperable without further out of band configuration and profiling.

Making registration work with minimal ambiguity was a priority for Connect and that has carried over.

I am not opposed to having this extended at some point in the future, once we have a second token type. The = new token type should be available to do updates as well.

The problem is that starting down the HoK route potentially requires a registered client that may need to be registered to do the registration. =

I think that is best left to another spec to sort out the possible = turtles.

So the default needs to be bearer tokens unless registration is extended by another profile.

John B.

On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>= ; wrote:

Because bearer tokens have a stable RFC-numbered spec and are widely implemented and the registration flow as documented seems like it should work? = -T

That=92s the answer for why there is support for bearer tokens but it is not the answer to why that=92s the only supported = mechanism.

If we want to support stronger security mechanisms (which the group has decided to work on already) then we need to have a story on how to support the other mechanisms as well = .

=
_______________________________________________
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

= --Apple-Mail=_1EACAAF5-D501-4C39-9D78-9B3AEB438B6E-- From phil.hunt@oracle.com Thu Jun 6 10:52:12 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43CF21F9AEF for ; Thu, 6 Jun 2013 10:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTiTOGxO6Cmb for ; Thu, 6 Jun 2013 10:52:07 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A6A3821F9A11 for ; Thu, 6 Jun 2013 10:52:06 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r56Hq1D1031760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Jun 2013 17:52:02 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r56Hq2Ob005457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 17:52:03 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r56Hq1sF005428; Thu, 6 Jun 2013 17:52:02 GMT Received: from [192.168.1.89] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Jun 2013 10:51:58 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_7CFFDC03-024E-4A1A-AF65-0F713B73DD8B" From: Phil Hunt In-Reply-To: <51B0CBC5.5090509@mitre.org> Date: Thu, 6 Jun 2013 10:51:56 -0700 Message-Id: <0314A5D5-A6B1-4D05-B348-AC17AA30F61B@oracle.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <18C751E2-31B2-4C7F-BC9A-49F382F96673@oracle.com> <77A0DA5E-09CE-4A5E-9500-54A0842252FB@oracle.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <51B0BDA2.7010705@mitre.org> <7B00614C-6B25-4951-B004-C17932432D17@oracle.com> <51B0C6D4.804000!> <9@mitre.org> <51B0C8A0.2020306@mitre.org> <51B0CB18.50! 90003@mitre.org> <51B0CBC5.5090509@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Donald F Coffin , "oauth@ietf.org" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:52:12 -0000 --Apple-Mail=_7CFFDC03-024E-4A1A-AF65-0F713B73DD8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 When they are issued their client credential after successfully = registering=85.isn't that the whole point of the process? Once they register, they are no longer public. After that, they just = get a token like everyone else. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-06-06, at 10:49 AM, Justin Richer wrote: > Then how do they get their equivalent of a registration access token = to manage their configurations?=20 >=20 > The draft proposes that they get this token right from the = registration endpoint. You're proposing that they get this from the = token endpoint. >=20 > The initial access token isn't even in play here. >=20 > -- Justin >=20 > On 06/06/2013 01:49 PM, Phil Hunt wrote: >> Huh? >>=20 >> There's no need for public clients to access the token endpoint as = they can register anonymously. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-06-06, at 10:47 AM, Justin Richer wrote: >>=20 >>> Because anonymous *registration* and public client *access* to the = token endpoint are two different things. >>>=20 >>> -- Justin >>>=20 >>> On 06/06/2013 01:43 PM, Phil Hunt wrote: >>>> *why* will the 6749 standard flows (specifically 4.4) not work? >>>>=20 >>>> The registration endpoint can allow anonymous access to permit = anonymous registration. >>>>=20 >>>> This means the configuration endpoints can use normal access tokens = obtained through RFC6749 section 4.4 (Client Auth) flows. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-06-06, at 10:36 AM, Justin Richer wrote: >>>>=20 >>>>> ... because it already *is* a REST protected API. It's protected = with the Registration Access Token. Which is an OAuth 2.0 Bearer token.=20= >>>>>=20 >>>>> The *only* difference is how you get the token, which has nothing = to do with the REST protected API that it's protecting. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On 06/06/2013 01:35 PM, Phil Hunt wrote: >>>>>> Nobody has explained why using a normal REST protected API won't = work. You keep saying that and that you won't go back. But that doesn't = explain the issue. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-06-06, at 10:28 AM, Justin Richer wrote: >>>>>>=20 >>>>>>> I feel we're still just going in circles with these arguments, = but my comments are inline: >>>>>>>=20 >>>>>>> On 06/06/2013 01:17 PM, Phil Hunt wrote: >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-06-06, at 9:49 AM, Justin Richer wrote: >>>>>>>>=20 >>>>>>>>> Tim, thanks for your review! Comments inline. >>>>>>>>>=20 >>>>>>>>> On 06/05/2013 04:59 PM, Tim Bray wrote: >>>>>>>>>> FWIW, I just read the spec through with fresh eyes, and I = found the explanation of the workflow in 1.4.2 very useful. =20 >>>>>>>>>>=20 >>>>>>>>>> - A developer manually registers and then is able to request = =93Initial tokens=94 tokens for a dynamic-app-registration-scope,=20 >>>>>>>>>> - you use that =93Initial token=94 token to register, in = exchange you get the client-id & so on, and also a a per-registration = =93Registration token=94 for updating that particular registration = information >>>>>>>>>> - you fetch/update/delete your registration information with = that registration token. >>>>>>>>>>=20 >>>>>>>>>> The first part, where the developer registers & gets a token = for a scope, is vanilla OAuth 2. (right?) =20 >>>>>>>>>=20 >>>>>>>>> Yes, it can be vanilla Oauth2 or it can be the developer (or = someone) getting a token through some other means, like browsing to a = developer portal and getting a Bearer token. I've edited the example in = 1.4.3 in the latest (unpublished) text so that the developer is = literally doing OAuth2 to get the initial token. It's important to note = that this could be any flavor of OAuth2 token, though Bearer tokens are = of course the most common. >>>>>>>>>=20 >>>>>>>>>> The bit about getting an access token specific to that = registration is a new flow (right?), but it seems convenient. >>>>>>>>>=20 >>>>>>>>> Right, it's a new way to get a bearer token so that you can = use it at the protected resource. We wanted to re-use the token endpoint = for this, but couldn't come up with a reasonable way of doing so (as has = been discussed on the list. >>>>>>>>=20 >>>>>>>> [PH] We still greatly disagree on this. >>>>>>>>=20 >>>>>>>> *Use the normal token issuing process.* One reason given was = what about anonymous clients? The answer is, they don't have to do = anything. Remember that you have defined TWO endpoints. The = "registration endpoint" and the "configuration endpoint". A server = accepting anonymous registration simply accepts anonymous access at the = "registration endpoint". Clients wanting to update their profiles do = the normal client token request flow to the token endpoint to obtain a = normal access token useable at the "configuration endpoint". >>>>>>>>=20 >>>>>>>=20 >>>>>>> [JR] But then you're opening up the client_credentials flow to = anonymous clients, or you've got to be able to lock down = client_credentials as a flow to only a special (service-specific) scope = for client configuration purposes. This, I think, is much more = complicated to implement and much more error prone. I don't think it's = even possible in the software stack we're building on top of. And = furthermore, you're not letting public clients dynamically register = anymore, since you'd be forcing everyone to have a client secret. Your = dynamic public clients would have to save the client secret but know to = only use it at the registration endpoint, and not the token endpoint = where they're used to. This way, it's clear. You get a token that you = use at a given endpoint, the end. >>>>>>>=20 >>>>>>>> As soon as you do this, other things simplify. >>>>>>>>=20 >>>>>>>> 1. No need to keep "registration access token" around = indefinitely. It's just an access token. In fact it is only needed for = minutes since it will likely only be used to read or update profiles or = to perform client initiated credential rotation. >>>>>>>=20 >>>>>>> [JR] You *can* throw away your registration access tokens if you = want to, or have them expire, if you want to limit the lifespan of your = clients. It's only the security considerations section that suggests = against expiring the tokens, and for good reason. But it's your choice = to change that if you don't want longstanding read/edit access to a = client's configuration. >>>>>>>=20 >>>>>>>> 2. No need to have a special token issuing method. Creating a = new issuing process suggests that the WG can't drink its own koolaid. = Because at the first seeming challenge, the WG create a new flow. How do = we expect implementers to behave? >>>>>>>=20 >>>>>>> [JR] That particular koolaid wasn't the right drink here, to = stretch your analogy. Bearer tokens were, which is also the group's = koolaid. We tried to go down the road you suggest and it was a dead end. = Why do you think it will work better this time? And I'd like to point = out a decision from several years ago now to separate the notion of "how = you get a token" from "how you use a token" in OAuth2. OAuth1 had all of = these rolled in together, and deployment experience showed us that = people didn't really want to use it that way. People want components = that make sense on their own that let you build systems like this that = also make sense. >>>>>>>=20 >>>>>>> Forced uniformity isn't necessarily a good thing. >>>>>>>=20 >>>>>>>> 3. The registration/configuration API is JUST a normal OAuth2 = protected API. >>>>>>>=20 >>>>>>> [JR] It already is. Protected resources don't care where you get = your tokens from, just that you have them, so from that perspective it = is just a protected resource. Our implementation here literally just = looks for the token on the way in in the auth layer and makes sure it's = got a special service-specific = scope that handles registration.=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> If the draft drops "registration access tokens", a lot of the = text in the draft disappears. The whole spec is much simpler. >>>>>>>=20 >>>>>>> [JR] Much simpler, perhaps, but much less functional and useful. = And honestly, not much of the text actually goes away. Most of the draft = isn't about dealing with the registration access token, it's about = dealing with the client metadata and the RESTful protocol for managing = that. The registration access token is a mechanism for doing so. >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> =46rom an OAuth 2 point of view, there's nothing special = about how you get or use the Initial token, but giving it a special name = makes explaining a plausible workflow easier. =20 >>>>>>>>>=20 >>>>>>>>> Right, and I've admitted that "Initial Access Token" a crappy = name, but I haven't heard a better suggestion yet.=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Having said that, I have trouble imagining the scenario where = you'd use the 1.4.1 flow, but that may be because of my Google-centric = worldview.=20 >>>>>>>>>=20 >>>>>>>>> Could be -- but if Google wants to be an open-registration = identity provider (like it has been with OpenID 2.0), it will need to = handle this flow as well. This is the client acting on its own behalf, = showing up and saying "hi, I'm a client!" and that's that. I think this = is a very important case for interoperability of dynamic registration. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> And I=92m not sure 1.4.3 adds any value at all. It just = seems to be a matter of different ways you could get and make use of the = registration access token; and I'm sure there are various interesting = combinations that haven't been thought of there. I'd just lose 1.4.3. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 1.4.3 in -11 is too close to 1.4.2, so what I've done in the = current working text is make the initial process of getting the Initial = Access Token different (the developer now uses OAuth2 to configure their = build environment). The *real* important difference that's being shown = here, though, is that the client doesn't call the registration endpoint, = the developer (and their build environment) does. So yes, it's exactly = all about how you get and use the registration access token. There are = plenty of other ways to do it as well, so that's why this section was a = non-normative set of examples. To facilitate that understanding, I've = moved it to an appendix in the working copy of draft -12. >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> -- Justin >>>>>>>>>=20 >>>>>>>>>> -T >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin = wrote: >>>>>>>>>> See my comments inline [DFC] >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Best regards, >>>>>>>>>>=20 >>>>>>>>>> Don >>>>>>>>>>=20 >>>>>>>>>> Donald F. Coffin >>>>>>>>>>=20 >>>>>>>>>> Founder/CTO >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> REMI Networks >>>>>>>>>>=20 >>>>>>>>>> 22751 El Prado Suite 6216 >>>>>>>>>>=20 >>>>>>>>>> Rancho Santa Margarita, CA 92688-3836 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Phone: (949) 636-8571 >>>>>>>>>>=20 >>>>>>>>>> Email: donald.coffin@reminetworks.com >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> From: Justin Richer [mailto:jricher@mitre.org]=20 >>>>>>>>>> Sent: Friday, May 31, 2013 12:40 PM >>>>>>>>>> To: Phil Hunt >>>>>>>>>> Cc: Donald F Coffin; oauth@ietf.org >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>>> =20 >>>>>>>>>> I feel the need to clarify a couple erroneous things in = Phil's statement: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> * To be clear, Draft 11 has the same Registration Access = Token system that has been in place since draft 01, it is not inventing = something new at the last minute as could be inferred from the statement = below. >>>>>>>>>> [DFC] I agree with Justin. There is nothing new in draft 11 = regarding Registration Access Tokens that wasn=92t in the initial draft. = It appears because Phil hasn=92t been following the proposed drafts = until the last call he is now raising an issue no one in the WG saw as = an issue. That=92s not to say his point isn=92t valid, but the = discussion continues to go all over = the map between =93local=94 and =93federated=94 = tokens, usage of the RFC6749 =93Token=94 endpoint, etc. It would be = great if all of Phil=92s points could be addressed in priority >>>>>>>>>> without the threads becoming so convoluted no one is able to = make sense or even comprehend the point being discussed. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> * DynReg is using an absolutely standard OAuth 2 Bearer = token as the Registration Access Token, it's just not coming from a = Token Endpoint. However, since an OAuth Protected Resource doesn't care = where its tokens come from so long as it can validate them, I don't see = this as a problem -- this is a key point where Phil and I disagree. >>>>>>>>>>=20 >>>>>>>>>> [DFC] I understand the disagreement, but I have not seen a = proposal from Phil that would describe the differences between the two = perspectives other than to say that the Dynamic Registration should use = the Token endpoint defined in RFC6749, which = does not discuss dynamic registration. = Phil=92s point as I understand it is that there should be no difference = between an access token used to access resource owner protected data and = the registration structure, which I do not agree with. As I said in the = previous >>>>>>>>>> response, my users do NOT want to provide implied = access to resource owner protected data just because a client is = creating a registration with an AS. This would be the situation if the = client credential flow is used to register an application. Since our >>>>>>>>>> implementation does NOT support the implicit = flow, that use case is one we have elected NOT to support. >>>>>>>>>>=20 >>>>>>>>>> [DFC] I repeat my initial comment, this = conversation has been a circular exchange now for the past few days = without any appearance of an alternative option to resolve the issues. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- Justin >>>>>>>>>>=20 >>>>>>>>>> On 05/31/2013 03:33 PM, Phil Hunt wrote: >>>>>>>>>>=20 >>>>>>>>>> Don, >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> I am not proposing any change in meaning. If registration = acces token issues by normal token server with scope registration = everything is clear as it is for any other protected API. Draft 11 = invents a whole new system. I strongly disagree with this. >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-05-31, at 15:16, Donald F Coffin = wrote: >>>>>>>>>>=20 >>>>>>>>>> For something that was agreed to be parked a few hours ago, = there sure seems to still be a lot of circular discussion. Should we = ask a mediator to intervene? >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> FWIW I believe that is a significantly strong reason to = differentiate an access token that can access the registration = information without having the ability to access protected data. = Especially given the implied strength of the =93client credential=94 = obtained access token. I have found it extremely confusing to users = when explaining the difference between an access token obtained thorough = an authorization code flow and a client credential flow, simply because = they are both called an =93access token=94. Changing the meaning of an = access token obtained through the client credential flow to mean it has = the ability to update a registration, when a user may not want it to = have access to protected data will only increase both the complexity of = the access tokens as well as make their usage harder to explain to = non-technical individuals who have to understand the differences between = the access tokens obtained through the various flows. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Just my two cents. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Best regards, >>>>>>>>>>=20 >>>>>>>>>> Don >>>>>>>>>>=20 >>>>>>>>>> Donald F. Coffin >>>>>>>>>>=20 >>>>>>>>>> Founder/CTO >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> REMI Networks >>>>>>>>>>=20 >>>>>>>>>> 22751 El Prado Suite 6216 >>>>>>>>>>=20 >>>>>>>>>> Rancho Santa Margarita, CA 92688-3836 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Phone: (949) 636-8571 >>>>>>>>>>=20 >>>>>>>>>> Email: donald.coffin@reminetworks.com >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 >>>>>>>>>> Sent: Friday, May 31, 2013 11:11 AM >>>>>>>>>> To: Justin Richer >>>>>>>>>> Cc: oauth@ietf.org WG >>>>>>>>>> Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> To be clear.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> It is two separate issues.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> 1. Anonymous clients can easily be handled through policy = config.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> 2. Support for implicit clients needs to be discussed. The = current proposal creates large negative value for the service provider = and most would never allow in current form. Yes it gives each execution = instance a new = id, but that isnt what sp's want. It is a huge attack and management = headache. Eliminate or propose a different solution.=20 >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-05-31, at 13:58, Justin Richer = wrote: >>>>>>>>>>=20 >>>>>>>>>> I'm not willing to write out an entire class of clients from = this spec, especially when we have stated use cases for them doing = dynamic registration. >>>>>>>>>>=20 >>>>>>>>>> I'm sorry, but your proposed solution will simply not work. >>>>>>>>>>=20 >>>>>>>>>> -- Justin >>>>>>>>>>=20 >>>>>>>>>> On 05/31/2013 01:56 PM, Phil Hunt wrote: >>>>>>>>>>=20 >>>>>>>>>> Well the only client that wouldn't have a credential is an = implicit client. An implicit client is transient and so would never = update.=20 >>>>>>>>>>=20 >>>>>>>>>> Besides, as i have stated, implicit clients should not use = dyn reg.=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-05-31, at 13:41, Justin Richer = wrote: >>>>>>>>>>=20 >>>>>>>>>> But the outstanding question is: how do you get the access = token to access the created resource (IE: the Registration Access = Token)? You can't use the client_credentials flow for a client with no = credentials! >>>>>>>>>>=20 >>>>>>>>>> -- Justin >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 05/31/2013 12:58 PM, Phil Hunt wrote: >>>>>>>>>>=20 >>>>>>>>>> Yes. I specified the trivial solution to anonymous clients = earlier. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Even simpler. You don't need an access token to create a new = resource. You just need one to access one. That is just basic security = config.=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-05-31, at 12:34, Justin Richer = wrote: >>>>>>>>>>=20 >>>>>>>>>> I agree that we are going in circles, since I just was going = to bring up my counter argument of "what about clients with no = credentials?" again, which *still* isn't addressed by what you suggest = doing, below. I also believe that getting rid of the Registration Access = Token but using some other token = method would actually make the spec larger, though I'd = be glad to review a concrete counter-proposal if you'd like to write = one. And the fact that OIDC is doing it this way, and considered but = rejected the way that you're describing, should say something to the WG = here about whether or not this is the right choice. Rough consensus and = running code, after all. >>>>>>>>>>=20 >>>>>>>>>> Regardless, I agree to park = this issue and leave the text = as is. We'll move to the next = draft in the last call process = shortly, as I have a handful of non-normative editorial = changes that I need to make, thanks to feedback from a few folks. >>>>>>>>>>=20 >>>>>>>>>> Again, thanks for your thorough review, Phil, and I look = forward to future feedback. >>>>>>>>>>=20 >>>>>>>>>> -- Justin >>>>>>>>>>=20 >>>>>>>>>> On 05/31/2013 12:28 PM, Phil Hunt wrote: >>>>>>>>>>=20 >>>>>>>>>> I disagree.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> There is absolutely no need for a = registration access token.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Get rid of it and just use access tokens as per 6749. If you = can't follow 6749 and need new issuing methods, what are others to say = regarding inventing new methods? >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> I have not heard a good reason = for the special process or one good enough to = warrant a new method for issuing an access token. Does the broader group = realize this is what the spec says? >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Yes, i heard a lot saying OIDC does it this way. But that is = a political reason, not a = technical reason. Still, = compatibility = is always a strong objective. Even so, oidc could = keep using their method just fine. There is no obligation here to do the = same.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> The only reason so far was expiry of client creds. Well, why = not require = the client to update prior to expiry? It makes no sense to have another = token with longer expiry. B'sides, even = expired the client can re-register from = scratch.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Why force the client to persist multiple tokens and creds? = That is far far too complex.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Finally if you get rid of registration access token = the spec size = will drop roughly in half = IMO. This suggests simplicity to me.=20 >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> Apologies for my rant. Maybe we should park this for now. We = are going in circles.=20 >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-05-31, at 11:25, = Justin Richer = wrote: >>>>>>>>>>=20 >>>>>>>>>> Phil, >>>>>>>>>>=20 >>>>>>>>>> We *can* keep it straight just fine, but I just need you to = be clear about which part you're objecting to because the answers are = different. Please use the terms as defined in the document so that we = all know which component we're talking about. I'm sure you'd agree than = in specification work such as this, precision of language and labels is = key for communication between parties. This is precisely why there's a = Terminology section right up front, so that when I say "Registration = Access Token" you can know that I mean a very specific thing, and when I = say "Initial Registration Token" I mean a very different specific thing. = So I'm asking you, please, use the defined terms so that we can avoid = this unnecessary confusion. >>>>>>>>>>=20 >>>>>>>>>> But anyway, what you're talking about below, "the token the = client uses to update is profile" *IS* the Registration Access Token. = That's all that that token is used for. You're not asking for it to go = away, you're asking for it to come from the Token Endpoint instead of = the response from the Registration Endpoint. I don't see how the client = *can* get it from the normal token process without jumping through = specialized hoops to make that happen. I've implemented the draft the = way that it is right now, both client and server side, and it works. = Others have implemented it, too. We've done interop testing, and it = works. This is a proven pattern and from where I sit there is both rough = consensus and running code. >>>>>>>>>>=20 >>>>>>>>>> I believe that I've already pointed out how the solutions = you've proposed so far won't work in practice, for various reasons, many = of which have already been brought up and discussed previously. If you = have another way for the client to get its Registration Access Token, = please propose it; but I haven't seen anything yet that will fly. >>>>>>>>>>=20 >>>>>>>>>> -- Justin >>>>>>>>>>=20 >>>>>>>>>> On 05/31/2013 11:10 AM, Phil Hunt wrote: >>>>>>>>>>=20 >>>>>>>>>> Justin, >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> This is my primary objection! We can't keep it straight. = Their should be no such thing as a registrstion access token! Just the = token the client obtains to update its profile through the normal token = request process. >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-05-31, at 10:55, Justin Richer = wrote: >>>>>>>>>>=20 >>>>>>>>>> Which token are you referring to here? >>>>>>>>>>=20 >>>>>>>>>> If it's the Initial Registration Token, then you could get = that through the normal token server no problem. (The lifecycle writeups = don't call this out explicitly but I would be willing to do so.) Or you = could get it elsewhere. Doesn't matter, just like it doesn't matter with = any other OAuth2 protected resource. >>>>>>>>>>=20 >>>>>>>>>> If it's the Registration Access Token, then having the token = come from the token endpoint would require a lot more work and = complexity on behalf of both of the client and server. Either you end up = with public clients getting secrets they shouldn't need or with granting = clients access to the client_credentials flow when they shouldn't = actually have it. Plus it adds extra round trips which don't buy you = anything. >>>>>>>>>>=20 >>>>>>>>>> -- Justin >>>>>>>>>>=20 >>>>>>>>>> On 05/31/2013 10:15 AM, Phil Hunt wrote: >>>>>>>>>>=20 >>>>>>>>>> The preference is to have the access token for registration = issued by the normal token server rather then by the registration = endpoint. >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> In the current draft it is obtained through a unique process = and must outlive the client. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-05-30, at 19:47, "Richer, Justin P." = wrote: >>>>>>>>>>=20 >>>>>>>>>> I don't understand any of the comments below -- it already = *is* an OAuth2 protected resource without any special handling. Your = access tokens can be short-lived, long-lived, federated, structured, = random blobs ... totally doesn't matter. They are access tokens being = used to access a normal protected resource. Full stop. >>>>>>>>>>=20 >>>>>>>>>> Anything else is out of scope. The lifecycle discussions at = the beginning are merely examples of some ways you *could* use it and = are non-normative and non-exhaustive. >>>>>>>>>>=20 >>>>>>>>>> You seem to be asking for something that's already in the = draft. >>>>>>>>>>=20 >>>>>>>>>> -- Justin >>>>>>>>>>=20 >>>>>>>>>> From: Phil Hunt [phil.hunt@oracle.com] >>>>>>>>>> Sent: Thursday, May 30, 2013 7:31 PM >>>>>>>>>> To: Richer, Justin P. >>>>>>>>>> Cc: John Bradley; oauth@ietf.org WG >>>>>>>>>> Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-05-30, at 16:11, "Richer, Justin P." = wrote: >>>>>>>>>>=20 >>>>>>>>>> Comments inline, marked by [JR]. >>>>>>>>>>=20 >>>>>>>>>> From: Phil Hunt [phil.hunt@oracle.com] >>>>>>>>>> Sent: Thursday, May 30, 2013 5:25 PM >>>>>>>>>> To: Richer, Justin P. >>>>>>>>>> Cc: John Bradley; oauth@ietf.org WG >>>>>>>>>> Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>>>=20 >>>>>>>>>> See below. >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> @independentid >>>>>>>>>>=20 >>>>>>>>>> www.independentid.com >>>>>>>>>>=20 >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> On 2013-05-30, at 2:09 PM, Justin Richer wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> OK, I think see part of the hang up. I have not seen the = scenario that you describe, where you trade a 3rd party token for a = "local" token. I have seen where access tokens are federated directly at = the PR. (Introspection lets you do some good things with that pattern.) >>>>>>>>>>=20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>> =20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_7CFFDC03-024E-4A1A-AF65-0F713B73DD8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 When = they are issued their client credential after successfully = registering=85.isn't that the whole point of the = process?

Once they register, they are no longer = public. After that, they just get a token like everyone = else.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2013-06-06, at 10:49 AM, Justin Richer wrote:

=20 =20
Then how do they get their equivalent of a registration access token to manage their configurations?

The draft proposes that they get this token right from the registration endpoint. You're proposing that they get this from the token endpoint.

The initial access token isn't even in play here.

-- Justin

On 06/06/2013 01:49 PM, Phil Hunt wrote:

Huh?

There's no need for public clients to access the token endpoint as they can register anonymously.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:47 AM, Justin Richer wrote:

Because anonymous *registration* and public client *access* to the token endpoint are two different things.

-- Justin

On 06/06/2013 01:43 PM, = Phil Hunt wrote:

*why* will the 6749 standard flows (specifically 4.4) not work?

The registration endpoint can allow anonymous access to permit anonymous registration.

This means the configuration endpoints can use normal access tokens obtained through RFC6749 section 4.4 (Client Auth) flows.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:36 AM, Justin Richer wrote:

... because it already *is* a REST protected API. It's protected with the Registration Access Token. Which is an OAuth 2.0 Bearer token.

The *only* difference is how you get the token, which has nothing to do with the REST protected API that it's protecting.

-- Justin

On 06/06/2013 01:35 PM, Phil Hunt wrote:

Nobody has explained why using a normal REST protected API won't work. You keep saying that and that you won't go back. But that doesn't = explain the issue.

=

Phil

=
@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:28 AM, Justin Richer wrote:

=

I feel we're still just going in circles with these arguments, but my comments are inline:

On 06/06/2013 01:17 PM, Phil Hunt wrote:

=
Phil

=
@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 9:49 AM, Justin Richer = wrote:

Tim, thanks for your review! Comments inline.

On 06/05/2013 04:59 PM, Tim Bray wrote:

FWIW, I just read the spec through with fresh eyes, and I found the explanation of the workflow in 1.4.2 very useful.

- A developer manually registers and then is able to request =93Initial tokens=94= tokens for a = dynamic-app-registration-scope,

- you use that =93Initial token=94 token to register, in exchange you get the client-id & so on, and also a a per-registration =93Registration token=94 for updating that particular registration information

- you = fetch/update/delete your registration information with that registration token.

The first part, where the developer registers & gets a token for a scope, is vanilla OAuth 2. = (right?)

Yes, it can be vanilla Oauth2 or it can be the developer (or someone) getting a token through some other means, like browsing to a developer portal and getting a Bearer token. I've edited the example in 1.4.3 in the latest (unpublished) text so that the developer is literally doing OAuth2 to get the initial token. It's important to note that this could be any flavor of OAuth2 token, though Bearer tokens are of course the most = common.

The bit about getting an access token specific to that registration is a new flow (right?), but it seems = convenient.

Right, it's a new way to get a bearer token so that you can use it at the protected resource. We wanted to re-use the token endpoint for this, but couldn't come up with a reasonable way of doing so (as has been discussed on the list.

[PH] We still greatly disagree on this.

*Use the normal token issuing process.* One = reason given was what about anonymous clients? The answer is, = they don't have to do anything. Remember that you have defined TWO endpoints. The "registration endpoint" and the "configuration endpoint". A server accepting = anonymous registration simply accepts anonymous access at the "registration endpoint". Clients wanting to = update their profiles do the normal client token request flow to the token endpoint to obtain a normal access token useable at the "configuration = endpoint".

[JR] But then you're opening up the client_credentials flow to anonymous clients, or you've got to be able to lock down client_credentials as a flow to only a special (service-specific) scope for client configuration purposes. This, I think, is much more complicated to implement and much more error prone. I don't think it's even possible in the software stack we're building on top of. And furthermore, you're not letting public clients dynamically register anymore, since you'd be forcing everyone to have a client secret. Your dynamic public clients would have to save the client secret but know to only use it at the registration endpoint, and not the token endpoint where they're used to. This way, it's clear. You get a token that you use at a given endpoint, the end.

As soon as you do this, other things simplify.

1. No need to keep "registration access token" around indefinitely. It's just an access token. In fact = it is only needed for minutes since it will likely only be used to read or update profiles or to perform client initiated credential = rotation.

[JR] You *can* throw away your registration access tokens if you want to, or have them expire, if you want to limit the lifespan of your clients. It's only the security considerations section that suggests against expiring the tokens, and for good reason. But it's your choice to change that if you don't want longstanding read/edit access to a client's configuration.

2. No need to have a special token issuing method. Creating a new = issuing process suggests that the WG can't drink its own koolaid. Because at the first = seeming challenge, the WG create a new flow. How do we expect implementers to behave?

[JR] That particular koolaid wasn't the right drink here, to stretch your analogy. Bearer tokens were, which is also the group's koolaid. We tried to go down the road you suggest and it was a dead end. Why do you think it will work better this time? And I'd like to point out a decision from several years ago now to separate the notion of "how you get a token" from "how you use a token" in OAuth2. OAuth1 had all of these rolled in together, and deployment experience showed us that people didn't really want to use it that way. People want components that make sense on their own that let you build systems like this that also make sense.

Forced uniformity isn't necessarily a good thing.

3. The registration/configuration API is JUST a normal OAuth2 protected API.

[JR] It already is. Protected resources don't care where you get your tokens from, just that you have them, so from that perspective it is just a protected resource. Our implementation here literally just looks for the token on the way in in the auth layer and makes sure it's got a special service-specific scope that handles registration.

If the draft drops "registration access tokens", a lot of the text in the draft disappears. The whole = spec is much simpler.

[JR] Much simpler, perhaps, but much less functional and useful. And honestly, not much of the text actually goes away. Most of the draft isn't about dealing with the registration access token, it's about dealing with the client metadata and the RESTful protocol for managing that. The registration access token is a mechanism for doing so.

=46rom = an OAuth 2 point of view, there's nothing special about how you get or use the Initial token, but giving it a special name makes explaining a plausible workflow easier.

Right, and I've admitted that "Initial Access Token" a crappy name, but I haven't heard a better suggestion yet.

Having said that, I have trouble imagining the scenario where you'd use the 1.4.1 flow, but that may be because of my Google-centric worldview.

Could be -- but if Google wants to be an open-registration identity provider (like it has been with OpenID 2.0), it will need to handle this flow as well. This is the client acting on its own behalf, showing up and saying "hi, I'm a client!" and that's that. I think this is a very important case for interoperability of dynamic = registration.

And I=92m not sure 1.4.3 adds any value at all. It just = seems to be a matter of different ways you could get and make use of the registration access token; and I'm sure there are various interesting combinations that haven't been thought of there. I'd just = lose 1.4.3.

1.4.3 in -11 is too close to 1.4.2, so what I've done in the current working text is make the initial process of getting the Initial Access Token different (the developer now uses OAuth2 to configure their build environment). The *real* important difference that's being shown here, though, is that the client doesn't call the registration endpoint, the developer (and their build environment) does. So yes, it's exactly all about how you get and use the registration access token. There are plenty of other ways to do it as well, so that's why this section was a non-normative set of examples. To facilitate that understanding, I've moved it to an appendix in the working copy of draft -12.

Thanks,
-- Justin

-T

On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin <donald.coffin@reminetworks.com> wrote:

See my comments inline = [DFC]

Best = regards,
Don
Donald F. = Coffin
Founder/CTO

REMI = Networks
22751 El Prado Suite = 6216
Rancho Santa Margarita, = CA = 92688-3836

Phone:      (949) = 636-8571
Email:       donald.coffin@reminetworks.com

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, May 31, 2013 12:40 PM
To: Phil Hunt
Cc: Donald F Coffin; oauth@ietf.org

= Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

I feel the need to = clarify a couple erroneous things in Phil's statement:

* To be clear, Draft 11 has the same Registration Access Token system that has been in place since draft 01, it is not inventing something new at the last minute as could be inferred from the statement below.
[DFC] I agree = with Justin. = There is nothing new in draft 11 regarding Registration Access Tokens that wasn=92t = in the initial draft. = It appears because Phil hasn=92t been following the proposed drafts until the last call he is now raising an issue no one in the WG saw as an = issue. That=92s not = to say his point isn=92t valid, but the discussion continues to go all over the map between =93local=94 = and =93federated=94 tokens, usage of the RFC6749 =93Token=94 endpoint, etc. It = would be great if all of Phil=92s points could be addressed in = priority
without the threads becoming so convoluted no one is able to make sense or even comprehend the point being = discussed.

* = DynReg is using an absolutely standard OAuth 2 Bearer token as the Registration Access Token, it's just not coming from a Token Endpoint. However, since an OAuth Protected Resource doesn't care where its tokens come from so long as it can validate them, I don't see this as a problem -- this is a key point where Phil and I disagree.

[DFC] I = understand the disagreement, but I have not seen a proposal from Phil that would describe the differences between the two perspectives other than to say that the Dynamic Registration should use the Token endpoint defined in RFC6749, which does = not    discuss dynamic = registration. Phil=92s point as I understand it is that there should be no difference between an access token used to access resource owner protected data and the registration structure, which I do not agree = with. As I said in the = previous
=             response, my users do NOT want to provide implied access to resource owner protected data just because a client is creating a registration with an = AS. This would be the situation if the client credential flow is used to register an = application. Since our
=             implementation does NOT support the implicit flow, that use case is one we have elected NOT to = support.
        = ;    [DFC] I repeat my initial comment, this conversation has been a circular exchange now for the past few days without any appearance of an alternative option to resolve the = issues.

-- = Justin

On 05/31/2013 03:33 PM, Phil Hunt = wrote:

Don,

I am not proposing any change in meaning. If registration acces token issues by normal token server with scope registration everything is clear as it is for any other protected API. Draft 11 invents a whole new system. I strongly disagree with this.

Phil

On 2013-05-31, at 15:16, Donald F Coffin <donald.coffin@reminetworks.com> wrote:

For = something that was agreed to be parked a few hours ago, there sure seems to still be a lot of circular = discussion. Should we ask a mediator to = intervene?

<= br class=3D"webkit-block-placeholder">
FWIW I = believe that is a significantly strong reason to differentiate an access token that can access the registration information without having the ability to access protected data. Especially given the implied strength of the =93client credential=94 obtained access = token. I have found it extremely confusing to users when explaining the difference between an access token obtained thorough an authorization code flow and a client credential flow, simply because they are both called an =93access token=94. Changing the meaning of an access token obtained through the client credential flow to mean it has the ability to update a registration, when a user may not want it to have access to protected data will only increase both the complexity of the access tokens as well as make their usage harder to explain to non-technical individuals who have to understand the differences between the access tokens obtained through the various = flows.

<= br class=3D"webkit-block-placeholder">
Just my two = cents.

<= br class=3D"webkit-block-placeholder">

Best = regards,
Don
Donald = F. = Coffin
Founder/C= TO

REMI = Networks
22751 = El Prado Suite = 6216
Rancho Santa Margarita, = CA = 92688-3836

Phone:&nb= sp;     (949) = 636-8571
Email:&nb= sp;      donald.coffin@reminetworks.com

<= br class=3D"webkit-block-placeholder">

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Friday, May 31, 2013 11:11 AM
To: Justin = Richer
Cc: oauth@ietf.org WG
= Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt

To be = clear.

It is two separate = issues.

1. Anonymous clients can easily be handled through policy = config.

2. Support for implicit clients needs to be discussed. The current proposal creates large negative value for the service provider and most would never allow in current form. Yes it gives each execution instance a new id, but that isnt what sp's want. It is a huge attack and management headache. Eliminate or propose a different = solution.

Phil

On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org> wrote:

I'm not willing to = write out an entire class of clients from this spec, especially when we have stated use cases for them doing dynamic = registration.

I'm sorry, but your proposed solution will simply not work.

-- = Justin

On 05/31/2013 01:56 PM, Phil Hunt = wrote:

Well the only client that wouldn't have a credential is an implicit client. An implicit client is transient and so would never = update.

Besides, as i have stated, implicit clients should not use dyn reg.

Phil

On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org> wrote:

But the outstanding = question is: how do you get the access token to access the created resource (IE: the Registration Access Token)? You can't use the = client_credentials flow for a client with no = credentials!

-- = Justin

On 05/31/2013 12:58 PM, Phil Hunt = wrote:

Yes. I specified the trivial solution to anonymous clients earlier.

Even simpler. You don't need an access token to create a new resource. You just need one to access one. That is just basic security = config.

Phil

On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org> wrote:

I agree that we are = going in circles, since I just was going to bring up my counter argument of "what about clients with no credentials?" again, which *still* isn't addressed by what you suggest doing, below. I also believe that getting rid of the Registration Access Token but using some other token method would actually make the spec larger, though I'd be glad to review a concrete = counter-proposal if you'd like to write one. And the fact that OIDC is doing it this way, and considered but rejected the way that you're describing, should say something to the WG here about whether or not this is the right choice. Rough consensus and running code, after all.

Regardless, I agree to park this issue and leave the text as is. We'll move to the next draft in the last call process shortly, as I have a handful of non-normative editorial changes that I need to make, thanks to feedback from a few = folks.

Again, thanks for your thorough review, Phil, and I look forward to future feedback.

-- = Justin

On 05/31/2013 12:28 PM, Phil Hunt = wrote:

I = disagree.

There is absolutely no need for a registration access = token.

Get rid of it and just use access tokens as per 6749. If you can't follow 6749 and need new issuing methods, what are others to say regarding inventing new methods?

I have not heard a good reason for the special process or one good enough to warrant a new method for issuing an access token. Does the broader group realize this is what the spec says?

Yes, i heard a lot saying OIDC does it this way. But that is a political reason, not a technical reason. Still, compatibility is always a strong objective. Even so, = oidc could keep using their method just fine. There is no obligation here to do the = same.

The only reason so far was expiry of client creds. Well, why not require the client to update prior to expiry? It makes no sense to have another token with longer expiry. B'sides, even expired the client can re-register from = scratch.

Why force the client to persist multiple tokens and creds? That is far far too = complex.

=

Finally if you get rid of registration access token the spec size will drop roughly in half IMO. This suggests simplicity to me.

=

Apologies for my rant. Maybe we should park this for now. We are going in = circles.

Phil

On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org> wrote:

Phil,

We *can* keep it straight just fine, but I just need you to be clear about which part you're objecting to because the answers are different. Please use the terms as defined in the document so that we all know which component we're talking about. I'm sure you'd agree than in specification work such as this, precision of language and labels is key for communication between parties. This is precisely why there's a Terminology section right up front, so that when I say "Registration Access Token" you can know that I mean a very specific thing, and when I say "Initial Registration Token" I mean a very different specific thing. So I'm asking you, please, use the defined terms so that we can avoid this unnecessary confusion.

But anyway, what you're talking about below, "the token the client uses to update is profile" *IS* the Registration Access Token. That's all that that token is used for. You're not asking for it to go away, you're asking for it to come from the Token Endpoint instead of the response from the Registration Endpoint. I don't see how the client *can* get it from the normal token process without jumping through specialized hoops to make that happen. I've implemented the draft the way that it is right now, both client and server side, and it works. Others have implemented it, too. We've done interop testing, and it works. This is a proven pattern and from where I sit there is both rough consensus and running = code.

I believe that I've already pointed out how the solutions you've proposed so far won't work in practice, for various reasons, many of which have already been brought up and discussed previously. If you have another way for the client to get its Registration Access Token, please propose it; but I haven't seen anything yet that will = fly.

-- = Justin

On 05/31/2013 11:10 AM, Phil Hunt = wrote:

Justin,

This is my primary objection! We can't keep it straight. Their should be no such thing as a registrstion access token! Just the token the client obtains to update its profile through the normal token request = process.

Phil

On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org> wrote:

Which token are you = referring to here?

If it's the Initial Registration Token, then you could get that through the normal token server no problem. (The lifecycle writeups don't call this out explicitly but I would be willing to do so.) Or you could get it elsewhere. Doesn't matter, just like it doesn't matter with any other OAuth2 protected resource.

If it's the Registration Access Token, then having the token come from the token endpoint would require a lot more work and complexity on behalf of both of the client and server. Either you end up with public clients getting secrets they shouldn't need or with granting clients access to the = client_credentials flow when they shouldn't actually have it. Plus it adds extra round trips which don't buy you anything.

-- = Justin

On 05/31/2013 10:15 AM, Phil Hunt = wrote:

The preference is to have the access token for registration issued by the normal token server rather then by the registration = endpoint.

In the current draft it is obtained through a unique process and must outlive the = client.

Phil

On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org> wrote:

I don't understand any of the comments below -- it already *is* an OAuth2 protected resource without any special handling. Your access tokens can be short-lived, long-lived, federated, structured, random blobs ... totally doesn't matter. They are access tokens being used to access a normal protected resource. Full stop.

Anything else is out of scope. The lifecycle discussions at the beginning are merely examples of some ways you *could* use it and are non-normative and = non-exhaustive.

You seem to be asking for something that's already in the = draft.

-- = Justin

From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 7:31 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
= Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt

Phil

On 2013-05-30, at 16:11, "Richer, Justin P." <jricher@mitre.org> wrote:

Comments inline, marked by = [JR].

From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 5:25 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
= Subject: Re: [OAUTH-WG] review comments on = draft-ietf-oauth-dyn-reg-11.txt

See below.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-05-30, at 2:09 PM, Justin Richer wrote:

OK, I think see part of the hang up. I have not seen the scenario that you describe, where you trade a 3rd party token for a "local" token. I have seen where access tokens are federated directly at the PR. (Introspection lets you do some good things with that pattern.)

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

= --Apple-Mail=_7CFFDC03-024E-4A1A-AF65-0F713B73DD8B-- From jricher@mitre.org Thu Jun 6 10:55:29 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710F211E80D5 for ; Thu, 6 Jun 2013 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64G5yFflKRdz for ; Thu, 6 Jun 2013 10:55:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 869F521F9A12 for ; Thu, 6 Jun 2013 10:55:23 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2DD911F0625; Thu, 6 Jun 2013 13:55:23 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 17B971F041C; Thu, 6 Jun 2013 13:55:23 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 6 Jun 2013 13:55:22 -0400 Message-ID: <51B0CCDA.8010805@mitre.org> Date: Thu, 6 Jun 2013 13:54:34 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <255B9BB34FB7D647A506DC292726F6E1151B105DA5@WSMSG3153V.srv.dir.telstra.com> <1373E8CE237FCC43BCA36C6558612D2A9F26D0@USCHMBX001.nsn-intra.net> <919FB49B-2705-42E4-B5C3-B433C3F81C7F@ve7jtb.com> <9209089C-5B60-4212-88EA-376855DBCEA0@oracle.com> <51B0C14D.5020306@mitre.org> <1CCDB2B8-CAD9-4827-8113-F92537F70375@oracle.com> <51B0C8CE.6070309@!> <51B0CB6D.7060! 004@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070701020209050606040605" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:55:29 -0000 --------------070701020209050606040605 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit ... My bad, you're right. I was getting my wires crossed with all these emails. In my view, the initial access token is, fundamentally, an access token used to constrain access to the registration endpoint (not the configuration endpoint, and not to get "normal" access tokens). Just like a normal OAuth token is an opaque token used to constrain access to the protected resource. If you want to define anything more for either of those, you're going to need more work. I'm completely on board with making those definitions, but I think it goes beyond registration. And if registration is silent on all of this, and just says "the registration endpoint may be an OAuth 2.0 protected resource", then whatever interoperable solutions we can come up with for validating a cross-domain token can be applied here. I don't think it makes sense to constrain registration before the rest of this work is baked. -- Justin On 06/06/2013 01:50 PM, Phil Hunt wrote: > We have two separate discussions going on. 8-) > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-06-06, at 10:48 AM, Justin Richer wrote: > >> I thought we were talking about the registration access token, not >> the initial access token? >> >> -- Justin >> >> On 06/06/2013 01:48 PM, Phil Hunt wrote: >>> This is why this to-MAY-to vs. to-MAH-to distinction around is the >>> initial access token an authorization token is important. >>> >>> The purpose for the initial access token is dramatically different >>> then normal access tokens. This is for "registration" and does not >>> constitute authentication or authorization. >>> >>> Therefore, in this case, I do not believe that defining access >>> tokens in the broader sense makes this issue clearer. >>> >>> Registration is a very specific process different than authorization. >>> >>> This might be a good paper to look at so the group understands why I >>> am differentiating authorization from what is happening with initial >>> access: >>> http://tools.ietf.org/html/draft-hallambaker-httpauth-00 >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2013-06-06, at 10:37 AM, Justin Richer wrote: >>> >>>> Interoperability of the processing of OAuth tokens is a separate >>>> issue that needs to be solved not just for registration. When it is >>>> solved in the wider case, Registration as-is will inherit the solution. >>>> >>>> So today, if you're using an Initial Access Token (which is >>>> optional), then you're locked to whatever process you want to use >>>> to verify/validate that token. Since it's just an OAuth token, >>>> you've got a number of things that you can do (assertions, >>>> introspection, magic). >>>> >>>> I'd rather we solve the *real* cross-domain issue in the wider case >>>> than just try to cram something into registration. >>>> >>>> -- Justin >>>> >>>> On 06/06/2013 01:33 PM, Phil Hunt wrote: >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2013-06-06, at 10:05 AM, Justin Richer wrote: >>>>> >>>>>> >>>>>> On 06/06/2013 11:20 AM, Phil Hunt wrote: >>>>>>> As I've said before the initial auth token should nothing to do >>>>>>> with auth. It is simply an assertion given to the developer to >>>>>>> distribute in order to pass on signed claims about the software. >>>>>> >>>>>> Phil, as I and several others have explained previously, that's >>>>>> not true at all. It's a token that gives authorization to the >>>>>> registration endpoint. The fact that you can use it as an >>>>>> assertion to pass along signed claims is an artifact of it being >>>>>> an OAuth token and an OAuth token is an opaque string. Please >>>>>> read through the dynamic registration draft again -- it says >>>>>> absolutely nothing about assertions, signatures, or claims with >>>>>> regard to this token. >>>>> It depends which case you are using. If the developer is talking >>>>> to a single deployment domain and obtains an initial access token >>>>> and then ships it with all clients, then sure. In this scenario, >>>>> the contents are totally controlled by the local domain. >>>>> >>>>> I agree. In this case, you don't care about inter-op. The whole >>>>> environment is siloed. But then, if this is your case, I'm not >>>>> sure why this draft is at the IETF. >>>>> >>>>> The interoperability case is where a third party generates that >>>>> assertion and the deployment domain has to decide to accept it. >>>>> So you are a developer and you want to build a client for a >>>>> Microsoft or Oracle app. You want to be able to ship that to your >>>>> customers. You register with the appropriate publisher and they >>>>> give you a signed assertion that can be used as the "Initial >>>>> Access Token". This token is then accepted by the deployment >>>>> domain and then it decides if it trusts the signer or not. >>>>> >>>>> ===> For this to work, the contents and format of that token MUST >>>>> be defined. Otherwise how could we ensure a Microsoft signed >>>>> assertion would be accepted by a PingIdentity OAuth server? Or >>>>> any other combination of implementations from different >>>>> vendors/communities? >>>>> >>>>>> >>>>>>> >>>>>>> Bearer or not bearer is a distraction. The fact that the >>>>>>> contents and format of this token is out of scope leaves a HUGE >>>>>>> interop gap. >>>>>> >>>>>> The fact that some of us (myself included) are *using* this token >>>>>> to carry this kind of information is out of scope for the basic >>>>>> registration spec. I completely agree that there's value in >>>>>> defining this stuff, but as a separate and complementary spec >>>>>> from registration. >>>>> >>>>> [PH] I was reacting to John Bradley's assertion that the spec was >>>>> narrowly defined with interop in mind. Yet this mechanism is a key >>>>> factor being used to share information about the software. >>>>> >>>>>> >>>>>>> >>>>>>> Finally never-mind bearer bias, how are client credentials >>>>>>> rotated interoperably if the only thing rotated is client_secret? >>>>>> >>>>>> *any* parameter on the client, including the >>>>>> registration_access_token and any extension parameters, can be >>>>>> rotated on any call to the Read or Update methods (except for >>>>>> client_id). So if you've got another mechanism for doing client >>>>>> authentication, you can rotate that, too. >>>>>> >>>>>>> >>>>>>> I would say the spec only works for client secrets and/or >>>>>>> all-in-one domain where there is no interop. >>>>>> >>>>>> Considering I've personally used it across domains and without >>>>>> client secrets (using jwks_uri to register public keys), I have >>>>>> to empirically disagree with that statement. >>>>>> >>>>>> -- Justin >>>>>> >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> On 2013-06-06, at 1:53, John Bradley >>>>>> > wrote: >>>>>>> >>>>>>>> There are a couple of reasons. >>>>>>>> >>>>>>>> One criticism Hannes and others make of OAuth specs is they are >>>>>>>> not tightly profiled enough to be interoperable without further >>>>>>>> out of band configuration and profiling. >>>>>>>> >>>>>>>> Making registration work with minimal ambiguity was a priority >>>>>>>> for Connect and that has carried over. >>>>>>>> >>>>>>>> I am not opposed to having this extended at some point in the >>>>>>>> future, once we have a second token type. The new token type >>>>>>>> should be available to do updates as well. >>>>>>>> >>>>>>>> The problem is that starting down the HoK route potentially >>>>>>>> requires a registered client that may need to be registered to >>>>>>>> do the registration. >>>>>>>> I think that is best left to another spec to sort out the >>>>>>>> possible turtles. >>>>>>>> >>>>>>>> So the default needs to be bearer tokens unless registration is >>>>>>>> extended by another profile. >>>>>>>> >>>>>>>> John B. >>>>>>>> On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - >>>>>>>> FI/Espoo)" >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Because bearer tokens have a stable RFC-numbered spec and are >>>>>>>>> widely implemented and the registration flow as documented >>>>>>>>> seems like it should work? -T >>>>>>>>> That�s the answer for why there is support for bearer tokens >>>>>>>>> but it is not the answer to why that�s the only supported >>>>>>>>> mechanism. >>>>>>>>> If we want to support stronger security mechanisms (which the >>>>>>>>> group has decided to work on already) then we need to have a >>>>>>>>> story on how to support the other mechanisms as well . >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>> >>>>> >>>> >>> >> > --------------070701020209050606040605 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit ... My bad, you're right. I was getting my wires crossed with all these emails.

In my view, the initial access token is, fundamentally, an access token used to constrain access to the registration endpoint (not the configuration endpoint, and not to get "normal" access tokens). Just like a normal OAuth token is an opaque token used to constrain access to the protected resource. If you want to define anything more for either of those, you're going to need more work.

I'm completely on board with making those definitions, but I think it goes beyond registration. And if registration is silent on all of this, and just says "the registration endpoint may be an OAuth 2.0 protected resource", then whatever interoperable solutions we can come up with for validating a cross-domain token can be applied here. I don't think it makes sense to constrain registration before the rest of this work is baked.

�-- Justin

On 06/06/2013 01:50 PM, Phil Hunt wrote:

We have two separate discussions going on. �8-)

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:48 AM, Justin Richer wrote:

I thought we were talking about the registration access token, not the initial access token?

�-- Justin

On 06/06/2013 01:48 PM, Phil Hunt wrote:

This is why this to-MAY-to vs. to-MAH-to distinction around is the initial access token an authorization token is important.

The purpose for the initial access token is dramatically different then normal access tokens. �This is for "registration" and does not constitute authentication or authorization.

Therefore, in this case, I do not believe that defining access tokens in the broader sense makes this issue clearer.

Registration is a very specific process different than authorization.

This might be a good paper to look at so the group understands why I am differentiating authorization from what is happening with initial access:

http://tools.ietf.org/html/draft-hallambaker-httpauth-00

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:37 AM, Justin Richer wrote:

Interoperability of the processing of OAuth tokens is a separate issue that needs to be solved not just for registration. When it is solved in the wider case, Registration as-is will inherit the solution.

So today, if you're using an Initial Access Token (which is optional), then you're locked to whatever process you want to use to verify/validate that token. Since it's just an OAuth token, you've got a number of things that you can do (assertions, introspection, magic).

I'd rather we solve the *real* cross-domain issue in the wider case than just try to cram something into registration.

�-- Justin

On 06/06/2013 01:33 PM, Phil Hunt wrote:

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:05 AM, Justin Richer wrote:

On 06/06/2013 11:20 AM, Phil Hunt wrote:

As I've said before the initial auth token should nothing to do with auth. It is simply an assertion given to the developer to distribute in order to pass on signed claims about the software.

Phil, as I and several others have explained previously, that's not true at all. It's a token that gives authorization to the registration endpoint. The fact that you can use it as an assertion to pass along signed claims is an artifact of it being an OAuth token and an OAuth token is an opaque string. Please read through the dynamic registration draft again -- it says absolutely nothing about assertions, signatures, or claims with regard to this token.

It depends which case you are using. �If the developer is talking to a single deployment domain and obtains an initial access token and then ships it with all clients, then sure. �In this scenario, the contents are totally controlled by the local domain.

I agree. In this case, you don't care about inter-op. The whole environment is siloed. �But then, if this is your case, I'm not sure why this draft is at the IETF.

The interoperability case is where a third party generates that assertion and the deployment domain has to decide to accept it. �So you are a developer and you want to build a client for a Microsoft or Oracle app. �You want to be able to ship that to your customers. You register with the appropriate publisher and they give you a signed assertion that can be used as the "Initial Access Token". � �This token is then accepted by the deployment domain and then it decides if it trusts the signer or not.

===> For this to work, the contents and format of that token MUST be defined. � Otherwise how could we ensure a Microsoft signed assertion would be accepted by a PingIdentity OAuth server? �Or any other combination of implementations from different vendors/communities?

Bearer or not bearer is a distraction. The fact that the contents and format of this token is out of scope leaves a HUGE interop gap.

The fact that some of us (myself included) are *using* this token to carry this kind of information is out of scope for the basic registration spec. I completely agree that there's value in defining this stuff, but as a separate and complementary spec from registration.

[PH] I was reacting to John Bradley's assertion that the spec was narrowly defined with interop in mind. Yet this mechanism is a key factor being used to share information about the software.

Finally never-mind bearer bias, how are �client credentials rotated interoperably if the only thing rotated is client_secret?

*any* parameter on the client, including the registration_access_token and any extension parameters, can be rotated on any call to the Read or Update methods (except for client_id). So if you've got another mechanism for doing client authentication, you can rotate that, too.

I would say the spec only works for client secrets and/or all-in-one domain where there is no interop.

Considering I've personally used it across domains and without client secrets (using jwks_uri to register public keys), I have to empirically disagree with that statement.

�-- Justin

Phil

On 2013-06-06, at 1:53, John Bradley <ve7jtb@ve7jtb.com> wrote:

There are a couple of reasons. � �

One criticism Hannes and others make of OAuth specs is they are not tightly profiled enough to be interoperable without further out of band configuration and profiling.

Making registration work with minimal ambiguity was a priority for Connect and that has carried over.

I am not opposed to having this extended at some point in the future, once we have a second token type. � The new token type should be available to do updates as well.

The problem is that starting down the HoK route potentially requires a registered client that may need to be registered to do the registration. ��

I think that is best left to another spec to sort out the possible turtles.

So the default needs to be bearer tokens unless registration is extended by another profile.

John B.

On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> wrote:

Because bearer tokens have a stable RFC-numbered spec and are widely implemented and the registration flow as documented seems like it should work? �-T

�

That�s the answer for why there is support for bearer tokens but it is not the answer to why that�s the only supported mechanism.

If we want to support stronger security mechanisms (which the group has decided to work on already) then we need to have a story on how to support the other mechanisms as well .

_______________________________________________
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

--------------070701020209050606040605-- From jricher@mitre.org Thu Jun 6 10:57:05 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5298521F8470 for ; Thu, 6 Jun 2013 10:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhvsxtPQfXtF for ; Thu, 6 Jun 2013 10:57:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 47A1D21F84A1 for ; Thu, 6 Jun 2013 10:57:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E38E11F0625; Thu, 6 Jun 2013 13:57:03 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C44A42260059; Thu, 6 Jun 2013 13:57:03 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 6 Jun 2013 13:57:02 -0400 Message-ID: <51B0CD3D.8070907@mitre.org> Date: Thu, 6 Jun 2013 13:56:13 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A8C0ED.6040607@mitre.org> <87E1F74D-9CCA-4330-82D6-AB3D9B8EF48D@oracle.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <51B0BDA2.7010705@mitre.org> <7B00614C-6B25-4951-B004-C17932432D17@oracle.com> <51B0C6D4.804000!> <9@mitre.org> <51B0C8A0.2020306@mitre.org> <51B0CB18.50! 90003@mitre.org> <51B0CBC5.5090509@mitre.org> <0314A5D5-A6B1-4D05-B348-AC17AA30F61B@oracle.com> In-Reply-To: <0314A5D5-A6B1-4D05-B348-AC17AA30F61B@oracle.com> Content-Type: multipart/alternative; boundary="------------090707000100020606000304" X-Originating-IP: [129.83.31.56] Cc: Donald F Coffin , "oauth@ietf.org" Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:57:05 -0000 --------------090707000100020606000304 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Before they register, they're neither public nor private. After they register, they're either public or private depending on if they want to/can use a client secret or equivalent to talk to the token endpoint. Also, having a client register and allowing it to get a token through the client_credentials flow (without a user in the loop) is potentially dangerous unless things are very carefully scope-limited anyway. -- Justin On 06/06/2013 01:51 PM, Phil Hunt wrote: > When they are issued their client credential after successfully > registering�.isn't that the whole point of the process? > > Once they register, they are no longer public. After that, they just > get a token like everyone else. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-06-06, at 10:49 AM, Justin Richer wrote: > >> Then how do they get their equivalent of a registration access token >> to manage their configurations? >> >> The draft proposes that they get this token right from the >> registration endpoint. You're proposing that they get this from the >> token endpoint. >> >> The initial access token isn't even in play here. >> >> -- Justin >> >> On 06/06/2013 01:49 PM, Phil Hunt wrote: >>> Huh? >>> >>> There's no need for public clients to access the token endpoint as >>> they can register anonymously. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2013-06-06, at 10:47 AM, Justin Richer wrote: >>> >>>> Because anonymous *registration* and public client *access* to the >>>> token endpoint are two different things. >>>> >>>> -- Justin >>>> >>>> On 06/06/2013 01:43 PM, Phil Hunt wrote: >>>>> *why* will the 6749 standard flows (specifically 4.4) not work? >>>>> >>>>> The registration endpoint can allow anonymous access to permit >>>>> anonymous registration. >>>>> >>>>> This means the configuration endpoints can use normal access >>>>> tokens obtained through RFC6749 section 4.4 (Client Auth) flows. >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2013-06-06, at 10:36 AM, Justin Richer wrote: >>>>> >>>>>> ... because it already *is* a REST protected API. It's protected >>>>>> with the Registration Access Token. Which is an OAuth 2.0 Bearer >>>>>> token. >>>>>> >>>>>> The *only* difference is how you get the token, which has nothing >>>>>> to do with the REST protected API that it's protecting. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> On 06/06/2013 01:35 PM, Phil Hunt wrote: >>>>>>> Nobody has explained why using a normal REST protected API won't >>>>>>> work. You keep saying that and that you won't go back. But that >>>>>>> doesn't explain the issue. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2013-06-06, at 10:28 AM, Justin Richer wrote: >>>>>>> >>>>>>>> I feel we're still just going in circles with these arguments, >>>>>>>> but my comments are inline: >>>>>>>> >>>>>>>> On 06/06/2013 01:17 PM, Phil Hunt wrote: >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> @independentid >>>>>>>>> www.independentid.com >>>>>>>>> phil.hunt@oracle.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-06-06, at 9:49 AM, Justin Richer wrote: >>>>>>>>> >>>>>>>>>> Tim, thanks for your review! Comments inline. >>>>>>>>>> >>>>>>>>>> On 06/05/2013 04:59 PM, Tim Bray wrote: >>>>>>>>>>> FWIW, I just read the spec through with fresh eyes, and I >>>>>>>>>>> found the explanation of the workflow in 1.4.2 very useful. >>>>>>>>>>> >>>>>>>>>>> - A developer manually registers and then is able to request >>>>>>>>>>> �Initial tokens� tokens for a dynamic-app-registration-scope, >>>>>>>>>>> - you use that �Initial token� token to register, in >>>>>>>>>>> exchange you get the client-id & so on, and also a a >>>>>>>>>>> per-registration �Registration token� for updating that >>>>>>>>>>> particular registration information >>>>>>>>>>> - you fetch/update/delete your registration information with >>>>>>>>>>> that registration token. >>>>>>>>>>> >>>>>>>>>>> The first part, where the developer registers & gets a token >>>>>>>>>>> for a scope, is vanilla OAuth 2. (right?) >>>>>>>>>> >>>>>>>>>> Yes, it can be vanilla Oauth2 or it can be the developer (or >>>>>>>>>> someone) getting a token through some other means, like >>>>>>>>>> browsing to a developer portal and getting a Bearer token. >>>>>>>>>> I've edited the example in 1.4.3 in the latest (unpublished) >>>>>>>>>> text so that the developer is literally doing OAuth2 to get >>>>>>>>>> the initial token. It's important to note that this could be >>>>>>>>>> any flavor of OAuth2 token, though Bearer tokens are of >>>>>>>>>> course the most common. >>>>>>>>>> >>>>>>>>>>> The bit about getting an access token specific to that >>>>>>>>>>> registration is a new flow (right?), but it seems convenient. >>>>>>>>>> >>>>>>>>>> Right, it's a new way to get a bearer token so that you can >>>>>>>>>> use it at the protected resource. We wanted to re-use the >>>>>>>>>> token endpoint for this, but couldn't come up with a >>>>>>>>>> reasonable way of doing so (as has been discussed on the list. >>>>>>>>> >>>>>>>>> [PH] We still greatly disagree on this. >>>>>>>>> >>>>>>>>> *Use the normal token issuing process.* One reason given was >>>>>>>>> what about anonymous clients? The answer is, they don't have >>>>>>>>> to do anything. Remember that you have defined TWO endpoints. >>>>>>>>> The "registration endpoint" and the "configuration endpoint". >>>>>>>>> A server accepting anonymous registration simply accepts >>>>>>>>> anonymous access at the "registration endpoint". Clients >>>>>>>>> wanting to update their profiles do the normal client token >>>>>>>>> request flow to the token endpoint to obtain a normal access >>>>>>>>> token useable at the "configuration endpoint". >>>>>>>>> >>>>>>>> >>>>>>>> [JR] But then you're opening up the client_credentials flow to >>>>>>>> anonymous clients, or you've got to be able to lock down >>>>>>>> client_credentials as a flow to only a special >>>>>>>> (service-specific) scope for client configuration purposes. >>>>>>>> This, I think, is much more complicated to implement and much >>>>>>>> more error prone. I don't think it's even possible in the >>>>>>>> software stack we're building on top of. And furthermore, >>>>>>>> you're not letting public clients dynamically register anymore, >>>>>>>> since you'd be forcing everyone to have a client secret. Your >>>>>>>> dynamic public clients would have to save the client secret but >>>>>>>> know to only use it at the registration endpoint, and not the >>>>>>>> token endpoint where they're used to. This way, it's clear. You >>>>>>>> get a token that you use at a given endpoint, the end. >>>>>>>> >>>>>>>>> As soon as you do this, other things simplify. >>>>>>>>> >>>>>>>>> 1. No need to keep "registration access token" around >>>>>>>>> indefinitely. It's just an access token. In fact it is only >>>>>>>>> needed for minutes since it will likely only be used to read >>>>>>>>> or update profiles or to perform client initiated credential >>>>>>>>> rotation. >>>>>>>> >>>>>>>> [JR] You *can* throw away your registration access tokens if >>>>>>>> you want to, or have them expire, if you want to limit the >>>>>>>> lifespan of your clients. It's only the security considerations >>>>>>>> section that suggests against expiring the tokens, and for good >>>>>>>> reason. But it's your choice to change that if you don't want >>>>>>>> longstanding read/edit access to a client's configuration. >>>>>>>> >>>>>>>>> 2. No need to have a special token issuing method. Creating a >>>>>>>>> new issuing process suggests that the WG can't drink its own >>>>>>>>> koolaid. Because at the first seeming challenge, the WG >>>>>>>>> create a new flow. How do we expect implementers to behave? >>>>>>>> >>>>>>>> [JR] That particular koolaid wasn't the right drink here, to >>>>>>>> stretch your analogy. Bearer tokens were, which is also the >>>>>>>> group's koolaid. We tried to go down the road you suggest and >>>>>>>> it was a dead end. Why do you think it will work better this >>>>>>>> time? And I'd like to point out a decision from several years >>>>>>>> ago now to separate the notion of "how you get a token" from >>>>>>>> "how you use a token" in OAuth2. OAuth1 had all of these rolled >>>>>>>> in together, and deployment experience showed us that people >>>>>>>> didn't really want to use it that way. People want components >>>>>>>> that make sense on their own that let you build systems like >>>>>>>> this that also make sense. >>>>>>>> >>>>>>>> Forced uniformity isn't necessarily a good thing. >>>>>>>> >>>>>>>>> 3. The registration/configuration API is JUST a normal OAuth2 >>>>>>>>> protected API. >>>>>>>> >>>>>>>> [JR] It already is. Protected resources don't care where you >>>>>>>> get your tokens from, just that you have them, so from that >>>>>>>> perspective it is just a protected resource. Our implementation >>>>>>>> here literally just looks for the token on the way in in the >>>>>>>> auth layer and makes sure it's got a special service-specific >>>>>>>> scope that handles registration. >>>>>>>> >>>>>>>>> >>>>>>>>> If the draft drops "registration access tokens", a lot of the >>>>>>>>> text in the draft disappears. The whole spec is much simpler. >>>>>>>> >>>>>>>> [JR] Much simpler, perhaps, but much less functional and >>>>>>>> useful. And honestly, not much of the text actually goes away. >>>>>>>> Most of the draft isn't about dealing with the registration >>>>>>>> access token, it's about dealing with the client metadata and >>>>>>>> the RESTful protocol for managing that. The registration access >>>>>>>> token is a mechanism for doing so. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> From an OAuth 2 point of view, there's nothing special >>>>>>>>>>> about how you get or use the Initial token, but giving it a >>>>>>>>>>> special name makes explaining a plausible workflow easier. >>>>>>>>>> >>>>>>>>>> Right, and I've admitted that "Initial Access Token" a crappy >>>>>>>>>> name, but I haven't heard a better suggestion yet. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Having said that, I have trouble imagining the scenario >>>>>>>>>>> where you'd use the 1.4.1 flow, but that may be because of >>>>>>>>>>> my Google-centric worldview. >>>>>>>>>> >>>>>>>>>> Could be -- but if Google wants to be an open-registration >>>>>>>>>> identity provider (like it has been with OpenID 2.0), it will >>>>>>>>>> need to handle this flow as well. This is the client acting >>>>>>>>>> on its own behalf, showing up and saying "hi, I'm a client!" >>>>>>>>>> and that's that. I think this is a very important case for >>>>>>>>>> interoperability of dynamic registration. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> And I�m not sure 1.4.3 adds any value at all. It just seems >>>>>>>>>>> to be a matter of different ways you could get and make use >>>>>>>>>>> of the registration access token; and I'm sure there are >>>>>>>>>>> various interesting combinations that haven't been thought >>>>>>>>>>> of there. I'd just lose 1.4.3. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1.4.3 in -11 is too close to 1.4.2, so what I've done in the >>>>>>>>>> current working text is make the initial process of getting >>>>>>>>>> the Initial Access Token different (the developer now uses >>>>>>>>>> OAuth2 to configure their build environment). The *real* >>>>>>>>>> important difference that's being shown here, though, is that >>>>>>>>>> the client doesn't call the registration endpoint, the >>>>>>>>>> developer (and their build environment) does. So yes, it's >>>>>>>>>> exactly all about how you get and use the registration access >>>>>>>>>> token. There are plenty of other ways to do it as well, so >>>>>>>>>> that's why this section was a non-normative set of examples. >>>>>>>>>> To facilitate that understanding, I've moved it to an >>>>>>>>>> appendix in the working copy of draft -12. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> -- Justin >>>>>>>>>> >>>>>>>>>>> -T >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> See my comments inline [DFC] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> Don >>>>>>>>>>> >>>>>>>>>>> Donald F. Coffin >>>>>>>>>>> >>>>>>>>>>> Founder/CTO >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> REMI Networks >>>>>>>>>>> >>>>>>>>>>> 22751 El Prado Suite 6216 >>>>>>>>>>> >>>>>>>>>>> Rancho Santa Margarita, CA 92688-3836 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Phone: (949) 636-8571 >>>>>>>>>>> >>>>>>>>>>> Email: donald.coffin@reminetworks.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *From:*Justin Richer [mailto:jricher@mitre.org >>>>>>>>>>> ] >>>>>>>>>>> *Sent:* Friday, May 31, 2013 12:40 PM >>>>>>>>>>> *To:* Phil Hunt >>>>>>>>>>> *Cc:* Donald F Coffin; oauth@ietf.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Subject:* Re: [OAUTH-WG] review comments on >>>>>>>>>>> draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>>>> >>>>>>>>>>> I feel the need to clarify a couple erroneous things in >>>>>>>>>>> Phil's statement: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> * To be clear, Draft 11 has the same Registration >>>>>>>>>>> Access Token system that has been in place since draft >>>>>>>>>>> 01, it is not inventing something new at the last minute >>>>>>>>>>> as could be inferred from the statement below. >>>>>>>>>>> >>>>>>>>>>> [DFC] I agree with Justin. There is nothing new in >>>>>>>>>>> draft 11 regarding Registration Access Tokens that >>>>>>>>>>> wasn�t in the initial draft. It appears because Phil >>>>>>>>>>> hasn�t been following the proposed drafts until the last >>>>>>>>>>> call he is now raising an issue no one in the WG saw as >>>>>>>>>>> an issue. That�s not to say his point isn�t valid, but >>>>>>>>>>> the discussion continues to go all over the map between >>>>>>>>>>> �local� and �federated� tokens, usage of the RFC6749 >>>>>>>>>>> �Token� endpoint, etc. It would be great if all of >>>>>>>>>>> Phil�s points could be addressed in priority >>>>>>>>>>> without the threads becoming so convoluted no one is >>>>>>>>>>> able to make sense or even comprehend the point being >>>>>>>>>>> discussed. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> * DynReg is using an absolutely standard OAuth 2 >>>>>>>>>>> Bearer token as the Registration Access Token, it's just >>>>>>>>>>> not coming from a Token Endpoint. However, since an >>>>>>>>>>> OAuth Protected Resource doesn't care where its tokens >>>>>>>>>>> come from so long as it can validate them, I don't see >>>>>>>>>>> this as a problem -- this is a key point where Phil and >>>>>>>>>>> I disagree. >>>>>>>>>>> >>>>>>>>>>> [DFC] I understand the disagreement, but I have not >>>>>>>>>>> seen a proposal from Phil that would describe the >>>>>>>>>>> differences between the two perspectives other than to >>>>>>>>>>> say that the Dynamic Registration should use the Token >>>>>>>>>>> endpoint defined in RFC6749, which does not discuss >>>>>>>>>>> dynamic registration. Phil�s point as I understand it is >>>>>>>>>>> that there should be no difference between an access >>>>>>>>>>> token used to access resource owner protected data and >>>>>>>>>>> the registration structure, which I do not agree with. >>>>>>>>>>> As I said in the previous >>>>>>>>>>> response, my users do NOT want to provide implied access >>>>>>>>>>> to resource owner protected data just because a client >>>>>>>>>>> is creating a registration with an AS. This would be the >>>>>>>>>>> situation if the client credential flow is used to >>>>>>>>>>> register an application. Since our >>>>>>>>>>> implementation does NOT support the implicit flow, that >>>>>>>>>>> use case is one we have elected NOT to support. >>>>>>>>>>> >>>>>>>>>>> [DFC] I repeat my initial comment, this conversation >>>>>>>>>>> has been a circular exchange now for the past few days >>>>>>>>>>> without any appearance of an alternative option to >>>>>>>>>>> resolve the issues. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- Justin >>>>>>>>>>> >>>>>>>>>>> On 05/31/2013 03:33 PM, Phil Hunt wrote: >>>>>>>>>>> >>>>>>>>>>> Don, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I am not proposing any change in meaning. If >>>>>>>>>>> registration acces token issues by normal token >>>>>>>>>>> server with scope registration everything is clear >>>>>>>>>>> as it is for any other protected API. Draft 11 >>>>>>>>>>> invents a whole new system. I strongly disagree with >>>>>>>>>>> this. >>>>>>>>>>> >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2013-05-31, at 15:16, Donald F Coffin >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> For something that was agreed to be parked a few >>>>>>>>>>> hours ago, there sure seems to still be a lot of >>>>>>>>>>> circular discussion. Should we ask a mediator to >>>>>>>>>>> intervene? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> FWIW I believe that is a significantly strong >>>>>>>>>>> reason to differentiate an access token that can >>>>>>>>>>> access the registration information without >>>>>>>>>>> having the ability to access protected data. >>>>>>>>>>> Especially given the implied strength of the >>>>>>>>>>> �client credential� obtained access token. I >>>>>>>>>>> have found it extremely confusing to users when >>>>>>>>>>> explaining the difference between an access >>>>>>>>>>> token obtained thorough an authorization code >>>>>>>>>>> flow and a client credential flow, simply >>>>>>>>>>> because they are both called an �access token�. >>>>>>>>>>> Changing the meaning of an access token obtained >>>>>>>>>>> through the client credential flow to mean it >>>>>>>>>>> has the ability to update a registration, when a >>>>>>>>>>> user may not want it to have access to protected >>>>>>>>>>> data will only increase both the complexity of >>>>>>>>>>> the access tokens as well as make their usage >>>>>>>>>>> harder to explain to non-technical individuals >>>>>>>>>>> who have to understand the differences between >>>>>>>>>>> the access tokens obtained through the various >>>>>>>>>>> flows. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Just my two cents. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> Don >>>>>>>>>>> >>>>>>>>>>> Donald F. Coffin >>>>>>>>>>> >>>>>>>>>>> Founder/CTO >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> REMI Networks >>>>>>>>>>> >>>>>>>>>>> 22751 El Prado Suite 6216 >>>>>>>>>>> >>>>>>>>>>> Rancho Santa Margarita, CA 92688-3836 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Phone: (949) 636-8571 >>>>>>>>>>> >>>>>>>>>>> Email: donald.coffin@reminetworks.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *From:*Phil Hunt [mailto:phil.hunt@oracle.com] >>>>>>>>>>> *Sent:* Friday, May 31, 2013 11:11 AM >>>>>>>>>>> *To:* Justin Richer >>>>>>>>>>> *Cc:* oauth@ietf.org WG >>>>>>>>>>> *Subject:* Re: [OAUTH-WG] review comments on >>>>>>>>>>> draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> To be clear. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It is two separate issues. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1. Anonymous clients can easily be handled >>>>>>>>>>> through policy config. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2. Support for implicit clients needs to be >>>>>>>>>>> discussed. The current proposal creates large >>>>>>>>>>> negative value for the service provider and most >>>>>>>>>>> would never allow in current form. Yes it gives >>>>>>>>>>> each execution instance a new id, but that isnt >>>>>>>>>>> what sp's want. It is a huge attack and >>>>>>>>>>> management headache. Eliminate or propose a >>>>>>>>>>> different solution. >>>>>>>>>>> >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2013-05-31, at 13:58, Justin Richer >>>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> I'm not willing to write out an entire class >>>>>>>>>>> of clients from this spec, especially when >>>>>>>>>>> we have stated use cases for them doing >>>>>>>>>>> dynamic registration. >>>>>>>>>>> >>>>>>>>>>> I'm sorry, but your proposed solution will >>>>>>>>>>> simply not work. >>>>>>>>>>> >>>>>>>>>>> -- Justin >>>>>>>>>>> >>>>>>>>>>> On 05/31/2013 01:56 PM, Phil Hunt wrote: >>>>>>>>>>> >>>>>>>>>>> Well the only client that wouldn't have >>>>>>>>>>> a credential is an implicit client. An >>>>>>>>>>> implicit client is transient and so >>>>>>>>>>> would never update. >>>>>>>>>>> >>>>>>>>>>> Besides, as i have stated, implicit >>>>>>>>>>> clients should not use dyn reg. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2013-05-31, at 13:41, Justin Richer >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> But the outstanding question is: how >>>>>>>>>>> do you get the access token to >>>>>>>>>>> access the created resource (IE: the >>>>>>>>>>> Registration Access Token)? You >>>>>>>>>>> can't use the client_credentials >>>>>>>>>>> flow for a client with no credentials! >>>>>>>>>>> >>>>>>>>>>> -- Justin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 05/31/2013 12:58 PM, Phil Hunt wrote: >>>>>>>>>>> >>>>>>>>>>> Yes. I specified the trivial >>>>>>>>>>> solution to anonymous clients >>>>>>>>>>> earlier. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Even simpler. You don't need an >>>>>>>>>>> access token to create a new >>>>>>>>>>> resource. You just need one to >>>>>>>>>>> access one. That is just basic >>>>>>>>>>> security config. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2013-05-31, at 12:34, Justin >>>>>>>>>>> Richer >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> I agree that we are going in >>>>>>>>>>> circles, since I just was >>>>>>>>>>> going to bring up my counter >>>>>>>>>>> argument of "what about >>>>>>>>>>> clients with no >>>>>>>>>>> credentials?" again, which >>>>>>>>>>> *still* isn't addressed by >>>>>>>>>>> what you suggest doing, >>>>>>>>>>> below. I also believe that >>>>>>>>>>> getting rid of the >>>>>>>>>>> Registration Access Token >>>>>>>>>>> but using some other token >>>>>>>>>>> method would actually make >>>>>>>>>>> the spec larger, though I'd >>>>>>>>>>> be glad to review a concrete >>>>>>>>>>> counter-proposal if you'd >>>>>>>>>>> like to write one. And the >>>>>>>>>>> fact that OIDC is doing it >>>>>>>>>>> this way, and considered but >>>>>>>>>>> rejected the way that you're >>>>>>>>>>> describing, should say >>>>>>>>>>> something to the WG here >>>>>>>>>>> about whether or not this is >>>>>>>>>>> the right choice. Rough >>>>>>>>>>> consensus and running code, >>>>>>>>>>> after all. >>>>>>>>>>> >>>>>>>>>>> Regardless, I agree to park >>>>>>>>>>> this issue and leave the >>>>>>>>>>> text as is. We'll move to >>>>>>>>>>> the next draft in the last >>>>>>>>>>> call process shortly, as I >>>>>>>>>>> have a handful of >>>>>>>>>>> non-normative editorial >>>>>>>>>>> changes that I need to make, >>>>>>>>>>> thanks to feedback from a >>>>>>>>>>> few folks. >>>>>>>>>>> >>>>>>>>>>> Again, thanks for your >>>>>>>>>>> thorough review, Phil, and I >>>>>>>>>>> look forward to future feedback. >>>>>>>>>>> >>>>>>>>>>> -- Justin >>>>>>>>>>> >>>>>>>>>>> On 05/31/2013 12:28 PM, Phil >>>>>>>>>>> Hunt wrote: >>>>>>>>>>> >>>>>>>>>>> I disagree. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> There is absolutely no >>>>>>>>>>> need for a registration >>>>>>>>>>> access token. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Get rid of it and just >>>>>>>>>>> use access tokens as per >>>>>>>>>>> 6749. If you can't >>>>>>>>>>> follow 6749 and need new >>>>>>>>>>> issuing methods, what >>>>>>>>>>> are others to say >>>>>>>>>>> regarding inventing new >>>>>>>>>>> methods? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I have not heard a good >>>>>>>>>>> reason for the special >>>>>>>>>>> process or one good >>>>>>>>>>> enough to warrant a new >>>>>>>>>>> method for issuing an >>>>>>>>>>> access token. Does the >>>>>>>>>>> broader group realize >>>>>>>>>>> this is what the spec says? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yes, i heard a lot >>>>>>>>>>> saying OIDC does it this >>>>>>>>>>> way. But that is a >>>>>>>>>>> political reason, not a >>>>>>>>>>> technical reason. Still, >>>>>>>>>>> compatibility is always >>>>>>>>>>> a strong objective. >>>>>>>>>>> Even so, oidc could >>>>>>>>>>> keep using their method >>>>>>>>>>> just fine. There is no >>>>>>>>>>> obligation here to do >>>>>>>>>>> the same. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The only reason so far >>>>>>>>>>> was expiry of client >>>>>>>>>>> creds. Well, why not >>>>>>>>>>> require the client to >>>>>>>>>>> update prior to expiry? >>>>>>>>>>> It makes no sense to >>>>>>>>>>> have another token with >>>>>>>>>>> longer expiry. B'sides, >>>>>>>>>>> even expired the client >>>>>>>>>>> can re-register from >>>>>>>>>>> scratch. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Why force the client to >>>>>>>>>>> persist multiple tokens >>>>>>>>>>> and creds? That is far >>>>>>>>>>> far too complex. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Finally if you get rid >>>>>>>>>>> of registration access >>>>>>>>>>> token the spec size will >>>>>>>>>>> drop roughly in half >>>>>>>>>>> IMO. This suggests >>>>>>>>>>> simplicity to me. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Apologies for my rant. >>>>>>>>>>> Maybe we should park >>>>>>>>>>> this for now. We are >>>>>>>>>>> going in circles. >>>>>>>>>>> >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2013-05-31, at 11:25, >>>>>>>>>>> Justin Richer >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Phil, >>>>>>>>>>> >>>>>>>>>>> We *can* keep it >>>>>>>>>>> straight just fine, >>>>>>>>>>> but I just need you >>>>>>>>>>> to be clear about >>>>>>>>>>> which part you're >>>>>>>>>>> objecting to because >>>>>>>>>>> the answers are >>>>>>>>>>> different. Please >>>>>>>>>>> use the terms as >>>>>>>>>>> defined in the >>>>>>>>>>> document so that we >>>>>>>>>>> all know which >>>>>>>>>>> component we're >>>>>>>>>>> talking about. I'm >>>>>>>>>>> sure you'd agree >>>>>>>>>>> than in >>>>>>>>>>> specification work >>>>>>>>>>> such as this, >>>>>>>>>>> precision of >>>>>>>>>>> language and labels >>>>>>>>>>> is key for >>>>>>>>>>> communication >>>>>>>>>>> between parties. >>>>>>>>>>> This is precisely >>>>>>>>>>> why there's a >>>>>>>>>>> Terminology section >>>>>>>>>>> right up front, so >>>>>>>>>>> that when I say >>>>>>>>>>> "Registration Access >>>>>>>>>>> Token" you can know >>>>>>>>>>> that I mean a very >>>>>>>>>>> specific thing, and >>>>>>>>>>> when I say "Initial >>>>>>>>>>> Registration Token" >>>>>>>>>>> I mean a very >>>>>>>>>>> different specific >>>>>>>>>>> thing. So I'm asking >>>>>>>>>>> you, please, use the >>>>>>>>>>> defined terms so >>>>>>>>>>> that we can avoid >>>>>>>>>>> this unnecessary >>>>>>>>>>> confusion. >>>>>>>>>>> >>>>>>>>>>> But anyway, what >>>>>>>>>>> you're talking about >>>>>>>>>>> below, "the token >>>>>>>>>>> the client uses to >>>>>>>>>>> update is profile" >>>>>>>>>>> *IS* the >>>>>>>>>>> Registration Access >>>>>>>>>>> Token. That's all >>>>>>>>>>> that that token is >>>>>>>>>>> used for. You're not >>>>>>>>>>> asking for it to go >>>>>>>>>>> away, you're asking >>>>>>>>>>> for it to come from >>>>>>>>>>> the Token Endpoint >>>>>>>>>>> instead of the >>>>>>>>>>> response from the >>>>>>>>>>> Registration >>>>>>>>>>> Endpoint. I don't >>>>>>>>>>> see how the client >>>>>>>>>>> *can* get it from >>>>>>>>>>> the normal token >>>>>>>>>>> process without >>>>>>>>>>> jumping through >>>>>>>>>>> specialized hoops to >>>>>>>>>>> make that happen. >>>>>>>>>>> I've implemented the >>>>>>>>>>> draft the way that >>>>>>>>>>> it is right now, >>>>>>>>>>> both client and >>>>>>>>>>> server side, and it >>>>>>>>>>> works. Others have >>>>>>>>>>> implemented it, too. >>>>>>>>>>> We've done interop >>>>>>>>>>> testing, and it >>>>>>>>>>> works. This is a >>>>>>>>>>> proven pattern and >>>>>>>>>>> from where I sit >>>>>>>>>>> there is both rough >>>>>>>>>>> consensus and >>>>>>>>>>> running code. >>>>>>>>>>> >>>>>>>>>>> I believe that I've >>>>>>>>>>> already pointed out >>>>>>>>>>> how the solutions >>>>>>>>>>> you've proposed so >>>>>>>>>>> far won't work in >>>>>>>>>>> practice, for >>>>>>>>>>> various reasons, >>>>>>>>>>> many of which have >>>>>>>>>>> already been brought >>>>>>>>>>> up and discussed >>>>>>>>>>> previously. If you >>>>>>>>>>> have another way for >>>>>>>>>>> the client to get >>>>>>>>>>> its Registration >>>>>>>>>>> Access Token, please >>>>>>>>>>> propose it; but I >>>>>>>>>>> haven't seen >>>>>>>>>>> anything yet that >>>>>>>>>>> will fly. >>>>>>>>>>> >>>>>>>>>>> -- Justin >>>>>>>>>>> >>>>>>>>>>> On 05/31/2013 11:10 >>>>>>>>>>> AM, Phil Hunt wrote: >>>>>>>>>>> >>>>>>>>>>> Justin, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is my >>>>>>>>>>> primary >>>>>>>>>>> objection! We >>>>>>>>>>> can't keep it >>>>>>>>>>> straight. Their >>>>>>>>>>> should be no >>>>>>>>>>> such thing as a >>>>>>>>>>> registrstion >>>>>>>>>>> access token! >>>>>>>>>>> Just the token >>>>>>>>>>> the client >>>>>>>>>>> obtains to >>>>>>>>>>> update its >>>>>>>>>>> profile through >>>>>>>>>>> the normal token >>>>>>>>>>> request process. >>>>>>>>>>> >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2013-05-31, >>>>>>>>>>> at 10:55, Justin >>>>>>>>>>> Richer >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Which token >>>>>>>>>>> are you >>>>>>>>>>> referring to >>>>>>>>>>> here? >>>>>>>>>>> >>>>>>>>>>> If it's the >>>>>>>>>>> Initial >>>>>>>>>>> Registration >>>>>>>>>>> Token, then >>>>>>>>>>> you could >>>>>>>>>>> get that >>>>>>>>>>> through the >>>>>>>>>>> normal token >>>>>>>>>>> server no >>>>>>>>>>> problem. >>>>>>>>>>> (The >>>>>>>>>>> lifecycle >>>>>>>>>>> writeups >>>>>>>>>>> don't call >>>>>>>>>>> this out >>>>>>>>>>> explicitly >>>>>>>>>>> but I would >>>>>>>>>>> be willing >>>>>>>>>>> to do so.) >>>>>>>>>>> Or you could >>>>>>>>>>> get it >>>>>>>>>>> elsewhere. >>>>>>>>>>> Doesn't >>>>>>>>>>> matter, just >>>>>>>>>>> like it >>>>>>>>>>> doesn't >>>>>>>>>>> matter with >>>>>>>>>>> any other >>>>>>>>>>> OAuth2 >>>>>>>>>>> protected >>>>>>>>>>> resource. >>>>>>>>>>> >>>>>>>>>>> If it's the >>>>>>>>>>> Registration >>>>>>>>>>> Access >>>>>>>>>>> Token, then >>>>>>>>>>> having the >>>>>>>>>>> token come >>>>>>>>>>> from the >>>>>>>>>>> token >>>>>>>>>>> endpoint >>>>>>>>>>> would >>>>>>>>>>> require a >>>>>>>>>>> lot more >>>>>>>>>>> work and >>>>>>>>>>> complexity >>>>>>>>>>> on behalf of >>>>>>>>>>> both of the >>>>>>>>>>> client and >>>>>>>>>>> server. >>>>>>>>>>> Either you >>>>>>>>>>> end up with >>>>>>>>>>> public >>>>>>>>>>> clients >>>>>>>>>>> getting >>>>>>>>>>> secrets they >>>>>>>>>>> shouldn't >>>>>>>>>>> need or with >>>>>>>>>>> granting >>>>>>>>>>> clients >>>>>>>>>>> access to >>>>>>>>>>> the >>>>>>>>>>> client_credentials >>>>>>>>>>> flow when >>>>>>>>>>> they >>>>>>>>>>> shouldn't >>>>>>>>>>> actually >>>>>>>>>>> have it. >>>>>>>>>>> Plus it adds >>>>>>>>>>> extra round >>>>>>>>>>> trips which >>>>>>>>>>> don't buy >>>>>>>>>>> you anything. >>>>>>>>>>> >>>>>>>>>>> -- Justin >>>>>>>>>>> >>>>>>>>>>> On >>>>>>>>>>> 05/31/2013 >>>>>>>>>>> 10:15 AM, >>>>>>>>>>> Phil Hunt wrote: >>>>>>>>>>> >>>>>>>>>>> The >>>>>>>>>>> preference >>>>>>>>>>> is to >>>>>>>>>>> have the >>>>>>>>>>> access >>>>>>>>>>> token >>>>>>>>>>> for >>>>>>>>>>> registration >>>>>>>>>>> issued >>>>>>>>>>> by the >>>>>>>>>>> normal >>>>>>>>>>> token >>>>>>>>>>> server >>>>>>>>>>> rather >>>>>>>>>>> then by >>>>>>>>>>> the >>>>>>>>>>> registration >>>>>>>>>>> endpoint. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In the >>>>>>>>>>> current >>>>>>>>>>> draft it >>>>>>>>>>> is >>>>>>>>>>> obtained >>>>>>>>>>> through >>>>>>>>>>> a unique >>>>>>>>>>> process >>>>>>>>>>> and must >>>>>>>>>>> outlive >>>>>>>>>>> the client. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On >>>>>>>>>>> 2013-05-30, >>>>>>>>>>> at >>>>>>>>>>> 19:47, >>>>>>>>>>> "Richer, >>>>>>>>>>> Justin >>>>>>>>>>> P." >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> I >>>>>>>>>>> don't understand >>>>>>>>>>> any >>>>>>>>>>> of >>>>>>>>>>> the >>>>>>>>>>> comments >>>>>>>>>>> below -- >>>>>>>>>>> it >>>>>>>>>>> already >>>>>>>>>>> *is* >>>>>>>>>>> an >>>>>>>>>>> OAuth2 >>>>>>>>>>> protected >>>>>>>>>>> resource >>>>>>>>>>> without >>>>>>>>>>> any >>>>>>>>>>> special >>>>>>>>>>> handling. >>>>>>>>>>> Your >>>>>>>>>>> access >>>>>>>>>>> tokens >>>>>>>>>>> can >>>>>>>>>>> be >>>>>>>>>>> short-lived, >>>>>>>>>>> long-lived, >>>>>>>>>>> federated, >>>>>>>>>>> structured, >>>>>>>>>>> random >>>>>>>>>>> blobs ... >>>>>>>>>>> totally >>>>>>>>>>> doesn't >>>>>>>>>>> matter. >>>>>>>>>>> They >>>>>>>>>>> are >>>>>>>>>>> access >>>>>>>>>>> tokens >>>>>>>>>>> being used >>>>>>>>>>> to >>>>>>>>>>> access >>>>>>>>>>> a >>>>>>>>>>> normal >>>>>>>>>>> protected >>>>>>>>>>> resource. >>>>>>>>>>> Full >>>>>>>>>>> stop. >>>>>>>>>>> >>>>>>>>>>> Anything >>>>>>>>>>> else >>>>>>>>>>> is >>>>>>>>>>> out >>>>>>>>>>> of >>>>>>>>>>> scope. >>>>>>>>>>> The >>>>>>>>>>> lifecycle >>>>>>>>>>> discussions >>>>>>>>>>> at >>>>>>>>>>> the >>>>>>>>>>> beginning >>>>>>>>>>> are >>>>>>>>>>> merely >>>>>>>>>>> examples >>>>>>>>>>> of >>>>>>>>>>> some >>>>>>>>>>> ways >>>>>>>>>>> you >>>>>>>>>>> *could* >>>>>>>>>>> use >>>>>>>>>>> it >>>>>>>>>>> and >>>>>>>>>>> are >>>>>>>>>>> non-normative >>>>>>>>>>> and >>>>>>>>>>> non-exhaustive. >>>>>>>>>>> >>>>>>>>>>> You >>>>>>>>>>> seem >>>>>>>>>>> to >>>>>>>>>>> be >>>>>>>>>>> asking >>>>>>>>>>> for >>>>>>>>>>> something >>>>>>>>>>> that's >>>>>>>>>>> already >>>>>>>>>>> in >>>>>>>>>>> the >>>>>>>>>>> draft. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Justin >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> *From:*Phil >>>>>>>>>>> Hunt >>>>>>>>>>> [phil.hunt@oracle.com >>>>>>>>>>> ] >>>>>>>>>>> *Sent:* >>>>>>>>>>> Thursday, >>>>>>>>>>> May >>>>>>>>>>> 30, >>>>>>>>>>> 2013 >>>>>>>>>>> 7:31 PM >>>>>>>>>>> *To:* Richer, >>>>>>>>>>> Justin >>>>>>>>>>> P. >>>>>>>>>>> *Cc:* John >>>>>>>>>>> Bradley; >>>>>>>>>>> oauth@ietf.org >>>>>>>>>>> >>>>>>>>>>> WG >>>>>>>>>>> *Subject:* >>>>>>>>>>> Re: >>>>>>>>>>> [OAUTH-WG] >>>>>>>>>>> review >>>>>>>>>>> comments >>>>>>>>>>> on >>>>>>>>>>> draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On >>>>>>>>>>> 2013-05-30, >>>>>>>>>>> at >>>>>>>>>>> 16:11, >>>>>>>>>>> "Richer, >>>>>>>>>>> Justin >>>>>>>>>>> P." >>>>>>>>>>> >>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Comments >>>>>>>>>>> inline, >>>>>>>>>>> marked >>>>>>>>>>> by >>>>>>>>>>> [JR]. >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> *From:*Phil >>>>>>>>>>> Hunt >>>>>>>>>>> [phil.hunt@oracle.com >>>>>>>>>>> ] >>>>>>>>>>> *Sent:* >>>>>>>>>>> Thursday, >>>>>>>>>>> May >>>>>>>>>>> 30, >>>>>>>>>>> 2013 >>>>>>>>>>> 5:25 >>>>>>>>>>> PM >>>>>>>>>>> *To:* >>>>>>>>>>> Richer, >>>>>>>>>>> Justin >>>>>>>>>>> P. >>>>>>>>>>> *Cc:* >>>>>>>>>>> John >>>>>>>>>>> Bradley; >>>>>>>>>>> oauth@ietf.org >>>>>>>>>>> >>>>>>>>>>> WG >>>>>>>>>>> *Subject:* >>>>>>>>>>> Re: >>>>>>>>>>> [OAUTH-WG] >>>>>>>>>>> review >>>>>>>>>>> comments >>>>>>>>>>> on >>>>>>>>>>> draft-ietf-oauth-dyn-reg-11.txt >>>>>>>>>>> >>>>>>>>>>> See >>>>>>>>>>> below. >>>>>>>>>>> >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> @independentid >>>>>>>>>>> >>>>>>>>>>> www.independentid.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On >>>>>>>>>>> 2013-05-30, >>>>>>>>>>> at >>>>>>>>>>> 2:09 >>>>>>>>>>> PM, >>>>>>>>>>> Justin >>>>>>>>>>> Richer >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> OK, >>>>>>>>>>> I think >>>>>>>>>>> see >>>>>>>>>>> part >>>>>>>>>>> of >>>>>>>>>>> the >>>>>>>>>>> hang >>>>>>>>>>> up. >>>>>>>>>>> I have >>>>>>>>>>> not >>>>>>>>>>> seen >>>>>>>>>>> the >>>>>>>>>>> scenario >>>>>>>>>>> that >>>>>>>>>>> you >>>>>>>>>>> describe, >>>>>>>>>>> where >>>>>>>>>>> you >>>>>>>>>>> trade >>>>>>>>>>> a 3rd >>>>>>>>>>> party >>>>>>>>>>> token >>>>>>>>>>> for >>>>>>>>>>> a "local" >>>>>>>>>>> token. >>>>>>>>>>> I have >>>>>>>>>>> seen >>>>>>>>>>> where >>>>>>>>>>> access >>>>>>>>>>> tokens >>>>>>>>>>> are >>>>>>>>>>> federated >>>>>>>>>>> directly >>>>>>>>>>> at >>>>>>>>>>> the >>>>>>>>>>> PR. >>>>>>>>>>> (Introspection >>>>>>>>>>> lets >>>>>>>>>>> you >>>>>>>>>>> do >>>>>>>>>>> some >>>>>>>>>>> good >>>>>>>>>>> things >>>>>>>>>>> with >>>>>>>>>>> that >>>>>>>>>>> pattern.) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --------------090707000100020606000304 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Before they register, they're neither public nor private. After they register, they're either public or private depending on if they want to/can use a client secret or equivalent to talk to the token endpoint.

Also, having a client register and allowing it to get a token through the client_credentials flow (without a user in the loop) is potentially dangerous unless things are very carefully scope-limited anyway.

�-- Justin

On 06/06/2013 01:51 PM, Phil Hunt wrote:

When they are issued their client credential after successfully registering�.isn't that the whole point of the process?

Once they register, they are no longer public. �After that, they just get a token like everyone else.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:49 AM, Justin Richer wrote:

Then how do they get their equivalent of a registration access token to manage their configurations?

The draft proposes that they get this token right from the registration endpoint. You're proposing that they get this from the token endpoint.

The initial access token isn't even in play here.

�-- Justin

On 06/06/2013 01:49 PM, Phil Hunt wrote:

Huh?

There's no need for public clients to access the token endpoint as they can register anonymously.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:47 AM, Justin Richer wrote:

Because anonymous *registration* and public client *access* to the token endpoint are two different things.

�-- Justin

On 06/06/2013 01:43 PM, Phil Hunt wrote:

*why* will the 6749 standard flows (specifically 4.4) not work?

The registration endpoint can allow anonymous access to permit anonymous registration.

This means the configuration endpoints can use normal access tokens obtained through RFC6749 section 4.4 (Client Auth) flows.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:36 AM, Justin Richer wrote:

... because it already *is* a REST protected API. It's protected with the Registration Access Token. Which is an OAuth 2.0 Bearer token.

The *only* difference is how you get the token, which has nothing to do with the REST protected API that it's protecting.

�-- Justin

On 06/06/2013 01:35 PM, Phil Hunt wrote:

Nobody has explained why using a normal REST protected API won't work. You keep saying that and that you won't go back. �But that doesn't explain the issue.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:28 AM, Justin Richer wrote:

I feel we're still just going in circles with these arguments, but my comments are inline:

On 06/06/2013 01:17 PM, Phil Hunt wrote:

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 9:49 AM, Justin Richer wrote:

Tim, thanks for your review! Comments inline.

On 06/05/2013 04:59 PM, Tim Bray wrote:

FWIW, I just read the spec through with fresh eyes, and I found the explanation of the workflow in 1.4.2 very useful. �

- A developer manually registers and then is able to request �Initial tokens� tokens for a dynamic-app-registration-scope,�

- you use that �Initial token� token to register, in exchange you get the client-id & so on, and also a a per-registration �Registration token� for updating that particular registration information

- you fetch/update/delete your registration information with that registration token.

The first part, where the developer registers & gets a token for a scope, is vanilla OAuth 2. (right?)�

Yes, it can be vanilla Oauth2 or it can be the developer (or someone) getting a token through some other means, like browsing to a developer portal and getting a Bearer token. I've edited the example in 1.4.3 in the latest (unpublished) text so that the developer is literally doing OAuth2 to get the initial token. It's important to note that this could be any flavor of OAuth2 token, though Bearer tokens are of course the most common.

The bit about getting an access token specific to that registration is a new flow (right?), but it seems convenient.

Right, it's a new way to get a bearer token so that you can use it at the protected resource. We wanted to re-use the token endpoint for this, but couldn't come up with a reasonable way of doing so (as has been discussed on the list.

[PH] We still greatly disagree on this.

*Use the normal token issuing process.* �One reason given was what about anonymous clients? �The answer is, they don't have to do anything. Remember that you have defined TWO endpoints. �The "registration endpoint" and the "configuration endpoint". �A server accepting anonymous registration simply accepts anonymous access at the "registration endpoint". �Clients wanting to update their profiles do the normal client token request flow to the token endpoint to obtain a normal access token useable at the "configuration endpoint".

[JR] But then you're opening up the client_credentials flow to anonymous clients, or you've got to be able to lock down client_credentials as a flow to only a special (service-specific) scope for client configuration purposes. This, I think, is much more complicated to implement and much more error prone. I don't think it's even possible in the software stack we're building on top of. And furthermore, you're not letting public clients dynamically register anymore, since you'd be forcing everyone to have a client secret. Your dynamic public clients would have to save the client secret but know to only use it at the registration endpoint, and not the token endpoint where they're used to. This way, it's clear. You get a token that you use at a given endpoint, the end.

As soon as you do this, other things simplify.

1. �No need to keep "registration access token" around indefinitely. It's just an access token. �In fact it is only needed for minutes since it will likely only be used to read or update profiles or to perform client initiated credential rotation.

[JR] You *can* throw away your registration access tokens if you want to, or have them expire, if you want to limit the lifespan of your clients. It's only the security considerations section that suggests against expiring the tokens, and for good reason. But it's your choice to change that if you don't want longstanding read/edit access to a client's configuration.

2. �No need to have a special token issuing method.�Creating a new issuing process suggests that the WG can't drink its own koolaid. �Because at the first seeming challenge, the WG create a new flow. How do we expect implementers to behave?

[JR] That particular koolaid wasn't the right drink here, to stretch your analogy. Bearer tokens were, which is also the group's koolaid. We tried to go down the road you suggest and it was a dead end. Why do you think it will work better this time? And I'd like to point out a decision from several years ago now to separate the notion of "how you get a token" from "how you use a token" in OAuth2. OAuth1 had all of these rolled in together, and deployment experience showed us that people didn't really want to use it that way. People want components that make sense on their own that let you build systems like this that also make sense.

Forced uniformity isn't necessarily a good thing.

3. �The registration/configuration API is JUST a normal OAuth2 protected API.

[JR] It already is. Protected resources don't care where you get your tokens from, just that you have them, so from that perspective it is just a protected resource. Our implementation here literally just looks for the token on the way in in the auth layer and makes sure it's got a special service-specific scope that handles registration.

If the draft drops "registration access tokens", a lot of the text in the draft disappears. �The whole spec is much simpler.

[JR] Much simpler, perhaps, but much less functional and useful. And honestly, not much of the text actually goes away. Most of the draft isn't about dealing with the registration access token, it's about dealing with the client metadata and the RESTful protocol for managing that. The registration access token is a mechanism for doing so.

� From an OAuth 2 point of view, there's nothing special about how you get or use the Initial token, but giving it a special name makes explaining a plausible workflow easier.�

Right, and I've admitted that "Initial Access Token" a crappy name, but I haven't heard a better suggestion yet.

Having said that, I have trouble imagining the scenario where you'd use the 1.4.1 flow, but that may be because of my Google-centric worldview.

Could be -- but if Google wants to be an open-registration identity provider (like it has been with OpenID 2.0), it will need to handle this flow as well. This is the client acting on its own behalf, showing up and saying "hi, I'm a client!" and that's that. I think this is a very important case for interoperability of dynamic registration.

And I�m not sure 1.4.3 adds any value at all. �It just seems to be a matter of different ways you could get and make use of the registration access token; and I'm sure there are various interesting combinations that haven't been thought of there. �I'd just lose 1.4.3.

1.4.3 in -11 is too close to 1.4.2, so what I've done in the current working text is make the initial process of getting the Initial Access Token different (the developer now uses OAuth2 to configure their build environment). The *real* important difference that's being shown here, though, is that the client doesn't call the registration endpoint, the developer (and their build environment) does. So yes, it's exactly all about how you get and use the registration access token. There are plenty of other ways to do it as well, so that's why this section was a non-normative set of examples. To facilitate that understanding, I've moved it to an appendix in the working copy of draft -12.

Thanks,
�-- Justin

�-T

On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin <donald.coffin@reminetworks.com> wrote:

See my comments inline [DFC]

�

Best regards,

Don

Donald F. Coffin

Founder/CTO

�

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA� 92688-3836

�

Phone:�� (949) 636-8571

Email:�� donald.coffin@reminetworks.com

�

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, May 31, 2013 12:40 PM
To: Phil Hunt
Cc: Donald F Coffin; oauth@ietf.org

Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

�

I feel the need to clarify a couple erroneous things in Phil's statement:

� * To be clear, Draft 11 has the same Registration Access Token system that has been in place since draft 01, it is not inventing something new at the last minute as could be inferred from the statement below.

[DFC] �I agree with Justin.� There is nothing new in draft 11 regarding Registration Access Tokens that wasn�t in the initial draft.� It appears because Phil hasn�t been following the proposed drafts until the last call he is now raising an issue no one in the WG saw as an issue.� That�s not to say his point isn�t valid, but the discussion continues to go all over the map between �local� and �federated� tokens, usage of the RFC6749 �Token� endpoint, etc.� It would be great if all of Phil�s points could be addressed in priority
without the threads becoming so convoluted no one is able to make sense or even comprehend the point being discussed.

� * DynReg is using an absolutely standard OAuth 2 Bearer token as the Registration Access Token, it's just not coming from a Token Endpoint. However, since an OAuth Protected Resource doesn't care where its tokens come from so long as it can validate them, I don't see this as a problem -- this is a key point where Phil and I disagree.

[DFC] �I understand the disagreement, but I have not seen a proposal from Phil that would describe the differences between the two perspectives other than to say that the Dynamic Registration should use the Token endpoint defined in RFC6749, which does not�� discuss dynamic registration.� Phil�s point as I understand it is that there should be no difference between an access token used to access resource owner protected data and the registration structure, which I do not agree with.� As I said in the previous
�� response, my users do NOT want to provide implied access to resource owner protected data just because a client is creating a registration with an AS.� This would be the situation if the client credential flow is used to register an application.� Since our
�� implementation does NOT support the implicit flow, that use case is one we have elected NOT to support.

�� [DFC]� I repeat my initial comment, this conversation has been a circular exchange now for the past few days without any appearance of an alternative option to resolve the issues.

�-- Justin

On 05/31/2013 03:33 PM, Phil Hunt wrote:

Don,

�

I am not proposing any change in meaning. If registration acces token issues by normal token server with scope registration everything is clear as it is for any other protected API. Draft 11 invents a whole new system. I strongly disagree with this.

Phil

On 2013-05-31, at 15:16, Donald F Coffin <donald.coffin@reminetworks.com> wrote:

For something that was agreed to be parked a few hours ago, there sure seems to still be a lot of circular discussion.� Should we ask a mediator to intervene?

�

FWIW I believe that is a significantly strong reason to differentiate an access token that can access the registration information without having the ability to access protected data.� Especially given the implied strength of the �client credential� obtained access token.� I have found it extremely confusing to users when explaining the difference between an access token obtained thorough an authorization code flow and a client credential flow, simply because they are both called an �access token�.� Changing the meaning of an access token obtained through the client credential flow to mean it has the ability to update a registration, when a user may not want it to have access to protected data will only increase both the complexity of the access tokens as well as make their usage harder to explain to non-technical individuals who have to understand the differences between the access tokens obtained through the various flows.

�

Just my two cents.

�

Best regards,

Don

Donald F. Coffin

Founder/CTO

�

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA� 92688-3836

�

Phone:�� (949) 636-8571

Email:�� donald.coffin@reminetworks.com

�

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Friday, May 31, 2013 11:11 AM
To: Justin Richer
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

�

To be clear.�

�

It is two separate issues.�

�

1. Anonymous clients can easily be handled through policy config.�

�

2. Support for implicit clients needs to be discussed. The current proposal creates large negative value for the service provider and most would never allow in current form. Yes it gives each execution instance a new id, but that isnt what sp's want. It is a huge attack and management headache. Eliminate or propose a different solution.�

Phil

On 2013-05-31, at 13:58, Justin Richer <jricher@mitre.org> wrote:

I'm not willing to write out an entire class of clients from this spec, especially when we have stated use cases for them doing dynamic registration.

I'm sorry, but your proposed solution will simply not work.

�-- Justin

On 05/31/2013 01:56 PM, Phil Hunt wrote:

Well the only client that wouldn't have a credential is an implicit client. An implicit client is transient and so would never update.�

Besides, as i have stated, implicit clients should not use dyn reg.�

Phil

On 2013-05-31, at 13:41, Justin Richer <jricher@mitre.org> wrote:

But the outstanding question is: how do you get the access token to access the created resource (IE: the Registration Access Token)? You can't use the client_credentials flow for a client with no credentials!

�-- Justin

On 05/31/2013 12:58 PM, Phil Hunt wrote:

Yes. I specified the trivial solution to anonymous clients earlier.

�

Even simpler. You don't need an access token to create a new resource. You just need one to access one. That is just basic security config.�

Phil

On 2013-05-31, at 12:34, Justin Richer <jricher@mitre.org> wrote:

I agree that we are going in circles, since I just was going to bring up my counter argument of "what about clients with no credentials?" again, which *still* isn't addressed by what you suggest doing, below. I also believe that getting rid of the Registration Access Token but using some other token method would actually make the spec larger, though I'd be glad to review a concrete counter-proposal if you'd like to write one. And the fact that OIDC is doing it this way, and considered but rejected the way that you're describing, should say something to the WG here about whether or not this is the right choice. Rough consensus and running code, after all.

Regardless, I agree to park this issue and leave the text as is. We'll move to the next draft in the last call process shortly, as I have a handful of non-normative editorial changes that I need to make, thanks to feedback from a few folks.

Again, thanks for your thorough review, Phil, and I look forward to future feedback.

�-- Justin

On 05/31/2013 12:28 PM, Phil Hunt wrote:

I disagree.�

�

There is absolutely no need for a registration access token.�

�

Get rid of it and just use access tokens as per 6749. If you can't follow 6749 and need new issuing methods, what are others to say regarding inventing new methods?

�

I have not heard a good reason for the special process or one good enough to warrant a new method for issuing an access token. Does the broader group realize this is what the spec says?

�

Yes, i heard a lot saying OIDC does it this way. But that is a political reason, not a technical reason. Still, compatibility is always a strong objective. �Even so, oidc could keep using their method just fine. There is no obligation here to do the same.�

�

The only reason so far was expiry of client creds. Well, why not require the client to update prior to expiry? It makes no sense to have another token with longer expiry. B'sides, even expired the client can re-register from scratch.�

�

Why force the client to persist multiple tokens and creds? That is far far too complex.�

�

Finally if you get rid of registration access token the spec size will drop roughly in half IMO. This suggests simplicity to me.�

�

Apologies for my rant. Maybe we should park this for now. We are going in circles.�

Phil

On 2013-05-31, at 11:25, Justin Richer <jricher@mitre.org> wrote:

Phil,

We *can* keep it straight just fine, but I just need you to be clear about which part you're objecting to because the answers are different. Please use the terms as defined in the document so that we all know which component we're talking about. I'm sure you'd agree than in specification work such as this, precision of language and labels is key for communication between parties. This is precisely why there's a Terminology section right up front, so that when I say "Registration Access Token" you can know that I mean a very specific thing, and when I say "Initial Registration Token" I mean a very different specific thing. So I'm asking you, please, use the defined terms so that we can avoid this unnecessary confusion.

But anyway, what you're talking about below, "the token the client uses to update is profile" *IS* the Registration Access Token. That's all that that token is used for. You're not asking for it to go away, you're asking for it to come from the Token Endpoint instead of the response from the Registration Endpoint. I don't see how the client *can* get it from the normal token process without jumping through specialized hoops to make that happen. I've implemented the draft the way that it is right now, both client and server side, and it works. Others have implemented it, too. We've done interop testing, and it works. This is a proven pattern and from where I sit there is both rough consensus and running code.

I believe that I've already pointed out how the solutions you've proposed so far won't work in practice, for various reasons, many of which have already been brought up and discussed previously. If you have another way for the client to get its Registration Access Token, please propose it; but I haven't seen anything yet that will fly.

�-- Justin

On 05/31/2013 11:10 AM, Phil Hunt wrote:

Justin,

�

This is my primary objection! We can't keep it straight. Their should be no such thing as a registrstion access token! �Just the token the client obtains to update its profile through the normal token request process.�

Phil

On 2013-05-31, at 10:55, Justin Richer <jricher@mitre.org> wrote:

Which token are you referring to here?

If it's the Initial Registration Token, then you could get that through the normal token server no problem. (The lifecycle writeups don't call this out explicitly but I would be willing to do so.) Or you could get it elsewhere. Doesn't matter, just like it doesn't matter with any other OAuth2 protected resource.

If it's the Registration Access Token, then having the token come from the token endpoint would require a lot more work and complexity on behalf of both of the client and server. Either you end up with public clients getting secrets they shouldn't need or with granting clients access to the client_credentials flow when they shouldn't actually have it. Plus it adds extra round trips which don't buy you anything.

�-- Justin

On 05/31/2013 10:15 AM, Phil Hunt wrote:

The preference is to have the access token for registration issued by the normal token server rather then by the registration endpoint.�

�

In the current draft it is obtained through a unique process and must outlive the client.�

Phil

On 2013-05-30, at 19:47, "Richer, Justin P." <jricher@mitre.org> wrote:

I don't understand any of the comments below -- it already *is* an OAuth2 protected resource without any special handling. Your access tokens can be short-lived, long-lived, federated, structured, random blobs ... totally doesn't matter. They are access tokens being used to access a normal protected resource. Full stop.

Anything else is out of scope. The lifecycle discussions at the beginning are merely examples of some ways you *could* use it and are non-normative and non-exhaustive.

You seem to be asking for something that's already in the draft.

�-- Justin

From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 7:31 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

Phil

On 2013-05-30, at 16:11, "Richer, Justin P." <jricher@mitre.org> wrote:

Comments inline, marked by [JR].

From: Phil Hunt [phil.hunt@oracle.com]
Sent: Thursday, May 30, 2013 5:25 PM
To: Richer, Justin P.
Cc: John Bradley; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

See below.

Phil

�

@independentid

www.independentid.com

phil.hunt@oracle.com

�

�

�

On 2013-05-30, at 2:09 PM, Justin Richer wrote:

OK, I think see part of the hang up. I have not seen the scenario that you describe, where you trade a 3rd party token for a "local" token. I have seen where access tokens are federated directly at the PR. (Introspection lets you do some good things with that pattern.)

�

�

�

�

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

--------------090707000100020606000304-- From ve7jtb@ve7jtb.com Thu Jun 6 11:01:24 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA2B21E8084 for ; Thu, 6 Jun 2013 11:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70mtdU7a7NaW for ; Thu, 6 Jun 2013 11:01:22 -0700 (PDT) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id CFC3121E8054 for ; Thu, 6 Jun 2013 11:01:21 -0700 (PDT) Received: by mail-bk0-f41.google.com with SMTP id jc3so1780769bkc.14 for ; Thu, 06 Jun 2013 11:01:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=d/I/Yt8WbAWdXKLOh1cJkzTCsZq2xGZ61jmKmJcRvdA=; b=kpxuBSASOSKsry9jiOAAQ4vngXnjAT08J/8woE6L6rIQggEptFF+5ZdZE3IXELpLvZ 50ZciEeEpaCg4ljAkX4xWdxT9U+Jt2pn1Q0g5L2K6EOgA6ktZBgvIf5THEeQJeSmjSw7 +iHUvyvzeohzQlGfsq8lj8ony9J5qEpW2Qa10rsJ1Muoc+Zk689qqDncmE8WniZAKIXE +78M4afsR+U0DKBytczwKvOE359dILfdDAAgWbYWoPJQkzXRv8OXaKcEeOzyUCvPhEIT K9YkIGcSz0jHT+MO5lMoeck6Olq34WtCuBVRXVfpAKj59oGVrs5NY9kdoe7LuXQygJnp 45Ag== X-Received: by 10.204.234.134 with SMTP id kc6mr8229385bkb.142.1370541680479; Thu, 06 Jun 2013 11:01:20 -0700 (PDT) Received: from [10.87.159.63] ([88.128.80.6]) by mx.google.com with ESMTPSA id iy11sm28438360bkb.11.2013.06.06.11.01.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 11:01:18 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CE3118EF-8C68-4624-899A-1AEAFC2FF682"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: John Bradley In-Reply-To: <51B0CCDA.8010805@mitre.org> Date: Thu, 6 Jun 2013 20:00:49 +0200 Message-Id: <34F27971-32E6-4810-B075-9E4FEEAF7D15@ve7jtb.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <255B9BB34FB7D647A506DC292726F6E1151B105DA5@WSMSG3153V.srv.dir.telstra.com> <1373E8CE237FCC43BCA36C6558612D2A9F26D0@USCHMBX001.nsn-intra.net> <919FB49B-2705-42E4-B5C3-B433C3F81C7F@ve7jtb.com> <9209089C-5B60-4212-88EA-376855DBCEA0@oracle.com> <51B0C14D.5020306@mitre.org> <1CCDB2B8-CAD9-4827-8113-F92537F70375@oracle.com> <51B0C8CE.6070309@!> <51B0CB6D.7060! 004@mitre.org> <51B0CCDA.8010805@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlkbrsi2lINMn+P2Jgl2HgtfkGq8g4qIGAPUQDWrCeR/zbWGrJstGNlbL9/v486uIYIPyKp Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:01:24 -0000 --Apple-Mail=_CE3118EF-8C68-4624-899A-1AEAFC2FF682 Content-Type: multipart/alternative; boundary="Apple-Mail=_2EB78DAA-1103-425D-9488-FE314D3A3165" --Apple-Mail=_2EB78DAA-1103-425D-9488-FE314D3A3165 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 On 2013-06-06, at 7:54 PM, Justin Richer wrote: > ... My bad, you're right. I was getting my wires crossed with all = these emails. >=20 > In my view, the initial access token is, fundamentally, an access = token used to constrain access to the registration endpoint (not the = configuration endpoint, and not to get "normal" access tokens). Just = like a normal OAuth token is an opaque token used to constrain access to = the protected resource. If you want to define anything more for either = of those, you're going to need more work.=20 >=20 > I'm completely on board with making those definitions, but I think it = goes beyond registration. And if registration is silent on all of this, = and just says "the registration endpoint may be an OAuth 2.0 protected = resource", then whatever interoperable solutions we can come up with for = validating a cross-domain token can be applied here. I don't think it = makes sense to constrain registration before the rest of this work is = baked.=20 >=20 > -- Justin >=20 >=20 > On 06/06/2013 01:50 PM, Phil Hunt wrote: >> We have two separate discussions going on. 8-) >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-06-06, at 10:48 AM, Justin Richer wrote: >>=20 >>> I thought we were talking about the registration access token, not = the initial access token? >>>=20 >>> -- Justin >>>=20 >>> On 06/06/2013 01:48 PM, Phil Hunt wrote: >>>> This is why this to-MAY-to vs. to-MAH-to distinction around is the = initial access token an authorization token is important. >>>>=20 >>>> The purpose for the initial access token is dramatically different = then normal access tokens. This is for "registration" and does not = constitute authentication or authorization. >>>>=20 >>>> Therefore, in this case, I do not believe that defining access = tokens in the broader sense makes this issue clearer. >>>>=20 >>>> Registration is a very specific process different than = authorization. >>>>=20 >>>> This might be a good paper to look at so the group understands why = I am differentiating authorization from what is happening with initial = access: >>>> http://tools.ietf.org/html/draft-hallambaker-httpauth-00 >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-06-06, at 10:37 AM, Justin Richer wrote: >>>>=20 >>>>> Interoperability of the processing of OAuth tokens is a separate = issue that needs to be solved not just for registration. When it is = solved in the wider case, Registration as-is will inherit the solution. >>>>>=20 >>>>> So today, if you're using an Initial Access Token (which is = optional), then you're locked to whatever process you want to use to = verify/validate that token. Since it's just an OAuth token, you've got a = number of things that you can do (assertions, introspection, magic). >>>>>=20 >>>>> I'd rather we solve the *real* cross-domain issue in the wider = case than just try to cram something into registration. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On 06/06/2013 01:33 PM, Phil Hunt wrote: >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-06-06, at 10:05 AM, Justin Richer wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> On 06/06/2013 11:20 AM, Phil Hunt wrote: >>>>>>>> As I've said before the initial auth token should nothing to do = with auth. It is simply an assertion given to the developer to = distribute in order to pass on signed claims about the software.=20 >>>>>>>=20 >>>>>>> Phil, as I and several others have explained previously, that's = not true at all. It's a token that gives authorization to the = registration endpoint. The fact that you can use it as an assertion to = pass along signed claims is an artifact of it being an OAuth token and = an OAuth token is an opaque string. Please read through the dynamic = registration draft again -- it says absolutely nothing about assertions, = signatures, or claims with regard to this token. >>>>>> It depends which case you are using. If the developer is talking = to a single deployment domain and obtains an initial access token and = then ships it with all clients, then sure. In this scenario, the = contents are totally controlled by the local domain. >>>>>>=20 >>>>>> I agree. In this case, you don't care about inter-op. The whole = environment is siloed. But then, if this is your case, I'm not sure why = this draft is at the IETF. >>>>>>=20 >>>>>> The interoperability case is where a third party generates that = assertion and the deployment domain has to decide to accept it. So you = are a developer and you want to build a client for a Microsoft or Oracle = app. You want to be able to ship that to your customers. You register = with the appropriate publisher and they give you a signed assertion that = can be used as the "Initial Access Token". This token is then = accepted by the deployment domain and then it decides if it trusts the = signer or not. >>>>>>=20 >>>>>> =3D=3D=3D> For this to work, the contents and format of that = token MUST be defined. Otherwise how could we ensure a Microsoft = signed assertion would be accepted by a PingIdentity OAuth server? Or = any other combination of implementations from different = vendors/communities? >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Bearer or not bearer is a distraction. The fact that the = contents and format of this token is out of scope leaves a HUGE interop = gap.=20 >>>>>>>=20 >>>>>>> The fact that some of us (myself included) are *using* this = token to carry this kind of information is out of scope for the basic = registration spec. I completely agree that there's value in defining = this stuff, but as a separate and complementary spec from registration. >>>>>>=20 >>>>>> [PH] I was reacting to John Bradley's assertion that the spec was = narrowly defined with interop in mind. Yet this mechanism is a key = factor being used to share information about the software. >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Finally never-mind bearer bias, how are client credentials = rotated interoperably if the only thing rotated is client_secret? >>>>>>>=20 >>>>>>> *any* parameter on the client, including the = registration_access_token and any extension parameters, can be rotated = on any call to the Read or Update methods (except for client_id). So if = you've got another mechanism for doing client authentication, you can = rotate that, too. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> I would say the spec only works for client secrets and/or = all-in-one domain where there is no interop.=20 >>>>>>>=20 >>>>>>> Considering I've personally used it across domains and without = client secrets (using jwks_uri to register public keys), I have to = empirically disagree with that statement. >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> On 2013-06-06, at 1:53, John Bradley wrote: >>>>>>>>=20 >>>>>>>>> There are a couple of reasons. =20 >>>>>>>>>=20 >>>>>>>>> One criticism Hannes and others make of OAuth specs is they = are not tightly profiled enough to be interoperable without further out = of band configuration and profiling. >>>>>>>>>=20 >>>>>>>>> Making registration work with minimal ambiguity was a priority = for Connect and that has carried over. >>>>>>>>>=20 >>>>>>>>> I am not opposed to having this extended at some point in the = future, once we have a second token type. The new token type should be = available to do updates as well. >>>>>>>>>=20 >>>>>>>>> The problem is that starting down the HoK route potentially = requires a registered client that may need to be registered to do the = registration. =20 >>>>>>>>> I think that is best left to another spec to sort out the = possible turtles. >>>>>>>>>=20 >>>>>>>>> So the default needs to be bearer tokens unless registration = is extended by another profile. >>>>>>>>>=20 >>>>>>>>> John B. >>>>>>>>> On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - = FI/Espoo)" wrote: >>>>>>>>>=20 >>>>>>>>>> Because bearer tokens have a stable RFC-numbered spec and are = widely implemented and the registration flow as documented seems like it = should work? -T >>>>>>>>>> =20 >>>>>>>>>> That=92s the answer for why there is support for bearer = tokens but it is not the answer to why that=92s the only supported = mechanism. >>>>>>>>>> If we want to support stronger security mechanisms (which the = group has decided to work on already) then we need to have a story on = how to support the other mechanisms as well . >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_2EB78DAA-1103-425D-9488-FE314D3A3165 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 jricher@mitre.org> = wrote:

=20 =20
... My bad, you're right. I was getting my wires crossed with all these emails.

In my view, the initial access token is, fundamentally, an access token used to constrain access to the registration endpoint (not the configuration endpoint, and not to get "normal" access tokens). Just like a normal OAuth token is an opaque token used to constrain access to the protected resource. If you want to define anything more for either of those, you're going to need more work.

I'm completely on board with making those definitions, but I think it goes beyond registration. And if registration is silent on all of this, and just says "the registration endpoint may be an OAuth 2.0 protected resource", then whatever interoperable solutions we can come up with for validating a cross-domain token can be applied here. I don't think it makes sense to constrain registration before the rest of this work is baked.

-- Justin

On 06/06/2013 01:50 PM, Phil Hunt wrote:

We have two separate discussions going on. 8-)

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:48 AM, Justin Richer wrote:

I thought we were talking about the registration access token, not the initial access token?

-- Justin

On 06/06/2013 01:48 PM, = Phil Hunt wrote:

This is why this to-MAY-to vs. to-MAH-to distinction around is the initial access token an authorization token is important.

The purpose for the initial access token is dramatically different then normal access tokens. This is for "registration" and does not = constitute authentication or authorization.

Therefore, in this case, I do not believe that defining access tokens in the broader sense makes this issue clearer.

Registration is a very specific process different than authorization.

This might be a good paper to look at so the group understands why I am differentiating authorization from what is happening with initial access:

http://t= ools.ietf.org/html/draft-hallambaker-httpauth-00

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:37 AM, Justin Richer wrote:

Interoperability of the processing of OAuth tokens is a separate issue that needs to be solved not just for registration. When it is solved in the wider case, Registration as-is will inherit the solution.

So today, if you're using an Initial Access Token (which is optional), then you're locked to whatever process you want to use to verify/validate that token. Since it's just an OAuth token, you've got a number of things that you can do (assertions, introspection, = magic).

I'd rather we solve the *real* cross-domain issue in the wider case than just try to cram something into registration.

-- Justin

On 06/06/2013 = 01:33 PM, Phil Hunt wrote:

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:05 AM, Justin Richer wrote:

=

On 06/06/2013 11:20 AM, Phil Hunt = wrote:

As I've said before the initial auth token should nothing to do with auth. It is simply an assertion given to the developer to distribute in order to pass on signed claims about the software.

Phil, as I and several others have explained previously, that's not true at all. It's a token that gives authorization to the registration endpoint. The fact that you can use it as an assertion to pass along signed claims is an artifact of it being an OAuth token and an OAuth token is an opaque string. Please read through the dynamic registration draft again -- it says absolutely nothing about assertions, signatures, or claims with regard to this token.

It depends which case you are using. If the developer is talking to a = single deployment domain and obtains an initial access token and then ships it with all clients, then sure. In this = scenario, the contents are totally controlled by the local domain.

I agree. In this case, you don't care about inter-op. The whole environment is siloed. But then, if this is your = case, I'm not sure why this draft is at the IETF.

The interoperability case is where a third party generates that assertion and the deployment domain has to decide to accept it. So you are a developer = and you want to build a client for a Microsoft or Oracle app. You want to be able to = ship that to your customers. You register with the appropriate publisher and they give you a signed assertion that can be used as the "Initial Access Token". = This token is then accepted by the deployment domain and then it decides if it trusts the signer or not.

=3D=3D=3D> For this to work, the = contents and format of that token MUST be defined. Otherwise how could we ensure a Microsoft signed assertion would be accepted by a PingIdentity OAuth server? Or any other combination of implementations from different vendors/communities?

=

Bearer or not bearer is a distraction. The fact that the contents and format of this token is out of scope leaves a HUGE interop gap.

The fact that some of us (myself included) are *using* this token to carry this kind of information is out of scope for the basic registration spec. I completely agree that there's value in defining this stuff, but as a separate and complementary spec from registration.

[PH] I was reacting to John Bradley's assertion that the spec was narrowly defined with interop in mind. Yet this mechanism is a key factor being used to share information about the software.

=

Finally never-mind bearer bias, how are client credentials rotated interoperably if the only thing rotated is client_secret?

*any* parameter on the client, including the registration_access_token and any extension parameters, can be rotated on any call to the Read or Update methods (except for client_id). So if you've got another mechanism for doing client authentication, you can rotate that, too.

I would say the spec only works for client secrets and/or all-in-one domain where there is no interop. =

Considering I've personally used it across domains and without client secrets (using jwks_uri to register public keys), I have to empirically disagree with that statement.

-- Justin

Phil

On 2013-06-06, at 1:53, John Bradley <ve7jtb@ve7jtb.com> wrote:

There are a couple of reasons. =

One criticism Hannes and others make of OAuth specs is they are not tightly profiled enough to be interoperable without further out of band configuration and = profiling.

Making registration work with minimal ambiguity was a priority for Connect and that has carried over.

I am not opposed to having this extended at some point in the future, once we have a second token type. The = new token type should be available to do updates as well.

The problem is that starting down the HoK route potentially requires a registered client that may need to be registered to do the registration. =

I think that is best left to another spec to sort out the possible turtles.

So the default needs to be bearer tokens unless registration is extended by another profile.

John B.

On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>= ; wrote:

Because bearer tokens have a stable RFC-numbered spec and are widely implemented and the registration flow as documented seems like it should work? = -T

That=92s the answer for why there is support for bearer tokens but it is not the answer to why that=92s the only supported = mechanism.

If we want to support stronger security mechanisms (which the group has decided to work on already) then we need to have a story on how to support the other mechanisms as well = .

=
_______________________________________________
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

= --Apple-Mail=_2EB78DAA-1103-425D-9488-FE314D3A3165-- --Apple-Mail=_CE3118EF-8C68-4624-899A-1AEAFC2FF682 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 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjA2MTgwMDUwWjAjBgkqhkiG9w0BCQQxFgQUx3pdlswP vUejA1zLbS1vLkkix9AwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAaurn6OLVKbb1/jLrIhSVZq+8ZSLqPzoPedPZUtHL 5vaEEyYgdxXT6KoIDCg0wz9tbBkvvFrBBegZVTDEGrqQofpUellbiOYWKg3ySgmQOFQ/hfj2BTiS sf8kuNzUgNUHTRpWlw0BqZe5j87R+94gl9LywGvU8uVYQHIALAcJbn5dbHYGfLkCoiXvIg7HftuD TMa3HAelj56EkVo9aPXSmaFfH9r4kauy0df3FTP6m9BtTFy8ofo8WbZNVzkkR4jYiyfb41PNE73a ZuyzhF8PS+BZjjKYeEfPR5aSAxNLRbKL2RXbq34QDRWTJbcg3R/o0kQKcvIUkDJIyP6tNyIXcwAA AAAAAA== --Apple-Mail=_CE3118EF-8C68-4624-899A-1AEAFC2FF682-- From phil.hunt@oracle.com Thu Jun 6 11:05:27 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B72D21E8084 for ; Thu, 6 Jun 2013 11:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNubqZtfihQI for ; Thu, 6 Jun 2013 11:05:22 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E1A7321E80A3 for ; Thu, 6 Jun 2013 11:05:21 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r56I599r015145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Jun 2013 18:05:10 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r56I5Acg021152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Jun 2013 18:05:11 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r56I5ARi007522; Thu, 6 Jun 2013 18:05:10 GMT Received: from [192.168.1.89] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 Jun 2013 11:05:09 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4C0E6B40-EBC4-433A-B0DE-464B5B306CAC" From: Phil Hunt In-Reply-To: <51B0CCDA.8010805@mitre.org> Date: Thu, 6 Jun 2013 11:05:07 -0700 Message-Id: <7C53E628-B6C3-4E55-98B3-34336EB1D1F4@oracle.com> References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <51A8E0BD.9090908@mitre.org> <521EB2A2-C786-43BE-9449-A12324347E6D@oracle.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <255B9BB34FB7D647A506DC292726F6E1151B105DA5@WSMSG3153V.srv.dir.telstra.com> <1373E8CE237FCC43BCA36C6558612D2A9F26D0@USCHMBX001.nsn-intra.net> <919FB49B-2705-42E4-B5C3-B433C3F81C7F@ve7jtb.com> <9209089C-5B60-4212-88EA-376855DBCEA0@oracle.com> <51B0C14D.5020306@mitre.org> <1CCDB2B8-CAD9-4827-8113-F92537F70375@oracle.com> <51B0C8CE.6070309@!> <51B0CB6D.7060! 004@mitre.org> <51B0CCDA.8010805@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:05:27 -0000 --Apple-Mail=_4C0E6B40-EBC4-433A-B0DE-464B5B306CAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think we are getting to the source of the confusion. To me, the client POSTING to the registration endpoint in federated = scenarios is usually anonymous. It can present signed registration = claims. My preference was through a non-credential vector, like the = software_id parameter. This is just registration information. In your case, you are defining a local access token issued to a = developer inside a single domain. This is no inter-op, so no need to = specify. I still would prefer that it be defined as local registration = information, but in this case ONLY I can accept it is local = authorization. In this case, the process works the same, only now the client is no = longer anonymous. It is just doing instance registration. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-06-06, at 10:54 AM, Justin Richer wrote: > ... My bad, you're right. I was getting my wires crossed with all = these emails. >=20 > In my view, the initial access token is, fundamentally, an access = token used to constrain access to the registration endpoint (not the = configuration endpoint, and not to get "normal" access tokens). Just = like a normal OAuth token is an opaque token used to constrain access to = the protected resource. If you want to define anything more for either = of those, you're going to need more work.=20 >=20 > I'm completely on board with making those definitions, but I think it = goes beyond registration. And if registration is silent on all of this, = and just says "the registration endpoint may be an OAuth 2.0 protected = resource", then whatever interoperable solutions we can come up with for = validating a cross-domain token can be applied here. I don't think it = makes sense to constrain registration before the rest of this work is = baked.=20 >=20 > -- Justin >=20 >=20 > On 06/06/2013 01:50 PM, Phil Hunt wrote: >> We have two separate discussions going on. 8-) >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-06-06, at 10:48 AM, Justin Richer wrote: >>=20 >>> I thought we were talking about the registration access token, not = the initial access token? >>>=20 >>> -- Justin >>>=20 >>> On 06/06/2013 01:48 PM, Phil Hunt wrote: >>>> This is why this to-MAY-to vs. to-MAH-to distinction around is the = initial access token an authorization token is important. >>>>=20 >>>> The purpose for the initial access token is dramatically different = then normal access tokens. This is for "registration" and does not = constitute authentication or authorization. >>>>=20 >>>> Therefore, in this case, I do not believe that defining access = tokens in the broader sense makes this issue clearer. >>>>=20 >>>> Registration is a very specific process different than = authorization. >>>>=20 >>>> This might be a good paper to look at so the group understands why = I am differentiating authorization from what is happening with initial = access: >>>> http://tools.ietf.org/html/draft-hallambaker-httpauth-00 >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-06-06, at 10:37 AM, Justin Richer wrote: >>>>=20 >>>>> Interoperability of the processing of OAuth tokens is a separate = issue that needs to be solved not just for registration. When it is = solved in the wider case, Registration as-is will inherit the solution. >>>>>=20 >>>>> So today, if you're using an Initial Access Token (which is = optional), then you're locked to whatever process you want to use to = verify/validate that token. Since it's just an OAuth token, you've got a = number of things that you can do (assertions, introspection, magic). >>>>>=20 >>>>> I'd rather we solve the *real* cross-domain issue in the wider = case than just try to cram something into registration. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On 06/06/2013 01:33 PM, Phil Hunt wrote: >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-06-06, at 10:05 AM, Justin Richer wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> On 06/06/2013 11:20 AM, Phil Hunt wrote: >>>>>>>> As I've said before the initial auth token should nothing to do = with auth. It is simply an assertion given to the developer to = distribute in order to pass on signed claims about the software.=20 >>>>>>>=20 >>>>>>> Phil, as I and several others have explained previously, that's = not true at all. It's a token that gives authorization to the = registration endpoint. The fact that you can use it as an assertion to = pass along signed claims is an artifact of it being an OAuth token and = an OAuth token is an opaque string. Please read through the dynamic = registration draft again -- it says absolutely nothing about assertions, = signatures, or claims with regard to this token. >>>>>> It depends which case you are using. If the developer is talking = to a single deployment domain and obtains an initial access token and = then ships it with all clients, then sure. In this scenario, the = contents are totally controlled by the local domain. >>>>>>=20 >>>>>> I agree. In this case, you don't care about inter-op. The whole = environment is siloed. But then, if this is your case, I'm not sure why = this draft is at the IETF. >>>>>>=20 >>>>>> The interoperability case is where a third party generates that = assertion and the deployment domain has to decide to accept it. So you = are a developer and you want to build a client for a Microsoft or Oracle = app. You want to be able to ship that to your customers. You register = with the appropriate publisher and they give you a signed assertion that = can be used as the "Initial Access Token". This token is then = accepted by the deployment domain and then it decides if it trusts the = signer or not. >>>>>>=20 >>>>>> =3D=3D=3D> For this to work, the contents and format of that = token MUST be defined. Otherwise how could we ensure a Microsoft = signed assertion would be accepted by a PingIdentity OAuth server? Or = any other combination of implementations from different = vendors/communities? >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Bearer or not bearer is a distraction. The fact that the = contents and format of this token is out of scope leaves a HUGE interop = gap.=20 >>>>>>>=20 >>>>>>> The fact that some of us (myself included) are *using* this = token to carry this kind of information is out of scope for the basic = registration spec. I completely agree that there's value in defining = this stuff, but as a separate and complementary spec from registration. >>>>>>=20 >>>>>> [PH] I was reacting to John Bradley's assertion that the spec was = narrowly defined with interop in mind. Yet this mechanism is a key = factor being used to share information about the software. >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Finally never-mind bearer bias, how are client credentials = rotated interoperably if the only thing rotated is client_secret? >>>>>>>=20 >>>>>>> *any* parameter on the client, including the = registration_access_token and any extension parameters, can be rotated = on any call to the Read or Update methods (except for client_id). So if = you've got another mechanism for doing client authentication, you can = rotate that, too. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> I would say the spec only works for client secrets and/or = all-in-one domain where there is no interop.=20 >>>>>>>=20 >>>>>>> Considering I've personally used it across domains and without = client secrets (using jwks_uri to register public keys), I have to = empirically disagree with that statement. >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> On 2013-06-06, at 1:53, John Bradley wrote: >>>>>>>>=20 >>>>>>>>> There are a couple of reasons. =20 >>>>>>>>>=20 >>>>>>>>> One criticism Hannes and others make of OAuth specs is they = are not tightly profiled enough to be interoperable without further out = of band configuration and profiling. >>>>>>>>>=20 >>>>>>>>> Making registration work with minimal ambiguity was a priority = for Connect and that has carried over. >>>>>>>>>=20 >>>>>>>>> I am not opposed to having this extended at some point in the = future, once we have a second token type. The new token type should be = available to do updates as well. >>>>>>>>>=20 >>>>>>>>> The problem is that starting down the HoK route potentially = requires a registered client that may need to be registered to do the = registration. =20 >>>>>>>>> I think that is best left to another spec to sort out the = possible turtles. >>>>>>>>>=20 >>>>>>>>> So the default needs to be bearer tokens unless registration = is extended by another profile. >>>>>>>>>=20 >>>>>>>>> John B. >>>>>>>>> On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - = FI/Espoo)" wrote: >>>>>>>>>=20 >>>>>>>>>> Because bearer tokens have a stable RFC-numbered spec and are = widely implemented and the registration flow as documented seems like it = should work? -T >>>>>>>>>> =20 >>>>>>>>>> That=92s the answer for why there is support for bearer = tokens but it is not the answer to why that=92s the only supported = mechanism. >>>>>>>>>> If we want to support stronger security mechanisms (which the = group has decided to work on already) then we need to have a story on = how to support the other mechanisms as well . >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_4C0E6B40-EBC4-433A-B0DE-464B5B306CAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = think we are getting to the source of the = confusion.

To me, the client POSTING to the = registration endpoint in federated scenarios is usually anonymous. = It can present signed registration claims. My preference was = through a non-credential vector, like the software_id parameter. = This is just registration information.

In = your case, you are defining a local access token issued to a developer = inside a single domain. This is no inter-op, so no need to specify. = I still would prefer that it be defined as local registration = information, but in this case ONLY I can accept it is local = authorization.

In this case, the process works = the same, only now the client is no longer anonymous. It is just doing = instance registration.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2013-06-06, at 10:54 AM, Justin Richer wrote:

=20 =20
... My bad, you're right. I was getting my wires crossed with all these emails.

In my view, the initial access token is, fundamentally, an access token used to constrain access to the registration endpoint (not the configuration endpoint, and not to get "normal" access tokens). Just like a normal OAuth token is an opaque token used to constrain access to the protected resource. If you want to define anything more for either of those, you're going to need more work.

I'm completely on board with making those definitions, but I think it goes beyond registration. And if registration is silent on all of this, and just says "the registration endpoint may be an OAuth 2.0 protected resource", then whatever interoperable solutions we can come up with for validating a cross-domain token can be applied here. I don't think it makes sense to constrain registration before the rest of this work is baked.

-- Justin

On 06/06/2013 01:50 PM, Phil Hunt wrote:

We have two separate discussions going on. 8-)

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:48 AM, Justin Richer wrote:

I thought we were talking about the registration access token, not the initial access token?

-- Justin

On 06/06/2013 01:48 PM, = Phil Hunt wrote:

This is why this to-MAY-to vs. to-MAH-to distinction around is the initial access token an authorization token is important.

The purpose for the initial access token is dramatically different then normal access tokens. This is for "registration" and does not = constitute authentication or authorization.

Therefore, in this case, I do not believe that defining access tokens in the broader sense makes this issue clearer.

Registration is a very specific process different than authorization.

This might be a good paper to look at so the group understands why I am differentiating authorization from what is happening with initial access:

http://t= ools.ietf.org/html/draft-hallambaker-httpauth-00

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:37 AM, Justin Richer wrote:

Interoperability of the processing of OAuth tokens is a separate issue that needs to be solved not just for registration. When it is solved in the wider case, Registration as-is will inherit the solution.

So today, if you're using an Initial Access Token (which is optional), then you're locked to whatever process you want to use to verify/validate that token. Since it's just an OAuth token, you've got a number of things that you can do (assertions, introspection, = magic).

I'd rather we solve the *real* cross-domain issue in the wider case than just try to cram something into registration.

-- Justin

On 06/06/2013 = 01:33 PM, Phil Hunt wrote:

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:05 AM, Justin Richer wrote:

=

On 06/06/2013 11:20 AM, Phil Hunt = wrote:

As I've said before the initial auth token should nothing to do with auth. It is simply an assertion given to the developer to distribute in order to pass on signed claims about the software.

Phil, as I and several others have explained previously, that's not true at all. It's a token that gives authorization to the registration endpoint. The fact that you can use it as an assertion to pass along signed claims is an artifact of it being an OAuth token and an OAuth token is an opaque string. Please read through the dynamic registration draft again -- it says absolutely nothing about assertions, signatures, or claims with regard to this token.

It depends which case you are using. If the developer is talking to a = single deployment domain and obtains an initial access token and then ships it with all clients, then sure. In this = scenario, the contents are totally controlled by the local domain.

I agree. In this case, you don't care about inter-op. The whole environment is siloed. But then, if this is your = case, I'm not sure why this draft is at the IETF.

The interoperability case is where a third party generates that assertion and the deployment domain has to decide to accept it. So you are a developer = and you want to build a client for a Microsoft or Oracle app. You want to be able to = ship that to your customers. You register with the appropriate publisher and they give you a signed assertion that can be used as the "Initial Access Token". = This token is then accepted by the deployment domain and then it decides if it trusts the signer or not.

=3D=3D=3D> For this to work, the = contents and format of that token MUST be defined. Otherwise how could we ensure a Microsoft signed assertion would be accepted by a PingIdentity OAuth server? Or any other combination of implementations from different vendors/communities?

=

Bearer or not bearer is a distraction. The fact that the contents and format of this token is out of scope leaves a HUGE interop gap.

The fact that some of us (myself included) are *using* this token to carry this kind of information is out of scope for the basic registration spec. I completely agree that there's value in defining this stuff, but as a separate and complementary spec from registration.

[PH] I was reacting to John Bradley's assertion that the spec was narrowly defined with interop in mind. Yet this mechanism is a key factor being used to share information about the software.

=

Finally never-mind bearer bias, how are client credentials rotated interoperably if the only thing rotated is client_secret?

*any* parameter on the client, including the registration_access_token and any extension parameters, can be rotated on any call to the Read or Update methods (except for client_id). So if you've got another mechanism for doing client authentication, you can rotate that, too.

I would say the spec only works for client secrets and/or all-in-one domain where there is no interop. =

Considering I've personally used it across domains and without client secrets (using jwks_uri to register public keys), I have to empirically disagree with that statement.

-- Justin

Phil

On 2013-06-06, at 1:53, John Bradley <ve7jtb@ve7jtb.com> wrote:

There are a couple of reasons. =

One criticism Hannes and others make of OAuth specs is they are not tightly profiled enough to be interoperable without further out of band configuration and = profiling.

Making registration work with minimal ambiguity was a priority for Connect and that has carried over.

I am not opposed to having this extended at some point in the future, once we have a second token type. The = new token type should be available to do updates as well.

The problem is that starting down the HoK route potentially requires a registered client that may need to be registered to do the registration. =

I think that is best left to another spec to sort out the possible turtles.

So the default needs to be bearer tokens unless registration is extended by another profile.

John B.

On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>= ; wrote:

Because bearer tokens have a stable RFC-numbered spec and are widely implemented and the registration flow as documented seems like it should work? = -T

That=92s the answer for why there is support for bearer tokens but it is not the answer to why that=92s the only supported = mechanism.

If we want to support stronger security mechanisms (which the group has decided to work on already) then we need to have a story on how to support the other mechanisms as well = .

=
_______________________________________________
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

= --Apple-Mail=_4C0E6B40-EBC4-433A-B0DE-464B5B306CAC-- From jricher@mitre.org Thu Jun 6 11:20:25 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF1821F93F8 for ; Thu, 6 Jun 2013 11:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7o5oF77dAR0Q for ; Thu, 6 Jun 2013 11:20:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D974321F92FC for ; Thu, 6 Jun 2013 11:20:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4F7002270005; Thu, 6 Jun 2013 14:20:19 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 333791F0635; Thu, 6 Jun 2013 14:20:19 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 6 Jun 2013 14:20:18 -0400 Message-ID: <51B0D2B2.7060201@mitre.org> Date: Thu, 6 Jun 2013 14:19:30 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <20130524203638.25945.84709.idtracker@ietfa.amsl.com> <002701ce5e33$620faaa0$262effe0$@reminetworks.com> <0561023C-4AFC-4281-BC62-764C12EC763D@oracle.com> <51A8FCA6.9050109@mitre.org> <004401ce5e3a$01854b70$048fe250$@reminetworks.com> <255B9BB34FB7D647A506DC292726F6E1151B105DA5@WSMSG3153V.srv.dir.telstra.com> <1373E8CE237FCC43BCA36C6558612D2A9F26D0@USCHMBX001.nsn-intra.net> <919FB49B-2705-42E4-B5C3-B433C3F81C7F@ve7jtb.com> <9209089C-5B60-4212-88EA-376855DBCEA0@oracle.com> <51B0C14D.5020306@mitre.org> <1CCDB2B8-CAD9-4827-8113-F92537F70375@oracle.com> <51B0C8CE.6070309@!> <51B0CB6D.7060! 004@mitre.org> <51B0CCDA.8010805@mitre.org> <7C53E628-B6C3-4E55-98B3-34336EB1D1F4@oracle.com> In-Reply-To: <7C53E628-B6C3-4E55-98B3-34336EB1D1F4@oracle.com> Content-Type: multipart/alternative; boundary="------------060207090901030000070307" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 18:20:25 -0000 --------------060207090901030000070307 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Yes, this is exactly the case. I think that signing/asserting/verifying registration information, if you want to do that, is better left to extensions from the basic draft. We have many documented use cases for using the structure and protocol as-is. In BB+ we're using the initial access token mechanism to carry the signed information but defining discovery, token formats, and processing rules (and policies!) that make this actually work. We did this because carrying a signed chunk of information in a JWT is an established practice, as is using a JWT as an OAuth token, so it made sense to us. Putting that information inside of a software_id field with the same defined semantics would also be agreeable, I think, but I think we need a lot more eyes and hands on it. And either way, both of these mechanisms can be easily be built on top of the registration draft as is by either defining the processing of the initial access token (which is what BB+ does) or by defining a new metadata parameter (which is what you're suggesting), or even by providing some other mechanism that we haven't thought of yet. So my question is: Are you OK with this functionality being defined as a proper extension so that the base draft can move forward (and that we take care not to *block* such an extension in the base draft), and do you want to help write that extension? I'd be happy to help write it, and I think we can probably get some of the BB+ group over here as well to offer input from that side. I also think that we can start to extract cross-domain OAuth token processing rules to provide real cross-domain interoperability, which would also be inherited by the registration draft. -- Justin On 06/06/2013 02:05 PM, Phil Hunt wrote: > I think we are getting to the source of the confusion. > > To me, the client POSTING to the registration endpoint in federated > scenarios is usually anonymous. It can present signed registration > claims. My preference was through a non-credential vector, like the > software_id parameter. This is just registration information. > > In your case, you are defining a local access token issued to a > developer inside a single domain. This is no inter-op, so no need to > specify. I still would prefer that it be defined as local > registration information, but in this case ONLY I can accept it is > local authorization. > > In this case, the process works the same, only now the client is no > longer anonymous. It is just doing instance registration. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-06-06, at 10:54 AM, Justin Richer wrote: > >> ... My bad, you're right. I was getting my wires crossed with all >> these emails. >> >> In my view, the initial access token is, fundamentally, an access >> token used to constrain access to the registration endpoint (not the >> configuration endpoint, and not to get "normal" access tokens). Just >> like a normal OAuth token is an opaque token used to constrain access >> to the protected resource. If you want to define anything more for >> either of those, you're going to need more work. >> >> I'm completely on board with making those definitions, but I think it >> goes beyond registration. And if registration is silent on all of >> this, and just says "the registration endpoint may be an OAuth 2.0 >> protected resource", then whatever interoperable solutions we can >> come up with for validating a cross-domain token can be applied here. >> I don't think it makes sense to constrain registration before the >> rest of this work is baked. >> >> -- Justin >> >> >> On 06/06/2013 01:50 PM, Phil Hunt wrote: >>> We have two separate discussions going on. 8-) >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2013-06-06, at 10:48 AM, Justin Richer wrote: >>> >>>> I thought we were talking about the registration access token, not >>>> the initial access token? >>>> >>>> -- Justin >>>> >>>> On 06/06/2013 01:48 PM, Phil Hunt wrote: >>>>> This is why this to-MAY-to vs. to-MAH-to distinction around is the >>>>> initial access token an authorization token is important. >>>>> >>>>> The purpose for the initial access token is dramatically different >>>>> then normal access tokens. This is for "registration" and does >>>>> not constitute authentication or authorization. >>>>> >>>>> Therefore, in this case, I do not believe that defining access >>>>> tokens in the broader sense makes this issue clearer. >>>>> >>>>> Registration is a very specific process different than authorization. >>>>> >>>>> This might be a good paper to look at so the group understands why >>>>> I am differentiating authorization from what is happening with >>>>> initial access: >>>>> http://tools.ietf.org/html/draft-hallambaker-httpauth-00 >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2013-06-06, at 10:37 AM, Justin Richer wrote: >>>>> >>>>>> Interoperability of the processing of OAuth tokens is a separate >>>>>> issue that needs to be solved not just for registration. When it >>>>>> is solved in the wider case, Registration as-is will inherit the >>>>>> solution. >>>>>> >>>>>> So today, if you're using an Initial Access Token (which is >>>>>> optional), then you're locked to whatever process you want to use >>>>>> to verify/validate that token. Since it's just an OAuth token, >>>>>> you've got a number of things that you can do (assertions, >>>>>> introspection, magic). >>>>>> >>>>>> I'd rather we solve the *real* cross-domain issue in the wider >>>>>> case than just try to cram something into registration. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> On 06/06/2013 01:33 PM, Phil Hunt wrote: >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2013-06-06, at 10:05 AM, Justin Richer wrote: >>>>>>> >>>>>>>> >>>>>>>> On 06/06/2013 11:20 AM, Phil Hunt wrote: >>>>>>>>> As I've said before the initial auth token should nothing to >>>>>>>>> do with auth. It is simply an assertion given to the developer >>>>>>>>> to distribute in order to pass on signed claims about the >>>>>>>>> software. >>>>>>>> >>>>>>>> Phil, as I and several others have explained previously, that's >>>>>>>> not true at all. It's a token that gives authorization to the >>>>>>>> registration endpoint. The fact that you can use it as an >>>>>>>> assertion to pass along signed claims is an artifact of it >>>>>>>> being an OAuth token and an OAuth token is an opaque string. >>>>>>>> Please read through the dynamic registration draft again -- it >>>>>>>> says absolutely nothing about assertions, signatures, or claims >>>>>>>> with regard to this token. >>>>>>> It depends which case you are using. If the developer is >>>>>>> talking to a single deployment domain and obtains an initial >>>>>>> access token and then ships it with all clients, then sure. In >>>>>>> this scenario, the contents are totally controlled by the local >>>>>>> domain. >>>>>>> >>>>>>> I agree. In this case, you don't care about inter-op. The whole >>>>>>> environment is siloed. But then, if this is your case, I'm not >>>>>>> sure why this draft is at the IETF. >>>>>>> >>>>>>> The interoperability case is where a third party generates that >>>>>>> assertion and the deployment domain has to decide to accept it. >>>>>>> So you are a developer and you want to build a client for a >>>>>>> Microsoft or Oracle app. You want to be able to ship that to >>>>>>> your customers. You register with the appropriate publisher and >>>>>>> they give you a signed assertion that can be used as the >>>>>>> "Initial Access Token". This token is then accepted by the >>>>>>> deployment domain and then it decides if it trusts the signer or >>>>>>> not. >>>>>>> >>>>>>> ===> For this to work, the contents and format of that token >>>>>>> MUST be defined. Otherwise how could we ensure a Microsoft >>>>>>> signed assertion would be accepted by a PingIdentity OAuth >>>>>>> server? Or any other combination of implementations from >>>>>>> different vendors/communities? >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Bearer or not bearer is a distraction. The fact that the >>>>>>>>> contents and format of this token is out of scope leaves a >>>>>>>>> HUGE interop gap. >>>>>>>> >>>>>>>> The fact that some of us (myself included) are *using* this >>>>>>>> token to carry this kind of information is out of scope for the >>>>>>>> basic registration spec. I completely agree that there's value >>>>>>>> in defining this stuff, but as a separate and complementary >>>>>>>> spec from registration. >>>>>>> >>>>>>> [PH] I was reacting to John Bradley's assertion that the spec >>>>>>> was narrowly defined with interop in mind. Yet this mechanism is >>>>>>> a key factor being used to share information about the software. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Finally never-mind bearer bias, how are client credentials >>>>>>>>> rotated interoperably if the only thing rotated is client_secret? >>>>>>>> >>>>>>>> *any* parameter on the client, including the >>>>>>>> registration_access_token and any extension parameters, can be >>>>>>>> rotated on any call to the Read or Update methods (except for >>>>>>>> client_id). So if you've got another mechanism for doing client >>>>>>>> authentication, you can rotate that, too. >>>>>>>> >>>>>>>>> >>>>>>>>> I would say the spec only works for client secrets and/or >>>>>>>>> all-in-one domain where there is no interop. >>>>>>>> >>>>>>>> Considering I've personally used it across domains and without >>>>>>>> client secrets (using jwks_uri to register public keys), I have >>>>>>>> to empirically disagree with that statement. >>>>>>>> >>>>>>>> -- Justin >>>>>>>> >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> On 2013-06-06, at 1:53, John Bradley >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> There are a couple of reasons. >>>>>>>>>> >>>>>>>>>> One criticism Hannes and others make of OAuth specs is they >>>>>>>>>> are not tightly profiled enough to be interoperable without >>>>>>>>>> further out of band configuration and profiling. >>>>>>>>>> >>>>>>>>>> Making registration work with minimal ambiguity was a >>>>>>>>>> priority for Connect and that has carried over. >>>>>>>>>> >>>>>>>>>> I am not opposed to having this extended at some point in the >>>>>>>>>> future, once we have a second token type. The new token type >>>>>>>>>> should be available to do updates as well. >>>>>>>>>> >>>>>>>>>> The problem is that starting down the HoK route potentially >>>>>>>>>> requires a registered client that may need to be registered >>>>>>>>>> to do the registration. >>>>>>>>>> I think that is best left to another spec to sort out the >>>>>>>>>> possible turtles. >>>>>>>>>> >>>>>>>>>> So the default needs to be bearer tokens unless registration >>>>>>>>>> is extended by another profile. >>>>>>>>>> >>>>>>>>>> John B. >>>>>>>>>> On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - >>>>>>>>>> FI/Espoo)" >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Because bearer tokens have a stable RFC-numbered spec and >>>>>>>>>>> are widely implemented and the registration flow as >>>>>>>>>>> documented seems like it should work? -T >>>>>>>>>>> That�s the answer for why there is support for bearer tokens >>>>>>>>>>> but it is not the answer to why that�s the only supported >>>>>>>>>>> mechanism. >>>>>>>>>>> If we want to support stronger security mechanisms (which >>>>>>>>>>> the group has decided to work on already) then we need to >>>>>>>>>>> have a story on how to support the other mechanisms as well . >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --------------060207090901030000070307 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Yes, this is exactly the case.

I think that signing/asserting/verifying registration information, if you want to do that, is better left to extensions from the basic draft. We have many documented use cases for using the structure and protocol as-is.

In BB+ we're using the initial access token mechanism to carry the signed information but defining discovery, token formats, and processing rules (and policies!) that make this actually work. We did this because carrying a signed chunk of information in a JWT is an established practice, as is using a JWT as an OAuth token, so it made sense to us. Putting that information inside of a software_id field with the same defined semantics would also be agreeable, I think, but I think we need a lot more eyes and hands on it. And either way, both of these mechanisms can be easily be built on top of the registration draft as is by either defining the processing of the initial access token (which is what BB+ does) or by defining a new metadata parameter (which is what you're suggesting), or even by providing some other mechanism that we haven't thought of yet.

So my question is: Are you OK with this functionality being defined as a proper extension so that the base draft can move forward (and that we take care not to *block* such an extension in the base draft), and do you want to help write that extension? I'd be happy to help write it, and I think we can probably get some of the BB+ group over here as well to offer input from that side. I also think that we can start to extract cross-domain OAuth token processing rules to provide real cross-domain interoperability, which would also be inherited by the registration draft.

�-- Justin

On 06/06/2013 02:05 PM, Phil Hunt wrote:

I think we are getting to the source of the confusion.

To me, the client POSTING to the registration endpoint in federated scenarios is usually anonymous. �It can present signed registration claims. My preference was through a non-credential vector, like �the software_id parameter. �This is just registration information.

In your case, you are defining a local access token issued to a developer inside a single domain. This is no inter-op, so no need to specify. �I still would prefer that it be defined as local registration information, but in this case ONLY I can accept it is local authorization.

In this case, the process works the same, only now the client is no longer anonymous. It is just doing instance registration.

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:54 AM, Justin Richer wrote:

... My bad, you're right. I was getting my wires crossed with all these emails.

In my view, the initial access token is, fundamentally, an access token used to constrain access to the registration endpoint (not the configuration endpoint, and not to get "normal" access tokens). Just like a normal OAuth token is an opaque token used to constrain access to the protected resource. If you want to define anything more for either of those, you're going to need more work.

I'm completely on board with making those definitions, but I think it goes beyond registration. And if registration is silent on all of this, and just says "the registration endpoint may be an OAuth 2.0 protected resource", then whatever interoperable solutions we can come up with for validating a cross-domain token can be applied here. I don't think it makes sense to constrain registration before the rest of this work is baked.

�-- Justin

On 06/06/2013 01:50 PM, Phil Hunt wrote:

We have two separate discussions going on. �8-)

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:48 AM, Justin Richer wrote:

I thought we were talking about the registration access token, not the initial access token?

�-- Justin

On 06/06/2013 01:48 PM, Phil Hunt wrote:

This is why this to-MAY-to vs. to-MAH-to distinction around is the initial access token an authorization token is important.

The purpose for the initial access token is dramatically different then normal access tokens. �This is for "registration" and does not constitute authentication or authorization.

Therefore, in this case, I do not believe that defining access tokens in the broader sense makes this issue clearer.

Registration is a very specific process different than authorization.

This might be a good paper to look at so the group understands why I am differentiating authorization from what is happening with initial access:

http://tools.ietf.org/html/draft-hallambaker-httpauth-00

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:37 AM, Justin Richer wrote:

Interoperability of the processing of OAuth tokens is a separate issue that needs to be solved not just for registration. When it is solved in the wider case, Registration as-is will inherit the solution.

So today, if you're using an Initial Access Token (which is optional), then you're locked to whatever process you want to use to verify/validate that token. Since it's just an OAuth token, you've got a number of things that you can do (assertions, introspection, magic).

I'd rather we solve the *real* cross-domain issue in the wider case than just try to cram something into registration.

�-- Justin

On 06/06/2013 01:33 PM, Phil Hunt wrote:

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

On 2013-06-06, at 10:05 AM, Justin Richer wrote:

On 06/06/2013 11:20 AM, Phil Hunt wrote:

As I've said before the initial auth token should nothing to do with auth. It is simply an assertion given to the developer to distribute in order to pass on signed claims about the software.

Phil, as I and several others have explained previously, that's not true at all. It's a token that gives authorization to the registration endpoint. The fact that you can use it as an assertion to pass along signed claims is an artifact of it being an OAuth token and an OAuth token is an opaque string. Please read through the dynamic registration draft again -- it says absolutely nothing about assertions, signatures, or claims with regard to this token.

It depends which case you are using. �If the developer is talking to a single deployment domain and obtains an initial access token and then ships it with all clients, then sure. �In this scenario, the contents are totally controlled by the local domain.

I agree. In this case, you don't care about inter-op. The whole environment is siloed. �But then, if this is your case, I'm not sure why this draft is at the IETF.

The interoperability case is where a third party generates that assertion and the deployment domain has to decide to accept it. �So you are a developer and you want to build a client for a Microsoft or Oracle app. �You want to be able to ship that to your customers. You register with the appropriate publisher and they give you a signed assertion that can be used as the "Initial Access Token". � �This token is then accepted by the deployment domain and then it decides if it trusts the signer or not.

===> For this to work, the contents and format of that token MUST be defined. � Otherwise how could we ensure a Microsoft signed assertion would be accepted by a PingIdentity OAuth server? �Or any other combination of implementations from different vendors/communities?

Bearer or not bearer is a distraction. The fact that the contents and format of this token is out of scope leaves a HUGE interop gap.

The fact that some of us (myself included) are *using* this token to carry this kind of information is out of scope for the basic registration spec. I completely agree that there's value in defining this stuff, but as a separate and complementary spec from registration.

[PH] I was reacting to John Bradley's assertion that the spec was narrowly defined with interop in mind. Yet this mechanism is a key factor being used to share information about the software.

Finally never-mind bearer bias, how are �client credentials rotated interoperably if the only thing rotated is client_secret?

*any* parameter on the client, including the registration_access_token and any extension parameters, can be rotated on any call to the Read or Update methods (except for client_id). So if you've got another mechanism for doing client authentication, you can rotate that, too.

I would say the spec only works for client secrets and/or all-in-one domain where there is no interop.

Considering I've personally used it across domains and without client secrets (using jwks_uri to register public keys), I have to empirically disagree with that statement.

�-- Justin

Phil

On 2013-06-06, at 1:53, John Bradley <ve7jtb@ve7jtb.com> wrote:

There are a couple of reasons. � �

One criticism Hannes and others make of OAuth specs is they are not tightly profiled enough to be interoperable without further out of band configuration and profiling.

Making registration work with minimal ambiguity was a priority for Connect and that has carried over.

I am not opposed to having this extended at some point in the future, once we have a second token type. � The new token type should be available to do updates as well.

The problem is that starting down the HoK route potentially requires a registered client that may need to be registered to do the registration. ��

I think that is best left to another spec to sort out the possible turtles.

So the default needs to be bearer tokens unless registration is extended by another profile.

John B.

On 2013-06-06, at 10:15 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> wrote:

Because bearer tokens have a stable RFC-numbered spec and are widely implemented and the registration flow as documented seems like it should work? �-T

�

That�s the answer for why there is support for bearer tokens but it is not the answer to why that�s the only supported mechanism.

If we want to support stronger security mechanisms (which the group has decided to work on already) then we need to have a story on how to support the other mechanisms as well .

_______________________________________________
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

--------------060207090901030000070307-- From internet-drafts@ietf.org Thu Jun 6 12:36:12 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7361D21F9954; Thu, 6 Jun 2013 12:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQjgkmCoGntQ; Thu, 6 Jun 2013 12:36:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8741821F9956; Thu, 6 Jun 2013 12:36:11 -0700 (PDT) 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.50 Message-ID: <20130606193611.23401.97321.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2013 12:36:11 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 19:36:12 -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 : OAuth 2.0 Dynamic Client Registration Protocol Author(s) : Justin Richer John Bradley Michael B. Jones Maciej Machulak Filename : draft-ietf-oauth-dyn-reg-12.txt Pages : 34 Date : 2013-06-06 Abstract: This specification defines an endpoint and protocol for dynamic registration of OAuth 2.0 Clients at an Authorization Server and methods for the dynamically registered client to manage its registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jricher@mitre.org Thu Jun 6 12:56:49 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F7A21F85E6 for ; Thu, 6 Jun 2013 12:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUYCrfBM-DsB for ; Thu, 6 Jun 2013 12:56:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C724011E80F7 for ; Thu, 6 Jun 2013 12:56:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3007A2450328 for ; Thu, 6 Jun 2013 15:56:43 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 22A162450310 for ; Thu, 6 Jun 2013 15:56:42 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 6 Jun 2013 15:56:42 -0400 Message-ID: <51B0E94A.5040804@mitre.org> Date: Thu, 6 Jun 2013 15:55:54 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: References: <20130606193611.23401.97321.idtracker@ietfa.amsl.com> In-Reply-To: <20130606193611.23401.97321.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 19:56:49 -0000 To make sure the discussion keeps moving forward, I've just published another revision that incorporates changes and clarifications brought up by reviews from Torsten, Amanda, Tim, Hannes, Phil, and others. All changes are editorial in nature (non-normative). -- Justin On 06/06/2013 03:36 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol Working Group of the IETF. > > Title : OAuth 2.0 Dynamic Client Registration Protocol > Author(s) : Justin Richer > John Bradley > Michael B. Jones > Maciej Machulak > Filename : draft-ietf-oauth-dyn-reg-12.txt > Pages : 34 > Date : 2013-06-06 > > Abstract: > This specification defines an endpoint and protocol for dynamic > registration of OAuth 2.0 Clients at an Authorization Server and > methods for the dynamically registered client to manage its > registration. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-12 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Fri Jun 7 14:58:41 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3395421F99A3 for ; Fri, 7 Jun 2013 14:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkRYVv8PULZJ for ; Fri, 7 Jun 2013 14:58:36 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8531C21F99A2 for ; Fri, 7 Jun 2013 14:58:36 -0700 (PDT) Received: from mail-ie0-f171.google.com ([209.85.223.171]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKUbJXjARDMM6JIShzoRvTrxrK0uKHdTwD@postini.com; Fri, 07 Jun 2013 14:58:36 PDT Received: by mail-ie0-f171.google.com with SMTP id s9so12007809iec.2 for ; Fri, 07 Jun 2013 14:58:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Tx1527QgmobFYWruu3FdyJlGXKtsXv0wRF9kiTQSuos=; b=AfYLwrKC3wV8EmtFGbLQ/TNdftBYqc2Urp4omnstRi0Mu2cRoM1DO1/aat4xiftWTr TT8hHgmcwijgiuOvFK4dmZlXvN8Z/LCMMTrWJCO2Q/ALyCF5rSpEZtl9hKzFm3MURSus U6ft9hBnnmGQDhMUoT048FIs2hRTiQpWyCGrHPIfw5tpjOd4oNAlxxxliYJP1A6NQuKf 8AZVao4LyPAwBsLv4R+iZ0lTYpixnkhDSAY+vi+4IMWB2mrQNFYfeEgIvyg8FwH1o1eI Uz8i0snH+Yvfvj1SjhNTfqgMYR+V0p3KtJiu6Y98fBSmUDBBQAgCrpHVQ54QvOGgChl2 22Bw== X-Received: by 10.50.83.35 with SMTP id n3mr303250igy.83.1370642315789; Fri, 07 Jun 2013 14:58:35 -0700 (PDT) X-Received: by 10.50.83.35 with SMTP id n3mr303248igy.83.1370642315658; Fri, 07 Jun 2013 14:58:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.27.68 with HTTP; Fri, 7 Jun 2013 14:58:05 -0700 (PDT) In-Reply-To: <5A436946-C417-402E-B1ED-327A035363BA@gmx.net> References: <5A436946-C417-402E-B1ED-327A035363BA@gmx.net> From: Brian Campbell Date: Fri, 7 Jun 2013 15:58:05 -0600 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e013cbd4c56ebd304de97883f X-Gm-Message-State: ALoCoQnbqFFai+OJNKeOFiHFvRtoSctvirBHhzYzpAjqdLaFH13f56t0zWjS6g3VrdWxpBNPmk08RZnilUXcQGib7BkVaUnRax47a8D/LL5sgEnnFFLTRBiruJsVPNc83Ya1jB1ErBg9fim6TRvxlNAqj2pRaUxZyg== Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Review of the assertion drafts X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 21:58:42 -0000 --089e013cbd4c56ebd304de97883f Content-Type: text/plain; charset=ISO-8859-1 Thanks for the review Hannes. I've tried to constrain and/or clarify things as much as I could. I am confident that those who deploy these specifications are willing to take the steps described - there are real deployments doing so now. The introduction in the SAML document is intended to express the use-case (which is basically trading a SAML assertion for an access token) but it sounds like you were looking for something else. Do you have concrete suggestions or text you'd like to propose towards that end? As far as an example for a client authentication with the SAML assertion goes, there is an example that shows the HTTP request part. But not the detailed example like there is for an assertion grant. I did consider a similar more detailed example for client authentication but decided at the time that it didn't add much. I'm happy to revisit that decision though, if folks think it would be useful? On Wed, May 29, 2013 at 1:35 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi assertion document authors, > Hi all, > > I took a look at the assertion framework draft > (draft-ietf-oauth-assertions-11) and the SAML assertion profile document > (draft-ietf-oauth-saml2-bearer-16.txt). > > In general, I have to say that they are moving in the right direction. I > see progress. > > In the assertion draft I particularly liked the improved clarity about > what has to be agreed out-of-band (which relates to interoperability): > " > Specific > items that require agreement are as follows: values for the > issuer > and audience identifiers, supported assertion and client > authentication types, the location of the token endpoint, and > the key > used to apply and verify the digital signature or keyed message > digest over the assertion. > " > > There are also various places where the number of options have been > reduced. Various clarifications in the text seem useful (e.g., the client > id to assertion mapping) although I have not checked them in detail. > > I was hoping for more constraints (so that fewer aspects need to be > configured out-of-band) but I guess you guys are not willing to sacrifice > flexibility. I am sure you have noticed that there are a lot of things that > need to be agreed out-of-band. I hope you feel confident that those who > deploy the specification are willing to take these steps. But at least the > spec is not silent about them and provides the necessary information to the > reader. > > I also recognize improvements regarding the SAML assertion document. While > the use case description is still missing (that would give a bit more > background about what the deployment environment is) there is now a better > example available. The example illustrates an assertion grant; do you think > it would be useful to also show an example for a client authentication with > the SAML assertion? > > I am planning to talk to Barry to see what he thinks about the updated > document and in the meanwhile I can read into the detailed changes. > > Ciao > Hannes > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBCgAGBQJRpliZAAoJEGhJURNOOiAtEI0H/3iAd1FyAwPI+EsLri5rjE+q > Ic7NGknlQSG/wl9w2xGuq32OuPo/PihLTuEpqIsxwoia5O5wKSX0X42wxMR9dLVk > H9bSy5SFj8AoI66KPGeapBB6Lmuzm/7dWknJW9fv1BWIixEkAppY+M08aAYOHW6d > OcOy+fEP2x9sx/CE1l6goaXi2hR7M9witrTiGr3Yf/BYkE9ouaAnnZYP/UMrP78N > L2clRCykdzLMjjSzugNqnD6KJguHoH4JTnlDT3NS6jL+KwxgXUB5dd8OECuYzlbl > 1Z3ORCzFrM7ODytH7HC7SCgsOkIyjb1/xFaTElkVFKkVmvR1rnBz/6+ydgJ+pVk= > =vLB5 > -----END PGP SIGNATURE----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --089e013cbd4c56ebd304de97883f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the review Hannes. I've tried to const= rain and/or clarify things as much as I could. I am confident that those wh= o deploy these specifications are willing to take the steps described - the= re are real deployments doing so now.

The introduction in the SAML document is intended to express= the use-case (which is basically trading a SAML assertion for an access to= ken) but it sounds like you were looking for something else. Do you have co= ncrete suggestions or text you'd like to propose towards that end?=A0 <= br>
As far as an example for a client authentication with the SA= ML assertion goes, there is an example that shows the HTTP request part. Bu= t not the detailed example like there is for an assertion grant. I did cons= ider a similar more detailed example for client authentication but decided = at the time that it didn't add much. I'm happy to revisit that deci= sion though, if folks think it would be useful?

=A0

On Wed, May 29, 2013 at 1:35 PM, H= annes Tschofenig <hannes.tschofenig@gmx.net> wrote:<= br>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi assertion document authors,
Hi all,

I took a look at the assertion framework draft (draft-ietf-oauth-assertions= -11) and the SAML assertion profile document (draft-ietf-oauth-saml2-bearer= -16.txt).

In general, I have to say that they are moving in the right direction. I se= e progress.

In the assertion draft I particularly liked the improved clarity about what= has to be agreed out-of-band (which relates to interoperability):
"
=A0 =A0 =A0 =A0 =A0 =A0Specific
=A0 =A0 =A0 =A0 =A0 =A0items that require agreement are as follows: values = for the issuer
=A0 =A0 =A0 =A0 =A0 =A0and audience identifiers, supported assertion and cl= ient
=A0 =A0 =A0 =A0 =A0 =A0authentication types, the location of the token endp= oint, and the key
=A0 =A0 =A0 =A0 =A0 =A0used to apply and verify the digital signature or ke= yed message
=A0 =A0 =A0 =A0 =A0 =A0digest over the assertion.
"

There are also various places where the number of options have been reduced= . Various clarifications in the text seem useful (e.g., the client id to as= sertion mapping) although I have not checked them in detail.

I was hoping for more constraints (so that fewer aspects need to be configu= red out-of-band) but I guess you guys are not willing to sacrifice flexibil= ity. I am sure you have noticed that there are a lot of things that need to= be agreed out-of-band. I hope you feel confident that those who deploy the= specification are willing to take these steps. But at least the spec is no= t silent about them and provides the necessary information to the reader.
I also recognize improvements regarding the SAML assertion document. While = the use case description is still missing (that would give a bit more backg= round about what the deployment environment is) there is now a better examp= le available. The example illustrates an assertion grant; do you think it w= ould be useful to also show an example for a client authentication with the= SAML assertion?

I am planning to talk to Barry to see what he thinks about the updated docu= ment and in the meanwhile I can read into the detailed changes.

Ciao
Hannes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http:= //gpgtools.org

iQEcBAEBCgAGBQJRpliZAAoJEGhJURNOOiAtEI0H/3iAd1FyAwPI+EsLri5rjE+q
Ic7NGknlQSG/wl9w2xGuq32OuPo/PihLTuEpqIsxwoia5O5wKSX0X42wxMR9dLVk
H9bSy5SFj8AoI66KPGeapBB6Lmuzm/7dWknJW9fv1BWIixEkAppY+M08aAYOHW6d
OcOy+fEP2x9sx/CE1l6goaXi2hR7M9witrTiGr3Yf/BYkE9ouaAnnZYP/UMrP78N
L2clRCykdzLMjjSzugNqnD6KJguHoH4JTnlDT3NS6jL+KwxgXUB5dd8OECuYzlbl
1Z3ORCzFrM7ODytH7HC7SCgsOkIyjb1/xFaTElkVFKkVmvR1rnBz/6+ydgJ+pVk=3D
=3DvLB5
-----END PGP SIGNATURE-----
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--089e013cbd4c56ebd304de97883f-- From torsten@lodderstedt.net Sat Jun 15 10:58:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABD721F9DE9; Sat, 15 Jun 2013 10:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOMpkJEArBaJ; Sat, 15 Jun 2013 10:58:30 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by ietfa.amsl.com (Postfix) with ESMTP id A84CA21F9DDB; Sat, 15 Jun 2013 10:58:29 -0700 (PDT) Received: from [79.253.33.22] (helo=[192.168.71.68]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Unuk6-0006Ym-NB; Sat, 15 Jun 2013 19:58:26 +0200 Message-ID: <51BCAB42.3010204@lodderstedt.net> Date: Sat, 15 Jun 2013 19:58:26 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Richard Barnes References: <20130529190805.7996.64437.idtracker@ietfa.amsl.com> In-Reply-To: <20130529190805.7996.64437.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: draft-ietf-oauth-revocation@tools.ietf.org, oauth-chairs@tools.ietf.org, The IESG , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-revocation-09: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 17:58:34 -0000 Hi Richard, thanks for your review. Please find my comments inline. @oauth WG: I would like to gather opinions regarding an issue raised by Richard thus I'm dispatching this to the list as well. regards, Torsten. Am 29.05.2013 21:08, schrieb Richard Barnes: > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-revocation-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > D1. The mandate for TLS usage actually seems backward here. Suppose a > server receives a request over HTTP. At this point, the credentials have > been exposed, so you would *want* the token to be invalidated! Suggest: > -- Clients MUST NOT send over HTTP > -- Server revocation URIs MUST be HTTPS > -- Servers MAY support HTTP to the corresponding URI, just in case the > client screws up I see your point. Doesn't the last bullet contradict the first bullet? > > D2. Why are the requirements TLS versions different here than in RFC > 6749? Especially in a way that makes them worse. Suggest deleting the > sentence starting "The authorization server MUST support TLS 1.0 ..." subject to ongoing discussion on the WG list. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > C1. "Depending on the authorization server's revocation policy..." > It seems really bad for interop to have all of this be at the server's > discretion and opaque to the client. While its true that clients have to > be able to handle unilateral revocation, at the very least this leads to > unpredictable user experience. (Why am I being asked to authenticate > again?) Suggest that the document either place constraints on the > server, or have the server's response say exactly which tokens have been > revoked. The latter option might leak some information if tokens are not > opaque, but doesn't present a security risk, since by definition the > tokens are no longer good. It is at the discretion of the authorization server and the resource owner to invalidate any token at any time w/o notifying the client. So I don't see a reason to handle propagated token revocation any different here. I agree this causes unpredictable UX but I don't see a interop issue. > > C2. "unsupported_token_type" -- This seems insufficient. What if a > server can invalidate some access tokens and not others? (For example, > if it has different relationships with different resource servers.) It > seems like what you really want here is just a statement by the server > that "I can't revoke this token". Good point. Our assumption so far is that an authz server uses excactly one access token implementation and either supports access token revocation or not. What you envisions is an authz servers, which uses different access token implementations for different resource servers (probably even use cases). Correct? In order to support this use case, we would need to change the error name and description. I would like to discuss this in the WG. Any opinion from the WG? > > C3. It might be helpful to describe what happens if a client tries to > revoke something other than a valid token. If the token is bogus (not > issued by the Authorization Server), then it seems like "invalid_grant" > makes sense. However, if the token was issued and revoked by the > Authorization Server, then it seems like the request should return > success -- not "invalid_grant", as RFC 6749 implies. We had a long discussion about this and decided to not notify the client but just return 200. > > From internet-drafts@ietf.org Sun Jun 16 02:13:46 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61F621F9E9C; Sun, 16 Jun 2013 02:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsbu9BVHHFw4; Sun, 16 Jun 2013 02:13:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFEC21F9EA0; Sun, 16 Jun 2013 02:13:45 -0700 (PDT) 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.51.p2 Message-ID: <20130616091345.2031.39661.idtracker@ietfa.amsl.com> Date: Sun, 16 Jun 2013 02:13:45 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 09:13:47 -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 : OAuth 2.0 Token Revocation Author(s) : Torsten Lodderstedt Stefanie Dronia Marius Scurtescu Filename : draft-ietf-oauth-revocation-10.txt Pages : 11 Date : 2013-06-16 Abstract: This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-revocation-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From torsten@lodderstedt.net Sun Jun 16 02:28:29 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AE721F9E94; Sun, 16 Jun 2013 02:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uqa6bgLgEP0Z; Sun, 16 Jun 2013 02:28:23 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id E98BE21F9E64; Sun, 16 Jun 2013 02:28:22 -0700 (PDT) Received: from [79.253.34.124] (helo=[192.168.71.68]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Uo9G0-0002Fj-Ju; Sun, 16 Jun 2013 11:28:21 +0200 Message-ID: <51BD8536.9010805@lodderstedt.net> Date: Sun, 16 Jun 2013 11:28:22 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: internet-drafts@ietf.org References: <20130616091345.2031.39661.idtracker@ietfa.amsl.com> In-Reply-To: <20130616091345.2031.39661.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org, i-d-announce@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 09:28:30 -0000 Hi, the new revision addresses DISCUSSES and comments raised during IESG evaluation: - DISCUSS by Barry Leiba: incoporated Barry's text proposal - it strengthens requirements on the authorization server to immediately revoke tokens while acknowledging the practical constraints on change propagation among distributed servers - D2 by Richard Barnes: changed text to refer to respective section of RFC 6749 on TLS version - description of revocation endpoint URL now refers to respective section of RFC 6749 (comment by Sean Turner) - added intro to IANA section (comment by Joel Jaeggli) - some nits and editorial changes - should cover all comments raised during IESG evaluation There are two open issues - discussion regarding the TLS version on the list - DISCUSS regarding the mandate to use TLS (D1/Richard Barnes) regards, Torsten. Am 16.06.2013 11:13, schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol Working Group of the IETF. > > Title : OAuth 2.0 Token Revocation > Author(s) : Torsten Lodderstedt > Stefanie Dronia > Marius Scurtescu > Filename : draft-ietf-oauth-revocation-10.txt > Pages : 11 > Date : 2013-06-16 > > Abstract: > This document proposes an additional endpoint for OAuth authorization > servers, which allows clients to notify the authorization server that > a previously obtained refresh or access token is no longer needed. > This allows the authorization server to cleanup security credentials. > A revocation request will invalidate the actual token and, if > applicable, other tokens based on the same authorization grant. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-revocation-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-10 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sberyozkin@gmail.com Mon Jun 17 02:18:28 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BFD21F9B2D for ; Mon, 17 Jun 2013 02:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYrIKO559kqe for ; Mon, 17 Jun 2013 02:18:26 -0700 (PDT) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id E181121F9B3A for ; Mon, 17 Jun 2013 02:18:25 -0700 (PDT) Received: by mail-bk0-f48.google.com with SMTP id jf17so1045831bkc.21 for ; Mon, 17 Jun 2013 02:18:24 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=VL0bLxoXQ6nSmAOKKGMXCAJff3FREX1c+npS9MM3wQQ=; b=Zf+cYkFhPrzHZJ/AwK5lryczwYWAWpYWmCPwGriPYT4oEIe4TNQSSH2J7wtc/5TDzp N8ZhWOMkbfBGMp9Og+Ic8ptLjq5LQQ7hNdftghiLJH5i2LD/QURBa7fTxyQnfGV/ckCa kgTsOQrVySbNJiv4leeYzG+u/HL5R4TYWFYjS8CI7OiHY3GeL6d0mwh1vZsT0Wn0Gzjq Uqcwc+5jjeMlNwrvEUn8285s/cF+yldKd/l1VGi47kushFQlQVKBV8U8Rj9zkXXp3+Uf nqHucQ0fjP6cIJM+pOLZF8igh3UyAEtRi/f88464aZP6LkEZtDbzYlMWJ/+ddd4D4R7N G6OA== X-Received: by 10.205.131.72 with SMTP id hp8mr1790000bkc.20.1371460704228; Mon, 17 Jun 2013 02:18:24 -0700 (PDT) Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPSA id v7sm3201990bkh.12.2013.06.17.02.18.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Jun 2013 02:18:23 -0700 (PDT) Message-ID: <51BED44A.8060001@gmail.com> Date: Mon, 17 Jun 2013 10:18:02 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Reusing access tokens with scopes that allow updates X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 09:18:28 -0000 Hi, apologies if it is off-topic, though I'm hoping it won't be completely, I'm working on a demo where an access token allows a client to update the end user's resource, example, a calendar. For example, the end user requests a reservation service to book some event and the user may allow the client to update a calendar at a specific hour only. So in the authorization code flow, it may look like this: - client requests a code with scopes like "readCalendar updateCalendar-7" where "updateCalendar-7" means a request to update the user's calendar at 7 o'clock. - the user approves it and subsequently the client can update a calendar at the request hour only. This has worked well in the earlier version of the demo, but now that I've started looking into extending the demo such that the end user is not requested an authorization every time this user asks the reservation service to book something by attempting to reuse the existing access token I'm seeing the problems. The client (reservation service) associates an access token with a given user's alias and it seems that reusing this token before it has expired makes sense. However, the token was given to a client to allow update the calendar at 7'0 clock and now the end user requests to book something at 9 o'clock. So reusing that token seems wrong after all. This led me to conclude that when an access token allows to update something then it is effectively a single-use token only, with its expires_in (and refresh_token) having no any real value. Unless the end user is asked to 'widen' the requested scope, something along these lines: "The client has asked to update your calendar at 7. Do you want to allow it ? If yes - would you consider also allowing the client to update other calendar slots - this will let your authorization be reused until it has expired ?" Something like that - which would mean an access token would actually get a scope like "updateCalendar-24" meaning the client can update any calendar slot while working with this given access token. My questions are: - Does it sound correct that unless the user allows otherwise, the access tokens with the scopes which allow for the modification are not reusable ? - The idea of the end user widening the scope requested by the client, is it a wise idea at all ? - What would be the preferred OAuth2 way to do it if widening the scopes is not recommended ? Thanks, Sergey From sberyozkin@gmail.com Mon Jun 17 03:14:27 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568D621F9BA6 for ; Mon, 17 Jun 2013 03:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zPnhV1WBHI3 for ; Mon, 17 Jun 2013 03:14:20 -0700 (PDT) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 590BB21F9BAA for ; Mon, 17 Jun 2013 03:12:38 -0700 (PDT) Received: by mail-bk0-f42.google.com with SMTP id jk13so1103663bkc.29 for ; Mon, 17 Jun 2013 03:12:10 -0700 (PDT) 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=e4043YcovyyCWosEqxpebeINNXygubMLE2gsYWiHWT0=; b=BUrdBraZ3DtSN4CmPVWnQYMT8swpbiS27b41l2KyTmLQGRfUWTsj7mT9nvmV2xrtzp EytBhC7JAQ3AdXvbXsdpm7CEom78nMBq5Ofo+J9UHR/GCVHxD/e07ILC8Qs9CEsrD4Si H5r4TsG417RwdLzjlzO8TziKobnfmdEZwLCNWd9BXxfuF2X6fP0XO5rAOEyVk4c6bcr+ 3hPsQwF7+JLgedfcmldLF0DBqp+AH2lfrehhhQGep4uc6GChAd7NXxcFhkZ3PGyRpL3g dKul06yPGR9zBi+VUxeFHGIWuUif4x/xLunT0eljVkPdHY0vIbFg2rDS9ryABASIRrZf 012A== X-Received: by 10.205.36.5 with SMTP id sy5mr1836325bkb.182.1371463930385; Mon, 17 Jun 2013 03:12:10 -0700 (PDT) Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPSA id m6sm2710093bki.7.2013.06.17.03.12.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Jun 2013 03:12:09 -0700 (PDT) Message-ID: <51BEE0F7.2090702@gmail.com> Date: Mon, 17 Jun 2013 11:12:07 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "" References: <51BED44A.8060001@gmail.com> In-Reply-To: <51BED44A.8060001@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Reusing access tokens with scopes that allow updates X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 10:14:28 -0000 On 17/06/13 10:18, Sergey Beryozkin wrote: > Hi, apologies if it is off-topic, though I'm hoping it won't be completely, > > I'm working on a demo where an access token allows a client to update > the end user's resource, example, a calendar. For example, the end user > requests a reservation service to book some event and the user may allow > the client to update a calendar at a specific hour only. > > So in the authorization code flow, it may look like this: > > - client requests a code with scopes like "readCalendar > updateCalendar-7" where "updateCalendar-7" means a request to update the > user's calendar at 7 o'clock. > - the user approves it and subsequently the client can update a calendar > at the request hour only. > > This has worked well in the earlier version of the demo, but now that > I've started looking into extending the demo such that the end user is > not requested an authorization every time this user asks the reservation > service to book something by attempting to reuse the existing access > token I'm seeing the problems. > > The client (reservation service) associates an access token with a given > user's alias and it seems that reusing this token before it has expired > makes sense. However, the token was given to a client to allow update > the calendar at 7'0 clock and now the end user requests to book > something at 9 o'clock. So reusing that token seems wrong after all. > > This led me to conclude that when an access token allows to update > something then it is effectively a single-use token only, with its > expires_in (and refresh_token) having no any real value. > > Unless the end user is asked to 'widen' the requested scope, something > along these lines: "The client has asked to update your calendar at 7. > Do you want to allow it ? If yes - would you consider also allowing the > client to update other calendar slots - this will let your authorization > be reused until it has expired ?" > > Something like that - which would mean an access token would actually > get a scope like "updateCalendar-24" meaning the client can update any > calendar slot while working with this given access token. > > My questions are: > - Does it sound correct that unless the user allows otherwise, the > access tokens with the scopes which allow for the modification are not > reusable ? > - The idea of the end user widening the scope requested by the client, > is it a wise idea at all ? > - What would be the preferred OAuth2 way to do it if widening the scopes > is not recommended ? I've thought a bit more about it and I guess it is not exactly the OAuth2 issue, but rather an application design issue. Specifically, it is up to a client to decide if it wants a token be reused (for calendar updates while the token is valid) or not and if it wants then it should request a wide-enough scope at the start of the flow, example, request "readCalendar updateCalendar-24" and let the user to either authorize the calendar updates at any time of the day or downscope the requested scopes to allow the client to read a calendar only and then for a client to report the end user it can not update the calendar. I think I'm more or less clear on this but any comments will be of course welcome; again - sorry if it is off-topic Sergey > > Thanks, Sergey > > > > > > > > > From phil.hunt@oracle.com Wed Jun 19 10:05:44 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B720C21F98AD for ; Wed, 19 Jun 2013 10:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.302 X-Spam-Level: X-Spam-Status: No, score=-6.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaBQJSFKd9QF for ; Wed, 19 Jun 2013 10:05:37 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DDEF521F9DD7 for ; Wed, 19 Jun 2013 10:05:25 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5JGx7gG008648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 19 Jun 2013 16:59:08 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JH5OkQ015320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Jun 2013 17:05:24 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JH5NhZ022510 for ; Wed, 19 Jun 2013 17:05:23 GMT Received: from [192.168.1.128] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jun 2013 10:05:23 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jun 2013 10:05:20 -0700 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [OAUTH-WG] dyn reg - Human Readable Client Metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:05:44 -0000 I am looking over the section on Human Readable Client Metadata and am a = bit confused as it pertains to the rest of the specification and the = implications for service providers. Is it the intention that even single-valued client metadata may have = multiple localized values? Or, is the assumption that a client would = signal its preferred language and that ALL metadata values have only ONE = localization at a time? I started considering this when I got to the section discussing things = like having client_name#ja-Jpan-JP and client_name#en. =20 Would be a lot simpler to have preferredLanguage be part of the client = schema and assume that all human readable fields have been localized by = the client. It seems to me to be more complex if every client registers = its entire set of language translations for each piece of metadata if = the user will only ever use one at a time. Why track all variants? My thought is that in the case of OAuth client interactions, all = language localization is to drive the interface for the personal use of = the user at hand. We don't have the case as we do in directories where = an english language person might be looking up information about a = Japanese person. That said, it would become a normal for a client to trigger a = registration "update" event for the client to update its metadata when = the client detected a change in language by the user. E.g. from en to = ja-JPan-JP. Phil @independentid www.independentid.com phil.hunt@oracle.com From jricher@mitre.org Wed Jun 19 10:19:04 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2876221F9DC5 for ; Wed, 19 Jun 2013 10:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMnEfpOWW3Zs for ; Wed, 19 Jun 2013 10:18:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4AB21F9E3F for ; Wed, 19 Jun 2013 10:18:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 086691F02F2; Wed, 19 Jun 2013 13:18:59 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E1C8D1F02F3; Wed, 19 Jun 2013 13:18:58 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.194]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 13:18:58 -0400 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] dyn reg - Human Readable Client Metadata Thread-Index: AQHObQ9BAVQgdF2aqEOxRxazXoJqLZk9ixmA Date: Wed, 19 Jun 2013 17:18:57 +0000 Message-ID: <39BD4318-6F8C-4FD2-8D4D-FA3DB3CC4CF6@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: [172.31.12.243] Content-Type: text/plain; charset="us-ascii" Content-ID: <2BDE0F889B7E864E9EE104B1FD0285D0@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:19:04 -0000 Your question seems to assume a one-to-one mapping between client and user,= and that's not guaranteed to be the case. Think of an installed web applic= ation that's talking to an auth server, and that web application is going t= o talk to a number of different users. Those users can have multiple differ= ent language preferences. The human-readable fields are sent to the auth se= rver so that the auth server can display them to the end user during the au= thorization screen and the application management screens. As such, it make= s sense (and was requested by the working group at the last IETF) that a cl= ient can register its whole set of languages and the auth server picks the = appropriate one to display to the user.=20 It used to be the case that there was only a single value (unadorned with l= anguage tags) for things like client_name, and a client would've had to reg= ister itself multiple times to get at different languages. The Working Grou= p decided that this was both too complicated and too error prone, so we ado= pted (and adapted) the OpenID Connect method for flagging languages. This a= llows a client to register once for all users and all language types. It wo= uldn't make sense (and it would cause serious race conditions) for a client= to try and switch languages mid-stream for different users.=20 On the server side, if your auth server wants to handle localized values ap= propriately, it will need to parse and manage multiple tagged values for ea= ch human readable field. However, we're recommending that clients always se= nd the bare field with an internationalized value (i.e., it's got the best = chance of being read by the largest audience for the client/auth server, a = good default if you will), so you can fairly safely just look for and use t= he bare fields in most cases.=20 Hope this clears things up. If you have any recommendations for how to make= this intended usage clearer, I'd be happy to accept some new suggested tex= t. Thanks, -- Justin On Jun 19, 2013, at 1:05 PM, Phil Hunt wrote: > I am looking over the section on Human Readable Client Metadata and am a = bit confused as it pertains to the rest of the specification and the implic= ations for service providers. >=20 > Is it the intention that even single-valued client metadata may have mult= iple localized values? Or, is the assumption that a client would signal i= ts preferred language and that ALL metadata values have only ONE localizati= on at a time? >=20 > I started considering this when I got to the section discussing things li= ke having client_name#ja-Jpan-JP and client_name#en. =20 >=20 > Would be a lot simpler to have preferredLanguage be part of the client sc= hema and assume that all human readable fields have been localized by the c= lient. It seems to me to be more complex if every client registers its ent= ire set of language translations for each piece of metadata if the user wil= l only ever use one at a time. Why track all variants? >=20 > My thought is that in the case of OAuth client interactions, all language= localization is to drive the interface for the personal use of the user at= hand. We don't have the case as we do in directories where an english lan= guage person might be looking up information about a Japanese person. >=20 > That said, it would become a normal for a client to trigger a registratio= n "update" event for the client to update its metadata when the client dete= cted a change in language by the user. E.g. from en to ja-JPan-JP. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Wed Jun 19 10:27:14 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB34E21F9B63 for ; Wed, 19 Jun 2013 10:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.622 X-Spam-Level: X-Spam-Status: No, score=-5.622 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feY95ksdrFwF for ; Wed, 19 Jun 2013 10:27:09 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A3D9A21F9AEE for ; Wed, 19 Jun 2013 10:27:09 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5JHR8vO013493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jun 2013 17:27:09 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JHR7Ia019008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 17:27:08 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JHR7fc011689; Wed, 19 Jun 2013 17:27:07 GMT Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jun 2013 10:27:07 -0700 References: <39BD4318-6F8C-4FD2-8D4D-FA3DB3CC4CF6@mitre.org> Mime-Version: 1.0 (1.0) In-Reply-To: <39BD4318-6F8C-4FD2-8D4D-FA3DB3CC4CF6@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Wed, 19 Jun 2013 10:27:05 -0700 To: "Richer, Justin P." X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:27:14 -0000 Justin Thanks for refreshing my mind. I forgot the web client case is acting on beh= alf of many users.=20 Phil On 2013-06-19, at 10:18, "Richer, Justin P." wrote: > Your question seems to assume a one-to-one mapping between client and user= , and that's not guaranteed to be the case. Think of an installed web applic= ation that's talking to an auth server, and that web application is going to= talk to a number of different users. Those users can have multiple differen= t language preferences. The human-readable fields are sent to the auth serve= r so that the auth server can display them to the end user during the author= ization screen and the application management screens. As such, it makes sen= se (and was requested by the working group at the last IETF) that a client c= an register its whole set of languages and the auth server picks the appropr= iate one to display to the user.=20 >=20 > It used to be the case that there was only a single value (unadorned with l= anguage tags) for things like client_name, and a client would've had to regi= ster itself multiple times to get at different languages. The Working Group d= ecided that this was both too complicated and too error prone, so we adopted= (and adapted) the OpenID Connect method for flagging languages. This allows= a client to register once for all users and all language types. It wouldn't= make sense (and it would cause serious race conditions) for a client to try= and switch languages mid-stream for different users.=20 >=20 > On the server side, if your auth server wants to handle localized values a= ppropriately, it will need to parse and manage multiple tagged values for ea= ch human readable field. However, we're recommending that clients always sen= d the bare field with an internationalized value (i.e., it's got the best ch= ance of being read by the largest audience for the client/auth server, a goo= d default if you will), so you can fairly safely just look for and use the b= are fields in most cases.=20 >=20 > Hope this clears things up. If you have any recommendations for how to mak= e this intended usage clearer, I'd be happy to accept some new suggested tex= t. >=20 > Thanks, >=20 > -- Justin >=20 > On Jun 19, 2013, at 1:05 PM, Phil Hunt > wrote: >=20 >> I am looking over the section on Human Readable Client Metadata and am a b= it confused as it pertains to the rest of the specification and the implicat= ions for service providers. >>=20 >> Is it the intention that even single-valued client metadata may have mult= iple localized values? Or, is the assumption that a client would signal it= s preferred language and that ALL metadata values have only ONE localization= at a time? >>=20 >> I started considering this when I got to the section discussing things li= ke having client_name#ja-Jpan-JP and client_name#en. =20 >>=20 >> Would be a lot simpler to have preferredLanguage be part of the client sc= hema and assume that all human readable fields have been localized by the cl= ient. It seems to me to be more complex if every client registers its entir= e set of language translations for each piece of metadata if the user will o= nly ever use one at a time. Why track all variants? >>=20 >> My thought is that in the case of OAuth client interactions, all language= localization is to drive the interface for the personal use of the user at h= and. We don't have the case as we do in directories where an english langua= ge person might be looking up information about a Japanese person. >>=20 >> That said, it would become a normal for a client to trigger a registratio= n "update" event for the client to update its metadata when the client detec= ted a change in language by the user. E.g. from en to ja-JPan-JP. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From ve7jtb@ve7jtb.com Wed Jun 19 13:55:51 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AB921F9605 for ; Wed, 19 Jun 2013 13:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dS9Bj5NoB6zU for ; Wed, 19 Jun 2013 13:55:46 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id EFAB421E80AF for ; Wed, 19 Jun 2013 13:55:44 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id 1so3588138qee.12 for ; Wed, 19 Jun 2013 13:55:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=cEqEXZxOXKJSnW7/hmxZ1u701vQZfNMMO7vzJuXQI4c=; b=N8PQkPxClRx/ixA9SXqeh7ePC/Y2amZzuATOg1FleQiIKW3i6E+wOxbrESlix+fNKs KYzuHlRuZ0qwegkHbr2w71yL2U+jwo00lzJNnPAFOIt0kSwij6hJqtT8fEIS1ENTy7cn NZm+DYA+f83NBtHNPpsLbINyDRI2dHx1jo6Wzxqb8UnBmWEw74J3oi9VlTXFSahnVENF IzSfHIbAfYUb4UOCpKiP3xwKdObbeNFmWzaCPCpax+1j0luM2X8DvANqEwmcjz/BZF7N PiQimbWWT9SEXG+P1ptBBW7E336fuQnHWmQYBnWGDU40/WUHd0Bi1Op3PX+76m0qgpr1 qGIg== X-Received: by 10.224.105.130 with SMTP id t2mr5743345qao.90.1371675344257; Wed, 19 Jun 2013 13:55:44 -0700 (PDT) Received: from [10.2.2.156] (75-147-25-205-NewEngland.hfc.comcastbusiness.net. [75.147.25.205]) by mx.google.com with ESMTPSA id cf14sm36554579qab.0.2013.06.19.13.55.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 13:55:42 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_58541D58-7296-4806-B937-B4B31BA81325"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: John Bradley In-Reply-To: Date: Wed, 19 Jun 2013 16:55:40 -0400 Message-Id: <64506187-BE27-4A97-AD6B-6E6C68056389@ve7jtb.com> References: <39BD4318-6F8C-4FD2-8D4D-FA3DB3CC4CF6@mitre.org> To: Phil Hunt X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQnHomIGNx4pBj5Vieo+iXUg6d+sxooApMtVWqp9M66sTWDplabTD744iJV/yjtstGDvJrHR Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 20:55:51 -0000 --Apple-Mail=_58541D58-7296-4806-B937-B4B31BA81325 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes that is an important Connect use case for Web server client = registration. Also thought of as a typical web SP. John B. On 2013-06-19, at 1:27 PM, Phil Hunt wrote: > Justin >=20 > Thanks for refreshing my mind. I forgot the web client case is acting = on behalf of many users.=20 >=20 > Phil >=20 > On 2013-06-19, at 10:18, "Richer, Justin P." = wrote: >=20 >> Your question seems to assume a one-to-one mapping between client and = user, and that's not guaranteed to be the case. Think of an installed = web application that's talking to an auth server, and that web = application is going to talk to a number of different users. Those users = can have multiple different language preferences. The human-readable = fields are sent to the auth server so that the auth server can display = them to the end user during the authorization screen and the application = management screens. As such, it makes sense (and was requested by the = working group at the last IETF) that a client can register its whole set = of languages and the auth server picks the appropriate one to display to = the user.=20 >>=20 >> It used to be the case that there was only a single value (unadorned = with language tags) for things like client_name, and a client would've = had to register itself multiple times to get at different languages. The = Working Group decided that this was both too complicated and too error = prone, so we adopted (and adapted) the OpenID Connect method for = flagging languages. This allows a client to register once for all users = and all language types. It wouldn't make sense (and it would cause = serious race conditions) for a client to try and switch languages = mid-stream for different users.=20 >>=20 >> On the server side, if your auth server wants to handle localized = values appropriately, it will need to parse and manage multiple tagged = values for each human readable field. However, we're recommending that = clients always send the bare field with an internationalized value = (i.e., it's got the best chance of being read by the largest audience = for the client/auth server, a good default if you will), so you can = fairly safely just look for and use the bare fields in most cases.=20 >>=20 >> Hope this clears things up. If you have any recommendations for how = to make this intended usage clearer, I'd be happy to accept some new = suggested text. >>=20 >> Thanks, >>=20 >> -- Justin >>=20 >> On Jun 19, 2013, at 1:05 PM, Phil Hunt >> wrote: >>=20 >>> I am looking over the section on Human Readable Client Metadata and = am a bit confused as it pertains to the rest of the specification and = the implications for service providers. >>>=20 >>> Is it the intention that even single-valued client metadata may have = multiple localized values? Or, is the assumption that a client would = signal its preferred language and that ALL metadata values have only ONE = localization at a time? >>>=20 >>> I started considering this when I got to the section discussing = things like having client_name#ja-Jpan-JP and client_name#en. =20 >>>=20 >>> Would be a lot simpler to have preferredLanguage be part of the = client schema and assume that all human readable fields have been = localized by the client. It seems to me to be more complex if every = client registers its entire set of language translations for each piece = of metadata if the user will only ever use one at a time. Why track all = variants? >>>=20 >>> My thought is that in the case of OAuth client interactions, all = language localization is to drive the interface for the personal use of = the user at hand. We don't have the case as we do in directories where = an english language person might be looking up information about a = Japanese person. >>>=20 >>> That said, it would become a normal for a client to trigger a = registration "update" event for the client to update its metadata when = the client detected a change in language by the user. E.g. from en to = ja-JPan-JP. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_58541D58-7296-4806-B937-B4B31BA81325 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 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjE5MjA1NTQwWjAjBgkqhkiG9w0BCQQxFgQUw5XZKPMV hvhPhfRczrmLw+8xWQkwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAJKpmJhhzU/TA5HHBte8xpLwJ6P7MdZsrAzePSHs0 H6aqFvTZr7gXcsZAG/l3a/1AgjwnWci6TCA108FoZoY7HcDd4rMRa2w7ES0JajHTJSn+/T/I8W+U /NcuuO0ry29hdm2S5OSRbZtmQsCpY2FIy7ERTFer+mpPbXRDjDrcGpTidQd2paDwmxRVq/RD9HMs js/Iu52LjNmg8mgMRH5wFq3z1GuCFr0u2ea+IebO/8TVPt+T7dwvR5/cc6tmN9AjDttY4+JDL14a 7lfph+EGAkP0ErU2bZOmjDZktwm3ZSnYDtZkkpTZ96+QqOct1foUv40lAGHaabW+Wy3YRNHaYAAA AAAAAA== --Apple-Mail=_58541D58-7296-4806-B937-B4B31BA81325-- From phil.hunt@oracle.com Wed Jun 19 16:36:11 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0258421F9D0A for ; Wed, 19 Jun 2013 16:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.296 X-Spam-Level: X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls0AGnFCmecf for ; Wed, 19 Jun 2013 16:36:05 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D5D0721F9D4E for ; Wed, 19 Jun 2013 16:36:05 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5JNTk95005123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jun 2013 23:29:47 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JNa2S4000949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 23:36:03 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5JNa1Cq029970; Wed, 19 Jun 2013 23:36:02 GMT Received: from [192.168.1.128] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jun 2013 16:36:01 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Phil Hunt In-Reply-To: <64506187-BE27-4A97-AD6B-6E6C68056389@ve7jtb.com> Date: Wed, 19 Jun 2013 16:36:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <489BA1EA-656A-450B-B45F-998CB17CA31B@oracle.com> References: <39BD4318-6F8C-4FD2-8D4D-FA3DB3CC4CF6@mitre.org> <64506187-BE27-4A97-AD6B-6E6C68056389@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 23:36:11 -0000 Ok. So then going down this path, is the chosen encoding method, which = is LDAPish, the right way to go? =20 For example, I read the spec as suggesting: {=20 =85 "client_name#en":"My Client", "client_name#ja-Jpan-JP": = "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" ... } Why not make it more JSON-esque such as: {=20 =85 "client_name":[ { "value":"My Client", "lang":"en", "primary":"TRUE" } { "value":"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", "lang":"ja-Jpan-JP" } ] =85 } I mention this format as it seems more JSON-like and it is more = SCIM-friendly. Also wondering if anyone knows how vCards does = localization? I agree the draft format is more compact. But it requires more complex = attribute name parsing, whereas the SCIMish expression requires more = JSON parsing. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-06-19, at 1:55 PM, John Bradley wrote: > Yes that is an important Connect use case for Web server client = registration. Also thought of as a typical web SP. >=20 > John B. >=20 >=20 >=20 > On 2013-06-19, at 1:27 PM, Phil Hunt wrote: >=20 >> Justin >>=20 >> Thanks for refreshing my mind. I forgot the web client case is acting = on behalf of many users.=20 >>=20 >> Phil >>=20 >> On 2013-06-19, at 10:18, "Richer, Justin P." = wrote: >>=20 >>> Your question seems to assume a one-to-one mapping between client = and user, and that's not guaranteed to be the case. Think of an = installed web application that's talking to an auth server, and that web = application is going to talk to a number of different users. Those users = can have multiple different language preferences. The human-readable = fields are sent to the auth server so that the auth server can display = them to the end user during the authorization screen and the application = management screens. As such, it makes sense (and was requested by the = working group at the last IETF) that a client can register its whole set = of languages and the auth server picks the appropriate one to display to = the user.=20 >>>=20 >>> It used to be the case that there was only a single value (unadorned = with language tags) for things like client_name, and a client would've = had to register itself multiple times to get at different languages. The = Working Group decided that this was both too complicated and too error = prone, so we adopted (and adapted) the OpenID Connect method for = flagging languages. This allows a client to register once for all users = and all language types. It wouldn't make sense (and it would cause = serious race conditions) for a client to try and switch languages = mid-stream for different users.=20 >>>=20 >>> On the server side, if your auth server wants to handle localized = values appropriately, it will need to parse and manage multiple tagged = values for each human readable field. However, we're recommending that = clients always send the bare field with an internationalized value = (i.e., it's got the best chance of being read by the largest audience = for the client/auth server, a good default if you will), so you can = fairly safely just look for and use the bare fields in most cases.=20 >>>=20 >>> Hope this clears things up. If you have any recommendations for how = to make this intended usage clearer, I'd be happy to accept some new = suggested text. >>>=20 >>> Thanks, >>>=20 >>> -- Justin >>>=20 >>> On Jun 19, 2013, at 1:05 PM, Phil Hunt >>> wrote: >>>=20 >>>> I am looking over the section on Human Readable Client Metadata and = am a bit confused as it pertains to the rest of the specification and = the implications for service providers. >>>>=20 >>>> Is it the intention that even single-valued client metadata may = have multiple localized values? Or, is the assumption that a client = would signal its preferred language and that ALL metadata values have = only ONE localization at a time? >>>>=20 >>>> I started considering this when I got to the section discussing = things like having client_name#ja-Jpan-JP and client_name#en. =20 >>>>=20 >>>> Would be a lot simpler to have preferredLanguage be part of the = client schema and assume that all human readable fields have been = localized by the client. It seems to me to be more complex if every = client registers its entire set of language translations for each piece = of metadata if the user will only ever use one at a time. Why track all = variants? >>>>=20 >>>> My thought is that in the case of OAuth client interactions, all = language localization is to drive the interface for the personal use of = the user at hand. We don't have the case as we do in directories where = an english language person might be looking up information about a = Japanese person. >>>>=20 >>>> That said, it would become a normal for a client to trigger a = registration "update" event for the client to update its metadata when = the client detected a change in language by the user. E.g. from en to = ja-JPan-JP. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From jricher@mitre.org Thu Jun 20 06:06:13 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932AA21F9A8D for ; Thu, 20 Jun 2013 06:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHfGJgQhxdjW for ; Thu, 20 Jun 2013 06:06:08 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A7CF721F95D7 for ; Thu, 20 Jun 2013 06:05:54 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BB73B1F0ABE; Thu, 20 Jun 2013 09:05:53 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 92EF61F09C0; Thu, 20 Jun 2013 09:05:53 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 20 Jun 2013 09:05:53 -0400 Message-ID: <51C2FDF0.1040705@mitre.org> Date: Thu, 20 Jun 2013 09:04:48 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <39BD4318-6F8C-4FD2-8D4D-FA3DB3CC4CF6@mitre.org> <64506187-BE27-4A97-AD6B-6E6C68056389@ve7jtb.com> <489BA1EA-656A-450B-B45F-998CB17CA31B@oracle.com> In-Reply-To: <489BA1EA-656A-450B-B45F-998CB17CA31B@oracle.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 13:06:13 -0000 One of the things I really like about the current approach is that it leaves the bare field name as a simple string attribute, like: { ... "client_name": "My Client", "client_name#en":"My Client", "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" ... } So I can just grab client.client_name and get what I'm expecting most of the time, I don't need to pick a language tag if I don't care about or don't support them. This is why we're recommending that *all* clients send the "client_name" value alone, and if they want to, send "client_name#en" and "client_name#ja-Jpan-JP" as well. With the JSON structure, I'd have to get client.client_name as an array and search through it to find the one tagged "primary: true". That's a lot of work to just find a display string. Webfinger currently uses a different JSON structure like this: { "en-us" : "The Magical World of Bob", "fr" : "Le Monde Magique de Bob" } Though it was proposed a while back that they use the hash structure instead as well. This also has the problem that I have to call client.client_name.en-us explicitly, or client.client_name.und if it's there. I think we should make the use cases for single-language deployments (and internationlized deployments) simpler, and the hash structure does that at the expense of some extra attribute parsing for the more complex use case. -- Justin On 06/19/2013 07:36 PM, Phil Hunt wrote: > Ok. So then going down this path, is the chosen encoding method, which is LDAPish, the right way to go? > > For example, I read the spec as suggesting: > > { > � > > "client_name#en":"My Client", > "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" > ... > } > > Why not make it more JSON-esque such as: > > { > � > > "client_name":[ > { > "value":"My Client", > "lang":"en", > "primary":"TRUE" > } > { > "value":"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", > "lang":"ja-Jpan-JP" > } > ] > � > } > > I mention this format as it seems more JSON-like and it is more SCIM-friendly. Also wondering if anyone knows how vCards does localization? > > I agree the draft format is more compact. But it requires more complex attribute name parsing, whereas the SCIMish expression requires more JSON parsing. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-06-19, at 1:55 PM, John Bradley wrote: > >> Yes that is an important Connect use case for Web server client registration. Also thought of as a typical web SP. >> >> John B. >> >> >> >> On 2013-06-19, at 1:27 PM, Phil Hunt wrote: >> >>> Justin >>> >>> Thanks for refreshing my mind. I forgot the web client case is acting on behalf of many users. >>> >>> Phil >>> >>> On 2013-06-19, at 10:18, "Richer, Justin P." wrote: >>> >>>> Your question seems to assume a one-to-one mapping between client and user, and that's not guaranteed to be the case. Think of an installed web application that's talking to an auth server, and that web application is going to talk to a number of different users. Those users can have multiple different language preferences. The human-readable fields are sent to the auth server so that the auth server can display them to the end user during the authorization screen and the application management screens. As such, it makes sense (and was requested by the working group at the last IETF) that a client can register its whole set of languages and the auth server picks the appropriate one to display to the user. >>>> >>>> It used to be the case that there was only a single value (unadorned with language tags) for things like client_name, and a client would've had to register itself multiple times to get at different languages. The Working Group decided that this was both too complicated and too error prone, so we adopted (and adapted) the OpenID Connect method for flagging languages. This allows a client to register once for all users and all language types. It wouldn't make sense (and it would cause serious race conditions) for a client to try and switch languages mid-stream for different users. >>>> >>>> On the server side, if your auth server wants to handle localized values appropriately, it will need to parse and manage multiple tagged values for each human readable field. However, we're recommending that clients always send the bare field with an internationalized value (i.e., it's got the best chance of being read by the largest audience for the client/auth server, a good default if you will), so you can fairly safely just look for and use the bare fields in most cases. >>>> >>>> Hope this clears things up. If you have any recommendations for how to make this intended usage clearer, I'd be happy to accept some new suggested text. >>>> >>>> Thanks, >>>> >>>> -- Justin >>>> >>>> On Jun 19, 2013, at 1:05 PM, Phil Hunt >>>> wrote: >>>> >>>>> I am looking over the section on Human Readable Client Metadata and am a bit confused as it pertains to the rest of the specification and the implications for service providers. >>>>> >>>>> Is it the intention that even single-valued client metadata may have multiple localized values? Or, is the assumption that a client would signal its preferred language and that ALL metadata values have only ONE localization at a time? >>>>> >>>>> I started considering this when I got to the section discussing things like having client_name#ja-Jpan-JP and client_name#en. >>>>> >>>>> Would be a lot simpler to have preferredLanguage be part of the client schema and assume that all human readable fields have been localized by the client. It seems to me to be more complex if every client registers its entire set of language translations for each piece of metadata if the user will only ever use one at a time. Why track all variants? >>>>> >>>>> My thought is that in the case of OAuth client interactions, all language localization is to drive the interface for the personal use of the user at hand. We don't have the case as we do in directories where an english language person might be looking up information about a Japanese person. >>>>> >>>>> That said, it would become a normal for a client to trigger a registration "update" event for the client to update its metadata when the client detected a change in language by the user. E.g. from en to ja-JPan-JP. >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 From phil.hunt@oracle.com Thu Jun 20 10:44:27 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE09921F9F62 for ; Thu, 20 Jun 2013 10:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JV+NQ6o1SOm for ; Thu, 20 Jun 2013 10:44:22 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 79D9F21F9F58 for ; Thu, 20 Jun 2013 10:44:22 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5KHc3Ws021169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jun 2013 17:38:04 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5KHiK5c022485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 17:44:21 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5KHiKWd022450; Thu, 20 Jun 2013 17:44:20 GMT Received: from [192.168.1.128] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 10:44:19 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Phil Hunt In-Reply-To: <51C2FDF0.1040705@mitre.org> Date: Thu, 20 Jun 2013 10:44:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39BD4318-6F8C-4FD2-8D4D-FA3DB3CC4CF6@mitre.org> <64506187-BE27-4A97-AD6B-6E6C68056389@ve7jtb.com> <489BA1EA-656A-450B-B45F-998CB17CA31B@oracle.com> <51C2FDF0.1040705@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:44:27 -0000 The larger issue is that multi-lingual requirements do not go from 1 to = 2 or 3 languages, the requirements tend to go to 8 or 60 or more. This = is why I was hoping we could observe that clients simply want to select = a single preferred language. That said, web clients clearly need a = multi-language solution. As we do this, imagine javascript clients doing dyn reg with 60 = languages. That's a LOT of data being moved around. Even under normal = use, scale becomes a concern. How fast is it parsed? When is it stored? = Where is it stored? How is it retrieved and by what component(s)? I can think of a couple of possibilities to manage this: * Differentiate between public (or rather personal) clients that tend to = use only one language vs. web clients that are fewer in number but = support many users with many languages * Break registration into 2 parts: software registration (has all the = UI and language stuff), and client instance registration (deals with = only per-instance protocol driven data). While my gut reaction is simply towards the first (least breaking), the = latter strikes me as far more scalable (though with more complexity) -- = especially if the group really wants to proceed with implicit client = support that tends to register on every execution. Any other ideas? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-06-20, at 6:04 AM, Justin Richer wrote: > One of the things I really like about the current approach is that it = leaves the bare field name as a simple string attribute, like: >=20 > { > ... > "client_name": "My Client", > "client_name#en":"My Client", > "client_name#ja-Jpan-JP": = "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" > ... > } >=20 > So I can just grab client.client_name and get what I'm expecting most = of the time, I don't need to pick a language tag if I don't care about = or don't support them. This is why we're recommending that *all* clients = send the "client_name" value alone, and if they want to, send = "client_name#en" and "client_name#ja-Jpan-JP" as well. >=20 > With the JSON structure, I'd have to get client.client_name as an = array and search through it to find the one tagged "primary: true". = That's a lot of work to just find a display string. >=20 > Webfinger currently uses a different JSON structure like this: >=20 > { > "en-us" : "The Magical World of Bob", > "fr" : "Le Monde Magique de Bob" > } >=20 > Though it was proposed a while back that they use the hash structure = instead as well. This also has the problem that I have to call = client.client_name.en-us explicitly, or client.client_name.und if it's = there. I think we should make the use cases for single-language = deployments (and internationlized deployments) simpler, and the hash = structure does that at the expense of some extra attribute parsing for = the more complex use case. >=20 > -- Justin >=20 >=20 > On 06/19/2013 07:36 PM, Phil Hunt wrote: >> Ok. So then going down this path, is the chosen encoding method, = which is LDAPish, the right way to go? >>=20 >> For example, I read the spec as suggesting: >>=20 >> { >> =85 >>=20 >> "client_name#en":"My Client", >> "client_name#ja-Jpan-JP": = "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" >> ... >> } >>=20 >> Why not make it more JSON-esque such as: >>=20 >> { >> =85 >>=20 >> "client_name":[ >> { >> "value":"My Client", >> "lang":"en", >> "primary":"TRUE" >> } >> { >> "value":"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", >> "lang":"ja-Jpan-JP" >> } >> ] >> =85 >> } >>=20 >> I mention this format as it seems more JSON-like and it is more = SCIM-friendly. Also wondering if anyone knows how vCards does = localization? >>=20 >> I agree the draft format is more compact. But it requires more = complex attribute name parsing, whereas the SCIMish expression requires = more JSON parsing. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-06-19, at 1:55 PM, John Bradley wrote: >>=20 >>> Yes that is an important Connect use case for Web server client = registration. Also thought of as a typical web SP. >>>=20 >>> John B. >>>=20 >>>=20 >>>=20 >>> On 2013-06-19, at 1:27 PM, Phil Hunt wrote: >>>=20 >>>> Justin >>>>=20 >>>> Thanks for refreshing my mind. I forgot the web client case is = acting on behalf of many users. >>>>=20 >>>> Phil >>>>=20 >>>> On 2013-06-19, at 10:18, "Richer, Justin P." = wrote: >>>>=20 >>>>> Your question seems to assume a one-to-one mapping between client = and user, and that's not guaranteed to be the case. Think of an = installed web application that's talking to an auth server, and that web = application is going to talk to a number of different users. Those users = can have multiple different language preferences. The human-readable = fields are sent to the auth server so that the auth server can display = them to the end user during the authorization screen and the application = management screens. As such, it makes sense (and was requested by the = working group at the last IETF) that a client can register its whole set = of languages and the auth server picks the appropriate one to display to = the user. >>>>>=20 >>>>> It used to be the case that there was only a single value = (unadorned with language tags) for things like client_name, and a client = would've had to register itself multiple times to get at different = languages. The Working Group decided that this was both too complicated = and too error prone, so we adopted (and adapted) the OpenID Connect = method for flagging languages. This allows a client to register once for = all users and all language types. It wouldn't make sense (and it would = cause serious race conditions) for a client to try and switch languages = mid-stream for different users. >>>>>=20 >>>>> On the server side, if your auth server wants to handle localized = values appropriately, it will need to parse and manage multiple tagged = values for each human readable field. However, we're recommending that = clients always send the bare field with an internationalized value = (i.e., it's got the best chance of being read by the largest audience = for the client/auth server, a good default if you will), so you can = fairly safely just look for and use the bare fields in most cases. >>>>>=20 >>>>> Hope this clears things up. If you have any recommendations for = how to make this intended usage clearer, I'd be happy to accept some new = suggested text. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On Jun 19, 2013, at 1:05 PM, Phil Hunt >>>>> wrote: >>>>>=20 >>>>>> I am looking over the section on Human Readable Client Metadata = and am a bit confused as it pertains to the rest of the specification = and the implications for service providers. >>>>>>=20 >>>>>> Is it the intention that even single-valued client metadata may = have multiple localized values? Or, is the assumption that a client = would signal its preferred language and that ALL metadata values have = only ONE localization at a time? >>>>>>=20 >>>>>> I started considering this when I got to the section discussing = things like having client_name#ja-Jpan-JP and client_name#en. >>>>>>=20 >>>>>> Would be a lot simpler to have preferredLanguage be part of the = client schema and assume that all human readable fields have been = localized by the client. It seems to me to be more complex if every = client registers its entire set of language translations for each piece = of metadata if the user will only ever use one at a time. Why track all = variants? >>>>>>=20 >>>>>> My thought is that in the case of OAuth client interactions, all = language localization is to drive the interface for the personal use of = the user at hand. We don't have the case as we do in directories where = an english language person might be looking up information about a = Japanese person. >>>>>>=20 >>>>>> That said, it would become a normal for a client to trigger a = registration "update" event for the client to update its metadata when = the client detected a change in language by the user. E.g. from en to = ja-JPan-JP. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >=20 From jricher@mitre.org Thu Jun 20 11:39:18 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F9921F9F2D for ; Thu, 20 Jun 2013 11:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLV+Ka5TGXcZ for ; Thu, 20 Jun 2013 11:39:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 82E5B21F9EBC for ; Thu, 20 Jun 2013 11:39:10 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E2B6A22601D0; Thu, 20 Jun 2013 14:39:06 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 545E622601F0; Thu, 20 Jun 2013 14:39:06 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 20 Jun 2013 14:39:04 -0400 Message-ID: <51C34C07.9020300@mitre.org> Date: Thu, 20 Jun 2013 14:37:59 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <39BD4318-6F8C-4FD2-8D4D-FA3DB3CC4CF6@mitre.org> <64506187-BE27-4A97-AD6B-6E6C68056389@ve7jtb.com> <489BA1EA-656A-450B-B45F-998CB17CA31B@oracle.com> <51C2FDF0.1040705@mitre.org> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 18:39:18 -0000 For clients that simple want to use a single preferred language, we've got the bare field without the language tag (eg, "client_name"). I think we need to keep that. So the remaining question is whether and how to handle multiple language tags. I think any format changes are going to have the same scale issues -- it's inherent to the problem that if you want to pass around a lot of data, you're going to have a lot of data. With the use cases that have been brought up so far, it seems that the clients who would register the most often (the "public" dynamic clients) would probably have enough in-session information to pick a single client for a single user and be done with it. The clients who need to register many language for many users would be registering less often. So, the scaling problem seems to be self-limiting in that regard, right? The Javascript client you describe below probably wouldn't try to register with 60 languages, it would just pick one for the current user. I think it'll be fairly self-selecting with the general mechanism that's in there now, so I don't think that the mechanism for language in human-facing fields actually needs to change for this reason. However: Splitting things in two, as you suggest, is a prime candidate for an extension to dynamic registration. If we do it right we can solve it for more than just the language tags *without* breaking the underlying registration spec, which is already useful on its own. Specifically, if you're doing a two-stage dynamic registration, your first stage is the new step defined by the extension and the second (instance) stage is the existing Dyn-Reg spec with some extra processing on the part of the registration endpoint. If we can define the right mechanisms around assertions, discovery, validation, pre-registry and all that, you can actually do things pretty much exactly we both want to. The new pre-registration process handles any "fixed" parameters (languages, redirects, and stuff, perhaps) and generates something that can be handed to all instances of the software. This is a thing that can be validated by the registration endpoint and used to tie the instance presenting it into a larger ecosystem of a particular piece of software. Every instance will still get its own client_id and client_secret (a good thing), but the AS would know how to tie all these things together. With that in mind, I think it's important that we have the appropriate extension mechanisms in the dynamic registration spec to allow it, and so far, everything is there that I can think of. You can use the initial access token in the call to the registration endpoint (like we did with BB+), you can have an extension parameter to the client metadata (like you proposed with software_id, particularly as an assertion), and it's up to the registration endpoint to validate any of these. What we need are definitions of what actually goes *in* any of these components as well as the appropriate rules for validation and parsing in order for them to be useful and interoperable. -- Justin On 06/20/2013 01:44 PM, Phil Hunt wrote: > The larger issue is that multi-lingual requirements do not go from 1 to 2 or 3 languages, the requirements tend to go to 8 or 60 or more. This is why I was hoping we could observe that clients simply want to select a single preferred language. That said, web clients clearly need a multi-language solution. > > As we do this, imagine javascript clients doing dyn reg with 60 languages. That's a LOT of data being moved around. Even under normal use, scale becomes a concern. How fast is it parsed? When is it stored? Where is it stored? How is it retrieved and by what component(s)? > > I can think of a couple of possibilities to manage this: > * Differentiate between public (or rather personal) clients that tend to use only one language vs. web clients that are fewer in number but support many users with many languages > * Break registration into 2 parts: software registration (has all the UI and language stuff), and client instance registration (deals with only per-instance protocol driven data). > > While my gut reaction is simply towards the first (least breaking), the latter strikes me as far more scalable (though with more complexity) -- especially if the group really wants to proceed with implicit client support that tends to register on every execution. > > Any other ideas? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-06-20, at 6:04 AM, Justin Richer wrote: > >> One of the things I really like about the current approach is that it leaves the bare field name as a simple string attribute, like: >> >> { >> ... >> "client_name": "My Client", >> "client_name#en":"My Client", >> "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" >> ... >> } >> >> So I can just grab client.client_name and get what I'm expecting most of the time, I don't need to pick a language tag if I don't care about or don't support them. This is why we're recommending that *all* clients send the "client_name" value alone, and if they want to, send "client_name#en" and "client_name#ja-Jpan-JP" as well. >> >> With the JSON structure, I'd have to get client.client_name as an array and search through it to find the one tagged "primary: true". That's a lot of work to just find a display string. >> >> Webfinger currently uses a different JSON structure like this: >> >> { >> "en-us" : "The Magical World of Bob", >> "fr" : "Le Monde Magique de Bob" >> } >> >> Though it was proposed a while back that they use the hash structure instead as well. This also has the problem that I have to call client.client_name.en-us explicitly, or client.client_name.und if it's there. I think we should make the use cases for single-language deployments (and internationlized deployments) simpler, and the hash structure does that at the expense of some extra attribute parsing for the more complex use case. >> >> -- Justin >> >> >> On 06/19/2013 07:36 PM, Phil Hunt wrote: >>> Ok. So then going down this path, is the chosen encoding method, which is LDAPish, the right way to go? >>> >>> For example, I read the spec as suggesting: >>> >>> { >>> � >>> >>> "client_name#en":"My Client", >>> "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" >>> ... >>> } >>> >>> Why not make it more JSON-esque such as: >>> >>> { >>> � >>> >>> "client_name":[ >>> { >>> "value":"My Client", >>> "lang":"en", >>> "primary":"TRUE" >>> } >>> { >>> "value":"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", >>> "lang":"ja-Jpan-JP" >>> } >>> ] >>> � >>> } >>> >>> I mention this format as it seems more JSON-like and it is more SCIM-friendly. Also wondering if anyone knows how vCards does localization? >>> >>> I agree the draft format is more compact. But it requires more complex attribute name parsing, whereas the SCIMish expression requires more JSON parsing. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2013-06-19, at 1:55 PM, John Bradley wrote: >>> >>>> Yes that is an important Connect use case for Web server client registration. Also thought of as a typical web SP. >>>> >>>> John B. >>>> >>>> >>>> >>>> On 2013-06-19, at 1:27 PM, Phil Hunt wrote: >>>> >>>>> Justin >>>>> >>>>> Thanks for refreshing my mind. I forgot the web client case is acting on behalf of many users. >>>>> >>>>> Phil >>>>> >>>>> On 2013-06-19, at 10:18, "Richer, Justin P." wrote: >>>>> >>>>>> Your question seems to assume a one-to-one mapping between client and user, and that's not guaranteed to be the case. Think of an installed web application that's talking to an auth server, and that web application is going to talk to a number of different users. Those users can have multiple different language preferences. The human-readable fields are sent to the auth server so that the auth server can display them to the end user during the authorization screen and the application management screens. As such, it makes sense (and was requested by the working group at the last IETF) that a client can register its whole set of languages and the auth server picks the appropriate one to display to the user. >>>>>> >>>>>> It used to be the case that there was only a single value (unadorned with language tags) for things like client_name, and a client would've had to register itself multiple times to get at different languages. The Working Group decided that this was both too complicated and too error prone, so we adopted (and adapted) the OpenID Connect method for flagging languages. This allows a client to register once for all users and all language types. It wouldn't make sense (and it would cause serious race conditions) for a client to try and switch languages mid-stream for different users. >>>>>> >>>>>> On the server side, if your auth server wants to handle localized values appropriately, it will need to parse and manage multiple tagged values for each human readable field. However, we're recommending that clients always send the bare field with an internationalized value (i.e., it's got the best chance of being read by the largest audience for the client/auth server, a good default if you will), so you can fairly safely just look for and use the bare fields in most cases. >>>>>> >>>>>> Hope this clears things up. If you have any recommendations for how to make this intended usage clearer, I'd be happy to accept some new suggested text. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -- Justin >>>>>> >>>>>> On Jun 19, 2013, at 1:05 PM, Phil Hunt >>>>>> wrote: >>>>>> >>>>>>> I am looking over the section on Human Readable Client Metadata and am a bit confused as it pertains to the rest of the specification and the implications for service providers. >>>>>>> >>>>>>> Is it the intention that even single-valued client metadata may have multiple localized values? Or, is the assumption that a client would signal its preferred language and that ALL metadata values have only ONE localization at a time? >>>>>>> >>>>>>> I started considering this when I got to the section discussing things like having client_name#ja-Jpan-JP and client_name#en. >>>>>>> >>>>>>> Would be a lot simpler to have preferredLanguage be part of the client schema and assume that all human readable fields have been localized by the client. It seems to me to be more complex if every client registers its entire set of language translations for each piece of metadata if the user will only ever use one at a time. Why track all variants? >>>>>>> >>>>>>> My thought is that in the case of OAuth client interactions, all language localization is to drive the interface for the personal use of the user at hand. We don't have the case as we do in directories where an english language person might be looking up information about a Japanese person. >>>>>>> >>>>>>> That said, it would become a normal for a client to trigger a registration "update" event for the client to update its metadata when the client detected a change in language by the user. E.g. from en to ja-JPan-JP. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 From phil.hunt@oracle.com Thu Jun 20 13:15:06 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE8521E80DD for ; Thu, 20 Jun 2013 13:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL-wKQ+MZbjY for ; Thu, 20 Jun 2013 13:15:01 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E284221E80C1 for ; Thu, 20 Jun 2013 13:15:00 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5KK8guW018623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jun 2013 20:08:43 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5KKExtI022576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 20:14:59 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5KKEwE4004318; Thu, 20 Jun 2013 20:14:59 GMT Received: from [192.168.1.128] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jun 2013 13:14:58 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Phil Hunt In-Reply-To: <51C34C07.9020300@mitre.org> Date: Thu, 20 Jun 2013 13:14:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39BD4318-6F8C-4FD2-8D4D-FA3DB3CC4CF6@mitre.org> <64506187-BE27-4A97-AD6B-6E6C68056389@ve7jtb.com> <489BA1EA-656A-450B-B45F-998CB17CA31B@oracle.com> <51C2FDF0.1040705@mitre.org> <51C34C07.9020300@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 20:15:06 -0000 Let's think on this. I'm not convinced (yet) that creating an extension = point is the right thing to do. For me, extensions are appropriate when = there is a need to support multiple ways of doing something -- like = tokens for example. =20 In this case, we're talking about adding a single, possibly optional, = way of doing something. IOW. I think this is a "if you are going to do = it, you must do it this way" situation. Still, in general, we could try to work it in a backwards compatible way = if possible. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-06-20, at 11:37 AM, Justin Richer wrote: > For clients that simple want to use a single preferred language, we've = got the bare field without the language tag (eg, "client_name"). I think = we need to keep that. So the remaining question is whether and how to = handle multiple language tags. I think any format changes are going to = have the same scale issues -- it's inherent to the problem that if you = want to pass around a lot of data, you're going to have a lot of data. = With the use cases that have been brought up so far, it seems that the = clients who would register the most often (the "public" dynamic clients) = would probably have enough in-session information to pick a single = client for a single user and be done with it. The clients who need to = register many language for many users would be registering less often. = So, the scaling problem seems to be self-limiting in that regard, right? = The Javascript client you describe below probably wouldn't try to = register with 60 languages, it would just pick one for the current user. = I think it'll be fairly self-selecting with the general mechanism that's = in there now, so I don't think that the mechanism for language in = human-facing fields actually needs to change for this reason. >=20 > However: Splitting things in two, as you suggest, is a prime candidate = for an extension to dynamic registration. If we do it right we can solve = it for more than just the language tags *without* breaking the = underlying registration spec, which is already useful on its own. = Specifically, if you're doing a two-stage dynamic registration, your = first stage is the new step defined by the extension and the second = (instance) stage is the existing Dyn-Reg spec with some extra processing = on the part of the registration endpoint. If we can define the right = mechanisms around assertions, discovery, validation, pre-registry and = all that, you can actually do things pretty much exactly we both want = to. The new pre-registration process handles any "fixed" parameters = (languages, redirects, and stuff, perhaps) and generates something that = can be handed to all instances of the software. This is a thing that can = be validated by the registration endpoint and used to tie the instance = presenting it into a larger ecosystem of a particular piece of software. = Every instance will still get its own client_id and client_secret (a = good thing), but the AS would know how to tie all these things together. >=20 > With that in mind, I think it's important that we have the appropriate = extension mechanisms in the dynamic registration spec to allow it, and = so far, everything is there that I can think of. You can use the initial = access token in the call to the registration endpoint (like we did with = BB+), you can have an extension parameter to the client metadata (like = you proposed with software_id, particularly as an assertion), and it's = up to the registration endpoint to validate any of these. What we need = are definitions of what actually goes *in* any of these components as = well as the appropriate rules for validation and parsing in order for = them to be useful and interoperable. >=20 > -- Justin >=20 > On 06/20/2013 01:44 PM, Phil Hunt wrote: >> The larger issue is that multi-lingual requirements do not go from 1 = to 2 or 3 languages, the requirements tend to go to 8 or 60 or more. = This is why I was hoping we could observe that clients simply want to = select a single preferred language. That said, web clients clearly need = a multi-language solution. >>=20 >> As we do this, imagine javascript clients doing dyn reg with 60 = languages. That's a LOT of data being moved around. Even under normal = use, scale becomes a concern. How fast is it parsed? When is it stored? = Where is it stored? How is it retrieved and by what component(s)? >>=20 >> I can think of a couple of possibilities to manage this: >> * Differentiate between public (or rather personal) clients that tend = to use only one language vs. web clients that are fewer in number but = support many users with many languages >> * Break registration into 2 parts: software registration (has all = the UI and language stuff), and client instance registration (deals with = only per-instance protocol driven data). >>=20 >> While my gut reaction is simply towards the first (least breaking), = the latter strikes me as far more scalable (though with more complexity) = -- especially if the group really wants to proceed with implicit client = support that tends to register on every execution. >>=20 >> Any other ideas? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-06-20, at 6:04 AM, Justin Richer wrote: >>=20 >>> One of the things I really like about the current approach is that = it leaves the bare field name as a simple string attribute, like: >>>=20 >>> { >>> ... >>> "client_name": "My Client", >>> "client_name#en":"My Client", >>> "client_name#ja-Jpan-JP": = "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" >>> ... >>> } >>>=20 >>> So I can just grab client.client_name and get what I'm expecting = most of the time, I don't need to pick a language tag if I don't care = about or don't support them. This is why we're recommending that *all* = clients send the "client_name" value alone, and if they want to, send = "client_name#en" and "client_name#ja-Jpan-JP" as well. >>>=20 >>> With the JSON structure, I'd have to get client.client_name as an = array and search through it to find the one tagged "primary: true". = That's a lot of work to just find a display string. >>>=20 >>> Webfinger currently uses a different JSON structure like this: >>>=20 >>> { >>> "en-us" : "The Magical World of Bob", >>> "fr" : "Le Monde Magique de Bob" >>> } >>>=20 >>> Though it was proposed a while back that they use the hash structure = instead as well. This also has the problem that I have to call = client.client_name.en-us explicitly, or client.client_name.und if it's = there. I think we should make the use cases for single-language = deployments (and internationlized deployments) simpler, and the hash = structure does that at the expense of some extra attribute parsing for = the more complex use case. >>>=20 >>> -- Justin >>>=20 >>>=20 >>> On 06/19/2013 07:36 PM, Phil Hunt wrote: >>>> Ok. So then going down this path, is the chosen encoding method, = which is LDAPish, the right way to go? >>>>=20 >>>> For example, I read the spec as suggesting: >>>>=20 >>>> { >>>> =85 >>>>=20 >>>> "client_name#en":"My Client", >>>> "client_name#ja-Jpan-JP": = "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" >>>> ... >>>> } >>>>=20 >>>> Why not make it more JSON-esque such as: >>>>=20 >>>> { >>>> =85 >>>>=20 >>>> "client_name":[ >>>> { >>>> "value":"My Client", >>>> "lang":"en", >>>> "primary":"TRUE" >>>> } >>>> { >>>> "value":"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", >>>> "lang":"ja-Jpan-JP" >>>> } >>>> ] >>>> =85 >>>> } >>>>=20 >>>> I mention this format as it seems more JSON-like and it is more = SCIM-friendly. Also wondering if anyone knows how vCards does = localization? >>>>=20 >>>> I agree the draft format is more compact. But it requires more = complex attribute name parsing, whereas the SCIMish expression requires = more JSON parsing. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-06-19, at 1:55 PM, John Bradley wrote: >>>>=20 >>>>> Yes that is an important Connect use case for Web server client = registration. Also thought of as a typical web SP. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-06-19, at 1:27 PM, Phil Hunt wrote: >>>>>=20 >>>>>> Justin >>>>>>=20 >>>>>> Thanks for refreshing my mind. I forgot the web client case is = acting on behalf of many users. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> On 2013-06-19, at 10:18, "Richer, Justin P." = wrote: >>>>>>=20 >>>>>>> Your question seems to assume a one-to-one mapping between = client and user, and that's not guaranteed to be the case. Think of an = installed web application that's talking to an auth server, and that web = application is going to talk to a number of different users. Those users = can have multiple different language preferences. The human-readable = fields are sent to the auth server so that the auth server can display = them to the end user during the authorization screen and the application = management screens. As such, it makes sense (and was requested by the = working group at the last IETF) that a client can register its whole set = of languages and the auth server picks the appropriate one to display to = the user. >>>>>>>=20 >>>>>>> It used to be the case that there was only a single value = (unadorned with language tags) for things like client_name, and a client = would've had to register itself multiple times to get at different = languages. The Working Group decided that this was both too complicated = and too error prone, so we adopted (and adapted) the OpenID Connect = method for flagging languages. This allows a client to register once for = all users and all language types. It wouldn't make sense (and it would = cause serious race conditions) for a client to try and switch languages = mid-stream for different users. >>>>>>>=20 >>>>>>> On the server side, if your auth server wants to handle = localized values appropriately, it will need to parse and manage = multiple tagged values for each human readable field. However, we're = recommending that clients always send the bare field with an = internationalized value (i.e., it's got the best chance of being read by = the largest audience for the client/auth server, a good default if you = will), so you can fairly safely just look for and use the bare fields in = most cases. >>>>>>>=20 >>>>>>> Hope this clears things up. If you have any recommendations for = how to make this intended usage clearer, I'd be happy to accept some new = suggested text. >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>> On Jun 19, 2013, at 1:05 PM, Phil Hunt >>>>>>> wrote: >>>>>>>=20 >>>>>>>> I am looking over the section on Human Readable Client Metadata = and am a bit confused as it pertains to the rest of the specification = and the implications for service providers. >>>>>>>>=20 >>>>>>>> Is it the intention that even single-valued client metadata may = have multiple localized values? Or, is the assumption that a client = would signal its preferred language and that ALL metadata values have = only ONE localization at a time? >>>>>>>>=20 >>>>>>>> I started considering this when I got to the section discussing = things like having client_name#ja-Jpan-JP and client_name#en. >>>>>>>>=20 >>>>>>>> Would be a lot simpler to have preferredLanguage be part of the = client schema and assume that all human readable fields have been = localized by the client. It seems to me to be more complex if every = client registers its entire set of language translations for each piece = of metadata if the user will only ever use one at a time. Why track all = variants? >>>>>>>>=20 >>>>>>>> My thought is that in the case of OAuth client interactions, = all language localization is to drive the interface for the personal use = of the user at hand. We don't have the case as we do in directories = where an english language person might be looking up information about a = Japanese person. >>>>>>>>=20 >>>>>>>> That said, it would become a normal for a client to trigger a = registration "update" event for the client to update its metadata when = the client detected a change in language by the user. E.g. from en to = ja-JPan-JP. >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >=20 From Michael.Jones@microsoft.com Thu Jun 20 13:23:30 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7697F21F9DEC for ; Thu, 20 Jun 2013 13:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbi+57797nmS for ; Thu, 20 Jun 2013 13:23:24 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBDE21F9E4F for ; Thu, 20 Jun 2013 13:23:15 -0700 (PDT) Received: from BN1AFFO11FD015.protection.gbl (10.58.52.200) by BN1AFFO11HUB022.protection.gbl (10.58.52.132) with Microsoft SMTP Server (TLS) id 15.0.707.0; Thu, 20 Jun 2013 20:17:43 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD015.mail.protection.outlook.com (10.58.52.75) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Thu, 20 Jun 2013 20:17:42 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.25]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0136.001; Thu, 20 Jun 2013 20:17:25 +0000 From: Mike Jones To: Phil Hunt , Justin Richer Thread-Topic: [OAUTH-WG] dyn reg - Human Readable Client Metadata Thread-Index: AQHObQ9aVI1hNS/NnkKRcaBJvD14XJk9SAqAgAACRoCAADpHAIAALMwAgADh+gCAAE4XAIAADwCAgAAbFgCAAACHkA== Date: Thu, 20 Jun 2013 20:17:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436787A555@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <39BD4318-6F8C-4FD2-8D4D-FA3DB3CC4CF6@mitre.org> <64506187-BE27-4A97-AD6B-6E6C68056389@ve7jtb.com> <489BA1EA-656A-450B-B45F-998CB17CA31B@oracle.com> <51C2FDF0.1040705@mitre.org> <51C34C07.9020300@mitre.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(24454002)(189002)(51704005)(479174003)(52604005)(377454003)(377424004)(164054003)(13464003)(74662001)(53806001)(15974865002)(79102001)(47446002)(23726002)(74706001)(81542001)(76482001)(77096001)(46102001)(77982001)(56776001)(55846006)(33656001)(80022001)(50466002)(54316002)(74366001)(51856001)(59766001)(54356001)(74502001)(31966008)(65816001)(81342001)(47976001)(50986001)(6806003)(16406001)(63696002)(69226001)(46406003)(47776003)(4396001)(20776003)(76786001)(74876001)(47736001)(76796001)(66066001)(56816003)(49866001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB022; H:TK5EX14MLTC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 08831F51DC Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 20:23:30 -0000 I'm skeptical of multi-phase registration. It seems more complicated than = the "problem" that it's trying to solve. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Thursday, June 20, 2013 1:15 PM To: Justin Richer Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata Let's think on this. I'm not convinced (yet) that creating an extension poi= nt is the right thing to do. For me, extensions are appropriate when there= is a need to support multiple ways of doing something -- like tokens for e= xample. =20 In this case, we're talking about adding a single, possibly optional, way o= f doing something. IOW. I think this is a "if you are going to do it, you m= ust do it this way" situation. Still, in general, we could try to work it in a backwards compatible way if= possible. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-06-20, at 11:37 AM, Justin Richer wrote: > For clients that simple want to use a single preferred language, we've go= t the bare field without the language tag (eg, "client_name"). I think we n= eed to keep that. So the remaining question is whether and how to handle mu= ltiple language tags. I think any format changes are going to have the same= scale issues -- it's inherent to the problem that if you want to pass arou= nd a lot of data, you're going to have a lot of data. With the use cases th= at have been brought up so far, it seems that the clients who would registe= r the most often (the "public" dynamic clients) would probably have enough = in-session information to pick a single client for a single user and be don= e with it. The clients who need to register many language for many users wo= uld be registering less often. So, the scaling problem seems to be self-lim= iting in that regard, right? The Javascript client you describe below proba= bly wouldn't try to register with 60 languages, it would just pick one for = the current user. I think it'll be fairly self-selecting with the general m= echanism that's in there now, so I don't think that the mechanism for langu= age in human-facing fields actually needs to change for this reason. >=20 > However: Splitting things in two, as you suggest, is a prime candidate fo= r an extension to dynamic registration. If we do it right we can solve it f= or more than just the language tags *without* breaking the underlying regis= tration spec, which is already useful on its own. Specifically, if you're d= oing a two-stage dynamic registration, your first stage is the new step def= ined by the extension and the second (instance) stage is the existing Dyn-R= eg spec with some extra processing on the part of the registration endpoint= . If we can define the right mechanisms around assertions, discovery, valid= ation, pre-registry and all that, you can actually do things pretty much ex= actly we both want to. The new pre-registration process handles any "fixed"= parameters (languages, redirects, and stuff, perhaps) and generates someth= ing that can be handed to all instances of the software. This is a thing th= at can be validated by the registration endpoint and used to tie the instan= ce presenting it into a larger ecosystem of a particular piece of software.= Every instance will still get its own client_id and client_secret (a good = thing), but the AS would know how to tie all these things together. >=20 > With that in mind, I think it's important that we have the appropriate ex= tension mechanisms in the dynamic registration spec to allow it, and so far= , everything is there that I can think of. You can use the initial access t= oken in the call to the registration endpoint (like we did with BB+), you c= an have an extension parameter to the client metadata (like you proposed wi= th software_id, particularly as an assertion), and it's up to the registrat= ion endpoint to validate any of these. What we need are definitions of what= actually goes *in* any of these components as well as the appropriate rule= s for validation and parsing in order for them to be useful and interoperab= le. >=20 > -- Justin >=20 > On 06/20/2013 01:44 PM, Phil Hunt wrote: >> The larger issue is that multi-lingual requirements do not go from 1 to = 2 or 3 languages, the requirements tend to go to 8 or 60 or more. This is w= hy I was hoping we could observe that clients simply want to select a singl= e preferred language. That said, web clients clearly need a multi-language= solution. >>=20 >> As we do this, imagine javascript clients doing dyn reg with 60 language= s. That's a LOT of data being moved around. Even under normal use, scale be= comes a concern. How fast is it parsed? When is it stored? Where is it sto= red? How is it retrieved and by what component(s)? >>=20 >> I can think of a couple of possibilities to manage this: >> * Differentiate between public (or rather personal) clients that tend to= use only one language vs. web clients that are fewer in number but support= many users with many languages >> * Break registration into 2 parts: software registration (has all the U= I and language stuff), and client instance registration (deals with only pe= r-instance protocol driven data). >>=20 >> While my gut reaction is simply towards the first (least breaking), the = latter strikes me as far more scalable (though with more complexity) -- esp= ecially if the group really wants to proceed with implicit client support t= hat tends to register on every execution. >>=20 >> Any other ideas? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-06-20, at 6:04 AM, Justin Richer wrote: >>=20 >>> One of the things I really like about the current approach is that it l= eaves the bare field name as a simple string attribute, like: >>>=20 >>> { >>> ... >>> "client_name": "My Client", >>> "client_name#en":"My Client", >>> "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u= 540D" >>> ... >>> } >>>=20 >>> So I can just grab client.client_name and get what I'm expecting most o= f the time, I don't need to pick a language tag if I don't care about or do= n't support them. This is why we're recommending that *all* clients send th= e "client_name" value alone, and if they want to, send "client_name#en" and= "client_name#ja-Jpan-JP" as well. >>>=20 >>> With the JSON structure, I'd have to get client.client_name as an array= and search through it to find the one tagged "primary: true". That's a lot= of work to just find a display string. >>>=20 >>> Webfinger currently uses a different JSON structure like this: >>>=20 >>> { >>> "en-us" : "The Magical World of Bob", >>> "fr" : "Le Monde Magique de Bob" >>> } >>>=20 >>> Though it was proposed a while back that they use the hash structure in= stead as well. This also has the problem that I have to call client.client_= name.en-us explicitly, or client.client_name.und if it's there. I think we = should make the use cases for single-language deployments (and internationl= ized deployments) simpler, and the hash structure does that at the expense = of some extra attribute parsing for the more complex use case. >>>=20 >>> -- Justin >>>=20 >>>=20 >>> On 06/19/2013 07:36 PM, Phil Hunt wrote: >>>> Ok. So then going down this path, is the chosen encoding method, whic= h is LDAPish, the right way to go? >>>>=20 >>>> For example, I read the spec as suggesting: >>>>=20 >>>> { >>>> ... >>>>=20 >>>> "client_name#en":"My Client", >>>> "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8= \u540D" >>>> ... >>>> } >>>>=20 >>>> Why not make it more JSON-esque such as: >>>>=20 >>>> { >>>> ... >>>>=20 >>>> "client_name":[ >>>> { >>>> "value":"My Client", >>>> "lang":"en", >>>> "primary":"TRUE" >>>> } >>>> { >>>> "value":"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", >>>> "lang":"ja-Jpan-JP" >>>> } >>>> ] >>>> ... >>>> } >>>>=20 >>>> I mention this format as it seems more JSON-like and it is more SCIM-f= riendly. Also wondering if anyone knows how vCards does localization? >>>>=20 >>>> I agree the draft format is more compact. But it requires more comple= x attribute name parsing, whereas the SCIMish expression requires more JSON= parsing. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-06-19, at 1:55 PM, John Bradley wrote: >>>>=20 >>>>> Yes that is an important Connect use case for Web server client regis= tration. Also thought of as a typical web SP. >>>>>=20 >>>>> John B. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-06-19, at 1:27 PM, Phil Hunt wrote: >>>>>=20 >>>>>> Justin >>>>>>=20 >>>>>> Thanks for refreshing my mind. I forgot the web client case is actin= g on behalf of many users. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> On 2013-06-19, at 10:18, "Richer, Justin P." wro= te: >>>>>>=20 >>>>>>> Your question seems to assume a one-to-one mapping between client a= nd user, and that's not guaranteed to be the case. Think of an installed we= b application that's talking to an auth server, and that web application is= going to talk to a number of different users. Those users can have multipl= e different language preferences. The human-readable fields are sent to the= auth server so that the auth server can display them to the end user durin= g the authorization screen and the application management screens. As such,= it makes sense (and was requested by the working group at the last IETF) t= hat a client can register its whole set of languages and the auth server pi= cks the appropriate one to display to the user. >>>>>>>=20 >>>>>>> It used to be the case that there was only a single value (unadorne= d with language tags) for things like client_name, and a client would've ha= d to register itself multiple times to get at different languages. The Work= ing Group decided that this was both too complicated and too error prone, s= o we adopted (and adapted) the OpenID Connect method for flagging languages= . This allows a client to register once for all users and all language type= s. It wouldn't make sense (and it would cause serious race conditions) for = a client to try and switch languages mid-stream for different users. >>>>>>>=20 >>>>>>> On the server side, if your auth server wants to handle localized v= alues appropriately, it will need to parse and manage multiple tagged value= s for each human readable field. However, we're recommending that clients a= lways send the bare field with an internationalized value (i.e., it's got t= he best chance of being read by the largest audience for the client/auth se= rver, a good default if you will), so you can fairly safely just look for a= nd use the bare fields in most cases. >>>>>>>=20 >>>>>>> Hope this clears things up. If you have any recommendations for how= to make this intended usage clearer, I'd be happy to accept some new sugge= sted text. >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> -- Justin >>>>>>>=20 >>>>>>> On Jun 19, 2013, at 1:05 PM, Phil Hunt >>>>>>> wrote: >>>>>>>=20 >>>>>>>> I am looking over the section on Human Readable Client Metadata an= d am a bit confused as it pertains to the rest of the specification and the= implications for service providers. >>>>>>>>=20 >>>>>>>> Is it the intention that even single-valued client metadata may ha= ve multiple localized values? Or, is the assumption that a client would s= ignal its preferred language and that ALL metadata values have only ONE loc= alization at a time? >>>>>>>>=20 >>>>>>>> I started considering this when I got to the section discussing th= ings like having client_name#ja-Jpan-JP and client_name#en. >>>>>>>>=20 >>>>>>>> Would be a lot simpler to have preferredLanguage be part of the cl= ient schema and assume that all human readable fields have been localized b= y the client. It seems to me to be more complex if every client registers = its entire set of language translations for each piece of metadata if the u= ser will only ever use one at a time. Why track all variants? >>>>>>>>=20 >>>>>>>> My thought is that in the case of OAuth client interactions, all l= anguage localization is to drive the interface for the personal use of the = user at hand. We don't have the case as we do in directories where an engl= ish language person might be looking up information about a Japanese person= . >>>>>>>>=20 >>>>>>>> That said, it would become a normal for a client to trigger a regi= stration "update" event for the client to update its metadata when the clie= nt detected a change in language by the user. E.g. from en to ja-JPan-JP. >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >=20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Thu Jun 20 13:37:20 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C96621F9AC9 for ; Thu, 20 Jun 2013 13:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkLMPfPA5O1v for ; Thu, 20 Jun 2013 13:37:15 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id CFCB621F9AAE for ; Thu, 20 Jun 2013 13:37:14 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 715A42260007; Thu, 20 Jun 2013 16:37:10 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 406551F0B37; Thu, 20 Jun 2013 16:37:10 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 20 Jun 2013 16:37:10 -0400 Message-ID: <51C367B4.5010702@mitre.org> Date: Thu, 20 Jun 2013 16:36:04 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mike Jones References: <39BD4318-6F8C-4FD2-8D4D-FA3DB3CC4CF6@mitre.org> <64506187-BE27-4A97-AD6B-6E6C68056389@ve7jtb.com> <489BA1EA-656A-450B-B45F-998CB17CA31B@oracle.com> <51C2FDF0.1040705@mitre.org> <51C34C07.9020300@mitre.org> <4E1F6AAD24975D4BA5B16804296739436787A555@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436787A555@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 20:37:20 -0000 Mike, The multi-phase registration isn't necessarily all automated (though it=20 could be) and this actually fits directly along side use cases B2 and B3 = in draft 12 of Dyn Reg. The difference is that the current use cases=20 assume auth-provider-specific behaviors and mechanisms by calling them=20 out of scope (which is still useful, just like with token formats being=20 opaque in OAuth) but this other work would be creating one concrete,=20 interoperable mechanism for doing this (which is also useful, like the=20 JWT token format). -- Justin On 06/20/2013 04:17 PM, Mike Jones wrote: > I'm skeptical of multi-phase registration. It seems more complicated t= han the "problem" that it's trying to solve. > > -- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Thursday, June 20, 2013 1:15 PM > To: Justin Richer > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] dyn reg - Human Readable Client Metadata > > Let's think on this. I'm not convinced (yet) that creating an extension= point is the right thing to do. For me, extensions are appropriate when= there is a need to support multiple ways of doing something -- like toke= ns for example. > > In this case, we're talking about adding a single, possibly optional, w= ay of doing something. IOW. I think this is a "if you are going to do it,= you must do it this way" situation. > > Still, in general, we could try to work it in a backwards compatible wa= y if possible. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-06-20, at 11:37 AM, Justin Richer wrote: > >> For clients that simple want to use a single preferred language, we've= got the bare field without the language tag (eg, "client_name"). I think= we need to keep that. So the remaining question is whether and how to ha= ndle multiple language tags. I think any format changes are going to have= the same scale issues -- it's inherent to the problem that if you want t= o pass around a lot of data, you're going to have a lot of data. With the= use cases that have been brought up so far, it seems that the clients wh= o would register the most often (the "public" dynamic clients) would prob= ably have enough in-session information to pick a single client for a sin= gle user and be done with it. The clients who need to register many langu= age for many users would be registering less often. So, the scaling probl= em seems to be self-limiting in that regard, right? The Javascript client= you describe below probably wouldn't try to register with 60 languages, = it would just pick one for the current user. I think it'll be fairly self= -selecting with the general mechanism that's in there now, so I don't thi= nk that the mechanism for language in human-facing fields actually needs = to change for this reason. >> >> However: Splitting things in two, as you suggest, is a prime candidate= for an extension to dynamic registration. If we do it right we can solve= it for more than just the language tags *without* breaking the underlyin= g registration spec, which is already useful on its own. Specifically, if= you're doing a two-stage dynamic registration, your first stage is the n= ew step defined by the extension and the second (instance) stage is the e= xisting Dyn-Reg spec with some extra processing on the part of the regist= ration endpoint. If we can define the right mechanisms around assertions,= discovery, validation, pre-registry and all that, you can actually do th= ings pretty much exactly we both want to. The new pre-registration proces= s handles any "fixed" parameters (languages, redirects, and stuff, perhap= s) and generates something that can be handed to all instances of the sof= tware. This is a thing that can be validated by the registration endpoint= and used to tie the instance presenting it into a larger ecosystem of a = particular piece of software. Every instance will still get its own clien= t_id and client_secret (a good thing), but the AS would know how to tie a= ll these things together. >> >> With that in mind, I think it's important that we have the appropriate= extension mechanisms in the dynamic registration spec to allow it, and s= o far, everything is there that I can think of. You can use the initial a= ccess token in the call to the registration endpoint (like we did with BB= +), you can have an extension parameter to the client metadata (like you = proposed with software_id, particularly as an assertion), and it's up to = the registration endpoint to validate any of these. What we need are defi= nitions of what actually goes *in* any of these components as well as the= appropriate rules for validation and parsing in order for them to be use= ful and interoperable. >> >> -- Justin >> >> On 06/20/2013 01:44 PM, Phil Hunt wrote: >>> The larger issue is that multi-lingual requirements do not go from 1 = to 2 or 3 languages, the requirements tend to go to 8 or 60 or more. This= is why I was hoping we could observe that clients simply want to select = a single preferred language. That said, web clients clearly need a multi= -language solution. >>> >>> As we do this, imagine javascript clients doing dyn reg with 60 langu= ages. That's a LOT of data being moved around. Even under normal use, sca= le becomes a concern. How fast is it parsed? When is it stored? Where is= it stored? How is it retrieved and by what component(s)? >>> >>> I can think of a couple of possibilities to manage this: >>> * Differentiate between public (or rather personal) clients that tend= to use only one language vs. web clients that are fewer in number but su= pport many users with many languages >>> * Break registration into 2 parts: software registration (has all th= e UI and language stuff), and client instance registration (deals with on= ly per-instance protocol driven data). >>> >>> While my gut reaction is simply towards the first (least breaking), t= he latter strikes me as far more scalable (though with more complexity) -= - especially if the group really wants to proceed with implicit client su= pport that tends to register on every execution. >>> >>> Any other ideas? >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2013-06-20, at 6:04 AM, Justin Richer wrote: >>> >>>> One of the things I really like about the current approach is that i= t leaves the bare field name as a simple string attribute, like: >>>> >>>> { >>>> ... >>>> "client_name": "My Client", >>>> "client_name#en":"My Client", >>>> "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30= C8\u540D" >>>> ... >>>> } >>>> >>>> So I can just grab client.client_name and get what I'm expecting mos= t of the time, I don't need to pick a language tag if I don't care about = or don't support them. This is why we're recommending that *all* clients = send the "client_name" value alone, and if they want to, send "client_nam= e#en" and "client_name#ja-Jpan-JP" as well. >>>> >>>> With the JSON structure, I'd have to get client.client_name as an ar= ray and search through it to find the one tagged "primary: true". That's = a lot of work to just find a display string. >>>> >>>> Webfinger currently uses a different JSON structure like this: >>>> >>>> { >>>> "en-us" : "The Magical World of Bob", >>>> "fr" : "Le Monde Magique de Bob" >>>> } >>>> >>>> Though it was proposed a while back that they use the hash structure= instead as well. This also has the problem that I have to call client.cl= ient_name.en-us explicitly, or client.client_name.und if it's there. I th= ink we should make the use cases for single-language deployments (and int= ernationlized deployments) simpler, and the hash structure does that at t= he expense of some extra attribute parsing for the more complex use case.= >>>> >>>> -- Justin >>>> >>>> >>>> On 06/19/2013 07:36 PM, Phil Hunt wrote: >>>>> Ok. So then going down this path, is the chosen encoding method, w= hich is LDAPish, the right way to go? >>>>> >>>>> For example, I read the spec as suggesting: >>>>> >>>>> { >>>>> ... >>>>> >>>>> "client_name#en":"My Client", >>>>> "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u= 30C8\u540D" >>>>> ... >>>>> } >>>>> >>>>> Why not make it more JSON-esque such as: >>>>> >>>>> { >>>>> ... >>>>> >>>>> "client_name":[ >>>>> { >>>>> "value":"My Client", >>>>> "lang":"en", >>>>> "primary":"TRUE" >>>>> } >>>>> { >>>>> "value":"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", >>>>> "lang":"ja-Jpan-JP" >>>>> } >>>>> ] >>>>> ... >>>>> } >>>>> >>>>> I mention this format as it seems more JSON-like and it is more SCI= M-friendly. Also wondering if anyone knows how vCards does localization?= >>>>> >>>>> I agree the draft format is more compact. But it requires more com= plex attribute name parsing, whereas the SCIMish expression requires more= JSON parsing. >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2013-06-19, at 1:55 PM, John Bradley wrote: >>>>> >>>>>> Yes that is an important Connect use case for Web server client re= gistration. Also thought of as a typical web SP. >>>>>> >>>>>> John B. >>>>>> >>>>>> >>>>>> >>>>>> On 2013-06-19, at 1:27 PM, Phil Hunt wrote:= >>>>>> >>>>>>> Justin >>>>>>> >>>>>>> Thanks for refreshing my mind. I forgot the web client case is ac= ting on behalf of many users. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> On 2013-06-19, at 10:18, "Richer, Justin P." = wrote: >>>>>>> >>>>>>>> Your question seems to assume a one-to-one mapping between clien= t and user, and that's not guaranteed to be the case. Think of an install= ed web application that's talking to an auth server, and that web applica= tion is going to talk to a number of different users. Those users can hav= e multiple different language preferences. The human-readable fields are = sent to the auth server so that the auth server can display them to the e= nd user during the authorization screen and the application management sc= reens. As such, it makes sense (and was requested by the working group at= the last IETF) that a client can register its whole set of languages and= the auth server picks the appropriate one to display to the user. >>>>>>>> >>>>>>>> It used to be the case that there was only a single value (unado= rned with language tags) for things like client_name, and a client would'= ve had to register itself multiple times to get at different languages. T= he Working Group decided that this was both too complicated and too error= prone, so we adopted (and adapted) the OpenID Connect method for flaggin= g languages. This allows a client to register once for all users and all = language types. It wouldn't make sense (and it would cause serious race c= onditions) for a client to try and switch languages mid-stream for differ= ent users. >>>>>>>> >>>>>>>> On the server side, if your auth server wants to handle localize= d values appropriately, it will need to parse and manage multiple tagged = values for each human readable field. However, we're recommending that cl= ients always send the bare field with an internationalized value (i.e., i= t's got the best chance of being read by the largest audience for the cli= ent/auth server, a good default if you will), so you can fairly safely ju= st look for and use the bare fields in most cases. >>>>>>>> >>>>>>>> Hope this clears things up. If you have any recommendations for = how to make this intended usage clearer, I'd be happy to accept some new = suggested text. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -- Justin >>>>>>>> >>>>>>>> On Jun 19, 2013, at 1:05 PM, Phil Hunt >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I am looking over the section on Human Readable Client Metadata= and am a bit confused as it pertains to the rest of the specification an= d the implications for service providers. >>>>>>>>> >>>>>>>>> Is it the intention that even single-valued client metadata may= have multiple localized values? Or, is the assumption that a client wo= uld signal its preferred language and that ALL metadata values have only = ONE localization at a time? >>>>>>>>> >>>>>>>>> I started considering this when I got to the section discussing= things like having client_name#ja-Jpan-JP and client_name#en. >>>>>>>>> >>>>>>>>> Would be a lot simpler to have preferredLanguage be part of the= client schema and assume that all human readable fields have been locali= zed by the client. It seems to me to be more complex if every client reg= isters its entire set of language translations for each piece of metadata= if the user will only ever use one at a time. Why track all variants? >>>>>>>>> >>>>>>>>> My thought is that in the case of OAuth client interactions, al= l language localization is to drive the interface for the personal use of= the user at hand. We don't have the case as we do in directories where = an english language person might be looking up information about a Japane= se person. >>>>>>>>> >>>>>>>>> That said, it would become a normal for a client to trigger a r= egistration "update" event for the client to update its metadata when the= client detected a change in language by the user. E.g. from en to ja-JP= an-JP. >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> @independentid >>>>>>>>> www.independentid.com >>>>>>>>> phil.hunt@oracle.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 From vladimir@nimbusds.com Fri Jun 21 23:54:39 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15AB21F9DAB for ; Fri, 21 Jun 2013 23:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4i7-XhOs6yDL for ; Fri, 21 Jun 2013 23:54:35 -0700 (PDT) Received: from n1plsmtp07-03.prod.ams1.secureserver.net (n1plsmtp07-03-02.prod.ams1.secureserver.net [188.121.52.7]) by ietfa.amsl.com (Postfix) with SMTP id 5B33021F9DA1 for ; Fri, 21 Jun 2013 23:54:34 -0700 (PDT) Received: (qmail 19602 invoked from network); 22 Jun 2013 06:54:32 -0000 Received: from unknown (HELO localhost) (188.121.52.244) by n1plsmtp07-03.prod.ams1.secureserver.net with SMTP; 22 Jun 2013 06:54:28 -0000 Received: (qmail 26723 invoked by uid 99); 22 Jun 2013 06:54:28 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 46.10.72.53 User-Agent: Workspace Webmail 5.6.39 Message-Id: <20130621235427.cc40c4f3d92d2001859047cd8cabb9ab.e06d39c8a0.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: oauth@ietf.org Date: Fri, 21 Jun 2013 23:54:27 -0700 Mime-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 06:54:39 -0000 Hi Justin,=0A=0AThanks for continuing work on this important draft. I start= ed=0Aimplementing the new version into the Nimbus SDK and noticed a few=0Ap= roblems in section 5.2 regarding the expected error response codes:=0A=0Aht= tp://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2=0A=0A1. Th= e first paragraph says that the error codes specified in section=0A5.2 of O= Auth 2.0 (RFC 6749) may be used in registration error responses,=0Ahowever,= I cannot see any particular error code that could apply to=0Aregistration,= perhaps only "invalid_request" (also, the link to the=0AOAuth 2.0 core spe= c seems to be incorrect).=0A=0A2. Requests to the client configuration endp= oint involve a protected=0Aresource and require a bearer access token. How = about including a=0Areference to the error codes from OAuth 2.0 Bearer Toke= n Usage (RFC=0A6750) for that?=0A=0A3. Finally, the statement that HTTP 400= is to be returned on a error=0Acondition contradicts with other parts of t= he spec that require other=0Astatus codes.=0A=0A=0A=0AThanks,=0A=0AVladimir= =0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com From vladimir@nimbusds.com Sat Jun 22 00:32:32 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C4621F9DA1 for ; Sat, 22 Jun 2013 00:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbkVsCkOyMof for ; Sat, 22 Jun 2013 00:32:27 -0700 (PDT) Received: from n1plsmtp07-04.prod.ams1.secureserver.net (n1plsmtp07-04-02.prod.ams1.secureserver.net [188.121.52.8]) by ietfa.amsl.com (Postfix) with SMTP id 38BEA21F9DA4 for ; Sat, 22 Jun 2013 00:32:27 -0700 (PDT) Received: (qmail 12095 invoked from network); 22 Jun 2013 07:32:23 -0000 Received: from unknown (HELO localhost) (188.121.52.243) by n1plsmtp07-04.prod.ams1.secureserver.net with SMTP; 22 Jun 2013 07:32:18 -0000 Received: (qmail 31102 invoked by uid 99); 22 Jun 2013 07:32:18 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 46.10.72.53 User-Agent: Workspace Webmail 5.6.39 Message-Id: <20130622003217.cc40c4f3d92d2001859047cd8cabb9ab.48b02a77bc.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: oauth@ietf.org Date: Sat, 22 Jun 2013 00:32:17 -0700 Mime-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 07:32:32 -0000 I have three more notes after going through the version 12 draft:=0A=0A=0Ah= ttp://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-3.1=0A=0AMiss= ing comma in the JSON example after "redirect_uris".=0A=0A=0Ahttp://tools.i= etf.org/html/draft-ietf-oauth-dyn-reg-12#section-4.4=0A=0AHeader "Accept: a= pplication/json" not required.=0A=0A=0Ahttp://tools.ietf.org/html/draft-iet= f-oauth-dyn-reg-12#section-5.2=0A=0AError code invalid_client_id obsolete?= =0A=0A=0AThanks,=0A=0AVladimir=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.= com : vladimir@nimbusds.com From jricher@mitre.org Mon Jun 24 06:45:58 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BD811E812F for ; Mon, 24 Jun 2013 06:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3cOwJpRtQww for ; Mon, 24 Jun 2013 06:45:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6A57D11E8125 for ; Mon, 24 Jun 2013 06:45:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CF8741F071A; Mon, 24 Jun 2013 09:45:52 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C31941F0704; Mon, 24 Jun 2013 09:45:52 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 24 Jun 2013 09:45:52 -0400 Message-ID: <51C84D4A.60906@mitre.org> Date: Mon, 24 Jun 2013 09:44:42 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Vladimir Dzhuvinov / NimbusDS References: <20130621235427.cc40c4f3d92d2001859047cd8cabb9ab.e06d39c8a0.wbe@email07.europe.secureserver.net> In-Reply-To: <20130621235427.cc40c4f3d92d2001859047cd8cabb9ab.e06d39c8a0.wbe@email07.europe.secureserver.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 13:45:58 -0000 The idea here is that if you're using an OAuth access token to access the registration endpoint or client configuration endpoint, and that token causes an error, then you ought to use the error codes associated with that method (ie, the ones defined by the token type). I think that this is pointing to the wrong list of errors -- it should probably be section 6.2 in RFC6750. My mistake, and I'll fix the reference once I make sure I've got it straight. To address #3, would it be better to have "unless otherwise specified" in that text? Thanks for your review. -- Justin On 06/22/2013 02:54 AM, Vladimir Dzhuvinov / NimbusDS wrote: > Hi Justin, > > Thanks for continuing work on this important draft. I started > implementing the new version into the Nimbus SDK and noticed a few > problems in section 5.2 regarding the expected error response codes: > > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2 > > 1. The first paragraph says that the error codes specified in section > 5.2 of OAuth 2.0 (RFC 6749) may be used in registration error responses, > however, I cannot see any particular error code that could apply to > registration, perhaps only "invalid_request" (also, the link to the > OAuth 2.0 core spec seems to be incorrect). > > 2. Requests to the client configuration endpoint involve a protected > resource and require a bearer access token. How about including a > reference to the error codes from OAuth 2.0 Bearer Token Usage (RFC > 6750) for that? > > 3. Finally, the statement that HTTP 400 is to be returned on a error > condition contradicts with other parts of the spec that require other > status codes. > > > > Thanks, > > Vladimir > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Mon Jun 24 06:49:12 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70B611E812F for ; Mon, 24 Jun 2013 06:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOubv+BQ2jEn for ; Mon, 24 Jun 2013 06:49:08 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4AA21F9B32 for ; Mon, 24 Jun 2013 06:49:08 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B613E1F071A; Mon, 24 Jun 2013 09:49:07 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6A7791F0739; Mon, 24 Jun 2013 09:49:07 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 24 Jun 2013 09:49:07 -0400 Message-ID: <51C84E0D.9050001@mitre.org> Date: Mon, 24 Jun 2013 09:47:57 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Vladimir Dzhuvinov / NimbusDS References: <20130622003217.cc40c4f3d92d2001859047cd8cabb9ab.48b02a77bc.wbe@email07.europe.secureserver.net> In-Reply-To: <20130622003217.cc40c4f3d92d2001859047cd8cabb9ab.48b02a77bc.wbe@email07.europe.secureserver.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 13:49:13 -0000 On 06/22/2013 03:32 AM, Vladimir Dzhuvinov / NimbusDS wrote: > I have three more notes after going through the version 12 draft: > > > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-3.1 > > Missing comma in the JSON example after "redirect_uris". You're right -- thought I fixed this one already, guess I missed it again. > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-4.4 > > Header "Accept: application/json" not required. Good point, copypaste mistake. > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2 > > Error code invalid_client_id obsolete? This is sent if the client_id in the posted object doesn't match the one referenced by the registration_client_uri and registration_access_token. I should add text to clarify that. Thanks for the careful review, -- Justin > > > Thanks, > > Vladimir > > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From vladimir@nimbusds.com Mon Jun 17 22:26:48 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6200C21F9DBC for ; Mon, 17 Jun 2013 22:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+A6MMK4z57O for ; Mon, 17 Jun 2013 22:26:43 -0700 (PDT) Received: from n1plsmtp07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id 24E1921F9CF2 for ; Mon, 17 Jun 2013 22:26:42 -0700 (PDT) Received: (qmail 4944 invoked from network); 18 Jun 2013 05:26:40 -0000 Received: from unknown (HELO localhost) (188.121.52.244) by n1plsmtp07-01.prod.ams1.secureserver.net with SMTP; 18 Jun 2013 05:26:36 -0000 Received: (qmail 7078 invoked by uid 99); 18 Jun 2013 05:26:36 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 46.10.72.53 User-Agent: Workspace Webmail 5.6.39 Message-Id: <20130617222635.cc40c4f3d92d2001859047cd8cabb9ab.96939b97b7.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: oauth@ietf.org Date: Mon, 17 Jun 2013 22:26:35 -0700 Mime-Version: 1.0 X-Mailman-Approved-At: Tue, 25 Jun 2013 07:15:10 -0700 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 05:26:48 -0000 Hi Justin,=0A=0AThanks for continuing work on this important draft. I start= ed=0Aimplementing the new version into the Nimbus SDK and noticed a few=0Ap= roblems in section 5.2 regarding the expected error response codes:=0A=0Aht= tp://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2=0A=0A1. Th= e first paragraph says that the error codes specified in section=0A5.2 of O= Auth 2.0 (RFC 6749) may be used in registration error responses,=0Ahowever,= I cannot see any particular error code that could apply to=0Aregistration,= perhaps only "invalid_request" (also, the link to the=0AOAuth 2.0 core spe= c seems to be incorrect).=0A=0A2. Requests to the client configuration endp= oint involve a protected=0Aresource and require a bearer access token. How = about including a=0Areference to the error codes from OAuth 2.0 Bearer Toke= n Usage (RFC=0A6750) for that?=0A=0A3. Finally, the statement that HTTP 400= is to be returned on a error=0Acondition contradicts with other parts of t= he spec that require other=0Astatus codes.=0A=0A=0A=0AThanks,=0A=0AVladimir= =0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com From hannes.tschofenig@gmx.net Tue Jun 25 14:05:10 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B318521E80D7 for ; Tue, 25 Jun 2013 14:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isnoiP6Hw9hA for ; Tue, 25 Jun 2013 14:05:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA6821E809F for ; Tue, 25 Jun 2013 14:05:05 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LjP2f-1UH9jl2uFT-00dXCe for ; Tue, 25 Jun 2013 23:05:02 +0200 Received: (qmail invoked by alias); 25 Jun 2013 21:05:02 -0000 Received: from host-94-101-1-228.igua.fi (EHLO [192.168.4.115]) [94.101.1.228] by mail.gmx.net (mp016) with SMTP; 25 Jun 2013 23:05:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19GPMgUdexGxGEoBfW+QzddlMszV0otGpW4RejuNk ecvBP1CglTqkag From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jun 2013 00:05:00 +0300 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Design Team for Progressing the Dynamic Registration Document X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 21:05:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all,=20 Derek, Stephen and I had a chat about the status of the dynamic = registration draft and it seems that we need a high-bandwidth = conversation to close the open issues that were raised after the working = group last call.=20 As such, the mission statement of the design team is to collect the open = issues (from the WGLC feedback) and to develop proposals for how to = resolve the open issues. For those who have not followed the work the = draft is here and the WGLC comments can be found at=20 This design team is open for everyone in the group and we will use the = mailing list for our discussions. We will hold a couple of conference = calls and everyone is welcome to join those. (Yes, we like openness and = transparency.) Please take a look at http://moreganize.com/b240sPl7SEp = to indicate what dates are suitable for you. I tried to make the time = fit everyone (which is a bit challenging).=20 We will distribute the minutes of the conference calls to this mailing = list (as we with previous design team calls as well).=20 Note: As always, the output of a design team is input to the working = group, not the final result.=20 Suggestions, comments, questions?=20 Ciao Hannes & Derek -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJRygX9AAoJEGhJURNOOiAt4ZMH/0U/RE/OL25JddDUGzX17moN usdB3ibMgO0kONT4P5zf4X/tz3gB/FZM2nRAsJLqZI2eWIgSUxWinNtir1ZKWywe BxLIz3PEaWV/CicbdLa+vjNVn4WSOAI21onferho0bdu+nBgTZWl+DiXZly195EJ h010/cldYrFidJ0tN6BF+0zhy/OxGFCqIo30nEN6EJVWLsS7yCULZ77q8Ud0ktm5 8ACCLS44QlEahbWsFPrfttisFL5fW9leQ2N4t1Z+Hn8Mlv7fFVW53hXa0pCT3Gp1 byae0rJZ+GHe+yrogfc4A2Ri792ghATxqIZBI0XFPjqPh8KlvvMHpiGcoa40+6M=3D =3Db3Zj -----END PGP SIGNATURE----- From icoloma@gmail.com Wed Jun 26 06:50:09 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BC821E8140 for ; Wed, 26 Jun 2013 06:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tojM0+ZWZmZ for ; Wed, 26 Jun 2013 06:50:08 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E1E7621E813F for ; Wed, 26 Jun 2013 06:50:07 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id qd12so30971151ieb.2 for ; Wed, 26 Jun 2013 06:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=p4EvBZzLgO9floH03N0+1Fezh0GjHbzjWskjXZnlofk=; b=vW8vsNBNGDeJRQvjXtRHLtyXxhUZQofsfG0zFALa17Vsi/c9VGHzp3guN9jBVxH4zS gY/bCJtM0CUyf+ZVrPLwKe27f/Igvc3VlCSYiVssIb9DcPiGKu2gvPRYpNtqAXkoqSYT NSa8q1gW+yk9UwqEmQ1fdua9RvVOHMRTVG3UdqagSTnTDDBn9CViJnLBZivGSSm0ogUo Hiz5p0KuRtScFSJnNwmtLz0il4k2u7TyxpwLHnyPwxUqPh9s7puNpu9T3PjvEEVeDpqS ExLAHFbU66exIZAKHhItmB2dej7QEVWFarLNKlQz84TbsUrZgGt/k1UI+NJ2rvxS5bE1 w4vQ== X-Received: by 10.50.55.42 with SMTP id o10mr2722092igp.28.1372254607467; Wed, 26 Jun 2013 06:50:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.96.132 with HTTP; Wed, 26 Jun 2013 06:49:47 -0700 (PDT) From: Nacho Coloma Date: Wed, 26 Jun 2013 15:49:47 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=047d7b1119816b756d04e00eec3c Subject: [OAUTH-WG] Four-legged OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:54:10 -0000 --047d7b1119816b756d04e00eec3c Content-Type: text/plain; charset=ISO-8859-1 Apologies if this has been asked before, but AFAIK what I could find do not follow the problem until a valid solution. Let's say I have a website BookFace, which is offering services and using OAuth2 to validate its users. For this example, it is important that BookFace does not keep track of any users credentials, but instead delegates into Google to provide with an authenticated user. Now, let's say BookFace gets popular enough so that other people want to integrate its services impersonating users. The obvious choice is that BookFace becomes an Authorization provider itself, keeping Google as a delegate provider. This means that we now have the following flow: * Website X wants to "do things" and forwards to BookFace to get an access token. * BookFace forwards to, say, Google * Google does its thing and returns a Google Authorization code * BookFace exchanges the Google Authorization code for a Google Access Token * BookFace returns a BookFace Authorization code * Website X exchanges the BookFace Authorization code for a BookFace access token. In the process, website X has never seen anything from Google. This works fine, but the user has to allow permissions twice: Google asks to approve BookFace, and BookFace asks to approve Website X. This is confusing even for me, that as a user have to keep track of who is asking permission to do what. If anyone wants to experience this use case it can be done here (give it some time to initialize on first access): http://oauth2-client-example.appspot.com This can be a necessary evil, but my question is if there is any initiative in the WG to make this process less painful. In my ideal world painted with crayons there are few authentication providers and a lot of service providers, and this is a problem to achieve adoption. Regards, Nacho. --047d7b1119816b756d04e00eec3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Apologies if this has been asked before, but AFAIK what I = could find do not follow the problem until a valid solution.

=
Let's say I have a website BookFace, which is offering services an= d using OAuth2 to validate its users. For this example, it is important tha= t=A0BookFace=A0does not keep track of any users credentials, but instead de= legates into Google to provide with an authenticated user.

Now, let's say BookFace gets popular enough so that= other people want to integrate its services impersonating users. The obvio= us choice is that=A0BookFace=A0becomes an Authorization provider itself, ke= eping Google as a delegate provider. This means that we now have the follow= ing flow:

* Website X wants to "do things" and forwards= to BookFace to get an access token.
*=A0BookFace=A0forwards to, = say, Google
* Google does its thing and returns a Google Authoriz= ation code

*=A0BookFace=A0exchanges the Google Authorization code for a Google Ac= cess Token
*=A0BookFace=A0returns a BookFace=A0Authorization code= =A0
* Website X exchanges the=A0BookFace=A0Authorization code for= a=A0BookFace=A0access token. In the process, website X has never seen anyt= hing from Google.

This works fine, but the user has to allow permissions = twice: Google asks to approve BookFace, and BookFace asks to approve Websit= e X. This is confusing even for me, that as a user have to keep track of wh= o is asking permission to do what. =A0

If anyone wants to experience this use case it can be d= one here (give it some time to initialize on first access):
http://oauth2-client-examp= le.appspot.com

This can be a necessary evil, but my question is = if there is any initiative in the WG to make this process less painful. In = my ideal world painted with crayons there are few authentication providers = and a lot of service providers, and this is a problem to achieve adoption.<= /div>

Regards,

Nacho.
--047d7b1119816b756d04e00eec3c-- From jricher@mitre.org Wed Jun 26 08:19:35 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFBF21E80E6 for ; Wed, 26 Jun 2013 08:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQHcIOaxcwmx for ; Wed, 26 Jun 2013 08:19:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 565BE21E80B5 for ; Wed, 26 Jun 2013 08:19:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CE09C1F03E3; Wed, 26 Jun 2013 11:19:29 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BA4091F02AD; Wed, 26 Jun 2013 11:19:29 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 26 Jun 2013 11:19:29 -0400 Message-ID: <51CB0639.1050002@mitre.org> Date: Wed, 26 Jun 2013 11:18:17 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nacho Coloma References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080300040005020903040607" X-Originating-IP: [129.83.31.56] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Four-legged OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:19:35 -0000 --------------080300040005020903040607 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I think this is the only viable approach if you want to allow for different auth servers in different security domains. Accepting access tokens from somebody else's domain takes a few more steps and rules that the WG hasn't totally figured out yet, though some of us are working on the pieces (token instrospection, rules for processing/validating JWTs, etc.). -- Justin On 06/26/2013 09:49 AM, Nacho Coloma wrote: > Apologies if this has been asked before, but AFAIK what I could find > do not follow the problem until a valid solution. > > Let's say I have a website BookFace, which is offering services and > using OAuth2 to validate its users. For this example, it is important > that BookFace does not keep track of any users credentials, but > instead delegates into Google to provide with an authenticated user. > > Now, let's say BookFace gets popular enough so that other people want > to integrate its services impersonating users. The obvious choice is > that BookFace becomes an Authorization provider itself, keeping Google > as a delegate provider. This means that we now have the following flow: > > * Website X wants to "do things" and forwards to BookFace to get an > access token. > * BookFace forwards to, say, Google > * Google does its thing and returns a Google Authorization code > * BookFace exchanges the Google Authorization code for a Google Access > Token > * BookFace returns a BookFace Authorization code > * Website X exchanges the BookFace Authorization code for > a BookFace access token. In the process, website X has never seen > anything from Google. > > This works fine, but the user has to allow permissions twice: Google > asks to approve BookFace, and BookFace asks to approve Website X. This > is confusing even for me, that as a user have to keep track of who is > asking permission to do what. > > If anyone wants to experience this use case it can be done here (give > it some time to initialize on first access): > http://oauth2-client-example.appspot.com > > > This can be a necessary evil, but my question is if there is any > initiative in the WG to make this process less painful. In my ideal > world painted with crayons there are few authentication providers and > a lot of service providers, and this is a problem to achieve adoption. > > Regards, > > Nacho. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080300040005020903040607 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I think this is the only viable approach if you want to allow for different auth servers in different security domains. Accepting access tokens from somebody else's domain takes a few more steps and rules that the WG hasn't totally figured out yet, though some of us are working on the pieces (token instrospection, rules for processing/validating JWTs, etc.).

-- Justin

On 06/26/2013 09:49 AM, Nacho Coloma wrote:

Apologies if this has been asked before, but AFAIK what I could find do not follow the problem until a valid solution.

Let's say I have a website BookFace, which is offering services and using OAuth2 to validate its users. For this example, it is important that BookFace does not keep track of any users credentials, but instead delegates into Google to provide with an authenticated user.

Now, let's say BookFace gets popular enough so that other people want to integrate its services impersonating users. The obvious choice is that BookFace becomes an Authorization provider itself, keeping Google as a delegate provider. This means that we now have the following flow:

* Website X wants to "do things" and forwards to BookFace to get an access token.

* BookFace forwards to, say, Google

* Google does its thing and returns a Google Authorization code

* BookFace exchanges the Google Authorization code for a Google Access Token

* BookFace returns a BookFace Authorization code

* Website X exchanges the BookFace Authorization code for a BookFace access token. In the process, website X has never seen anything from Google.

This works fine, but the user has to allow permissions twice: Google asks to approve BookFace, and BookFace asks to approve Website X. This is confusing even for me, that as a user have to keep track of who is asking permission to do what.

If anyone wants to experience this use case it can be done here (give it some time to initialize on first access):

http://oauth2-client-example.appspot.com

This can be a necessary evil, but my question is if there is any initiative in the WG to make this process less painful. In my ideal world painted with crayons there are few authentication providers and a lot of service providers, and this is a problem to achieve adoption.

Regards,

Nacho.

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

--------------080300040005020903040607-- From vladimir@nimbusds.com Wed Jun 26 08:40:57 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AB611E81CD for ; Wed, 26 Jun 2013 08:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7ysvSsIfJFb for ; Wed, 26 Jun 2013 08:40:52 -0700 (PDT) Received: from n1plout04-02.prod.ams1.secureserver.net (n1plout04-02.prod.ams1.secureserver.net [188.121.53.2]) by ietfa.amsl.com (Postfix) with SMTP id 53A3E11E811A for ; Wed, 26 Jun 2013 08:40:52 -0700 (PDT) Received: (qmail 30863 invoked from network); 26 Jun 2013 15:40:51 -0000 Received: from unknown (109.160.88.2) by n1plout04-02.prod.ams1.secureserver.net (188.121.53.2) with ESMTP; 26 Jun 2013 15:40:49 -0000 Message-ID: <1372261248.11180.41.camel@shakespeare> From: Vladimir Dzhuvinov / NimbusDS To: Justin Richer Date: Wed, 26 Jun 2013 18:40:48 +0300 In-Reply-To: <51C84D4A.60906@mitre.org> References: <20130621235427.cc40c4f3d92d2001859047cd8cabb9ab.e06d39c8a0.wbe@email07.europe.secureserver.net> <51C84D4A.60906@mitre.org> Organization: Nimbus Directory Services Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:40:57 -0000 On Mon, 2013-06-24 at 09:44 -0400, Justin Richer wrote: > The idea here is that if you're using an OAuth access token to access > the registration endpoint or client configuration endpoint, and that > token causes an error, then you ought to use the error codes associated > with that method (ie, the ones defined by the token type). I think that > this is pointing to the wrong list of errors -- it should probably be > section 6.2 in RFC6750. My mistake, and I'll fix the reference once I > make sure I've got it straight. > > To address #3, would it be better to have "unless otherwise specified" > in that text? How about the following: """ If the client presents an invalid Registration Access Token, the Authorization Server returns an Error Response that is appropriate for the token type ( http://tools.ietf.org/html/rfc6749#section-7.2 ) """ My reasoning is that if we consider the registration request, the only thing that is OAuth 2.0 (RFC 6749) specific about it is the optional presence of an access token to authorise the registration. Since the access token type is not specified, then we ought to say the possible errors depend on the token type (and Bearer is just one instance of a token type, so perhaps we shouldn't mention RFC 6750). Hope this helped, Vladimir > Thanks for your review. > > -- Justin > > On 06/22/2013 02:54 AM, Vladimir Dzhuvinov / NimbusDS wrote: > > Hi Justin, > > > > Thanks for continuing work on this important draft. I started > > implementing the new version into the Nimbus SDK and noticed a few > > problems in section 5.2 regarding the expected error response codes: > > > > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2 > > > > 1. The first paragraph says that the error codes specified in section > > 5.2 of OAuth 2.0 (RFC 6749) may be used in registration error responses, > > however, I cannot see any particular error code that could apply to > > registration, perhaps only "invalid_request" (also, the link to the > > OAuth 2.0 core spec seems to be incorrect). > > > > 2. Requests to the client configuration endpoint involve a protected > > resource and require a bearer access token. How about including a > > reference to the error codes from OAuth 2.0 Bearer Token Usage (RFC > > 6750) for that? > > > > 3. Finally, the statement that HTTP 400 is to be returned on a error > > condition contradicts with other parts of the spec that require other > > status codes. > > > > > > > > Thanks, > > > > Vladimir > > -- > > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > From vladimir@nimbusds.com Wed Jun 26 08:44:30 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6D121E8063 for ; Wed, 26 Jun 2013 08:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LBAW7Tso5ff for ; Wed, 26 Jun 2013 08:44:26 -0700 (PDT) Received: from n1plout04-01.prod.ams1.secureserver.net (n1plout04-01.prod.ams1.secureserver.net [188.121.53.1]) by ietfa.amsl.com (Postfix) with SMTP id E486521F944F for ; Wed, 26 Jun 2013 08:44:25 -0700 (PDT) Received: (qmail 6390 invoked from network); 26 Jun 2013 15:44:24 -0000 Received: from unknown (109.160.88.2) by n1plout04-01.prod.ams1.secureserver.net (188.121.53.1) with ESMTP; 26 Jun 2013 15:44:23 -0000 Message-ID: <1372261462.11180.46.camel@shakespeare> From: Vladimir Dzhuvinov / NimbusDS To: oauth@ietf.org Date: Wed, 26 Jun 2013 18:44:22 +0300 In-Reply-To: References: Organization: Nimbus Directory Services Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [OAUTH-WG] Four-legged OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:44:30 -0000 Hi Nacho, The only spec that gets somewhat close to your problem of chaining identity providers is OpenID Connect, see the section on aggregate and distributed claims: http://openid.net/specs/openid-connect-messages-1_0.html#AggregatedDistributedClaims Vladimir On Wed, 2013-06-26 at 15:49 +0200, Nacho Coloma wrote: > Apologies if this has been asked before, but AFAIK what I could find > do not follow the problem until a valid solution. > > > Let's say I have a website BookFace, which is offering services and > using OAuth2 to validate its users. For this example, it is important > that BookFace does not keep track of any users credentials, but > instead delegates into Google to provide with an authenticated user. > > > Now, let's say BookFace gets popular enough so that other people want > to integrate its services impersonating users. The obvious choice is > that BookFace becomes an Authorization provider itself, keeping Google > as a delegate provider. This means that we now have the following > flow: > > > * Website X wants to "do things" and forwards to BookFace to get an > access token. > * BookFace forwards to, say, Google > * Google does its thing and returns a Google Authorization code > * BookFace exchanges the Google Authorization code for a Google Access > Token > * BookFace returns a BookFace Authorization code > * Website X exchanges the BookFace Authorization code for > a BookFace access token. In the process, website X has never seen > anything from Google. > > > This works fine, but the user has to allow permissions twice: Google > asks to approve BookFace, and BookFace asks to approve Website X. This > is confusing even for me, that as a user have to keep track of who is > asking permission to do what. > > > If anyone wants to experience this use case it can be done here (give > it some time to initialize on first access): > http://oauth2-client-example.appspot.com > > > > This can be a necessary evil, but my question is if there is any > initiative in the WG to make this process less painful. In my ideal > world painted with crayons there are few authentication providers and > a lot of service providers, and this is a problem to achieve adoption. > > > Regards, > > > Nacho. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From icoloma@gmail.com Wed Jun 26 10:21:09 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5E521F94FA for ; Wed, 26 Jun 2013 10:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LEBhFvVJYE6 for ; Wed, 26 Jun 2013 10:21:07 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 96C3F21F9473 for ; Wed, 26 Jun 2013 10:21:05 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so31818339iec.36 for ; Wed, 26 Jun 2013 10:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type; bh=K3B+yKO5fKwakdXBp+GmOfEFA9ivNCGvFnfcJI37Qus=; b=SmF7gJp0jxHQE7yUPSKOCsiNPmiAnzAucAZMxwY9NDjTkaUqCDsKDU5xsFxBMeZT8p +tfe8ixb5aJk1iCzEqpeM73ngGLb9DHOtTiINOE9O/bI56wxirsmdP55xqNFkSMX2PhW hYXHC3xNaqs08y8RgKrKPW4VlCoEZtgfJpXv4GrEl3SFZz3JY7wWxQ3Isof02Po3Q6uh 83rZNvffj6lHvK+AlDCPtPQVX4OK/r91DCJaNrwQaxDFYYE8Si8BCwQmOFg0UKrtB2nQ bTCpA65Dv7SDBf1nA78KUr+16EVZDsfh5ku3kxZ+Fn7uKo5FNObj+RBbJqGTYrt4lhE3 5bfQ== X-Received: by 10.42.52.201 with SMTP id k9mr2759505icg.47.1372267263963; Wed, 26 Jun 2013 10:21:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.96.132 with HTTP; Wed, 26 Jun 2013 10:20:43 -0700 (PDT) In-Reply-To: <1372261462.11180.46.camel@shakespeare> References: <1372261462.11180.46.camel@shakespeare> From: Nacho Coloma Date: Wed, 26 Jun 2013 19:20:43 +0200 Message-ID: Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary=485b397dd6b7ce3a7c04e011de18 Subject: Re: [OAUTH-WG] Four-legged OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:21:09 -0000 --485b397dd6b7ce3a7c04e011de18 Content-Type: text/plain; charset=ISO-8859-1 I was expecting to find that someone had seen this problem before and was working towards a solution like forwarding your scopes to the delegate authorization server to get all permissions from the user at once (something similar to the aggregate claims in the OpenID spec, if I read it correctly). I feel like I am alone in a corner talking about imaginary problems, like if nobody was offering OAuth services and consuming them at the same time. On Wed, Jun 26, 2013 at 5:44 PM, Vladimir Dzhuvinov / NimbusDS < vladimir@nimbusds.com> wrote: > Hi Nacho, > > The only spec that gets somewhat close to your problem of chaining > identity providers is OpenID Connect, see the section on aggregate and > distributed claims: > > > http://openid.net/specs/openid-connect-messages-1_0.html#AggregatedDistributedClaims > > > Vladimir > > > On Wed, 2013-06-26 at 15:49 +0200, Nacho Coloma wrote: > > Apologies if this has been asked before, but AFAIK what I could find > > do not follow the problem until a valid solution. > > > > > > Let's say I have a website BookFace, which is offering services and > > using OAuth2 to validate its users. For this example, it is important > > that BookFace does not keep track of any users credentials, but > > instead delegates into Google to provide with an authenticated user. > > > > > > Now, let's say BookFace gets popular enough so that other people want > > to integrate its services impersonating users. The obvious choice is > > that BookFace becomes an Authorization provider itself, keeping Google > > as a delegate provider. This means that we now have the following > > flow: > > > > > > * Website X wants to "do things" and forwards to BookFace to get an > > access token. > > * BookFace forwards to, say, Google > > * Google does its thing and returns a Google Authorization code > > * BookFace exchanges the Google Authorization code for a Google Access > > Token > > * BookFace returns a BookFace Authorization code > > * Website X exchanges the BookFace Authorization code for > > a BookFace access token. In the process, website X has never seen > > anything from Google. > > > > > > This works fine, but the user has to allow permissions twice: Google > > asks to approve BookFace, and BookFace asks to approve Website X. This > > is confusing even for me, that as a user have to keep track of who is > > asking permission to do what. > > > > > > If anyone wants to experience this use case it can be done here (give > > it some time to initialize on first access): > > http://oauth2-client-example.appspot.com > > > > > > > > This can be a necessary evil, but my question is if there is any > > initiative in the WG to make this process less painful. In my ideal > > world painted with crayons there are few authentication providers and > > a lot of service providers, and this is a problem to achieve adoption. > > > > > > Regards, > > > > > > Nacho. > > _______________________________________________ > > 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 > --485b397dd6b7ce3a7c04e011de18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I was expecting to find that someone had seen this pr= oblem before and was working towards a solution like forwarding your scopes= to the delegate authorization server to get all permissions from the user = at once (something similar to the aggregate claims in the OpenID spec, if I= read it correctly). I feel like I am alone in a corner talking about imagi= nary problems, like if nobody was offering OAuth services and consuming the= m at the same time.

On Wed, Jun 26, 2013 at 5:44 PM, Vladimir Dzhuvinov / NimbusDS <vladimir@nimbusds.com> wrote:

Hi Nacho,

The only spec that gets somewhat close to your problem of chaining
identity providers is OpenID Connect, see the section on aggregate and
distributed claims:

http://openid.net/specs/openid-conn= ect-messages-1_0.html#AggregatedDistributedClaims

Vladimir

On Wed, 2013-06-26 at 15:49 +0200, Nacho Coloma wrote:
> Apologies if this has been asked before, but AFAIK what I could find > do not follow the problem until a valid solution.
>
>
> Let's say I have a website BookFace, which is offering services an= d
> using OAuth2 to validate its users. For this example, it is important<= br> > that BookFace does not keep track of any users credentials, but
> instead delegates into Google to provide with an authenticated user. >
>
> Now, let's say BookFace gets popular enough so that other people w= ant
> to integrate its services impersonating users. The obvious choice is > that BookFace becomes an Authorization provider itself, keeping Google=
> as a delegate provider. This means that we now have the following
> flow:
>
>
> * Website X wants to "do things" and forwards to BookFace to= get an
> access token.
> * BookFace forwards to, say, Google
> * Google does its thing and returns a Google Authorization code
> * BookFace exchanges the Google Authorization code for a Google Access=
> Token
> * BookFace returns a BookFace Authorization code
> * Website X exchanges the BookFace Authorization code for
> a BookFace access token. In the process, website X has never seen
> anything from Google.
>
>
> This works fine, but the user has to allow permissions twice: Google > asks to approve BookFace, and BookFace asks to approve Website X. This=
> is confusing even for me, that as a user have to keep track of who is<= br> > asking permission to do what.
>
>
> If anyone wants to experience this use case it can be done here (give<= br> > it some time to initialize on first access):
> http://oauth2-client-example.appspot.com
>
>
>
> This can be a necessary evil, but my question is if there is any
> initiative in the WG to make this process less painful. In my ideal > world painted with crayons there are few authentication providers and<= br> > a lot of service providers, and this is a problem to achieve adoption.=
>
>
> Regards,
>
>
> Nacho.

> __________________= _____________________________
> 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

--485b397dd6b7ce3a7c04e011de18-- From hannes.tschofenig@gmx.net Wed Jun 26 11:56:28 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18ED621F965B for ; Wed, 26 Jun 2013 11:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObK3de6uvrLn for ; Wed, 26 Jun 2013 11:56:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id AD32F21F9385 for ; Wed, 26 Jun 2013 11:56:17 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MH2cu-1V4W5O3C4Y-00Dspc for ; Wed, 26 Jun 2013 20:56:12 +0200 Received: (qmail invoked by alias); 26 Jun 2013 18:56:12 -0000 Received: from host-94-101-1-228.igua.fi (EHLO [192.168.4.115]) [94.101.1.228] by mail.gmx.net (mp002) with SMTP; 26 Jun 2013 20:56:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/jG0s8m3rjs32/6phwJrlm2H5JJB6iPpwg9IGN5c ty/kckE+5s81/F From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jun 2013 21:56:10 +0300 Message-Id: <451753D4-6231-49FE-AD41-441670173952@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Berlin IETF Meeting: Agenda Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 18:56:28 -0000 Hi all,=20 please drop us a message if you are planning to attend the upcoming IETF = meeting and if you would like to talk about a specific topic.=20 It would also be great if you could let us know if you plan to = participate from remote (especially if you are a document author).=20 Ciao Hannes & Derek=20 From torsten@lodderstedt.net Wed Jun 26 13:07:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2198921F9F9F for ; Wed, 26 Jun 2013 13:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mo11ZPb1Fj1x for ; Wed, 26 Jun 2013 13:07:49 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB4811E8133 for ; Wed, 26 Jun 2013 13:07:49 -0700 (PDT) Received: from [79.253.5.92] (helo=[192.168.71.77]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Urw0H-0001gF-9T; Wed, 26 Jun 2013 22:07:45 +0200 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <451753D4-6231-49FE-AD41-441670173952@gmx.net> From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) In-Reply-To: <451753D4-6231-49FE-AD41-441670173952@gmx.net> Message-Id: <499CF4DF-2749-4454-A635-01427998B06C@lodderstedt.net> Date: Wed, 26 Jun 2013 22:06:32 +0200 To: Hannes Tschofenig X-Mailer: iPad Mail (10B329) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Berlin IETF Meeting: Agenda Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 20:07:54 -0000 Hi, I plan to attend. regards, Torsten. Am 26.06.2013 um 20:56 schrieb Hannes Tschofenig = : > Hi all,=20 >=20 > please drop us a message if you are planning to attend the upcoming IETF m= eeting and if you would like to talk about a specific topic.=20 > It would also be great if you could let us know if you plan to participate= from remote (especially if you are a document author).=20 >=20 > Ciao > Hannes & Derek=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Wed Jun 26 13:48:03 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB3421F9958 for ; Wed, 26 Jun 2013 13:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giHnhiqtBM2r for ; Wed, 26 Jun 2013 13:47:58 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6793821F9956 for ; Wed, 26 Jun 2013 13:47:58 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 677481F0A34; Wed, 26 Jun 2013 16:47:57 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 437461F0458; Wed, 26 Jun 2013 16:47:57 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 26 Jun 2013 16:47:57 -0400 Message-ID: <51CB5334.6000100@mitre.org> Date: Wed, 26 Jun 2013 16:46:44 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Hannes Tschofenig References: <451753D4-6231-49FE-AD41-441670173952@gmx.net> In-Reply-To: <451753D4-6231-49FE-AD41-441670173952@gmx.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Berlin IETF Meeting: Agenda Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 20:48:03 -0000 I will not be there in person, but I can attend remotely depending on the timing of the meeting. -- Justin On 06/26/2013 02:56 PM, Hannes Tschofenig wrote: > Hi all, > > please drop us a message if you are planning to attend the upcoming IETF meeting and if you would like to talk about a specific topic. > It would also be great if you could let us know if you plan to participate from remote (especially if you are a document author). > > Ciao > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Wed Jun 26 13:55:15 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C621E21F8EB3 for ; Wed, 26 Jun 2013 13:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.949 X-Spam-Level: X-Spam-Status: No, score=-6.949 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzmgNG0iuc2T for ; Wed, 26 Jun 2013 13:55:10 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA6A21F99C6 for ; Wed, 26 Jun 2013 13:55:10 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5QKmmc4008333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Jun 2013 20:48:49 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5QKt6DO012904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jun 2013 20:55:06 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5QKt6ec012896; Wed, 26 Jun 2013 20:55:06 GMT Received: from [192.168.1.128] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Jun 2013 13:55:06 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <451753D4-6231-49FE-AD41-441670173952@gmx.net> Date: Wed, 26 Jun 2013 13:55:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <451753D4-6231-49FE-AD41-441670173952@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Berlin IETF Meeting: Agenda Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 20:55:15 -0000 I plan to attend. When is the first draft of the 87 meeting agenda = out? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-06-26, at 11:56 AM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > please drop us a message if you are planning to attend the upcoming = IETF meeting and if you would like to talk about a specific topic.=20 > It would also be great if you could let us know if you plan to = participate from remote (especially if you are a document author).=20 >=20 > Ciao > Hannes & Derek=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stephen.farrell@cs.tcd.ie Wed Jun 26 13:58:58 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A708E21F9A74 for ; Wed, 26 Jun 2013 13:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUzBC3mNqd68 for ; Wed, 26 Jun 2013 13:58:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC7C21F9A6B for ; Wed, 26 Jun 2013 13:58:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 47509BE9A; Wed, 26 Jun 2013 21:58:30 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ7qXjUMwhqH; Wed, 26 Jun 2013 21:58:29 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.16.114]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1C992BE6E; Wed, 26 Jun 2013 21:58:29 +0100 (IST) Message-ID: <51CB55F4.7010009@cs.tcd.ie> Date: Wed, 26 Jun 2013 21:58:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phil Hunt References: <451753D4-6231-49FE-AD41-441670173952@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Berlin IETF Meeting: Agenda Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 20:58:58 -0000 On 06/26/2013 09:55 PM, Phil Hunt wrote: > I plan to attend. When is the first draft of the 87 meeting agenda out? Tomorrow/Friday. But it *always* changes a bit after that when the WG chairs spot stuff the IESG missed. S. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2013-06-26, at 11:56 AM, Hannes Tschofenig wrote: > >> Hi all, >> >> please drop us a message if you are planning to attend the upcoming IETF meeting and if you would like to talk about a specific topic. >> It would also be great if you could let us know if you plan to participate from remote (especially if you are a document author). >> >> Ciao >> Hannes & Derek >> >> _______________________________________________ >> 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 > > From ve7jtb@ve7jtb.com Wed Jun 26 14:02:07 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F7F21F9ABD for ; Wed, 26 Jun 2013 14:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYbRxW5oiEpb for ; Wed, 26 Jun 2013 14:02:06 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 83BAC21F9ABB for ; Wed, 26 Jun 2013 14:02:06 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id b12so6711135yha.2 for ; Wed, 26 Jun 2013 14:02:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=fbW+PxYVGfTvR0TPmgvSmBX9AUM2lHOkAMsTOMDWH6E=; b=mx538WTpg/oFhRySQonvTSnUl5RSafhBDuDc/ni9cOLiQLCUR6CCK2ZgniVqJ0cvcD egqIqri+P4/LwtYvQhwItqIWqoRResmxbFMpGZz9es8YRJFL/j79GxvzljH0E0rKXZSd DJTjItdnhayaIaq0hQ1PM0KCkwMhzJr7gCINz5Q8cPJ6xBBqd6Hon6X+7V0JdExn0pY1 DmGh9MY748PZeRE9BEgfMqSTIxelIGeK1oTb07EbXqEcUPccJPn3jH5s7Fa8NUJOROx4 jOGikInaaFFXTEzl2hS0jmGCR1y1pjWGSmFsFti1KTtv0OTJSH070Tj2/+XuIX13PkAz coJg== X-Received: by 10.236.32.208 with SMTP id o56mr1265320yha.231.1372280524705; Wed, 26 Jun 2013 14:02:04 -0700 (PDT) Received: from [192.168.1.216] (190-20-19-12.baf.movistar.cl. [190.20.19.12]) by mx.google.com with ESMTPSA id 62sm47602928yhi.10.2013.06.26.14.02.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 14:02:03 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9700F04F-AC66-46D5-80DE-14368B7B16E2"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: John Bradley In-Reply-To: <451753D4-6231-49FE-AD41-441670173952@gmx.net> Date: Wed, 26 Jun 2013 17:01:24 -0400 Message-Id: <59C125C2-2F6F-4AD4-8A5E-43ED965D34CB@ve7jtb.com> References: <451753D4-6231-49FE-AD41-441670173952@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQlFxeiAtg7ifDsAE5BXyP7n5NldHZ7xlIw80D/FvHQ+A20UWgkdAcQ5HhJg+gCfdvKhDHEd Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Berlin IETF Meeting: Agenda Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:02:07 -0000 --Apple-Mail=_9700F04F-AC66-46D5-80DE-14368B7B16E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Attending On 2013-06-26, at 2:56 PM, Hannes Tschofenig = wrote: > Hi all,=20 >=20 > please drop us a message if you are planning to attend the upcoming = IETF meeting and if you would like to talk about a specific topic.=20 > It would also be great if you could let us know if you plan to = participate from remote (especially if you are a document author).=20 >=20 > Ciao > Hannes & Derek=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_9700F04F-AC66-46D5-80DE-14368B7B16E2 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 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjI2MjEwMTI1WjAjBgkqhkiG9w0BCQQxFgQUp40IeHmr 6ouRIc+rXZP6Sq0NkqcwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAJa6L28C4d1t+/q8A7guYb56h5AI2H35zQxmm8nRr 5fuU+EBJBXxuQ7KGjJudpyCS0zAhlbEBNPDfE1Mb9EoEVzbCudRztjZopIgdewRJ2iS7Rd7LKP2u fsoyrqMT6aB6MM7PIqUqJsOxqh2Ii1cEewmneL7McBgj45+kVbg7BBLWXvVRiU79LxkQ/e3Dz2hP MSGWY8VKyC9LKNu4GwT9uf11E6ofpghvkq6TJidzarm1eX6yumSzILzqQ4XNfY0koUQY9SUb3Ygg p+xBBBQBR6JlQKBnnVI4VQe3a6fz+GSdeiGL+CHqVM98esChU28gaFXYNoKbs/c0ag8IQ/t/AAAA AAAAAA== --Apple-Mail=_9700F04F-AC66-46D5-80DE-14368B7B16E2-- From bcampbell@pingidentity.com Wed Jun 26 14:15:22 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B2821F9B11 for ; Wed, 26 Jun 2013 14:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiBv9IbsdKUP for ; Wed, 26 Jun 2013 14:15:17 -0700 (PDT) Received: from na3sys009aog133.obsmtp.com (na3sys009aog133.obsmtp.com [74.125.149.82]) by ietfa.amsl.com (Postfix) with ESMTP id 246D221F9B5B for ; Wed, 26 Jun 2013 14:15:16 -0700 (PDT) Received: from mail-ea0-f169.google.com ([209.85.215.169]) (using TLSv1) by na3sys009aob133.postini.com ([74.125.148.12]) with SMTP ID DSNKUctZ5JY/m3yeWXkYuQL5+5AIqkAyqfea@postini.com; Wed, 26 Jun 2013 14:15:17 PDT Received: by mail-ea0-f169.google.com with SMTP id h15so7864053eak.0 for ; Wed, 26 Jun 2013 14:15:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=4IfBfryeDdb59XnOdd2798usVGC332a9W1aLwnMDchU=; b=lzDpm1cazhGAWKuaGbQASiIKe3NpkzBWtiqPhAsxJDNI4dBc4acvzCXgREyFgkMORL tGEMkfAGKLQ5R2e4uVYtJRQ3BqkPkBBTcuvInr3R2v0+aDdrv1syjwn2GBTtFyQxntgr xABCV+4wYxZy2pYud2bwkH1Eoz/PkbLhYs/YFs8q3FquvC0mQoJzsUzDiH0MhE1cleBe RniwnqwhedvzA+RgUcVrTd0x1TSS1SzpSi/rBJfSu63KnD1BRL73YgDZ7LSQAVyqN/QZ 3qv1KedZOGqTeEqIQI29wqP7I8Ol+t1Nt9jARFtSDdCkvQORT4TMMpPb1sKHFFhuja7k VhVw== X-Received: by 10.14.106.195 with SMTP id m43mr5908155eeg.60.1372281315493; Wed, 26 Jun 2013 14:15:15 -0700 (PDT) X-Received: by 10.14.106.195 with SMTP id m43mr5908149eeg.60.1372281315342; Wed, 26 Jun 2013 14:15:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.134.13 with HTTP; Wed, 26 Jun 2013 14:14:45 -0700 (PDT) In-Reply-To: <451753D4-6231-49FE-AD41-441670173952@gmx.net> References: <451753D4-6231-49FE-AD41-441670173952@gmx.net> From: Brian Campbell Date: Wed, 26 Jun 2013 15:14:45 -0600 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c1b8305569ee04e015241f X-Gm-Message-State: ALoCoQmvu2jCILF5DuVkweYFth8jjpwQ4U5BUKoW4mHut+fv8IlLLdZHtiqOe1B4FJj8w1b/5vfs6sbjn5OlsYSpkUKh2WDZ2xeuhF6bi9+xyJ9bglVY+DE9tfOTy2u+qHVKOgBGha9KYnplwIu3NjRzAYgJtHTiEQ== Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Berlin IETF Meeting: Agenda Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:15:22 -0000 --001a11c1b8305569ee04e015241f Content-Type: text/plain; charset=ISO-8859-1 I'll be attending. I'd like to request some time to talk about the state of the assertion drafts. http://tools.ietf.org/html/draft-ietf-oauth-assertions http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer Thanks, Brian On Wed, Jun 26, 2013 at 12:56 PM, Hannes Tschofenig < Hannes.Tschofenig@gmx.net> wrote: > Hi all, > > please drop us a message if you are planning to attend the upcoming IETF > meeting and if you would like to talk about a specific topic. > It would also be great if you could let us know if you plan to participate > from remote (especially if you are a document author). > > Ciao > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c1b8305569ee04e015241f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'll be attending.

I'd like= to request some time to talk about the state of the assertion drafts.
<= br>http://tools.ietf.org/html/draft-ietf-oauth-assertions
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearerhttp://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer

Thanks,
Brian
<= br>
On Wed, Jun 26, 2013 at 12:56 PM, Hannes = Tschofenig <Hannes.Tschofenig@gmx.net> wrote:

Hi all,

please drop us a message if you are planning to attend the upcoming IETF me= eting and if you would like to talk about a specific topic.
It would also be great if you could let us know if you plan to participate = from remote (especially if you are a document author).

Ciao
Hannes & Derek

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

--001a11c1b8305569ee04e015241f-- From Michael.Jones@microsoft.com Wed Jun 26 14:25:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A868121F9ABD for ; Wed, 26 Jun 2013 14:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pF3A6PQM6IKw for ; Wed, 26 Jun 2013 14:25:23 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 3A44621F9AC5 for ; Wed, 26 Jun 2013 14:25:23 -0700 (PDT) Received: from BL2FFO11FD023.protection.gbl (10.173.161.200) by BL2FFO11HUB003.protection.gbl (10.173.161.21) with Microsoft SMTP Server (TLS) id 15.0.717.3; Wed, 26 Jun 2013 21:25:09 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD023.mail.protection.outlook.com (10.173.161.102) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Wed, 26 Jun 2013 21:25:08 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.25]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0136.001; Wed, 26 Jun 2013 21:24:57 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] Berlin IETF Meeting: Agenda Items? Thread-Index: AQHOcp7z8bYdfMfshkaK8ZU+TCaUQplIgWEg Date: Wed, 26 Jun 2013 21:24:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436789BA5C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <451753D4-6231-49FE-AD41-441670173952@gmx.net> In-Reply-To: <451753D4-6231-49FE-AD41-441670173952@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464003)(377454003)(53754006)(199002)(189002)(4396001)(50986001)(80022001)(53806001)(59766001)(69226001)(74876001)(65816001)(76482001)(66066001)(46102001)(54316002)(47776003)(20776003)(63696002)(51856001)(56776001)(55846006)(23726002)(47736001)(49866001)(77982001)(47976001)(47446002)(56816003)(81342001)(81542001)(74366001)(54356001)(15202345003)(16406001)(44976004)(50466002)(46406003)(74662001)(33656001)(79102001)(6806003)(77096001)(76796001)(76786001)(31966008)(74502001)(74706001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB003; H:TK5EX14HUBC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 08897B549D Subject: Re: [OAUTH-WG] Berlin IETF Meeting: Agenda Items? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:25:53 -0000 I will be attending. I'd like separate time slots to talk about these draf= ts: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token - 15-20 minutes http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg - 30 minutes I'll prepare the presentations with my co-authors in advance. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Wednesday, June 26, 2013 11:56 AM To: oauth@ietf.org WG Subject: [OAUTH-WG] Berlin IETF Meeting: Agenda Items? Hi all,=20 please drop us a message if you are planning to attend the upcoming IETF me= eting and if you would like to talk about a specific topic.=20 It would also be great if you could let us know if you plan to participate = from remote (especially if you are a document author).=20 Ciao Hannes & Derek=20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From vladimir@nimbusds.com Wed Jun 26 20:32:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862F421F9930 for ; Wed, 26 Jun 2013 20:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py7J31ykpWAY for ; Wed, 26 Jun 2013 20:32:47 -0700 (PDT) Received: from n1plout04-02.prod.ams1.secureserver.net (n1plout04-02.prod.ams1.secureserver.net [188.121.53.2]) by ietfa.amsl.com (Postfix) with SMTP id 6CE8621F992A for ; Wed, 26 Jun 2013 20:32:47 -0700 (PDT) Received: (qmail 15709 invoked from network); 27 Jun 2013 03:32:40 -0000 Received: from unknown (79.100.136.182) by n1plout04-02.prod.ams1.secureserver.net (188.121.53.2) with ESMTP; 27 Jun 2013 03:32:39 -0000 Message-ID: <1372303958.11180.61.camel@shakespeare> From: Vladimir Dzhuvinov / NimbusDS To: Justin Richer Date: Thu, 27 Jun 2013 06:32:38 +0300 In-Reply-To: <51C84E0D.9050001@mitre.org> References: <20130622003217.cc40c4f3d92d2001859047cd8cabb9ab.48b02a77bc.wbe@email07.europe.secureserver.net> <51C84E0D.9050001@mitre.org> Organization: Nimbus Directory Services Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 03:32:52 -0000 Hi Justin, > > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2 > > > > Error code invalid_client_id obsolete? > > This is sent if the client_id in the posted object doesn't match the one > referenced by the registration_client_uri and registration_access_token. > I should add text to clarify that. How about removing the requirement to have client_id in the PUT body of client update requests? The ID can be derived from the registration URL and servers will certainly have to support that in order to process client delete requests. That way the invalid_client_id error code will no longer be needed, and we can simply return HTTP status 404, as a RESTful API would do. Vladimir From jricher@mitre.org Thu Jun 27 07:32:11 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E3721F9814 for ; Thu, 27 Jun 2013 07:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx+Px6l5lzz1 for ; Thu, 27 Jun 2013 07:32:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 928BC21F9930 for ; Thu, 27 Jun 2013 07:32:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 230ED1F0470; Thu, 27 Jun 2013 10:32:06 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 16F2D1F051E; Thu, 27 Jun 2013 10:32:06 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 27 Jun 2013 10:32:05 -0400 Message-ID: <51CC4C9C.8090404@mitre.org> Date: Thu, 27 Jun 2013 10:30:52 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Vladimir Dzhuvinov / NimbusDS References: <20130622003217.cc40c4f3d92d2001859047cd8cabb9ab.48b02a77bc.wbe@email07.europe.secureserver.net> <51C84E0D.9050001@mitre.org> <1372303958.11180.61.camel@shakespeare> In-Reply-To: <1372303958.11180.61.camel@shakespeare> Content-Type: multipart/alternative; boundary="------------060403070108040106010306" X-Originating-IP: [129.83.31.56] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:32:11 -0000 --------------060403070108040106010306 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Not all URLs will have the client_id in them (even though it's recommended and the common examples do) -- some systems will just re-use the Registration Endpoint's URL and switch behavior based on the presence of a valid registration_access_token and look up the client_id based on the token itself. My initial thought was that having the client leave out the client_id from the data model seems to be asking for trouble. However, we already preclude people from sending back some other fields: The Client MUST NOT include the "registration_access_token", "registration_client_uri", "client_secret_expires_at", or "client_id_issued_at" fields described in Client Information Response (Section 5.1 ). So an argument might be to have clients send *only* the fields described in Client Metadata (2) and not the extra fields in the Client Information Response (5.1). We need to decide whether these fields MUST NOT be sent, or if they MAY be sent and if sent they MUST match. The former would get rid of the paragraph saying that the client_id and client_secret have to be checked, and get rid of the invalid_client_id parameter. Do we want this change, or do we want to leave it as it is? -- Justin On 06/26/2013 11:32 PM, Vladimir Dzhuvinov / NimbusDS wrote: > Hi Justin, > > >>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2 >>> >>> Error code invalid_client_id obsolete? >> This is sent if the client_id in the posted object doesn't match the one >> referenced by the registration_client_uri and registration_access_token. >> I should add text to clarify that. > How about removing the requirement to have client_id in the PUT body of > client update requests? The ID can be derived from the registration URL > and servers will certainly have to support that in order to process > client delete requests. That way the invalid_client_id error code will > no longer be needed, and we can simply return HTTP status 404, as a > RESTful API would do. > > Vladimir > --------------060403070108040106010306 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Not all URLs will have the client_id in them (even though it's recommended and the common examples do) -- some systems will just re-use the Registration Endpoint's URL and switch behavior based on the presence of a valid registration_access_token and look up the client_id based on the token itself.

My initial thought was that having the client leave out the client_id from the data model seems to be asking for trouble. However, we already preclude people from sending back some other fields:

The Client MUST NOT include the "registration_access_token", "registration_client_uri", "client_secret_expires_at", or "client_id_issued_at" fields described in Client Information Response (Section 5.1).

So an argument might be to have clients send *only* the fields described in Client Metadata (2) and not the extra fields in the Client Information Response (5.1). We need to decide whether these fields MUST NOT be sent, or if they MAY be sent and if sent they MUST match. The former would get rid of the paragraph saying that the client_id and client_secret have to be checked, and get rid of the invalid_client_id parameter.

Do we want this change, or do we want to leave it as it is?

��-- Justin

On 06/26/2013 11:32 PM, Vladimir Dzhuvinov / NimbusDS wrote:

Hi Justin,

http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2 Error code invalid_client_id obsolete?

This is sent if the client_id in the posted object doesn't match the one referenced by the registration_client_uri and registration_access_token. I should add text to clarify that.

How about removing the requirement to have client_id in the PUT body of client update requests? The ID can be derived from the registration URL and servers will certainly have to support that in order to process client delete requests. That way the invalid_client_id error code will no longer be needed, and we can simply return HTTP status 404, as a RESTful API would do. Vladimir

--------------060403070108040106010306-- From Michael.Jones@microsoft.com Thu Jun 27 07:59:03 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C97921F9D95 for ; Thu, 27 Jun 2013 07:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0gvc6TNt09z for ; Thu, 27 Jun 2013 07:58:56 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 284D021F9DC4 for ; Thu, 27 Jun 2013 07:58:28 -0700 (PDT) Received: from BN1BFFO11FD007.protection.gbl (10.58.52.202) by BN1BFFO11HUB016.protection.gbl (10.58.53.126) with Microsoft SMTP Server (TLS) id 15.0.707.0; Thu, 27 Jun 2013 14:58:22 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD007.mail.protection.outlook.com (10.58.53.67) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Thu, 27 Jun 2013 14:58:22 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.25]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0136.001; Thu, 27 Jun 2013 14:58:05 +0000 From: Mike Jones To: Justin Richer , Vladimir Dzhuvinov / NimbusDS Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt Thread-Index: AQHObxqf2ZoCtoGOxESipKjPm2/u75lE5KiAgAQLFACAALfoAIAABxDw Date: Thu, 27 Jun 2013 14:58:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436789DD40@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130622003217.cc40c4f3d92d2001859047cd8cabb9ab.48b02a77bc.wbe@email07.europe.secureserver.net> <51C84E0D.9050001@mitre.org> <1372303958.11180.61.camel@shakespeare> <51CC4C9C.8090404@mitre.org> In-Reply-To: <51CC4C9C.8090404@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436789DD40TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(24454002)(377454003)(479174003)(76796001)(77982001)(16406001)(31966008)(15202345003)(71186001)(74366001)(59766001)(33656001)(65816001)(79102001)(55846006)(46102001)(51856001)(54356001)(54316002)(6806003)(19300405004)(81542001)(77096001)(47446002)(512874002)(56776001)(53806001)(81342001)(74662001)(56816003)(76786001)(47736001)(16236675002)(74706001)(66066001)(63696002)(76482001)(20776003)(80022001)(49866001)(4396001)(69226001)(74502001)(74876001)(47976001)(50986001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB016; H:TK5EX14MLTC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 08902E536D Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:59:03 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436789DD40TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoYXQgd2Ugc2hvdWxkIGxlYXZlIGl0IGFzLWlzLiAgRm9yIG1hbnkgaW1wbGVt ZW50YXRpb25zLCBpdOKAmXMgaW1wb3J0YW50IHRvIGNvbW11bmljYXRlIHRoZSBjbGllbnRfaWQg dmFsdWUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gUmljaGVyDQpT ZW50OiBUaHVyc2RheSwgSnVuZSAyNywgMjAxMyA3OjMxIEFNDQpUbzogVmxhZGltaXIgRHpodXZp bm92IC8gTmltYnVzRFMNCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1X R10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVnLTEyLnR4dA0KDQpOb3QgYWxs IFVSTHMgd2lsbCBoYXZlIHRoZSBjbGllbnRfaWQgaW4gdGhlbSAoZXZlbiB0aG91Z2ggaXQncyBy ZWNvbW1lbmRlZCBhbmQgdGhlIGNvbW1vbiBleGFtcGxlcyBkbykgLS0gc29tZSBzeXN0ZW1zIHdp bGwganVzdCByZS11c2UgdGhlIFJlZ2lzdHJhdGlvbiBFbmRwb2ludCdzIFVSTCBhbmQgc3dpdGNo IGJlaGF2aW9yIGJhc2VkIG9uIHRoZSBwcmVzZW5jZSBvZiBhIHZhbGlkIHJlZ2lzdHJhdGlvbl9h Y2Nlc3NfdG9rZW4gYW5kIGxvb2sgdXAgdGhlIGNsaWVudF9pZCBiYXNlZCBvbiB0aGUgdG9rZW4g aXRzZWxmLg0KDQpNeSBpbml0aWFsIHRob3VnaHQgd2FzIHRoYXQgaGF2aW5nIHRoZSBjbGllbnQg bGVhdmUgb3V0IHRoZSBjbGllbnRfaWQgZnJvbSB0aGUgZGF0YSBtb2RlbCBzZWVtcyB0byBiZSBh c2tpbmcgZm9yIHRyb3VibGUuIEhvd2V2ZXIsIHdlIGFscmVhZHkgcHJlY2x1ZGUgcGVvcGxlIGZy b20gc2VuZGluZyBiYWNrIHNvbWUgb3RoZXIgZmllbGRzOg0KDQpUaGUgQ2xpZW50IE1VU1QgTk9U IGluY2x1ZGUgdGhlDQoNCiAgICJyZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuIiwgInJlZ2lzdHJh dGlvbl9jbGllbnRfdXJpIiwNCg0KICAgImNsaWVudF9zZWNyZXRfZXhwaXJlc19hdCIsIG9yICJj bGllbnRfaWRfaXNzdWVkX2F0IiBmaWVsZHMgZGVzY3JpYmVkDQoNCiAgIGluIENsaWVudCBJbmZv cm1hdGlvbiBSZXNwb25zZSAoU2VjdGlvbiA1LjE8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1vYXV0aC1keW4tcmVnLTEyI3NlY3Rpb24tNS4xPikuDQoNClNvIGFuIGFyZ3Vt ZW50IG1pZ2h0IGJlIHRvIGhhdmUgY2xpZW50cyBzZW5kICpvbmx5KiB0aGUgZmllbGRzIGRlc2Ny aWJlZCBpbiBDbGllbnQgTWV0YWRhdGEgKDIpIGFuZCBub3QgdGhlIGV4dHJhIGZpZWxkcyBpbiB0 aGUgQ2xpZW50IEluZm9ybWF0aW9uIFJlc3BvbnNlICg1LjEpLiBXZSBuZWVkIHRvIGRlY2lkZSB3 aGV0aGVyIHRoZXNlIGZpZWxkcyBNVVNUIE5PVCBiZSBzZW50LCBvciBpZiB0aGV5IE1BWSBiZSBz ZW50IGFuZCBpZiBzZW50IHRoZXkgTVVTVCBtYXRjaC4gVGhlIGZvcm1lciB3b3VsZCBnZXQgcmlk IG9mIHRoZSBwYXJhZ3JhcGggc2F5aW5nIHRoYXQgdGhlIGNsaWVudF9pZCBhbmQgY2xpZW50X3Nl Y3JldCBoYXZlIHRvIGJlIGNoZWNrZWQsIGFuZCBnZXQgcmlkIG9mIHRoZSBpbnZhbGlkX2NsaWVu dF9pZCBwYXJhbWV0ZXIuDQoNCkRvIHdlIHdhbnQgdGhpcyBjaGFuZ2UsIG9yIGRvIHdlIHdhbnQg dG8gbGVhdmUgaXQgYXMgaXQgaXM/DQoNCiAtLSBKdXN0aW4NCk9uIDA2LzI2LzIwMTMgMTE6MzIg UE0sIFZsYWRpbWlyIER6aHV2aW5vdiAvIE5pbWJ1c0RTIHdyb3RlOg0KDQpIaSBKdXN0aW4sDQoN Cg0KDQoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1keW4t cmVnLTEyI3NlY3Rpb24tNS4yDQoNCg0KDQpFcnJvciBjb2RlIGludmFsaWRfY2xpZW50X2lkIG9i c29sZXRlPw0KDQoNCg0KVGhpcyBpcyBzZW50IGlmIHRoZSBjbGllbnRfaWQgaW4gdGhlIHBvc3Rl ZCBvYmplY3QgZG9lc24ndCBtYXRjaCB0aGUgb25lDQoNCnJlZmVyZW5jZWQgYnkgdGhlIHJlZ2lz dHJhdGlvbl9jbGllbnRfdXJpIGFuZCByZWdpc3RyYXRpb25fYWNjZXNzX3Rva2VuLg0KDQpJIHNo b3VsZCBhZGQgdGV4dCB0byBjbGFyaWZ5IHRoYXQuDQoNCg0KDQpIb3cgYWJvdXQgcmVtb3Zpbmcg dGhlIHJlcXVpcmVtZW50IHRvIGhhdmUgY2xpZW50X2lkIGluIHRoZSBQVVQgYm9keSBvZg0KDQpj bGllbnQgdXBkYXRlIHJlcXVlc3RzPyBUaGUgSUQgY2FuIGJlIGRlcml2ZWQgZnJvbSB0aGUgcmVn aXN0cmF0aW9uIFVSTA0KDQphbmQgc2VydmVycyB3aWxsIGNlcnRhaW5seSBoYXZlIHRvIHN1cHBv cnQgdGhhdCBpbiBvcmRlciB0byBwcm9jZXNzDQoNCmNsaWVudCBkZWxldGUgcmVxdWVzdHMuIFRo YXQgd2F5IHRoZSBpbnZhbGlkX2NsaWVudF9pZCBlcnJvciBjb2RlIHdpbGwNCg0Kbm8gbG9uZ2Vy IGJlIG5lZWRlZCwgYW5kIHdlIGNhbiBzaW1wbHkgcmV0dXJuIEhUVFAgc3RhdHVzIDQwNCwgYXMg YQ0KDQpSRVNUZnVsIEFQSSB3b3VsZCBkby4NCg0KDQoNClZsYWRpbWlyDQoNCg0KDQo= --_000_4E1F6AAD24975D4BA5B16804296739436789DD40TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYmVsaWV2ZSB0aGF0IHdlIHNob3VsZCBsZWF2ZSBpdCBh cy1pcy4mbmJzcDsgRm9yIG1hbnkgaW1wbGVtZW50YXRpb25zLCBpdOKAmXMgaW1wb3J0YW50IHRv IGNvbW11bmljYXRlIHRoZSBjbGllbnRfaWQgdmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3Rl eHQiPiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFJpY2hlcjxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgSnVuZSAyNywgMjAxMyA3OjMxIEFNPGJyPg0KPGI+VG86PC9iPiBWbGFkaW1pciBE emh1dmlub3YgLyBOaW1idXNEUzxicj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vYXV0 aC1keW4tcmVnLTEyLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk5vdCBhbGwgVVJMcyB3aWxsIGhhdmUgdGhlIGNsaWVudF9pZCBpbiB0aGVtIChldmVu IHRob3VnaCBpdCdzIHJlY29tbWVuZGVkIGFuZCB0aGUgY29tbW9uIGV4YW1wbGVzIGRvKSAtLSBz b21lIHN5c3RlbXMgd2lsbCBqdXN0IHJlLXVzZSB0aGUgUmVnaXN0cmF0aW9uIEVuZHBvaW50J3Mg VVJMIGFuZCBzd2l0Y2ggYmVoYXZpb3IgYmFzZWQgb24gdGhlIHByZXNlbmNlIG9mIGEgdmFsaWQg cmVnaXN0cmF0aW9uX2FjY2Vzc190b2tlbg0KIGFuZCBsb29rIHVwIHRoZSBjbGllbnRfaWQgYmFz ZWQgb24gdGhlIHRva2VuIGl0c2VsZi48YnI+DQo8YnI+DQpNeSBpbml0aWFsIHRob3VnaHQgd2Fz IHRoYXQgaGF2aW5nIHRoZSBjbGllbnQgbGVhdmUgb3V0IHRoZSBjbGllbnRfaWQgZnJvbSB0aGUg ZGF0YSBtb2RlbCBzZWVtcyB0byBiZSBhc2tpbmcgZm9yIHRyb3VibGUuIEhvd2V2ZXIsIHdlIGFs cmVhZHkgcHJlY2x1ZGUgcGVvcGxlIGZyb20gc2VuZGluZyBiYWNrIHNvbWUgb3RoZXIgZmllbGRz OjxvOnA+PC9vOnA+PC9wPg0KPHByZT5UaGUgQ2xpZW50IE1VU1QgTk9UIGluY2x1ZGUgdGhlPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7ICZxdW90O3JlZ2lzdHJhdGlvbl9hY2Nl c3NfdG9rZW4mcXVvdDssICZxdW90O3JlZ2lzdHJhdGlvbl9jbGllbnRfdXJpJnF1b3Q7LDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAmcXVvdDtjbGllbnRfc2VjcmV0X2V4cGly ZXNfYXQmcXVvdDssIG9yICZxdW90O2NsaWVudF9pZF9pc3N1ZWRfYXQmcXVvdDsgZmllbGRzIGRl c2NyaWJlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpbiBDbGllbnQgSW5m b3JtYXRpb24gUmVzcG9uc2UgKDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtb2F1dGgtZHluLXJlZy0xMiNzZWN0aW9uLTUuMSI+U2VjdGlvbiA1LjE8L2E+KS48 bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpTbyBhbiBhcmd1bWVudCBtaWdodCBiZSB0byBoYXZlIGNsaWVudHMg c2VuZCAqb25seSogdGhlIGZpZWxkcyBkZXNjcmliZWQgaW4gQ2xpZW50IE1ldGFkYXRhICgyKSBh bmQgbm90IHRoZSBleHRyYSBmaWVsZHMgaW4gdGhlIENsaWVudCBJbmZvcm1hdGlvbiBSZXNwb25z ZSAoNS4xKS4gV2UgbmVlZCB0byBkZWNpZGUgd2hldGhlciB0aGVzZSBmaWVsZHMgTVVTVCBOT1Qg YmUgc2VudCwgb3IgaWYgdGhleSBNQVkgYmUgc2VudCBhbmQgaWYgc2VudCB0aGV5DQogTVVTVCBt YXRjaC4gVGhlIGZvcm1lciB3b3VsZCBnZXQgcmlkIG9mIHRoZSBwYXJhZ3JhcGggc2F5aW5nIHRo YXQgdGhlIGNsaWVudF9pZCBhbmQgY2xpZW50X3NlY3JldCBoYXZlIHRvIGJlIGNoZWNrZWQsIGFu ZCBnZXQgcmlkIG9mIHRoZSBpbnZhbGlkX2NsaWVudF9pZCBwYXJhbWV0ZXIuDQo8YnI+DQo8YnI+ DQpEbyB3ZSB3YW50IHRoaXMgY2hhbmdlLCBvciBkbyB3ZSB3YW50IHRvIGxlYXZlIGl0IGFzIGl0 IGlzPzxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA2LzI2LzIwMTMgMTE6MzIgUE0sIFZsYWRpbWlyIER6aHV2 aW5vdiAvIE5pbWJ1c0RTIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SGkg SnVzdGluLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWR5bi1yZWctMTIjc2VjdGlvbi01LjIi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZHluLXJlZy0xMiNz ZWN0aW9uLTUuMjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT5FcnJvciBjb2RlIGludmFsaWRfY2xpZW50X2lkIG9ic29sZXRlPzxvOnA+PC9v OnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPlRoaXMgaXMgc2VudCBpZiB0aGUgY2xpZW50X2lkIGluIHRoZSBwb3N0ZWQgb2JqZWN0IGRv ZXNuJ3QgbWF0Y2ggdGhlIG9uZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZWZlcmVuY2VkIGJ5 IHRoZSByZWdpc3RyYXRpb25fY2xpZW50X3VyaSBhbmQgcmVnaXN0cmF0aW9uX2FjY2Vzc190b2tl bi4gPG86cD48L286cD48L3ByZT4NCjxwcmU+SSBzaG91bGQgYWRkIHRleHQgdG8gY2xhcmlmeSB0 aGF0LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPkhvdyBhYm91dCByZW1vdmluZyB0aGUgcmVxdWlyZW1lbnQgdG8gaGF2 ZSBjbGllbnRfaWQgaW4gdGhlIFBVVCBib2R5IG9mPG86cD48L286cD48L3ByZT4NCjxwcmU+Y2xp ZW50IHVwZGF0ZSByZXF1ZXN0cz8gVGhlIElEIGNhbiBiZSBkZXJpdmVkIGZyb20gdGhlIHJlZ2lz dHJhdGlvbiBVUkw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbmQgc2VydmVycyB3aWxsIGNlcnRh aW5seSBoYXZlIHRvIHN1cHBvcnQgdGhhdCBpbiBvcmRlciB0byBwcm9jZXNzPG86cD48L286cD48 L3ByZT4NCjxwcmU+Y2xpZW50IGRlbGV0ZSByZXF1ZXN0cy4gVGhhdCB3YXkgdGhlIGludmFsaWRf Y2xpZW50X2lkIGVycm9yIGNvZGUgd2lsbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm5vIGxvbmdl ciBiZSBuZWVkZWQsIGFuZCB3ZSBjYW4gc2ltcGx5IHJldHVybiBIVFRQIHN0YXR1cyA0MDQsIGFz IGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SRVNUZnVsIEFQSSB3b3VsZCBkby48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5WbGFkaW1pcjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739436789DD40TK5EX14MBXC283r_-- From hannes.tschofenig@gmx.net Thu Jun 27 11:56:36 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDA221F9EDF for ; Thu, 27 Jun 2013 11:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9piDLfSCvu+K for ; Thu, 27 Jun 2013 11:56:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id F2B1A21F9ED2 for ; Thu, 27 Jun 2013 11:56:20 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M7FLk-1U5HXj2lLK-00x7M4 for ; Thu, 27 Jun 2013 20:56:17 +0200 Received: (qmail invoked by alias); 27 Jun 2013 18:56:17 -0000 Received: from host-94-101-1-228.igua.fi (EHLO [192.168.4.115]) [94.101.1.228] by mail.gmx.net (mp017) with SMTP; 27 Jun 2013 20:56:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+gEopQpMmg+oqut//w3DvImCCYsB8hsiPfGDP2+J QcFEzWOAgPGYLi From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Jun 2013 21:56:16 +0300 Message-Id: <6A6401A4-0B6D-4AAE-B495-7206CEE37BC7@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] OAuth Dynamic Client Registration Design Team Calls X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 18:56:38 -0000 Thanks for the feedback so far. For those who have not yet indicated = their availability please do so by Friday (=3Dtomorrow) so that I can = initiate the next steps.=20 Here is the link again: http://moreganize.com/b240sPl7SEp=20 Ciao Hannes & Derek From jricher@mitre.org Thu Jun 27 12:15:50 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC2321F9F12 for ; Thu, 27 Jun 2013 12:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGhuozHmLxRt for ; Thu, 27 Jun 2013 12:15:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EAA7321F9F11 for ; Thu, 27 Jun 2013 12:15:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8228E1F038E; Thu, 27 Jun 2013 15:15:44 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6FAFB1F0514; Thu, 27 Jun 2013 15:15:44 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 27 Jun 2013 15:15:44 -0400 Message-ID: <51CC8F16.8050209@mitre.org> Date: Thu, 27 Jun 2013 15:14:30 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Mike Jones References: <20130622003217.cc40c4f3d92d2001859047cd8cabb9ab.48b02a77bc.wbe@email07.europe.secureserver.net> <51C84E0D.9050001@mitre.org> <1372303958.11180.61.camel@shakespeare> <51CC4C9C.8090404@mitre.org> <4E1F6AAD24975D4BA5B16804296739436789DD40@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436789DD40@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------040308060908010401010601" X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 19:15:50 -0000 --------------040308060908010401010601 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit That's a very good point -- the extra layer of sanity checking is valuable in many cases. -- Justin On 06/27/2013 10:58 AM, Mike Jones wrote: > > I believe that we should leave it as-is. For many implementations, > it��s important to communicate the client_id value. > > -- Mike > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Justin Richer > *Sent:* Thursday, June 27, 2013 7:31 AM > *To:* Vladimir Dzhuvinov / NimbusDS > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt > > Not all URLs will have the client_id in them (even though it's > recommended and the common examples do) -- some systems will just > re-use the Registration Endpoint's URL and switch behavior based on > the presence of a valid registration_access_token and look up the > client_id based on the token itself. > > My initial thought was that having the client leave out the client_id > from the data model seems to be asking for trouble. However, we > already preclude people from sending back some other fields: > > The Client MUST NOT include the > "registration_access_token", "registration_client_uri", > "client_secret_expires_at", or "client_id_issued_at" fields described > in Client Information Response (Section 5.1 ). > > > So an argument might be to have clients send *only* the fields > described in Client Metadata (2) and not the extra fields in the > Client Information Response (5.1). We need to decide whether these > fields MUST NOT be sent, or if they MAY be sent and if sent they MUST > match. The former would get rid of the paragraph saying that the > client_id and client_secret have to be checked, and get rid of the > invalid_client_id parameter. > > Do we want this change, or do we want to leave it as it is? > > -- Justin > > On 06/26/2013 11:32 PM, Vladimir Dzhuvinov / NimbusDS wrote: > > Hi Justin, > > > > > > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2 > > > > Error code invalid_client_id obsolete? > > > > This is sent if the client_id in the posted object doesn't match the one > > referenced by the registration_client_uri and registration_access_token. > > I should add text to clarify that. > > > > How about removing the requirement to have client_id in the PUT body of > > client update requests? The ID can be derived from the registration URL > > and servers will certainly have to support that in order to process > > client delete requests. That way the invalid_client_id error code will > > no longer be needed, and we can simply return HTTP status 404, as a > > RESTful API would do. > > > > Vladimir > > > --------------040308060908010401010601 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit That's a very good point -- the extra layer of sanity checking is valuable in many cases.

��-- Justin

On 06/27/2013 10:58 AM, Mike Jones wrote:

I believe that we should leave it as-is.�� For many implementations, it��s important to communicate the client_id value.

��

�� -- Mike

��

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, June 27, 2013 7:31 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt

��

Not all URLs will have the client_id in them (even though it's recommended and the common examples do) -- some systems will just re-use the Registration Endpoint's URL and switch behavior based on the presence of a valid registration_access_token and look up the client_id based on the token itself.

My initial thought was that having the client leave out the client_id from the data model seems to be asking for trouble. However, we already preclude people from sending back some other fields:

The Client MUST NOT include the

�� "registration_access_token", "registration_client_uri",

�� "client_secret_expires_at", or "client_id_issued_at" fields described

�� in Client Information Response (Section 5.1).

So an argument might be to have clients send *only* the fields described in Client Metadata (2) and not the extra fields in the Client Information Response (5.1). We need to decide whether these fields MUST NOT be sent, or if they MAY be sent and if sent they MUST match. The former would get rid of the paragraph saying that the client_id and client_secret have to be checked, and get rid of the invalid_client_id parameter.

Do we want this change, or do we want to leave it as it is?

��-- Justin

On 06/26/2013 11:32 PM, Vladimir Dzhuvinov / NimbusDS wrote:

Hi Justin,

��

��

http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2

��

Error code invalid_client_id obsolete?

��

This is sent if the client_id in the posted object doesn't match the one

referenced by the registration_client_uri and registration_access_token.

I should add text to clarify that.

��

How about removing the requirement to have client_id in the PUT body of

client update requests? The ID can be derived from the registration URL

and servers will certainly have to support that in order to process

client delete requests. That way the invalid_client_id error code will

no longer be needed, and we can simply return HTTP status 404, as a

RESTful API would do.

��

Vladimir

��

��

--------------040308060908010401010601-- From ve7jtb@ve7jtb.com Thu Jun 27 12:32:10 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA4121F9EC5 for ; Thu, 27 Jun 2013 12:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRCdImbBUDSN for ; Thu, 27 Jun 2013 12:32:06 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id DD92621F9EC9 for ; Thu, 27 Jun 2013 12:32:05 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id nd7so379204qeb.19 for ; Thu, 27 Jun 2013 12:32:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=u1QrGKPBmHdQ0tLB7zqZf+YJDKLwz6kv3A/0xxjxIyE=; b=Bh6v0S/YxdXCY8nSJR83YH3YRL1ygW/2U62xMi7jR/Ntu8D14afPr1K7z9N7FHqfqL 97dJczPIXVhluApGA/rdhyIs+8ApKmX5X+ZYqxSicJnRIz7/6Haq2cYUpCDd6e0HoXmZ pBOt8EIXKAFgGXNDrbZ1tAAsNkK1KjVLSkcujl1Irn9teQSAox0Lo7HleiIJ5LdS/mJs 915s61h5ITCJQc6IuYIAun8JVtdIojsEVY2R868YxFJj5yf4xLurzJqgKZJ9bbSg4TY5 leFzIlAN/MfmYxczL4RTTjg/+gtaLNN9lmQFwUfPZtDi41l6zDRNwcx4kspVYBhV8LEi Gjnw== X-Received: by 10.224.26.7 with SMTP id b7mr13475152qac.102.1372361523989; Thu, 27 Jun 2013 12:32:03 -0700 (PDT) Received: from [192.168.1.216] (190-20-7-218.baf.movistar.cl. [190.20.7.218]) by mx.google.com with ESMTPSA id s9sm5640452qeo.3.2013.06.27.12.31.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Jun 2013 12:32:02 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2DFED0B1-29AE-4A4E-A387-C6E994CD2374"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: John Bradley In-Reply-To: <51CC8F16.8050209@mitre.org> Date: Thu, 27 Jun 2013 15:30:58 -0400 Message-Id: <4504EB19-1E0E-4FCD-B674-3B389823E84B@ve7jtb.com> References: <20130622003217.cc40c4f3d92d2001859047cd8cabb9ab.48b02a77bc.wbe@email07.europe.secureserver.net> <51C84E0D.9050001@mitre.org> <1372303958.11180.61.camel@shakespeare> <51CC4C9C.8090404@mitre.org> <4E1F6AAD24975D4BA5B16804296739436789DD40@TK5EX14MBXC283.redmond.corp.microsoft.com> <51CC8F16.8050209@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQmyQpjv3fa3jYpT2IOZuqmbzYGXj+h/Eix+jBlNuSNMOVwb4jwnQkULeemzHnq2pbiUhvtu Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 19:32:10 -0000 --Apple-Mail=_2DFED0B1-29AE-4A4E-A387-C6E994CD2374 Content-Type: multipart/alternative; boundary="Apple-Mail=_500C11BA-83ED-4458-8865-6E8EA059CC52" --Apple-Mail=_500C11BA-83ED-4458-8865-6E8EA059CC52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It is a useful debug and sanity check. Leave it in for now. John B. On 2013-06-27, at 3:14 PM, Justin Richer wrote: > That's a very good point -- the extra layer of sanity checking is = valuable in many cases.=20 >=20 > -- Justin >=20 > On 06/27/2013 10:58 AM, Mike Jones wrote: >> I believe that we should leave it as-is. For many implementations, = it=92s important to communicate the client_id value. >> =20 >> -- Mike >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Justin Richer >> Sent: Thursday, June 27, 2013 7:31 AM >> To: Vladimir Dzhuvinov / NimbusDS >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt >> =20 >> Not all URLs will have the client_id in them (even though it's = recommended and the common examples do) -- some systems will just re-use = the Registration Endpoint's URL and switch behavior based on the = presence of a valid registration_access_token and look up the client_id = based on the token itself. >>=20 >> My initial thought was that having the client leave out the client_id = from the data model seems to be asking for trouble. However, we already = preclude people from sending back some other fields: >> The Client MUST NOT include the >> "registration_access_token", "registration_client_uri", >> "client_secret_expires_at", or "client_id_issued_at" fields = described >> in Client Information Response (Section 5.1). >>=20 >> So an argument might be to have clients send *only* the fields = described in Client Metadata (2) and not the extra fields in the Client = Information Response (5.1). We need to decide whether these fields MUST = NOT be sent, or if they MAY be sent and if sent they MUST match. The = former would get rid of the paragraph saying that the client_id and = client_secret have to be checked, and get rid of the invalid_client_id = parameter.=20 >>=20 >> Do we want this change, or do we want to leave it as it is? >>=20 >> -- Justin >>=20 >> On 06/26/2013 11:32 PM, Vladimir Dzhuvinov / NimbusDS wrote: >> Hi Justin, >> =20 >> =20 >> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2 >> =20 >> Error code invalid_client_id obsolete? >> =20 >> This is sent if the client_id in the posted object doesn't match the = one=20 >> referenced by the registration_client_uri and = registration_access_token.=20 >> I should add text to clarify that. >> =20 >> How about removing the requirement to have client_id in the PUT body = of >> client update requests? The ID can be derived from the registration = URL >> and servers will certainly have to support that in order to process >> client delete requests. That way the invalid_client_id error code = will >> no longer be needed, and we can simply return HTTP status 404, as a >> RESTful API would do. >> =20 >> Vladimir >> =20 >> =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_500C11BA-83ED-4458-8865-6E8EA059CC52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 It is = a useful debug and sanity check. Leave it in for = now.

John B.

On 2013-06-27, = at 3:14 PM, Justin Richer <jricher@mitre.org> = wrote:

=20 =20
That's a very good point -- the extra layer of sanity checking is valuable in many cases.

-- Justin

On 06/27/2013 10:58 AM, Mike Jones wrote:

I believe that we should leave it as-is. For many implementations, it=92s important to communicate the = client_id value.

        &nbs= p;            =             &n= bsp;           &nbs= p;            = -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, June 27, 2013 7:31 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt

Not all URLs will have the client_id in them (even though it's recommended and the common examples do) -- some systems will just re-use the Registration Endpoint's URL and switch behavior based on the presence of a valid registration_access_token and look up the client_id based on the token itself.

My initial thought was that having the client leave out the client_id from the data model seems to be asking for trouble. However, we already preclude people from sending back some other fields:

The Client MUST NOT include the

   "registration_access_token", = "registration_client_uri",

   "client_secret_expires_at", or = "client_id_issued_at" fields described

   in Client Information Response (Section 5.1).

So an argument might be to have clients send *only* the fields described in Client Metadata (2) and not the extra fields in the Client Information Response (5.1). We need to decide whether these fields MUST NOT be sent, or if they MAY be sent and if sent they MUST match. The former would get rid of the paragraph saying that the client_id and client_secret have to be checked, and get rid of the invalid_client_id parameter.

Do we want this change, or do we want to leave it as it = is?

-- Justin

On 06/26/2013 11:32 PM, Vladimir Dzhuvinov / NimbusDS wrote:

Hi Justin,

http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2

Error code invalid_client_id = obsolete?

This is sent if the client_id in the posted object = doesn't match the one

referenced by the registration_client_uri and = registration_access_token.

I should add text to clarify that.

How about removing the requirement to have client_id in = the PUT body of

client update requests? The ID can be derived from the = registration URL

and servers will certainly have to support that in order = to process

client delete requests. That way the invalid_client_id = error code will

no longer be needed, and we can simply return HTTP status = 404, as a

RESTful API would do.

Vladimir

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

= --Apple-Mail=_500C11BA-83ED-4458-8865-6E8EA059CC52-- --Apple-Mail=_2DFED0B1-29AE-4A4E-A387-C6E994CD2374 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 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjI3MTkzMDU4WjAjBgkqhkiG9w0BCQQxFgQUXR3oPRGg PliGjibspnIjyMkVNe0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAmd1NJ0tbNWUTAW+sslx4PRhIWzYkkfrVQb427D0r 05tuKcju5obzr0Y1aRgXCjQF5IfuQlnD25JaZK9w5WV3KRkKtaxGGuUdLxq7LxaBD386SeLhUsRX MGW/mVsVEkmXJym7ZiC22CitD8wuPyMNOkB+ailtCaUJgjHTWaEDT3fmLiAyez551GUF2c9r95IL PHhyDJGqCHmAtX2GKgRuliR7Giws6ggLrbyeEVc1PxO3VhzikFg0ifh7LYiUX971lIzY3611z/Cy nfY7VQ6X/Dknv6Uwwtzru+U4Ct1v/8Lr91suuA25skzuHEAhEjpVz8aDxeNj+PzvAcEIRYNDnAAA AAAAAA== --Apple-Mail=_2DFED0B1-29AE-4A4E-A387-C6E994CD2374-- From hannes.tschofenig@nsn.com Thu Jun 27 23:25:09 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5909521F9DFA for ; Thu, 27 Jun 2013 23:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104 X-Spam-Level: X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZY8HT8lsc+a for ; Thu, 27 Jun 2013 23:25:00 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0D09721F9E0D for ; Thu, 27 Jun 2013 23:24:51 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r5S6OjQR010017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Jun 2013 08:24:48 +0200 Received: from USCHHTC002.nsn-intra.net ([10.159.161.15]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r5S6OgcQ018575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 28 Jun 2013 08:24:44 +0200 Received: from USCHHTC003.nsn-intra.net (10.159.161.16) by USCHHTC002.nsn-intra.net (10.159.161.15) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 28 Jun 2013 01:24:42 -0500 Received: from USCHMBX001.nsn-intra.net ([169.254.1.83]) by USCHHTC003.nsn-intra.net ([10.159.161.16]) with mapi id 14.03.0123.003; Fri, 28 Jun 2013 01:24:42 -0500 From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "oauth@ietf.org WG" Thread-Topic: IETF 87 Preliminary Agenda Thread-Index: AQHOc4BqeRdz6DVYH0Svei0rVkvU75lKqEgA Date: Fri, 28 Jun 2013 06:24:42 +0000 Message-ID: <1373E8CE237FCC43BCA36C6558612D2AA0BDBD@USCHMBX001.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.161.118] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1508 X-purgate-ID: 151667::1372400688-00002EAE-57ECA3F2/0-0/0-0 Subject: [OAUTH-WG] FW: IETF 87 Preliminary Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 06:25:09 -0000 QXQgbGVhc3QgSnVzdGluIHNhaWQgdGhhdCBoZSB3b3VsZCBwYXJ0aWNpcGF0ZSBmcm9tIHJlbW90 ZS4gQmVsb3cgaXMgdGhlIGp1c3QgcHVibGlzaGVkICoqcHJlbGltaW5hcnkqKiBhZ2VuZGEuIFRo ZSBPQXV0aCBzZXNzaW9uIGlzIGluIHRoZSBtb3JuaW5nIEJlcmxpbiB0aW1lIChzdGFydGluZyBh dCA5YW0gQ0VTVCkgYW5kIHRoYXQgd291bGQgdHJhbnNsYXRlIHRvIDNhbSBOZXcgWW9yayB0aW1l LiAgLS0+IHlpa2VzIA0KDQpTaG91bGQgSSB0cnkgdG8gc3dhcCBpdCB3aXRoIHNvbWUgYWZ0ZXJu b29uIHNlc3Npb24/IA0KDQpDaWFvDQpIYW5uZXMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IHdnY2hhaXJzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp3Z2NoYWlycy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IElFVEYgQWdlbmRhDQpTZW50OiBGcmlkYXks IEp1bmUgMjgsIDIwMTMgMTI6NTEgQU0NClRvOiBXb3JraW5nIEdyb3VwIENoYWlycw0KQ2M6IGly c2dAaXJ0Zi5vcmcNClN1YmplY3Q6IElFVEYgODcgUHJlbGltaW5hcnkgQWdlbmRhDQoNCg0KSGVs bG8gRXZlcnlvbmUsDQoNClRoZSBwcmVsaW1pbmFyeSBhZ2VuZGEgZm9yIElFVEYgODcgaXMgYXZh aWxhYmxlIGZvciB2aWV3aW5nLiAgUGxlYXNlIG5vdGUgdGhlIGN1dC1vZmYgZGF0ZSBmb3IgcmVx dWVzdHMgdG8gcmVzY2hlZHVsZSBXb3JraW5nIEdyb3VwLCBJUlRGLCBhbmQgQm9GIG1lZXRpbmdz IGlzIEp1bHkgMXN0LCAyMDEzLiAgVGhlIGZpbmFsIGFnZW5kYSB3aWxsIGJlIHB1Ymxpc2hlZCBv biBKdWx5IDV0aCwgMjAxMy4NCg0KVGhpcyBhZ2VuZGEgaXMgZXh0cmVtZWx5IGZ1bGwgYW5kIGNo YW5nZXMgd2lsbCBiZSBkaWZmaWN1bHQgdG8gbWFrZS4gIFBsZWFzZSB0YWtlIHRoYXQgaW50byBj b25zaWRlcmF0aW9uIGJlZm9yZSByZXF1ZXN0aW5nIGFueSBjaGFuZ2VzLg0KDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvODcvYWdlbmRhLmh0bWwNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvbWVldGluZy84Ny9hZ2VuZGEudHh0DQoNClRoYW5rIHlvdSENCg0KU3Rl cGhhbmllIE1jQ2FtbW9uDQo= From vladimir@nimbusds.com Fri Jun 28 00:52:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4513A21F9ECC for ; Fri, 28 Jun 2013 00:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfFIarBR2YrU for ; Fri, 28 Jun 2013 00:52:22 -0700 (PDT) Received: from n1plout04-02.prod.ams1.secureserver.net (n1plout04-02.prod.ams1.secureserver.net [188.121.53.2]) by ietfa.amsl.com (Postfix) with SMTP id A7CE821F9EC8 for ; Fri, 28 Jun 2013 00:52:06 -0700 (PDT) Received: (qmail 18711 invoked from network); 28 Jun 2013 07:52:03 -0000 Received: from unknown (87.97.198.36) by n1plout04-02.prod.ams1.secureserver.net (188.121.53.2) with ESMTP; 28 Jun 2013 07:52:02 -0000 Message-ID: <1372405921.11180.101.camel@shakespeare> From: Vladimir Dzhuvinov / NimbusDS To: John Bradley Date: Fri, 28 Jun 2013 10:52:01 +0300 In-Reply-To: <4504EB19-1E0E-4FCD-B674-3B389823E84B@ve7jtb.com> References: <20130622003217.cc40c4f3d92d2001859047cd8cabb9ab.48b02a77bc.wbe@email07.europe.secureserver.net> <51C84E0D.9050001@mitre.org> <1372303958.11180.61.camel@shakespeare> <51CC4C9C.8090404@mitre.org> <4E1F6AAD24975D4BA5B16804296739436789DD40@TK5EX14MBXC283.redmond.corp.microsoft.com> <51CC8F16.8050209@mitre.org> <4504EB19-1E0E-4FCD-B674-3B389823E84B@ve7jtb.com> Organization: Nimbus Directory Services Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 07:52:34 -0000 Hi guys, On Thu, 2013-06-27 at 15:30 -0400, John Bradley wrote: > It is a useful debug and sanity check. Leave it in for now > > John B. If we look at the client delete request, it relies solely on the request URL and / or the access token to identify the client, and the client_id is not duplicated on the body: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-4.4 DELETE /register/s6BhdRkqt3 HTTP/1.1 Host: server.example.com Authorization: Bearer reg-23410913-abewfq.123483 Servers that handle dynamic registration will still have to implement a reliable lookup method that is based on the URL / access token anyway, which becomes the lowest common denominator, and from that perspective encoding the client_id into the request body does seem redundant. This is what I ended up doing in the NimbusDS OAuth 2.0/ OIDC SDK. As a developer I also like the simplicity of not having to deal with an extra parameter + error, which is perceived to have some debugging value to server implementations, but is otherwise an extra bit of spec and code that client-side developers will have to live with. Which brings me to my final argument for removing the client_id and the invalid_client_id error, the principle that seems to be established here in regard to OAuth 2.0 and OIDC, to push complexity away from clients and to servers. Thanks, Vladimir > > On 2013-06-27, at 3:14 PM, Justin Richer wrote: > > > That's a very good point -- the extra layer of sanity checking is > > valuable in many cases. > > > > -- Justin > > > > On 06/27/2013 10:58 AM, Mike Jones wrote: > > > > > I believe that we should leave it as-is. For many > > > implementations, it��s important to communicate the client_id > > > value. > > > > > > > > > > > > -- > > > Mike > > > > > > > > > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > > Behalf Of Justin Richer > > > Sent: Thursday, June 27, 2013 7:31 AM > > > To: Vladimir Dzhuvinov / NimbusDS > > > Cc: oauth@ietf.org > > > Subject: Re: [OAUTH-WG] I-D Action: > > > draft-ietf-oauth-dyn-reg-12.txt > > > > > > > > > > > > > > > Not all URLs will have the client_id in them (even though it's > > > recommended and the common examples do) -- some systems will just > > > re-use the Registration Endpoint's URL and switch behavior based > > > on the presence of a valid registration_access_token and look up > > > the client_id based on the token itself. > > > > > > My initial thought was that having the client leave out the > > > client_id from the data model seems to be asking for trouble. > > > However, we already preclude people from sending back some other > > > fields: > > > > > > The Client MUST NOT include the > > > "registration_access_token", "registration_client_uri", > > > "client_secret_expires_at", or "client_id_issued_at" fields described > > > in Client Information Response (Section 5.1). > > > > > > > > > So an argument might be to have clients send *only* the fields > > > described in Client Metadata (2) and not the extra fields in the > > > Client Information Response (5.1). We need to decide whether these > > > fields MUST NOT be sent, or if they MAY be sent and if sent they > > > MUST match. The former would get rid of the paragraph saying that > > > the client_id and client_secret have to be checked, and get rid of > > > the invalid_client_id parameter. > > > > > > Do we want this change, or do we want to leave it as it is? > > > > > > -- Justin > > > > > > On 06/26/2013 11:32 PM, Vladimir Dzhuvinov / NimbusDS wrote: > > > > > > > > > Hi Justin, > > > > > > > > > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2 > > > > > > Error code invalid_client_id obsolete? > > > > > > This is sent if the client_id in the posted object doesn't match the one > > > referenced by the registration_client_uri and registration_access_token. > > > I should add text to clarify that. > > > > > > How about removing the requirement to have client_id in the PUT body of > > > client update requests? The ID can be derived from the registration URL > > > and servers will certainly have to support that in order to process > > > client delete requests. That way the invalid_client_id error code will > > > no longer be needed, and we can simply return HTTP status 404, as a > > > RESTful API would do. > > > > > > Vladimir > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 From vladimir@nimbusds.com Fri Jun 28 00:58:53 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C46421F9ED1 for ; Fri, 28 Jun 2013 00:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-gMGa0QNR-z for ; Fri, 28 Jun 2013 00:58:43 -0700 (PDT) Received: from n1plout04-02.prod.ams1.secureserver.net (n1plout04-02.prod.ams1.secureserver.net [188.121.53.2]) by ietfa.amsl.com (Postfix) with SMTP id 2010521F9E27 for ; Fri, 28 Jun 2013 00:58:30 -0700 (PDT) Received: (qmail 28121 invoked from network); 28 Jun 2013 07:58:30 -0000 Received: from unknown (87.97.198.36) by n1plout04-02.prod.ams1.secureserver.net (188.121.53.2) with ESMTP; 28 Jun 2013 07:58:26 -0000 Message-ID: <1372406305.11180.105.camel@shakespeare> From: Vladimir Dzhuvinov / NimbusDS To: Justin Richer Date: Fri, 28 Jun 2013 10:58:25 +0300 In-Reply-To: <51CC4C9C.8090404@mitre.org> References: <20130622003217.cc40c4f3d92d2001859047cd8cabb9ab.48b02a77bc.wbe@email07.europe.secureserver.net> <51C84E0D.9050001@mitre.org> <1372303958.11180.61.camel@shakespeare> <51CC4C9C.8090404@mitre.org> Organization: Nimbus Directory Services Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 07:58:53 -0000 On Thu, 2013-06-27 at 10:30 -0400, Justin Richer wrote: > My initial thought was that having the client leave out the client_id > from the data model seems to be asking for trouble. However, we > already preclude people from sending back some other fields: > The Client MUST NOT include the > "registration_access_token", "registration_client_uri", > "client_secret_expires_at", or "client_id_issued_at" fields described > in Client Information Response (Section 5.1). > > So an argument might be to have clients send *only* the fields > described in Client Metadata (2) and not the extra fields in the > Client Information Response (5.1). We need to decide whether these > fields MUST NOT be sent, or if they MAY be sent and if sent they MUST > match. The former would get rid of the paragraph saying that the > client_id and client_secret have to be checked, and get rid of the > invalid_client_id parameter. > > Do we want this change, or do we want to leave it as it is? Requiring only the client metadata needs to be included in the update request will definitely simplify the spec and implementations. I like that. What is the argument for including client_secret in the request? Vladimir > > -- Justin > > On 06/26/2013 11:32 PM, Vladimir Dzhuvinov / NimbusDS wrote: > > > Hi Justin, > > > > > > > > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2 > > > > > > > > Error code invalid_client_id obsolete? > > > This is sent if the client_id in the posted object doesn't match the one > > > referenced by the registration_client_uri and registration_access_token. > > > I should add text to clarify that. > > How about removing the requirement to have client_id in the PUT body of > > client update requests? The ID can be derived from the registration URL > > and servers will certainly have to support that in order to process > > client delete requests. That way the invalid_client_id error code will > > no longer be needed, and we can simply return HTTP status 404, as a > > RESTful API would do. > > > > Vladimir > > > From vladimir@nimbusds.com Fri Jun 28 01:21:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F0B21F9D5E for ; Fri, 28 Jun 2013 01:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[AWL=-0.790, MISSING_HEADERS=1.581] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVCieEd2ZpTp for ; Fri, 28 Jun 2013 01:21:41 -0700 (PDT) Received: from n1plout04-01.prod.ams1.secureserver.net (n1plout04-01.prod.ams1.secureserver.net [188.121.53.1]) by ietfa.amsl.com (Postfix) with SMTP id C172C21F9D58 for ; Fri, 28 Jun 2013 01:21:33 -0700 (PDT) Received: (qmail 29561 invoked from network); 28 Jun 2013 08:21:32 -0000 Received: from unknown (87.97.198.36) by n1plout04-01.prod.ams1.secureserver.net (188.121.53.1) with ESMTP; 28 Jun 2013 08:21:32 -0000 Message-ID: <1372407690.2094.5.camel@shakespeare> From: Vladimir Dzhuvinov / NimbusDS Cc: oauth@ietf.org Date: Fri, 28 Jun 2013 11:21:30 +0300 In-Reply-To: <51C84D4A.60906@mitre.org> References: <20130621235427.cc40c4f3d92d2001859047cd8cabb9ab.e06d39c8a0.wbe@email07.europe.secureserver.net> <51C84D4A.60906@mitre.org> Organization: Nimbus Directory Services Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 08:21:52 -0000 A server that implements dynamic registration must support all three requests - register, update and delete, is that correct? I had another careful read of the spec and I think it would help to mention this explicitly. Cheers, Vladimir From jricher@mitre.org Fri Jun 28 06:20:09 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE21621F9EFB for ; Fri, 28 Jun 2013 06:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30g1QixO9TRM for ; Fri, 28 Jun 2013 06:20:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4C72C21F9B0E for ; Fri, 28 Jun 2013 06:20:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DFB901F0675; Fri, 28 Jun 2013 09:20:01 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C4C591F066F; Fri, 28 Jun 2013 09:20:01 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 28 Jun 2013 09:20:01 -0400 Message-ID: <51CD8D36.60303@mitre.org> Date: Fri, 28 Jun 2013 09:18:46 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Vladimir Dzhuvinov / NimbusDS References: <20130622003217.cc40c4f3d92d2001859047cd8cabb9ab.48b02a77bc.wbe@email07.europe.secureserver.net> <51C84E0D.9050001@mitre.org> <1372303958.11180.61.camel@shakespeare> <51CC4C9C.8090404@mitre.org> <1372406305.11180.105.camel@shakespeare> In-Reply-To: <1372406305.11180.105.camel@shakespeare> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 13:20:10 -0000 On 06/28/2013 03:58 AM, Vladimir Dzhuvinov / NimbusDS wrote: > On Thu, 2013-06-27 at 10:30 -0400, Justin Richer wrote: > >> My initial thought was that having the client leave out the client_id >> from the data model seems to be asking for trouble. However, we >> already preclude people from sending back some other fields: >> The Client MUST NOT include the >> "registration_access_token", "registration_client_uri", >> "client_secret_expires_at", or "client_id_issued_at" fields described >> in Client Information Response (Section 5.1). >> >> So an argument might be to have clients send *only* the fields >> described in Client Metadata (2) and not the extra fields in the >> Client Information Response (5.1). We need to decide whether these >> fields MUST NOT be sent, or if they MAY be sent and if sent they MUST >> match. The former would get rid of the paragraph saying that the >> client_id and client_secret have to be checked, and get rid of the >> invalid_client_id parameter. >> >> Do we want this change, or do we want to leave it as it is? > Requiring only the client metadata needs to be included in the update > request will definitely simplify the spec and implementations. I like > that. > > What is the argument for including client_secret in the request? The argument (and initial design of this) was based around what we saw as the data model on the client side and how we think clients are generally going to store things. What I've seen (and what I've implemented) splits things into two parts: the client information, and the registration API information. The former contains client_id, client_secret, client_name, redirect_uris, and all that -- everything you need to act like an OAuth client. The latter contains the registration_access_token, registration_client_uri, and the issued/expires timestamps -- everything you need to access the registration API. By taking the information in the former and turning into a JSON object you can call the update part of the API. -- Justin > Vladimir > >> -- Justin >> >> On 06/26/2013 11:32 PM, Vladimir Dzhuvinov / NimbusDS wrote: >> >>> Hi Justin, >>> >>> >>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2 >>>>> >>>>> Error code invalid_client_id obsolete? >>>> This is sent if the client_id in the posted object doesn't match the one >>>> referenced by the registration_client_uri and registration_access_token. >>>> I should add text to clarify that. >>> How about removing the requirement to have client_id in the PUT body of >>> client update requests? The ID can be derived from the registration URL >>> and servers will certainly have to support that in order to process >>> client delete requests. That way the invalid_client_id error code will >>> no longer be needed, and we can simply return HTTP status 404, as a >>> RESTful API would do. >>> >>> Vladimir >>> > From jricher@mitre.org Fri Jun 28 06:26:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D881221F9C22 for ; Fri, 28 Jun 2013 06:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lKcaKkic-tW for ; Fri, 28 Jun 2013 06:26:29 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9683E21F88A9 for ; Fri, 28 Jun 2013 06:26:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 365351F0776; Fri, 28 Jun 2013 09:26:20 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7F40122600CF; Fri, 28 Jun 2013 09:26:19 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 28 Jun 2013 09:26:19 -0400 Message-ID: <51CD8EB0.1080603@mitre.org> Date: Fri, 28 Jun 2013 09:25:04 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Vladimir Dzhuvinov / NimbusDS References: <20130621235427.cc40c4f3d92d2001859047cd8cabb9ab.e06d39c8a0.wbe@email07.europe.secureserver.net> <51C84D4A.60906@mitre.org> <1372407690.2094.5.camel@shakespeare> In-Reply-To: <1372407690.2094.5.camel@shakespeare> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 13:26:35 -0000 A server is supposed to at least listen for all actions and return the right error codes if it can't (or won't) complete the request. For instance, a 403 from the update action means the client isn't allowed to update its record. A 405 from the delete action means the server can't support the action at all, and a 403 from the delete means that the server supports the action but the client isn't allowed to delete its own record. You can get at that information by reading through each of the sections in (4), but if you can suggest text for the introductory section of (4) that would help clarify this situation, I'd appreciate it. Thanks, -- Justin On 06/28/2013 04:21 AM, Vladimir Dzhuvinov / NimbusDS wrote: > A server that implements dynamic registration must support all three > requests - register, update and delete, is that correct? > > I had another careful read of the spec and I think it would help to > mention this explicitly. > > Cheers, > > Vladimir > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Fri Jun 28 06:30:34 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF4321F9B95 for ; Fri, 28 Jun 2013 06:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvdo-6eTrXSg for ; Fri, 28 Jun 2013 06:30:29 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 11F2421F9A8F for ; Fri, 28 Jun 2013 06:30:29 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AF40B1F0682; Fri, 28 Jun 2013 09:30:28 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 96B981F067F; Fri, 28 Jun 2013 09:30:28 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 28 Jun 2013 09:30:28 -0400 Message-ID: <51CD8FA9.2070102@mitre.org> Date: Fri, 28 Jun 2013 09:29:13 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <1373E8CE237FCC43BCA36C6558612D2AA0BDBD@USCHMBX001.nsn-intra.net> In-Reply-To: <1373E8CE237FCC43BCA36C6558612D2AA0BDBD@USCHMBX001.nsn-intra.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.56] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] FW: IETF 87 Preliminary Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 13:30:34 -0000 I'll participate remotely if I can (I have some personal/family obligations that week) -- but that day and time is going to make it very difficult for me here in the EDT timezone. I'm not expecting the WG to shuffle around just for my sake, but if we can swap for something earlier in the week and later in the day, I'll be better able to participate. If I can't call in, I'll still work with my co-authors on the DynReg spec who are planning to attend in person. -- Justin On 06/28/2013 02:24 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > At least Justin said that he would participate from remote. Below is the just published **preliminary** agenda. The OAuth session is in the morning Berlin time (starting at 9am CEST) and that would translate to 3am New York time. --> yikes > > Should I try to swap it with some afternoon session? > > Ciao > Hannes > > -----Original Message----- > From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of ext IETF Agenda > Sent: Friday, June 28, 2013 12:51 AM > To: Working Group Chairs > Cc: irsg@irtf.org > Subject: IETF 87 Preliminary Agenda > > > Hello Everyone, > > The preliminary agenda for IETF 87 is available for viewing. Please note the cut-off date for requests to reschedule Working Group, IRTF, and BoF meetings is July 1st, 2013. The final agenda will be published on July 5th, 2013. > > This agenda is extremely full and changes will be difficult to make. Please take that into consideration before requesting any changes. > > https://datatracker.ietf.org/meeting/87/agenda.html > https://datatracker.ietf.org/meeting/87/agenda.txt > > Thank you! > > Stephanie McCammon > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stephen.farrell@cs.tcd.ie Fri Jun 28 06:54:54 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5DA21F8528 for ; Fri, 28 Jun 2013 06:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98Vb5p3Z9v6x for ; Fri, 28 Jun 2013 06:54:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7400921F854F for ; Fri, 28 Jun 2013 06:54:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 67172BEAF; Fri, 28 Jun 2013 14:54:28 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUFcenkpmPrs; Fri, 28 Jun 2013 14:54:28 +0100 (IST) Received: from [IPv6:2001:770:10:203:3561:24ef:7ef:e35e] (unknown [IPv6:2001:770:10:203:3561:24ef:7ef:e35e]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0D366BEA1; Fri, 28 Jun 2013 14:54:28 +0100 (IST) Message-ID: <51CD9595.5020808@cs.tcd.ie> Date: Fri, 28 Jun 2013 14:54:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Torsten Lodderstedt References: <20130616091345.2031.39661.idtracker@ietfa.amsl.com> <51BD8536.9010805@lodderstedt.net> In-Reply-To: <51BD8536.9010805@lodderstedt.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 13:54:55 -0000 Hi, On 06/16/2013 10:28 AM, Torsten Lodderstedt wrote: > Hi, > > the new revision addresses DISCUSSES and comments raised during IESG > evaluation: > > - DISCUSS by Barry Leiba: incoporated Barry's text proposal - it > strengthens requirements on the authorization server to immediately > revoke tokens while acknowledging the practical constraints on change > propagation among distributed servers > - D2 by Richard Barnes: changed text to refer to respective section of > RFC 6749 on TLS version > - description of revocation endpoint URL now refers to respective > section of RFC 6749 (comment by Sean Turner) > - added intro to IANA section (comment by Joel Jaeggli) > - some nits and editorial changes - should cover all comments raised > during IESG evaluation > > There are two open issues > - discussion regarding the TLS version on the list > - DISCUSS regarding the mandate to use TLS (D1/Richard Barnes) Can we please close these on the list so we don't have to spend time on 'em in Berlin? As a reminder Richard's discuss says: D1. The mandate for TLS usage actually seems backward here. Suppose a server receives a request over HTTP. At this point, the credentials have been exposed, so you would *want* the token to be invalidated! Suggest: -- Clients MUST NOT send over HTTP -- Server revocation URIs MUST be HTTPS -- Servers MAY support HTTP to the corresponding URI, just in case the client screws up D2. Why are the requirements TLS versions different here than in RFC 6749? Especially in a way that makes them worse. Suggest deleting the sentence starting "The authorization server MUST support TLS 1.0 ..." Thanks, S. > > regards, > Torsten. > > Am 16.06.2013 11:13, schrieb internet-drafts@ietf.org: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol Working >> Group of the IETF. >> >> Title : OAuth 2.0 Token Revocation >> Author(s) : Torsten Lodderstedt >> Stefanie Dronia >> Marius Scurtescu >> Filename : draft-ietf-oauth-revocation-10.txt >> Pages : 11 >> Date : 2013-06-16 >> >> Abstract: >> This document proposes an additional endpoint for OAuth authorization >> servers, which allows clients to notify the authorization server that >> a previously obtained refresh or access token is no longer needed. >> This allows the authorization server to cleanup security credentials. >> A revocation request will invalidate the actual token and, if >> applicable, other tokens based on the same authorization grant. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-oauth-revocation-10 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-10 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 > > From torsten@lodderstedt.net Sat Jun 29 01:31:42 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97D121F9E94 for ; Sat, 29 Jun 2013 01:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfrKOo8mU-8D for ; Sat, 29 Jun 2013 01:31:38 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) by ietfa.amsl.com (Postfix) with ESMTP id DC33C21F9E93 for ; Sat, 29 Jun 2013 01:31:37 -0700 (PDT) Received: from [79.253.61.13] (helo=[192.168.71.77]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1UsqZC-0006el-KC; Sat, 29 Jun 2013 10:31:34 +0200 References: <20130616091345.2031.39661.idtracker@ietfa.amsl.com> <51BD8536.9010805@lodderstedt.net> <51CD9595.5020808@cs.tcd.ie> Mime-Version: 1.0 (1.0) In-Reply-To: <51CD9595.5020808@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B329) From: Torsten Lodderstedt Date: Sat, 29 Jun 2013 10:31:33 +0200 To: Stephen Farrell X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 08:31:42 -0000 Hi Stephen, Am 28.06.2013 um 15:54 schrieb Stephen Farrell : >=20 > Hi, >=20 > On 06/16/2013 10:28 AM, Torsten Lodderstedt wrote: >> Hi, >>=20 >> the new revision addresses DISCUSSES and comments raised during IESG >> evaluation: >>=20 >> - DISCUSS by Barry Leiba: incoporated Barry's text proposal - it >> strengthens requirements on the authorization server to immediately >> revoke tokens while acknowledging the practical constraints on change >> propagation among distributed servers >> - D2 by Richard Barnes: changed text to refer to respective section of >> RFC 6749 on TLS version >> - description of revocation endpoint URL now refers to respective >> section of RFC 6749 (comment by Sean Turner) >> - added intro to IANA section (comment by Joel Jaeggli) >> - some nits and editorial changes - should cover all comments raised >> during IESG evaluation >>=20 >> There are two open issues >> - discussion regarding the TLS version on the list >> - DISCUSS regarding the mandate to use TLS (D1/Richard Barnes) >=20 > Can we please close these on the list so we don't have to > spend time on 'em in Berlin? >=20 > As a reminder Richard's discuss says: >=20 > D1. The mandate for TLS usage actually seems backward here. Suppose > a server receives a request over HTTP. At this point, the > credentials have been exposed, so you would *want* the token to be > invalidated! Suggest: -- Clients MUST NOT send over HTTP -- Server > revocation URIs MUST be HTTPS -- Servers MAY support HTTP to the > corresponding URI, just in case the client screws up If the server does not support HTTP (which is prohibited by the spec), the c= lient cannot send the request over HTTP so there is no way to expose the tok= en. I don't understand why the server should support HTTP. >=20 > D2. Why are the requirements TLS versions different here than in > RFC 6749? Especially in a way that makes them worse. Suggest > deleting the sentence starting "The authorization server MUST > support TLS 1.0 ..." This is already fixed in -10. Regards, Torsten. >=20 > Thanks, > S. >=20 >=20 >>=20 >> regards, >> Torsten. >>=20 >> Am 16.06.2013 11:13, schrieb internet-drafts@ietf.org: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Web Authorization Protocol Working >>> Group of the IETF. >>>=20 >>> Title : OAuth 2.0 Token Revocation >>> Author(s) : Torsten Lodderstedt >>> Stefanie Dronia >>> Marius Scurtescu >>> Filename : draft-ietf-oauth-revocation-10.txt >>> Pages : 11 >>> Date : 2013-06-16 >>>=20 >>> Abstract: >>> This document proposes an additional endpoint for OAuth authorization= >>> servers, which allows clients to notify the authorization server that= >>> a previously obtained refresh or access token is no longer needed. >>> This allows the authorization server to cleanup security credentials.= >>> A revocation request will invalidate the actual token and, if >>> applicable, other tokens based on the same authorization grant. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-10 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-10 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 From hardjono@mit.edu Sat Jun 29 06:37:40 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DA711E8128 for ; Sat, 29 Jun 2013 06:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLJRVbMk2iYH for ; Sat, 29 Jun 2013 06:37:34 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC3111E811D for ; Sat, 29 Jun 2013 06:37:34 -0700 (PDT) X-AuditID: 1209190c-b7fa48e000000947-f6-51cee31da819 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id CF.00.02375.D13EEC15; Sat, 29 Jun 2013 09:37:33 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r5TDbWC1018076 for ; Sat, 29 Jun 2013 09:37:33 -0400 Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (w92exedge6.exchange.mit.edu [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id r5TDbVrZ013723 for ; Sat, 29 Jun 2013 09:37:32 -0400 Received: from OC11EXHUB12.exchange.mit.edu (18.9.3.26) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sat, 29 Jun 2013 09:37:27 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.205]) by OC11EXHUB12.exchange.mit.edu ([18.9.3.26]) with mapi id 14.02.0309.002; Sat, 29 Jun 2013 09:37:31 -0400 From: Thomas Hardjono To: "oauth@ietf.org" Thread-Topic: New Version Notification for draft-hardjono-oauth-umacore-07.txt Thread-Index: AQHOdMyTxOTaV/BHakCyQ1hNyEo9vJlMseRg Date: Sat, 29 Jun 2013 13:37:30 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A2F1B9A63@OC11EXPO24.exchange.mit.edu> References: <20130629132841.10418.25232.idtracker@ietfa.amsl.com> In-Reply-To: <20130629132841.10418.25232.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [218.45.236.137] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPKsWRmVeSWpSXmKPExsUixCmqrSv7+FygwcfzWhYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt6di9gKlvBVTOq9zt7A+IW3i5GTQ0LARGL+0hfMELaYxIV7 69m6GLk4hAT2MUoc/HOYEcK5yiix7vVUFgjnNqPE37/XmCCc7YwSnRs3skM4qxklnt5awgYy jE1AQ+Lc773sILaIgKrEvqNXwGxhAV+JKbueM0LEAySeTOxlgrCNJJoaXrGA2CxA9V/f7gKL 8woESZz8vRnMFhJwlPj99DpYL6eAk8TZ6Q/AbEagw7+fWgNWwywgLnHryXwmiIcEJRbN3gP3 3L9dD9kgbCWJFa/2APVyANVrSqzfpQ/RqigxpfshO8RaQYmTM5+wTGCUmIVk6iyEjllIOmYh 6VjAyLKKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11AvN7NELzWldBMjON4keXYwvjmodIhRgINR iYfXYcHZQCHWxLLiytxDjJIcTEqivHl3zgUK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuGV1AHK 8aYkVlalFuXDpKQ5WJTEeZ8+BZokkJ5YkpqdmlqQWgSTleHgUJLglX4E1ChYlJqeWpGWmVOC kGbi4AQZzgM0/PVDkOHFBYm5xZnpEPlTjIpS4rzuIM0CIImM0jy4Xlg6fMUoDvSKMC8XSBUP MJXCdb8CGswENJi3FWxwSSJCSqqBUe6crIGqyY3EZKGCrLO7gk6mllck93/qtRYIX5XA9P7B h23W12R5c9eGhavX8Cw92NG46zmHGovpomcvm9/+DZx6qPsU28SaNS76kwtNXCI0dKfG5gQ8 3RNWH6O4fuUaVTfFjb/3WCd+eCz41mHvtpWtkUHLJ67ZPueekUncp1733cJ2X7pXKbEUZyQa ajEXFScCADTkXHxiAwAA Subject: [OAUTH-WG] FW: New Version Notification for draft-hardjono-oauth-umacore-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 13:37:40 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBTYXR1cmRheSwg SnVuZSAyOSwgMjAxMyA5OjI5IEFNDQpUbzogVGhvbWFzIEhhcmRqb25vDQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhcmRqb25vLW9hdXRoLXVtYWNvcmUtMDcu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhhcmRqb25vLW9hdXRoLXVtYWNv cmUtMDcudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRob21hcyBIYXJk am9ubyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAg ICAgZHJhZnQtaGFyZGpvbm8tb2F1dGgtdW1hY29yZQ0KUmV2aXNpb246ICAgICAgICAwNw0KVGl0 bGU6ICAgICAgICAgICBVc2VyLU1hbmFnZWQgQWNjZXNzIChVTUEpIFByb2ZpbGUgb2YgT0F1dGgg Mi4wDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTMtMDYtMjkNCkdyb3VwOiAgICAgICAgICAgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDM2DQpVUkw6ICAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhcmRqb25vLW9hdXRoLXVt YWNvcmUtMDcudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaGFyZGpvbm8tb2F1dGgtdW1hY29yZQ0KSHRtbGl6ZWQ6ICAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkam9uby1vYXV0aC11bWFjb3JlLTA3DQpE aWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWhh cmRqb25vLW9hdXRoLXVtYWNvcmUtMDcNCg0KQWJzdHJhY3Q6DQogICBVc2VyLU1hbmFnZWQgQWNj ZXNzIChVTUEpIGlzIGEgcHJvZmlsZSBvZiBPQXV0aCAyLjAuICBVTUEgZGVmaW5lcyBob3cNCiAg IHJlc291cmNlIG93bmVycyBjYW4gY29udHJvbCBwcm90ZWN0ZWQtcmVzb3VyY2UgYWNjZXNzIGJ5 IGNsaWVudHMNCiAgIG9wZXJhdGVkIGJ5IGFyYml0cmFyeSByZXF1ZXN0aW5nIHBhcnRpZXMsIHdo ZXJlIHRoZSByZXNvdXJjZXMgcmVzaWRlDQogICBvbiBhbnkgbnVtYmVyIG9mIHJlc291cmNlIHNl cnZlcnMsIGFuZCB3aGVyZSBhIGNlbnRyYWxpemVkDQogICBhdXRob3JpemF0aW9uIHNlcnZlciBn b3Zlcm5zIGFjY2VzcyBiYXNlZCBvbiByZXNvdXJjZSBvd25lciBwb2xpY3kuDQoNCg0KDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From hardjono@mit.edu Sat Jun 29 06:37:52 2013 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EAA11E812F for ; Sat, 29 Jun 2013 06:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCSMXE+602Xx for ; Sat, 29 Jun 2013 06:37:46 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0A811E812D for ; Sat, 29 Jun 2013 06:37:46 -0700 (PDT) X-AuditID: 1209190c-b7fa48e000000947-1d-51cee32a5145 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id B0.10.02375.A23EEC15; Sat, 29 Jun 2013 09:37:46 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r5TDbjxE002695 for ; Sat, 29 Jun 2013 09:37:45 -0400 Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (w92exedge6.exchange.mit.edu [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id r5TDbicR013750 for ; Sat, 29 Jun 2013 09:37:45 -0400 Received: from W92EXHUB11.exchange.mit.edu (18.7.73.20) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sat, 29 Jun 2013 09:37:40 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.205]) by W92EXHUB11.exchange.mit.edu ([18.7.73.20]) with mapi id 14.02.0309.002; Sat, 29 Jun 2013 09:37:44 -0400 From: Thomas Hardjono To: "oauth@ietf.org" Thread-Topic: New Version Notification for draft-hardjono-oauth-resource-reg-01.txt Thread-Index: AQHOdM0gSK1dDrm+BU+eIJt7XtZCuplMsgUw Date: Sat, 29 Jun 2013 13:37:43 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A2F1B9A90@OC11EXPO24.exchange.mit.edu> References: <20130629133238.32360.88950.idtracker@ietfa.amsl.com> In-Reply-To: <20130629133238.32360.88950.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [218.45.236.137] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHKsWRmVeSWpSXmKPExsUixCmqrKv1+FygQcMhdouTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr483M32wFj3gr3l3oY2pg3MLbxcjJISFgIvF9egMzhC0mceHe erYuRi4OIYF9jBJ7b95jgXCuMkqs3byZFcK5zShxaHcDI4SznVHi9LybLCD9QgKrGSX2XNAF sdkENCTO/d7LDmKLCKhK7Dt6BcwWFgiR2Ni3gA0iHirR/HE6E4RtJLHz2HWwGhag+qkfVoLV 8AoESTz9uJ4NYr6jxIkFs8DqOQWcJOYu+8cKYjMC3f391BqwOLOAuMStJ/OZIP4RlFg0ew/c b/92PWSDsJUkVrzaA/QAB1C9psT6XfoQrYoSU7ofskOsFZQ4OfMJywRGiVlIps5C6JiFpGMW ko4FjCyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdA31cjNL9FJTSjcxgqNNkmcH45uDSocYBTgY lXh4HRacDRRiTSwrrsw9xCjJwaQkypt351ygEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFeSR2g HG9KYmVValE+TEqag0VJnPfpU6BJAumJJanZqakFqUUwWRkODiUJXulHQI2CRanpqRVpmTkl CGkmDk6Q4TxAw18/BBleXJCYW5yZDpE/xagoJc7rDtIsAJLIKM2D64Ulw1eM4kCvCPNygVTx ABMpXPcroMFMQIN5W8EGlyQipKQaGCcV3si5tDQ0qob/8DPxsNN3D2oqKMj5aYVpvDI4f9hv 4d5QJafNz3KlQnY4WtxSfF/uV3jbkc1gjhuTItfB36EeN8t01C7Nu6zLI5FW7K+z+JlXfnrg 62+s+kGrH3Zvt6xvv1lZbDR/5YLc1SlTL3lzJ389sdi56NP3xB3XPzvriQo2CjUeUGIpzkg0 1GIuKk4EAOlhUb5hAwAA Subject: [OAUTH-WG] FW: New Version Notification for draft-hardjono-oauth-resource-reg-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 13:37:52 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBTYXR1cmRheSwg SnVuZSAyOSwgMjAxMyA5OjMzIEFNDQpUbzogVGhvbWFzIEhhcmRqb25vDQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhcmRqb25vLW9hdXRoLXJlc291cmNlLXJl Zy0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaGFyZGpvbm8tb2F1dGgt cmVzb3VyY2UtcmVnLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBU aG9tYXMgSGFyZGpvbm8gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxl bmFtZTogICAgICAgIGRyYWZ0LWhhcmRqb25vLW9hdXRoLXJlc291cmNlLXJlZw0KUmV2aXNpb246 ICAgICAgICAwMQ0KVGl0bGU6ICAgICAgICAgICBPQXV0aCAyLjAgUmVzb3VyY2UgU2V0IFJlZ2lz dHJhdGlvbg0KQ3JlYXRpb24gZGF0ZTogICAyMDEzLTA2LTI5DQpHcm91cDogICAgICAgICAgIElu ZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxOQ0KVVJMOiAgICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oYXJkam9uby1vYXV0 aC1yZXNvdXJjZS1yZWctMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaGFyZGpvbm8tb2F1dGgtcmVzb3VyY2UtcmVnDQpIdG1saXpl ZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmRqb25vLW9hdXRo LXJlc291cmNlLXJlZy0wMQ0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1oYXJkam9uby1vYXV0aC1yZXNvdXJjZS1yZWctMDENCg0KQWJzdHJh Y3Q6DQogICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIHJlc291cmNlIHNldCByZWdpc3Ry YXRpb24gbWVjaGFuaXNtDQogICBiZXR3ZWVuIGFuIE9BdXRoIDIuMCBhdXRob3JpemF0aW9uIHNl cnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyLiAgVGhlDQogICByZXNvdXJjZSBzZXJ2ZXIgcmVnaXN0 ZXJzIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzZW1hbnRpY3MgYW5kDQogICBkaXNjb3ZlcnkgcHJv cGVydGllcyBvZiBpdHMgcmVzb3VyY2VzIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLg0K DQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=