[Openid-specs-ab] Feedback requested: JWT library effort

Adam Dawes adawes at google.com
Wed Sep 6 12:27:02 UTC 2017

Sorry for the slow reply.

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

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:

   - 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
   - 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".
   - 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.
   - 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.


On Mon, Aug 28, 2017 at 1:10 AM, Vladimir Dzhuvinov <vladimir at connect2id.com
> wrote:

> Hi Adam,
> Client code and client developers are indeed the weak link in the whole
> system.
> Since 2012 we maintain a JOSE/JWT library and a separate SDK for
> building OAuth 2.0 and OpenID Connect clients and servers. We actively
> discourage developers from using the JWT library directory for ID token
> validation. Even if you give developers a JWT library that is
> cryptographically sound and compliant with the JWT spec, this is no
> guarantee that the ID token validation will be implemented correctly and
> according to the requirements of the specific OpenID Connect flow /
> profile. What has worked best was to provide developers with an OpenID
> Connect client abstraction for validating ID tokens where dealing with
> the JWT specific stuff is completely hidden (including things like
> OpenID provider key retrieval and caching), so developers need only
> provide the following inputs:
> 1. An object with the OpenID provider details (endpoints).
> 2. An object with the OpenID client details (client_id, secret or JWKs,
> etc).
> 3. The OpenID authentication request.
> 4. The OpenID authentication response and / or token response.
> How to achieve this practically and with minimum effort?
> Fortunately, the OpenID Foundation has created a Relying Party
> certification program, which includes a test suite for OpenID clients,
> and is platform / language / framework independent:
> http://openid.net/certification/
> Suggesting client library developers certify, or giving them with some
> incentive to do so (e.g. when they register with Google) will probably
> be the most efficient way to achieve the security you're looking for,
> without having to maintain "compliant" libraries yourself for a variety
> of platforms, etc.
> In terms of innovation, this also seems like the best approach -
> developers will be free to innovate, e.g. by adding support for new
> frameworks, languages, platforms, etc. They just need to make sure their
> client library becomes certified to be credible.
> If you want to achieve particular security objectives, you could do that
> by contributing to / extending the certification suite. The suite itself
> is open source.
> Vladimir
> On 24/08/17 03:50, Adam Dawes via Openid-specs-ab wrote:
> > Hi all,
> >
> > I have mentioned to some of you that Google is very interested in making
> it
> > easy and secure for developers to do JWT/ID Token validation on their
> > servers. We think resources like jwt.io and the many open source
> libraries
> > have helped developers a lot with this process. But we are also concerned
> > that there are still many ways to mess up validation and want to make it
> > easy for developers to automatically do the right thing. I'm reaching out
> > because we would like to partner with the Foundation and the Connect WG
> to
> > build canonical libraries that gain wide adoption and which help drive
> > greater adoption of federation.
> >
> > To drive this effort forward, I wanted to introduce a new PM on my team,
> > Luke Camery. He's put together a spec
> > <https://docs.google.com/document/d/1V5uE-aR6k5JYuQQ6Ylgj8t1F_
> HMS7DEMJ4AIRMyR9Ts/edit#>
> > for
> > the libraries.
> >
> > I'd like to invite the group to provide feedback and also see if it would
> > be worthwhile to walk through this on an upcoming WG call. Also, we're
> also
> > going to be looking for contractors to help us implement these
> requirements
> > so if any of you are available or have recommendations, we would love to
> > get those.
> >
> > Please let us know what you think.
> >
> > thanks,
> > AD
> >

Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170906/14640baa/attachment.html>

More information about the Openid-specs-ab mailing list