[Openid-specs-ab] Mandatory JWK Support for OpenID Connect

Anthony Nadalin tonynad at microsoft.com
Fri Jul 27 20:36:47 UTC 2012


There is no proof that JWK is any better (could be better or could be worse). No way near an easy win, far from it. We are not about to extract keys and transform them, yet another break point. . There is no consensus to make this change and needs to be discussed more in depth.

From: Justin Richer [mailto:jricher at mitre.org]
Sent: Friday, July 27, 2012 1:06 PM
To: Anthony Nadalin
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Mandatory JWK Support for OpenID Connect

Speaking from an enterprise that does have a PKI infrastructure, I wholeheartedly disagree with the claim that this is going to be a deal breaker. I also wholeheartedly disagree with whether or not we should be in the business of replacing legacy technology with something better -- you could use the same arguments you have listed below to use SAML over OpenID Connect, or any number of strawman arguments. I don't buy it. We're trying to reinvent wheels with better wheels here. Isn't that the whole point of going through this standardization exercise again and again? We take what's been done before, figure out what works and what doesn't, and make the best informed decision to move forward.

Besides, nobody is even suggesting that we drop support for x509, merely make support for JWK the MTI standard. You still get to keep all your certificates, you just get to publish them in a way that makes it easier for new clients to use them. Your clients that want to use x509 can still use x509. Nobody's telling them not to. Your servers still get to publish the x509 certs. Nobody's telling them not to.

This should be an easy win for you and your users.

 -- Justin

On 07/27/2012 03:40 PM, Anthony Nadalin wrote:
There are other interop issues beside this one, so this is not the break point. You should not be in the business mandating the replacement of technology that works and is proven with technology that may or may not work and has yet to be proven, as enterprises care about these choices. This will be a deal breaker for companies that already have a PKI infrastructure and use keys/certificates within that infrastructure.

From: Justin Richer [mailto:jricher at mitre.org]
Sent: Friday, July 27, 2012 12:24 PM
To: Anthony Nadalin
Cc: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Mandatory JWK Support for OpenID Connect

"Let the customer decide" has already caused interoperability issues in several instances. I think we need to put a stake on the simple solution. JWK solves the problem of key publishing in an HTTP-friendly, JSON-friendly format.

Also, with JWK, as John pointed out, you can very easily translate the keys in your certificates into the JWK format. It's a couple lines of code on almost any platform. However, getting the public keys inside of a JWK into a valid certificate is another issue. We shouldn't be in the business of writing the spec to prop up legacy architectures.

 -- Justin

On 07/27/2012 03:14 PM, Anthony Nadalin wrote:
That's why I'm against a mandatory to implement as someone gets screwed in this case. With JWK you're asking that people invest in a un proven technology when they may already have proven technology that is working and proven, so let customer decide.

From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Justin Richer
Sent: Friday, July 27, 2012 11:13 AM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Mandatory JWK Support for OpenID Connect

Alteratively, why would you want to force people who don't have the same tools that you do to invest the years that you have in order to get a new protocol running when there's a simpler alternative that's fairly easy to build from the ground up? :)

 -- Justin

On 07/27/2012 01:36 PM, Anthony Nadalin wrote:
If I have the tools already for x.509, why would I want to invest in another set of tools and have to work on them for years to get them to the point our x.509 tools are today? Not sure there should be a mandatory, there should be an equal option for both and you either implement one or the other oe both, but making JWK mandatory means everyone has to create new tooling and test the new tooling, etc.

From: John Bradley [mailto:ve7jtb at ve7jtb.com]
Sent: Friday, July 27, 2012 10:18 AM
To: Magnus Andersson
Cc: Anthony Nadalin; openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com>; openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>; Edmund Jay
Subject: Re: [Openid-specs-ab] Mandatory JWK Support for OpenID Connect

There are some use cases where the use of PKIX trust relationships may be required.

In the EU there may be reasons to publish a x.509 cert so that the signature on the id_token is qualified digital signature for non repudiation at higher LOA.

