More interesting since now the great "public key cryptopolitics compromise" (that let ssl flourish) can kick in. This keeps the value of strong crypto at the fore of the debate, countering the surveillance (and vendor subversion) issue set. Somehow politics does its magic, and happy medium can be (re)found.<br><br>I noted in ping-issued jwts the option to reference x.509 (user) certs. Unlike saml, i assume jwts will not carry the user cert (but reference it). <br><br>I assume its up to the jwt verifier to form cert chains, and validate them, following references to oscp or crldb addresses - per the assurance class. This is easy on windows of course, where "rich" cert infrastructure exists, suiting every industries different taste for assurances.<br><br>Breno de Medeiros <breno@google.com> wrote:<br><br>
<div class="PlainText">Google uses RSA and supplies keys in X.509 self-signed certificates.<br>
<br>
On Thu, Sep 26, 2013 at 9:04 PM, n-sakimura <n-sakimura@nri.co.jp> wrote:<br>
> Bunch of us are actualy using RSA.<br>
> I thought Google was also using it in their service but I may be wrong.<br>
><br>
> Nat<br>
><br>
><br>
> (2013/09/27 4:05), Peter Williams wrote:<br>
><br>
> From a Nat write up (for the 7 billion of us web users who are not<br>
> inherently exceptional), the idtoken seems to be a symmetrically signed jwt<br>
> *in anticipated practice*. Its motivation is as an "integrity check".<br>
><br>
> If anyone is interested (in a relying party industry perspective) the RSA<br>
> signed token was more interesting, when referencing a x509 cert chain.<br>
> Testable by third parties during offline dispute handling, its indication<br>
> enabled the client to retain and present unforgeable evidence of its<br>
> authority to access/store and even snoop/share on data retrieved from<br>
> certain other endpoints, concerning user x. Typically, those endpoints are<br>
> not even guarded (by access tokens)<br>
><br>
> Note , despite being a willing windows developer, I have nothing to do with<br>
> Microsoft - don't be confused by the consumer centric msn.com domain name! I<br>
> played with DSL-based (dsam pop delivered) pptp VPN in 2001ish to see where<br>
> the surveillance crypto politics & associated engineering was at, in the<br>
> us), and the name stuck.<br>
><br>
> My assumption is that Microsoft activities with their peers here are being<br>
> done in anticipation of services to be delivered in 1-2 years from now to<br>
> (developer) customers (per normal engineering cycles).<br>
><br>
> Sent from my Windows Phone<br>
> ________________________________<br>
> From: Mike Jones<br>
> Sent: 9/26/2013 10:02 AM<br>
> To: peter williams; general@openid net<br>
> Subject: RE: [OpenID] Openid connect and interoperability (today)<br>
><br>
> There's over a dozen implementations with test sites up at<br>
> <a href="http://osis.idcommons.net/">http://osis.idcommons.net/</a>. See the Solutions link and the page about the<br>
> current OpenID Connect interop activities. (We're currently in the 5th<br>
> round of public interop testing.)<br>
><br>
> Best wishes,<br>
> -- Mike<br>
> ________________________________<br>
> From: peter williams<br>
> Sent: 9/26/2013 7:49 AM<br>
> To: general@openid net<br>
> Subject: [OpenID] Openid connect and interoperability (today)<br>
><br>
> One more general question comes to mind. Using rsa-signed jwts, using id<br>
> certs, using access tokens that reference id certs, noting the claim that<br>
> google have deployed openid connect in essence, and noting that facebook<br>
> apparently use an original proprietary version of openid connect, what is<br>
> the state of multi-vendor openid connect deployment?<br>
><br>
> We almost licensed ping identitys openid module for their federation server,<br>
> once the firm announced oauth v2 conformance and once id figured that<br>
> app/plugin fever had struck in the heart of microsofts Office365 cloud<br>
> service (wherein web-hosted sites can host pages that display in the outlook<br>
> email client, augmenting the email page itself, as rendered by the cloud<br>
> service AND where oauth-like authorization grant and vendor control<br>
> practices govern plugin activation and subscription). This seemed like a<br>
> good fit...for us...allowing professional data about a "member of realty<br>
> association" to augment the email addressing information.<br>
><br>
> Ping did their best to accomodate (since they tend to be market leading and<br>
> put up with me like few others do). But i was stunned to learn that oauth 2<br>
> delivered nothing of any value (to such a multi-vendor concept). The very<br>
> concept was still scoped to private community devices (logically enabling<br>
> controlled realty iphone apps talking to realty apis, aping facebook model<br>
> of world order). Such devices (including windows toolkits making sp website<br>
> into "authorized devices") would still require custom code or realty plugins<br>
> even for that 5 year old world view.<br>
><br>
> While the ping deal idn't happen for some strange commercial reasons and my<br>
> lack of faith that the market concept was of much importance (why do i want<br>
> to ape google/facebook, being intentionally 5 years late to the party), we<br>
> did go off and extend our websso so that third party authorization servers<br>
> could do their thing, adding oauth2 value. Thus we let microsoft azure cloud<br>
> services for oauth offer such extensibility (effectively adding yap - yet<br>
> another (websso) protocol - to the family). And duly another realty firm<br>
> with native table/phone apps did connect up .. finding oauth 2 code grant<br>
> flow with rsa-signed jwts "just right".<br>
><br>
> Which leads me back to the main question. Where is openid connect in<br>
> practice? Is there a groundswell? Is it at the im explosion stage still<br>
> (wherein aol, yahoo, live refused to connect up...)? Is the technical<br>
> profiling and core interoperability phase done? Is it at the find a vc,<br>
> phase?<br>
><br>
> Perhaps want i really want to know is when will openid connect be an open<br>
> system? When can i talk to office 365 using my jwts, much as i can talk to<br>
> any webserver on the planet using my ssl x509 client certs?<br>
><br>
> Or is that the wrong question? Is it _supposed_ to be a closed system, like<br>
> x400/x500, fully distributed but with a hierarchical connectivity mesh<br>
> controlled much public phone systems connect (at a relatively few formal<br>
> connection points)?<br>
><br>
><br>
> _______________________________________________<br>
> general mailing list<br>
> general@lists.openid.net<br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-general">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
><br>
><br>
> _______________________________________________<br>
> general mailing list<br>
> general@lists.openid.net<br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-general">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
><br>
><br>
><br>
> --<br>
> Nat Sakimura (n-sakimura@nri.co.jp)<br>
> Nomura Research Institute, Ltd.<br>
> Tel:+81-3-6274-1412 Fax:+81-3-6274-1547<br>
><br>
> 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござӓ<br>
> 6;|<br>
> 14;せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。<br>
> PLEASE READ:<br>
> The information contained in this e-mail is confidential and intended for<br>
> the named recipient(s) only.<br>
> If you are not an intended recipient of this e-mail, you are hereby notified<br>
> that any review, dissemination, distribution or duplication of this message<br>
> is strictly prohibited. If you have received this message in error, please<br>
> notify the sender immediately and delete your copy from your system.<br>
><br>
><br>
> _______________________________________________<br>
> general mailing list<br>
> general@lists.openid.net<br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-general">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
><br>
<br>
<br>
<br>
-- <br>
--Breno<br>
</div>