Re: [OAUTH-WG] draft-ietf-oauth-dyn-reg and bearer tokens

[Justin Richer <[e-mail]>]

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 <http://www.independentid.com>
> [e-mail] <mailto:[e-mail]>
>
>
>
>
>
> 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 <http://www.independentid.com/>
>>> [e-mail] <mailto:[e-mail]>
>>>
>>>
>>>
>>>
>>>
>>> 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 <http://www.independentid.com/>
>>>>> [e-mail] <mailto:[e-mail]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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 <http://www.independentid.com/>
>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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 <[e-mail] 
>>>>>>>>> <mailto:[e-mail]>> 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)" <[e-mail] 
>>>>>>>>>> <mailto:[e-mail]>> 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
>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>