I don't think anyone wants to remove the x.509 option.

The question is if clients or servers MUST implement both, or if only one format needs to be mandatory for servers what should it be.

For simple clients JWK is arguably (I say that knowing Tony will argue) simpler to build as it doesn't need ASN1 parsing.   For servers x.509 certificates have existing tools.

Our design principal to this point is for pushing complexity from clients to servers.

John B.
On 2012-07-27, at 8:06 AM, Magnus Andersson wrote:





Hi

My name is Magnus I own a startup and I'm implementing OpenID Connect.

As an implementor: if the JWK-format is mandatory, exactly what added value does optionally exposing x.509 certificates to the client give?

As long as the JWK is mandatory I personally don't see how optional x.509 certificates would simplify anything for those who have existing Public-key infrastructure. They still have to handle the JWK case and map that to their PKI.

I recognize I don't know all the history in this matter. But could the option to choose only JWK (as it is already deemed mandatory) and skip x.509 be added, to balance out the current options?

BR Magnus Andersson
Solvies AB
2012/7/27 John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>
Extracting a key from a certificate is not that hard, to make a JWK out of it.

We can likely automate that.   People who want to support x509 are free to do that it is just not mandatory for the client.   For the basic client using the code flow there is no MTI,  for the implicit flow  JWK is MTI if you want general support.  I suppose if a client just wants to talk to a specific IDP it could just do x509 if that is supported.

The options are.
1 Client must support both and server chooses
2 Server must support both and client chooses
3 Server must support one and the other is optional.

Tony are you saying you prefer 1 or 2, or 3 your preference but making x.509 the default.

There are advantages and disadvantages to picking JWK as the default.

It is true that most common tools like openSSL easily produce self signed certificates.
On the other hand they expire and create run time issues later because some people may try and do PKIX processing on them.

This is a continual debate in SAML over raw keys vs certificates.   Many federations think raw keys cause less support issues over time.

Thoughts?

John B.
On 2012-07-26, at 9:43 PM, Anthony Nadalin wrote:

This creates problems with folks that already have a PIK infrastructure and want to use existing keys

From: Edmund Jay [mailto:ejay at mgi1.com<mailto:ejay at mgi1.com>]
Sent: Thursday, July 26, 2012 3:11 PM
To: Anthony Nadalin; openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>; openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com>
Subject: Re: [Openid-specs-ab] Mandatory JWK Support for OpenID Connect

This is in reference to the open issue # 633 at http://hg.openid.net/connect/issue/633/messages-42-jwk-and-x509-format-support
The specs currently support x509 and JWK format for publishing public keys but is silent on which must be supported.
There may be interop problems related to cryptographic aspects of OpenID due to lack of common support between client and server.

-- Edmund

________________________________
From: Anthony Nadalin <tonynad at microsoft.com<mailto:tonynad at microsoft.com>>
To: Edmund Jay <ejay at mgi1.com<mailto:ejay at mgi1.com>>; "openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>" <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>; "openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com>" <openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com>>
Sent: Thu, July 26, 2012 1:46:41 PM
Subject: RE: [Openid-specs-ab] Mandatory JWK Support for OpenID Connect
Can you provide the rationale or a pointer to the rationale?

From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-specs-ab-bounces at lists.openid.net]<mailto:[mailto:openid-specs-ab-bounces at lists.openid.net]> On Behalf Of Edmund Jay
Sent: Thursday, July 26, 2012 11:58 AM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>; openid-connect-interop at googlegroups.com<mailto:openid-connect-interop at googlegroups.com>
Subject: [Openid-specs-ab] Mandatory JWK Support for OpenID Connect

This is to inform everyone that the Working Group has decided to make JWK support mandatory for both the client and server.
Feedbacks welcome.


-- Edmund
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab


_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab










_______________________________________________

Openid-specs-ab mailing list

Openid-specs-ab at lists.openid.net<mailto: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/20120727/365837b9/attachment-0001.html>


More information about the Openid-specs-ab mailing list