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

Breno de Medeiros breno at google.com
Fri Jul 27 20:41:28 UTC 2012


Yes, and I am not calling for JWK as the mandatory solution. I am just
arguing that there should be one.


On Fri, Jul 27, 2012 at 1:36 PM, Anthony Nadalin <tonynad at microsoft.com>wrote:

>  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 <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/dec7eebe/attachment-0001.html>


More information about the Openid-specs-ab mailing list