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

John Bradley ve7jtb at ve7jtb.com
Wed Nov 26 20:23:08 UTC 2014


Mike, 

I think I recommended using the jwks_uri in registration for the client to publish an endpoint for it’s keys if it is going to rotate them.

I think you may have gotten the wrong element the request object doesn’t seem like a good idea.

For Symmetric keys you are sort of out of luck for the moment, until the draft-ietf-oauth-dyn-reg-management spec or something like it is finalized.

We did have that as part of the Connect dynamic registration at one point but took it out as it needed more work.

For clients if you want a stable reference over time for clients doing asymmetric authentication, the https: uri for jwks_uri would work as long as they don’t change it.

John  B.


> On Nov 26, 2014, at 4:50 PM, Chuck Mortimore <cmortimore at salesforce.com> wrote:
> 
> 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 rotation.       
> 
> client_id seems proper here.
> 
> -cmort
> 
> On Wed, Nov 26, 2014 at 11:46 AM, Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
> 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 <http://yahoo.com/> and flickr.com <http://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 <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 <mailto: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 <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 <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 <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 <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <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/aaefde0a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20141126/aaefde0a/attachment.p7s>


More information about the Openid-specs-ab mailing list