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

John Bradley ve7jtb at ve7jtb.com
Wed Sep 6 19:22:42 UTC 2017


+1
> On Sep 6, 2017, at 3:33 PM, Mike Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> Thanks for bringing this project idea to us, Adam.  Promoting high-quality JWT libraries is clearly a good thing.  One thing that I think would be really valuable to this effort is for the working group to produce a clear specification of what features of the JWT libraries would be validated.
>  
> I’ll also note that there may be multiple layers to the validation we want to do.  The first level is probably testing specific invariants specified in the JWS, JWE, JWK, JWA, and JWT specs.  However, as much of the claims and header parameters functionality (other than “crit”) is optional, I doubt that this level of validation will be adequate by itself.
>  
> The second layer is probably testing the validation of specific token invariants.  For instance, some example tests would be making sure that the “c_hash”, “at_hash”, and “nonce” values in ID Tokens are correct and present when required.  These kinds of invariants are specified for ID Tokens in the ID Token Validation Sections http://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken <http://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken>, http://openid.net/specs/openid-connect-core-1_0.html#ImplicitIDTValidation <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitIDTValidation>, and http://openid.net/specs/openid-connect-core-1_0.html#ImplicitIDTValidation <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitIDTValidation>.  Similarly, the logout token validation rules are specified at http://openid.net/specs/openid-connect-backchannel-1_0.html#Validation <http://openid.net/specs/openid-connect-backchannel-1_0.html#Validation>.
>  
> Negative tests should be implemented for each of the invariants being tested – such as passing the test suite an invalid “c_hash” value or an ID Token without a “c_hash” value when one is required.
>  
> I’d be curious to know what other kinds of specifics people think we should be testing.
>  
>                                                                 Cheers,
>                                                                 -- Mike
>  
> From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Adam Dawes via Openid-specs-ab
> Sent: Wednesday, September 6, 2017 5:27 AM
> To: Vladimir Dzhuvinov <vladimir at connect2id.com>
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Feedback requested: JWT library effort
>  
> 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 question. 
>  
> 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 created.
> ·  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.
> thanks,
> AD
>  
> On Mon, Aug 28, 2017 at 1:10 AM, Vladimir Dzhuvinov <vladimir at connect2id.com <mailto: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/ <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 <http://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# <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 <mailto:adawes at google.com> | +1 650-214-2410
>  
> _______________________________________________
> 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/20170906/315a21f0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4383 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170906/315a21f0/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list