[Openid-specs-ab] request_uris parameter of Dynamic Client Registration
cmortimore at salesforce.com
Wed Nov 26 19:47:35 UTC 2014
On Wed, Nov 26, 2014 at 10:43 AM, Mike Schwartz <mike at gluu.org> wrote:
> 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:
> See http://openid.net/specs/openid-connect-registration-1_
> 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.
Our interpretation and implementation treat client_id as a relatively
stable identifier, and analagous to entityid in SAML.
> 2) If clientID is meant to be stable, how would an OP automate trust and
> correlate the clients of a partner?
Initial trust establishment is straightforward with either out of band, or
dynamic registration. Dynamic reg might need update semantics for your
use-cases though, which it seems to lack in current draft.
> 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
I don't think public key is good for this, as you'll want to support key
> 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.
I believe overloading request uri in this way is pretty far away from their
intent in the spec, and would mess with the operational needs of the OP.
> 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!
> - Mike
> Michael Schwartz
> Founder / CEO
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab