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

[Justin Richer <[e-mail]>]

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." <[e-mail] 
> <mailto:[e-mail]>> 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 [[e-mail] <mailto:[e-mail]>]
>> *Sent:* Thursday, May 30, 2013 7:31 PM
>> *To:* Richer, Justin P.
>> *Cc:* John Bradley; [e-mail] <mailto:[e-mail]> 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." <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>> Comments inline, marked by [JR].
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Phil Hunt [[e-mail] <mailto:[e-mail]>]
>>> *Sent:* Thursday, May 30, 2013 5:25 PM
>>> *To:* Richer, Justin P.
>>> *Cc:* John Bradley; [e-mail] <mailto:[e-mail]> WG
>>> *Subject:* Re: [OAUTH-WG] review comments on 
>>> draft-ietf-oauth-dyn-reg-11.txt
>>>
>>> See below.
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com <http://www.independentid.com>
>>> [e-mail] <mailto:[e-mail]>
>>>
>>>
>>>
>>>
>>>
>>> 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.) But that's neither here nor there, as you can already do 
>>>> what you're asking for and I think I can clear things up:
>>>>
>>>> In your case, the "3rd party bearer assertion" is simply *not* the 
>>>> Initial Registration Token. It's an assertion that can be used to 
>>>> *get* an Initial Registration Token. The token that you get from 
>>>> the Token Endpoint, in your case, would be "local" from your own 
>>>> AS. Your registration endpoint would look at this token on the way 
>>>> in, know how to validate it, do whatever else it wants to with it, 
>>>> and process the registration. Then it would issue a Registration 
>>>> Access Token that to the registering client to use at the RESTful 
>>>> endpoint. Incidentally, that token would also be "local", just like 
>>>> before.
>>>
>>>> How you (the client/developer) get the actual Initial Registration 
>>>> Token is completely and forever out of scope for the Dynamic 
>>>> Registration spec.
>>>
>>> [PH]  Yes, the issuance of the third party bearer assertion token 
>>> token would be out of scope of this spec.
>>>
>>> If however the group decides to except federated direct access 
>>> tokens as registration *access* tokens, then I think we have to 
>>> define federation for access tokens first.   For me, I think this is 
>>> something that should be discussed in a different charter.
>>>
>>> [JR] It's an access token, plain and simple. The draft doesn't care 
>>> -- and shouldn't care -- if it's federated or not. I agree, and have 
>>> been arguing all along, that if you have a use case for federated 
>>> access tokens, you need to define the mechanisms for such tokens, 
>>> and that registration is *not* the place for that definition.It's 
>>> orthogonal but they can be used together. Let's define them 
>>> separately but ina compatible way.
>>>
>> [ph] thats not the impression i get from the draft. As i mentioned 
>> earlier using access token for registration is clearer.
>>>>
>>>>
>>>> This all still fits with the current definitions as they are. You 
>>>> don't have to use federated tokens if you don't want to. I can 
>>>> still use them if I want to. Everybody's happy! And this is all 
>>>> because we are not defining any content or semantics tied to the 
>>>> processing of the Initial Registration Token or calling it an 
>>>> Assertion or anything -- it's up to the AS to process it however it 
>>>> would normally process an OAuth Access token. So if your AS needs a 
>>>> local token, then you need to use a local token. If you don't want 
>>>> to use structured foreign tokens as your Initial Registration 
>>>> Tokens, don't. But that shouldn't preclude others of us from doing so.
>>>
>>> [PH] The difference is where the client is expected to present the 
>>> federated (aka 3rd party) assertion.  I would rather follow the 
>>> standard 6749 4.5 method in all cases for consistency.
>>>
>>> You can choose to short circuit, but I think the draft should follow 
>>> a consistent methodology.
>>>
>>> [JR] 6749 section 4.5 (extension grants) is irrelevant to 
>>> registration as it's talking about access to the token endpoint and 
>>> not to protected resources. Additionally, people do use assertions 
>>> encoded inside of OAuth tokens directly at protected resources all 
>>> the time (since OAuth2 tokens are opaque to clients but must be 
>>> understood by protected resources), but that's *still* completely 
>>> irrelevant to this discussion because it doesn't matter in terms of 
>>> the interoperability of the protocol. If you want to use assertions 
>>> or auth codes or client credentials or magic to get your Initial 
>>> Registration Token, the dynamic registration protocol doesn't care 
>>> how you did it. Just like any other OAuth2 protected resource 
>>> doesn't care how you got the token. This abstraction was one of the 
>>> key insights in how OAuth2 is structured as a framework and 
>>> protocol. The important thing here is that if the client gets an 
>>> Initial Registration Token it knows where to send it and how to use 
>>> it. What I hear you saying is that you don't want to use a federated 
>>> token as an Initial Registration Token. That's fine! Don't do it -- 
>>> and you have that option precisely because of how we've already 
>>> written it! If your clients get handed a token that *isn't* an 
>>> Initial Registration Token and you want them to go through another 
>>> step to *get* an Initial Registration Token, so be it! But it 
>>> doesn't make sense to encode that behavior as required into the 
>>> registration protocol, because (as you point out) not everything is 
>>> going to be an assertion in the first place. Again I say that you 
>>> can do everything that you want to do with existing mechanisms or 
>>> self-contained extensions.
>>
>> [ph] i am referring to the mechanism currently defined that accepts 
>> external assertions in exchange for access tokens within the server.
>>
>> When you do it this way all clients are now accessing the reg 
>> endpoint with a short term access token.
>>
>> If you want to make federated access tokens a formal approach you 
>> need to profile it since there is no spec for federated access tokens.
>>
>> IOW, handle federated access tokens the same way 6749 does which is 
>> to say nothing.
>>
>> If you do this you can really simplify registration because now it 
>> just normal oauth protected resource without any special handling.
>>
>>>
>>>>
>>>> If you think it would be helpful, I can add language to the 
>>>> lifecycle discussion to clarify that the Initial Registration Token 
>>>> can be gotten through any number of means, not just the 
>>>> manual-portal approach that's talked about now. Or if you want to 
>>>> write up this specific use case we can add it as another concrete 
>>>> example.
>>>
>>> [PH] I think there is potential to cut a lot of text out of the spec 
>>> if we strictly define the registration endpoint as a normal OAuth2 
>>> protected endpoint.
>>>
>>> [JR] I don't understand what you're saying here -- it already *is* 
>>> an OAuth2 protected endpoint, like I've pointed out below. All 
>>> OAuth2 protected endpoints don't care how you get the token, neither 
>>> does this one. All OAuth2 protected endpoints don't care (from 
>>> OAuth2's perspective) how the token is verified or processed, and 
>>> neither does this one (from the draft's perspective). I explicitly 
>>> want to keep that kind of token and assertion processing *out* of 
>>> this draft because it's more useful to build generally applicable 
>>> mechanisms. If we keep the registration endpoint as an OAuth2 
>>> protected endpoint -- like it already is -- then we can inherit 
>>> whatever mechanisms you want, and that is a very powerful setup.
>>>>
>>>> I will close by pointing out that I have *never* proposed that we 
>>>> dictate that the Registration Endpoint have to accept and process 
>>>> federated tokens, and it would be ludicrous to do so. I have been 
>>>> and still am committed to the Initial Registration Token and the 
>>>> Registration Access Token being plain old opaque-to-the-client 
>>>> OAuth 2 tokens.
>>>
>>> [PH] Agreed.  However, the use case of a 3rd party signer for client 
>>> applications is critical to both commercial organizations and open 
>>> source orgs that publish software that are deployed by many separate 
>>> entities.  The client developer needs to be able to contact the 
>>> publisher in many cases to obtain a signed assertion.
>>>
>>> I believe this is a core use case.
>>>
>>> I believe as I've proposed it using the normal 4.5 exchange 
>>> federated assertion for local token method, the draft doesn't have 
>>> to get into the details of the assertion.  Though that said, I would 
>>> suggest the draft make some suggestions on the contents of such 
>>> assertions.
>>>
>>> [JR] You can already do what you want to without mentioning 
>>> assertions. The current draft doesn't mention assertions at all, 
>>> either. All talk of use of assertions is outside the scope of 
>>> registration. You're proposing adding it in, and I'm strongly 
>>> against that.
>>>>
>>>> I think it's possible that you're still conflating the work I'm 
>>>> doing with the BB+ *extension* to dynamic registration with the 
>>>> dynamic registration document itself. I have never suggested that 
>>>> we pull all the extended BB+ stuff down into Dyn Reg, and in fact I 
>>>> think quite the opposite as I don't believe it's as generally 
>>>> applicable without the larger BB+ stack (which includes discovery 
>>>> as well as reliance on policy and other frameworks).
>>>
>>> [PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle 
>>> have very similar requirements.  As I said above, the use case is a 
>>> key use case.
>>>
>>> However I agree, the way you solve it in BB+ is not the way to solve 
>>> it within the draft spec.  I think the BB+ does well inform our 
>>> discussions though.
>>>
>>> [JR] Considering that BB+ manages to do all of this with a cleanly 
>>> defined extension without any changes in the existing draft text, I 
>>> think that's as strong an argument as anything to keep it defined 
>>> how it is, and that what's there is a sufficient base to build on.
>>>>
>>>>  -- Justin
>>>>
>>>> On 05/30/2013 03:54 PM, Phil Hunt wrote:
>>>>> Justin,
>>>>>
>>>>> So far, every time an OAuth server has accepted a 3rd party token 
>>>>> it has been a bearer assertion. The common pattern is to exchange 
>>>>> that assertion for a an access token issued by the local server 
>>>>> for the local resource endpoint.
>>>>>
>>>>> That's the pattern I am trying to follow.
>>>>>
>>>>> Going this way means we do not have to define the initial 
>>>>> registration token.
>>>>>
>>>>> If however, you really want to use the initial registration token 
>>>>> AS an access token, you are taking us into the question of using 
>>>>> federated access tokens.  I prefer not to do that here.
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>> www.independentid.com <http://www.independentid.com/>
>>>>> [e-mail] <mailto:[e-mail]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2013-05-30, at 12:51 PM, Justin Richer wrote:
>>>>>
>>>>>> I don't understand which access token is being talked about here 
>>>>>> -- is this the Initial Registration Token? Because you can 
>>>>>> already do everything below. How you get the Initial Registration 
>>>>>> token is out of scope precisely so that the AS can decide what 
>>>>>> that means. We can add language in the lifecycle discussions to 
>>>>>> bring up the fact that you can get this token from an OAuth flow, 
>>>>>> if you think that'll help clear things up.
>>>>>>
>>>>>> However, the client doesn't register using the client credential 
>>>>>> flow at all -- it registers using a POST to the registration 
>>>>>> endpoint, and that POST might have an OAuth token attached to it. 
>>>>>> How the client got that OAuth tok=