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

[George Fletcher <[e-mail]>]

Argh! Typos (due to iPhone? no bad brain <-> hand connections). Sorry 
Justin!

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