[Openid-specs-ab] request_uris parameter of Dynamic Client Registration

Chuck Mortimore 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_
> 0.html#ClientMetadata
> 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
> contains?

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
> Gluu
> Founder / CEO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20141126/c6c293cf/attachment.html>

More information about the Openid-specs-ab mailing list