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

Chuck Mortimore cmortimore at salesforce.com
Wed Nov 26 19:50:02 UTC 2014

I don't believe Mike is trying to correlate the clients to the same
provider.    As far as I understand it, from offline conversations, he's
trying to rotate the client secret, and lacking any update in dynamic
client reg, he's creating a net new client and trying to correlate with the
old client.

IMO this isn't a good model for the OP which will want 1 stable identifier
for a client over time, which should not be impacted by things like secret

client_id seems proper here.


On Wed, Nov 26, 2014 at 11:46 AM, Mike Jones <Michael.Jones at microsoft.com>

> 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?
>                                 -- Mike
> -----Original Message-----
> 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:
>    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.
>    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!
> - Mike
> -------------------------------------
> Michael Schwartz
> Gluu
> Founder / CEO
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20141126/f72a89c7/attachment-0001.html>

More information about the Openid-specs-ab mailing list