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

Breno de Medeiros breno at google.com
Fri Jul 27 20:16:37 UTC 2012


Generally, spec compliance is an issue with writers of libraries and
vendors of solutions. It's well understood that any actual deployment can
switch off any features it doesn't care about.

Choosing mandatory to support features gives guidance to library
implementations and vendors as to the minimum subset they need to implement
before they can label their product spec-compliant. If we think JWK is
worth promoting as a convergence point, then marking it as mandatory helps
that in the sense that many environments will support it since because it's
easily available. It will not prevent any enterprise organization from
using PKI-only solution, or any vendor from allowing PKI-only as a simple
configuration of their product.

Since this is not an optional feature (i.e., some form of key distribution
is required for the spec to work), then in principle it would be preferable
to declare one option as mandatory to support. Choosing not to pick a
mandatory option is somewhat in departure from common practice and would
require a higher level of justification. That would not be the case if this
were a truly optional feature.


On Fri, Jul 27, 2012 at 1:05 PM, Justin Richer <jricher at mitre.org> wrote:

>  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 <jricher at mitre.org>]
> *Sent:* Friday, July 27, 2012 12:24 PM
> *To:* Anthony Nadalin
> *Cc:* 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<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
> *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 <ve7jtb at ve7jtb.com>]
> *Sent:* Friday, July 27, 2012 10:18 AM
> *To:* Magnus Andersson
> *Cc:* Anthony Nadalin; openid-connect-interop at googlegroups.com;
> 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>****
>
> 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]
> *Sent:* Thursday, July 26, 2012 3:11 PM
> *To:* Anthony Nadalin; openid-specs-ab at lists.openid.net;
> 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>
> *To:* Edmund Jay <ejay at mgi1.com>; "openid-specs-ab at lists.openid.net" <
> openid-specs-ab at lists.openid.net>; "
> openid-connect-interop at googlegroups.com" <
> 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] *On Behalf Of *Edmund
> Jay
> *Sent:* Thursday, July 26, 2012 11:58 AM
> *To:* openid-specs-ab at lists.openid.net;
> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
>   ****
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> 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****
>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
>   ****
>
> ** **
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


-- 
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120727/b04d7fbc/attachment-0001.html>


More information about the Openid-specs-ab mailing list