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

Justin Richer <> Fri, 31 May 2013 16:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46A9721F8B64 for <>; Fri, 31 May 2013 09:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DAbOXDh4Ntne for <>; Fri, 31 May 2013 09:35:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2F37D21F86D5 for <>; Fri, 31 May 2013 09:35:26 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id A7BDE1F09BF; Fri, 31 May 2013 12:35:25 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG ( []) by (Postfix) with ESMTP id 8B63B1F09C0; Fri, 31 May 2013 12:35:25 -0400 (EDT)
Received: from [] ( by IMCCAS02.MITRE.ORG ( with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 31 May 2013 12:35:24 -0400
Message-ID: <>
Date: Fri, 31 May 2013 12:34:43 -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: <> <> <> <> <> <> <> <> <> <> <> <> <> <B33BFB58CCC8BE4998958016839DE27E08F97708@IMCMBX01.MITRE.ORG> <> <B33BFB58CCC8BE49989! 58016839DE27E08F977D8@IMCMBX01.MITRE.ORG> <> <51A8B9C4.8020200!> <> ! <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------040307050704000703040408"
X-Originating-IP: []
Cc: " WG" <>
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
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, 31 May 2013 16:35:32 -0000

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 [ 
>>>>>> <>]
>>>>>> *Sent:* Thursday, May 30, 2013 7:31 PM
>>>>>> *To:* Richer, Justin P.
>>>>>> *Cc:* John Bradley; <> 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 [ 
>>>>>>> <>]
>>>>>>> *Sent:* Thursday, May 30, 2013 5:25 PM
>>>>>>> *To:* Richer, Justin P.
>>>>>>> *Cc:* John Bradley; <> WG
>>>>>>> *Subject:* Re: [OAUTH-WG] review comments on 
>>>>>>> draft-ietf-oauth-dyn-reg-11.txt
>>>>>>> See below.
>>>>>>> Phil
>>>>>>> @independentid
>>>>>>> <>
>>>>>>> <>
>>>>>>> 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.)