<div dir="ltr"><span style="font-size:12.8px">Sorry for the slow reply.</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I've had a couple of others also ask me about the relationship between the RP certification suite and the JWT validation libraries. This is a good question. </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Basically, we think that these are complementary efforts. The main reason why we think the validation libraries are a good thing even with the existence of the testing suite:</div><div style="font-size:12.8px"><ul><li style="margin-left:15px">Libraries help get the implementation right in the first place. The conformance suite does a great job of highlighting issues with and implementation but it is less helpful in getting validation actually created.</li><li style="margin-left:15px">It allows us to be more prescriptive in our documentation. Instead of telling developers "validate your ID token per the spec and check with the conformance tests" we can say "use this library for x framewords and use the conformance suite to test it".</li><li style="margin-left:15px">More JWTs are coming. Between back channel log out, RISC and SETs, there are more kinds of validation that need to be done correctly. Good libraries can help make these other use cases easy for developers.</li><li style="margin-left:15px">New kinds of flows. Google and Facebook do a lot of auth via our native client SDKs and we document that developers can use our ID tokens from the client to their home server. I don't believe the conformance tests support that flow. We're also starting to see cases of using id tokens as statically verifiable access tokens so the library helps with these use cases too.</li></ul><div>thanks,</div><div>AD</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 28, 2017 at 1:10 AM, Vladimir Dzhuvinov <span dir="ltr"><<a href="mailto:vladimir@connect2id.com" target="_blank">vladimir@connect2id.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Adam,<br>
<br>
Client code and client developers are indeed the weak link in the whole<br>
system.<br>
<br>
Since 2012 we maintain a JOSE/JWT library and a separate SDK for<br>
building OAuth 2.0 and OpenID Connect clients and servers. We actively<br>
discourage developers from using the JWT library directory for ID token<br>
validation. Even if you give developers a JWT library that is<br>
cryptographically sound and compliant with the JWT spec, this is no<br>
guarantee that the ID token validation will be implemented correctly and<br>
according to the requirements of the specific OpenID Connect flow /<br>
profile. What has worked best was to provide developers with an OpenID<br>
Connect client abstraction for validating ID tokens where dealing with<br>
the JWT specific stuff is completely hidden (including things like<br>
OpenID provider key retrieval and caching), so developers need only<br>
provide the following inputs:<br>
<br>
1. An object with the OpenID provider details (endpoints).<br>
<br>
2. An object with the OpenID client details (client_id, secret or JWKs,<br>
etc).<br>
<br>
3. The OpenID authentication request.<br>
<br>
4. The OpenID authentication response and / or token response.<br>
<br>
<br>
<br>
How to achieve this practically and with minimum effort?<br>
<br>
Fortunately, the OpenID Foundation has created a Relying Party<br>
certification program, which includes a test suite for OpenID clients,<br>
and is platform / language / framework independent:<br>
<br>
<a href="http://openid.net/certification/" rel="noreferrer" target="_blank">http://openid.net/<wbr>certification/</a><br>
<br>
<br>
Suggesting client library developers certify, or giving them with some<br>
incentive to do so (e.g. when they register with Google) will probably<br>
be the most efficient way to achieve the security you're looking for,<br>
without having to maintain "compliant" libraries yourself for a variety<br>
of platforms, etc.<br>
<br>
In terms of innovation, this also seems like the best approach -<br>
developers will be free to innovate, e.g. by adding support for new<br>
frameworks, languages, platforms, etc. They just need to make sure their<br>
client library becomes certified to be credible.<br>
<br>
If you want to achieve particular security objectives, you could do that<br>
by contributing to / extending the certification suite. The suite itself<br>
is open source.<br>
<br>
<br>
Vladimir<br>
<span class=""><br>
<br>
On 24/08/17 03:50, Adam Dawes via Openid-specs-ab wrote:<br>
> Hi all,<br>
><br>
> I have mentioned to some of you that Google is very interested in making it<br>
> easy and secure for developers to do JWT/ID Token validation on their<br>
> servers. We think resources like <a href="http://jwt.io" rel="noreferrer" target="_blank">jwt.io</a> and the many open source libraries<br>
> have helped developers a lot with this process. But we are also concerned<br>
> that there are still many ways to mess up validation and want to make it<br>
> easy for developers to automatically do the right thing. I'm reaching out<br>
> because we would like to partner with the Foundation and the Connect WG to<br>
> build canonical libraries that gain wide adoption and which help drive<br>
> greater adoption of federation.<br>
><br>
> To drive this effort forward, I wanted to introduce a new PM on my team,<br>
> Luke Camery. He's put together a spec<br>
</span>> <<a href="https://docs.google.com/document/d/1V5uE-aR6k5JYuQQ6Ylgj8t1F_HMS7DEMJ4AIRMyR9Ts/edit#" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>document/d/1V5uE-<wbr>aR6k5JYuQQ6Ylgj8t1F_<wbr>HMS7DEMJ4AIRMyR9Ts/edit#</a>><br>
<div class="HOEnZb"><div class="h5">> for<br>
> the libraries.<br>
><br>
> I'd like to invite the group to provide feedback and also see if it would<br>
> be worthwhile to walk through this on an upcoming WG call. Also, we're also<br>
> going to be looking for contractors to help us implement these requirements<br>
> so if any of you are available or have recommendations, we would love to<br>
> get those.<br>
><br>
> Please let us know what you think.<br>
><br>
> thanks,<br>
> AD<br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif;font-size:small"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Adam Dawes |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Sr. Product Manager |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> <a href="mailto:adawes@google.com" target="_blank">adawes@google.com</a> |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> +1 650-214-2410</span></div><br></div></div>
</div>