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

[Phil Hunt <[e-mail]>]

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 model.  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 together (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