+1 The fact that there has been so much discussion around this topic seems like a clear indicator to me that the group needs to carefully and precisely figure out the use cases and mechanisms needed to identify "application classes" or "client instances" (or whatever they should be called), in a secure and trustworthy manner. The security aspect is key here – otherwise we will end up with a situation like all the kerfluffle over the Implicit Grant and how it's not secure but everyone is using it (because it's easy) and it's bad for the OAuth 2.0 brand because it's not as secure.
Phil previously wrote: 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. However, I think everyone else has made pretty convincing arguments as to why that's not a door worth opening in *this* spec, and cracking it open by just dropping in a self-asserted application ID could cause much more trouble than it's worth. DynReg has clear extension points to add new parameters if needed, but I agree with Justin that there are a lot of other things that need to be defined and specified beyond just adding an extra parameter. Let's get DynReg finished and then those that are interested can start work on an extension to it, to fill in what's needed for client instance identification. --Amanda From: Justin Richer <jric...@mitre.org<mailto:jric...@mitre.org>> Date: Tuesday, June 4, 2013 12:45 PM To: Phil Hunt <phil.h...@oracle.com<mailto:phil.h...@oracle.com>> Cc: Derek Atkins <de...@ihtfp.com<mailto:de...@ihtfp.com>>, "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10 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<mailto: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<mailto: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<mailto:de...@ihtfp.com>> wrote: Phil, Phil Hunt <phil.h...@oracle.com<mailto: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<mailto:de...@ihtfp.com> www.ihtfp.com<http://www.ihtfp.com> Computer and Internet Security Consultant ________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org>https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org>https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
