+1 Sent from my iPhone
On 2013-06-04, at 7:56 PM, George Fletcher <gffle...@aol.com> wrote: > +1 for leaving dyn reg as is and working on a profile that enables this more > domain specific scenario. I agree with Phil and Justine that it's > important... I just don't think it should be put in the core dyn reg spec. > > Thanks, > George > > On 6/4/13 12:45 PM, Justin Richer wrote: >> I agree with the goal of standardizing on identifying software instances, >> but I think it's out of scope to do so inside of dynamic registration when >> most dynamic registration use cases don't need it and won't use it. I >> think that you've got to define discovery, assertion contents, and a few >> other things in order to make it work and interoperable across different >> services. Do we really want to define assertion formats and server/client >> discovery and processing rules inside of dynamic registration? I really >> don't think that's beneficial, either to dynamic registration itself or to >> the problem that the software instance tracking is trying to solve. >> >> If this gets proposed as a separate document, I will support it and I will >> help work on it. Heck, I'll even help edit the thing (or things) if people >> want. But I strongly believe that it's a separate concern from dynamic >> client registration, and I think it needs to have its own proper discussion >> apart from that. >> >> -- Justin >> >> On 06/04/2013 02:28 AM, Phil Hunt wrote: >>> 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 >> >> >> >> _______________________________________________ >> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
