<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 26, 2014 at 10:43 AM, Mike Schwartz <span dir="ltr"><<a href="mailto:mike@gluu.org" target="_blank">mike@gluu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">OpenID Connect gurus,<br>
<br>
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 "<a href="https://example.com/idp" target="_blank">https://example.com/idp</a>" I will release the username and mail attributes. And of course SAML supports several workflows for getting the latest metadata for entityID "<a href="https://example.com/idp" target="_blank">https://example.com/idp</a>" in case a new public certificate is required.<br>
<br>
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).<br>
<br>
I chatted with John Bradley about this in a past IIW, and he suggested to perhaps use the "request_uris" parameter:<br>
  See <a href="http://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata" target="_blank">http://openid.net/specs/<u></u>openid-connect-registration-1_<u></u>0.html#ClientMetadata</a><br>
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.<br>
<br>
My questions are :<br>
  1) Is the clientid meant to be a stable identifier of the RP. Or is it a throw-away identifier to<br>
     just represent the clientID at a given time.<br></blockquote><div><br></div><div>Our interpretation and implementation treat client_id as a relatively stable identifier, and analagous to entityid in SAML.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  2) If clientID is meant to be stable, how would an OP automate trust and correlate the clients of a partner?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  3) Wouldn't it be best for the client to register a 2048 public key for future correlation, like in many SAML<br>
     trust models? Or could this in fact be what one of the request_uris contains?<br></blockquote><div><br></div><div>I don't think public key is good for this, as you'll want to support key rotation.    </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Am I missing something... as usual?<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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!<br>
<br>
- Mike<br>
<br>
<br>
------------------------------<u></u>-------<br>
Michael Schwartz<br>
Gluu<br>
Founder / CEO<br>
</blockquote></div><br></div></div>