Re: [OAUTH-WG] draft-richer-oauth-instance-00

[Justin Richer <[e-mail]>]

I would be fine with a machine-readable "instance_id" parameter to be 
paired with the human-readable items that are in there today. However, 
since this is a value that goes to the Authorization Endpoint and 
therefore goes through the browser, it MUST always be treated as 
self-asserted by the client. As such, I don't see how it can be used as 
a security-related parameter. The client_id and redirect_uri can be used 
in this regard because they are registered and paired with other 
security mechanisms like a client_secret or equivalent. The instance_ 
parameters are, by their very definition, not provided at registration 
time.

That's not to say it's without utility - browser identifier strings are 
generally useful to servers and JS apps even though as an end user you 
can send basically whatever you want there.

  -- Justin

On 12/18/2012 09:47 PM, Nat Sakimura wrote:
> Justin,
>
> In addition to instance_name and instance_description, I think we need 
> collision resistant instance_id which can be cryptographically linked 
> to the instance so that it can actually be authenticated, in a similar 
> manner to what we do with the self-issued IdP in the OpenID Connect.
>
> My proposal is to create a public-private key pair at the install time 
> and use the sha256 of the public key as the instance_id.
>
> Note: If the client is going to talk to multiple entities, the 
> instance_id would have some privacy impact.
> We may need to generate the keypair for each entity that the client 
> talks to.
>
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>