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
