[Openid-specs-ab] request_uris parameter of Dynamic Client Registration
Michael.Jones at microsoft.com
Wed Nov 26 19:46:30 UTC 2014
Client ID is a stable identifier for the client, so I don't think that's what you want.
OpenID Connect uses the Sector Identifier to enable making the statement that multiple sites are actually controlled by the same party. For instance, Yahoo might use the same sector identifier for both yahoo.com and flickr.com. That may be what you want.
Can you explain a little better the business problem that you're trying to solve, maybe with an example or two?
From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Mike Schwartz
Sent: Wednesday, November 26, 2014 10:44 AM
To: openid-specs-ab at lists.openid.net
Subject: [Openid-specs-ab] request_uris parameter of Dynamic Client Registration
OpenID Connect gurus,
In SAML, an IDP can use the entityID to identify a website, and make a business decision for a certain attribute release policy. For example, to entityID "https://example.com/idp" I will release the username and mail attributes. And of course SAML supports several workflows for getting the latest metadata for entityID "https://example.com/idp" in case a new public certificate is required.
So in OpenID Connect, I am wondering what is the equivalent of "entityID" ? In our first implementation at Gluu, we used clientID as the entityID, and established trust to a certain clientID. The problem:
OpenID Connect doesn't define a PUT method to update client credentials.
So what to do if your client wants to get a new client secret or update its public key. Then you need to re-create the attribute release policy on the OP (and other policies, like supressing authorization in certain cases).
I chatted with John Bradley about this in a past IIW, and he suggested to perhaps use the "request_uris" parameter:
These request_uris could contain files that would provide the required information to correlate subsequent client registrations. The OP could store a SHA-256 hash to detect changes to the files.
My questions are :
1) Is the clientid meant to be a stable identifier of the RP. Or is it a throw-away identifier to
just represent the clientID at a given time.
2) If clientID is meant to be stable, how would an OP automate trust and correlate the clients of a partner?
3) Wouldn't it be best for the client to register a 2048 public key for future correlation, like in many SAML
trust models? Or could this in fact be what one of the request_uris contains?
Am I missing something... as usual?
This issue is pressing for producing RP recommendations on how to support OpenID Connect. If request_uris is the way to correlate, we should be recommending every RP to add an optional field for this parameter.
Thanks all! And happy Thanksgiving to all the US based people! One thing we all have to be thankful for is the amazing work of the OpenID Connect community this year!
Founder / CEO
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab