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 protected]> wrote: > 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 > > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
