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

[Justin Richer <[e-mail]>]

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