+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
<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
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
