Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10

[John Bradley <[e-mail]>]

+1

Sent from my iPhone

On 2013-06-04, at 7:56 PM, George Fletcher <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>                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 <[e-mail]> wrote:
>>>>> 
>>>>>> Phil,
>>>>>> 
>>>>>> Phil Hunt <[e-mail]> 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
>>>>>> [e-mail]             www.ihtfp.com
>>>>>> Computer and Internet Security Consultant
>>>>> 
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth