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

From: Nat Sakimura <[email-masked]>
Date: Wed, 19 Dec 2012 11:47:44 +0900

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

---

From: Justin Richer <[email-masked]>
Date: Thu, 20 Dec 2012 13:18:25 -0500

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:
> 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)

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 21 Dec 2012 09:59:15 +0900

For plain OAuth, it would just be a self asserted identifier. (For the time
being.)

Once request object gets in, the situation changes, and for OpenID Connect,
the situation obviously is different.
In these cases, you can sign the request, and for OpenID Connect, the
response may be encrypted.

Nat

On Fri, Dec 21, 2012 at 3:18 AM, Justin Richer <[email-masked]> wrote:

> 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.
>
> generally useful to servers and JS apps even though as an end user you can
> send basically whatever you want there.
>
>  -- Justin
>
>