>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* force another standard. It seems trivial to maintain the notion of software is 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 <de...@ihtfp.com> wrote: > Phil, > > Phil Hunt <phil.h...@oracle.com> 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 > de...@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
