Argh! Typos (due to iPhone? no bad brain <-> hand connections). Sorry
Justin!
On 6/4/13 1:56 PM, George Fletcher 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 <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
