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

Breno de Medeiros breno at google.com
Fri Jul 27 20:45:51 UTC 2012


In other words, I think it's incumbent on this WG to invite feedback,
developer implementation experience reports and deployment in different
environments, evaluate feedback and make a recommendation for a mandatory
option.


On Fri, Jul 27, 2012 at 1:41 PM, Breno de Medeiros <breno at google.com> wrote:

> 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
>



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


More information about the Openid-specs-ab mailing list