Yes. However the contents and format are out of scope. Phil
On 2013-06-03, at 22:32, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > 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 m! >>>> odel. >>>> 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 to! >>> gether >>> (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
