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

[Phil Hunt <[e-mail]>]

Arg iphone types...
See below

Phil

On 2013-06-03, at 20:34, Phil Hunt <[e-mail]> wrote:

> From an operational security and change management perspective it is absolutely critical to know what clients should be of the same software type and version. 
> 
> We have customers that will want to be able to approve what 3rd party software is used on their service. 
> 
> If the spec doesn't support it, i *will*
it will
> force another standard. It seems trivial to maintain the notion of software is
software id
> rather than another draft for two attributes. 
> 
> I have agreed to make this optional. 
> 
> Those that are arguing for are oidc and only google has production deployment. 
> 
> Finally when we did 6819 we were hammered by the iesg on the notion of authenticating legit software. I believe they will send the draft back if it leaves that issue entirely out of scope. 
> 
> 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