Arg iphone types... See below Phil
On 2013-06-03, at 20:34, Phil Hunt <phil.h...@oracle.com> 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 <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
