[Openid-specs-ab] Mandatory JWK Support for OpenID Connect
Justin Richer
jricher at mitre.org
Fri Jul 27 19:23:58 UTC 2012
"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] *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]
> *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/dab96137/attachment.html>
More information about the Openid-specs-ab
mailing list