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 <phil.h...@oracle.com> 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 <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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
