Phil,
Phil Hunt <[email protected]> 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 model. 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 together (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
[email protected] www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
