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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
