<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Mike, <div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I think you may have gotten the wrong element the request object doesn’t seem like a good idea.</div><div class=""><br class=""></div><div class="">For Symmetric keys you are sort of out of luck for the moment, until the <span style="font-family: 'Helvetica Neue';" class="">draft-ietf-oauth-dyn-reg-management spec or something like it is finalized.</span></div><div class=""><span style="font-family: 'Helvetica Neue';" class=""><br class=""></span></div><div class=""><span style="font-family: 'Helvetica Neue';" class="">We did have that as part of the Connect dynamic registration at one point but took it out as it needed more work.</span></div><div class=""><span style="font-family: 'Helvetica Neue';" class=""><br class=""></span></div><div class=""><font face="Helvetica Neue" class="">For clients if you want a stable reference over time for clients doing asymmetric authentication, the https: uri for </font>jwks_uri would work as long as they don’t change it.</div><div class=""><br class=""></div><div class="">John B.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 26, 2014, at 4:50 PM, Chuck Mortimore <<a href="mailto:cmortimore@salesforce.com" class="">cmortimore@salesforce.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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. <div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">client_id seems proper here.</div><div class=""><br class=""></div><div class="">-cmort</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Nov 26, 2014 at 11:46 AM, Mike Jones <span dir="ltr" class=""><<a href="mailto:Michael.Jones@microsoft.com" target="_blank" class="">Michael.Jones@microsoft.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Client ID is a stable identifier for the client, so I don't think that's what you want.<br class="">
<br class="">
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 <a href="http://yahoo.com/" target="_blank" class="">yahoo.com</a> and <a href="http://flickr.com/" target="_blank" class="">flickr.com</a>. That may be what you want.<br class="">
<br class="">
Can you explain a little better the business problem that you're trying to solve, maybe with an example or two?<br class="">
<br class="">
-- Mike<br class="">
<div class=""><div class="h5"><br class="">
-----Original Message-----<br class="">
From: Openid-specs-ab [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net" class="">openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Mike Schwartz<br class="">
Sent: Wednesday, November 26, 2014 10:44 AM<br class="">
To: <a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a><br class="">
Subject: [Openid-specs-ab] request_uris parameter of Dynamic Client Registration<br class="">
<br class="">
OpenID Connect gurus,<br class="">
<br class="">
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" class="">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" class="">https://example.com/idp</a>" in case a new public certificate is required.<br class="">
<br class="">
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:<br class="">
OpenID Connect doesn't define a PUT method to update client credentials.<br class="">
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 class="">
<br class="">
I chatted with John Bradley about this in a past IIW, and he suggested to perhaps use the "request_uris" parameter:<br class="">
See<br class="">
<a href="http://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata" target="_blank" class="">http://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata</a><br class="">
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 class="">
<br class="">
My questions are :<br class="">
1) Is the clientid meant to be a stable identifier of the RP. Or is it a throw-away identifier to<br class="">
just represent the clientID at a given time.<br class="">
2) If clientID is meant to be stable, how would an OP automate trust and correlate the clients of a partner?<br class="">
3) Wouldn't it be best for the client to register a 2048 public key for future correlation, like in many SAML<br class="">
trust models? Or could this in fact be what one of the request_uris contains?<br class="">
<br class="">
Am I missing something... as usual?<br class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
- Mike<br class="">
<br class="">
<br class="">
-------------------------------------<br class="">
Michael Schwartz<br class="">
Gluu<br class="">
Founder / CEO<br class="">
</div></div>_______________________________________________<br class="">
Openid-specs-ab mailing list<br class="">
<a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br class="">
_______________________________________________<br class="">
Openid-specs-ab mailing list<br class="">
<a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br class="">
</blockquote></div><br class=""></div>
_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab<br class=""></div></blockquote></div><br class=""></div></body></html>