[Openid-specs-ab] jku and x5u

Tim Bray tbray at textuality.com
Wed Apr 3 17:10:44 UTC 2013


Well, and I deal with the reality of what real-world software
developers will do when we ask them to add OIDC support to Java and
Python and Ruby and PHP  and .NET web frameworks.  I can explain the
.well-known/openid-configuration=>JWK-url=> validate chain in about 3
minutes and everyone will say “yeah, I can do that” given a cert
parsing/validation library, which they have, and it’ll provide
everything you need to be an RP against mainstream IDPs and it’s
acceptably secure, assuming TLS throughout, which we do.

Once you get past that, there need to be way better arguments than
I’ve heard so far if we’re going to get any traction with these
people.

 -T

On Wed, Apr 3, 2013 at 10:06 AM, Breno de Medeiros <breno at google.com> wrote:
> On Wed, Apr 3, 2013 at 10:03 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> self issued is a special case where the public key is provided in the envelope directly and validated against the sig the sub is derived from the public key.
>>
>> I don't think that is a problem.
>>
>> For IdP that publish a discovery document that is authoritative that specifies the jku url not the JWT.
>>
>> For idp who can't publish a discovery document RP will need to manually configure out of band as they do now for facebook and others, or there needs to be a trusted source of meta-data for those small IdP.
>
> I disagree that the benefit of creating a complex and likely
> security-challenged discovery mechanism is worth the cost.
>
>>
>> John
>>
>> On 2013-04-03, at 1:58 PM, Breno de Medeiros <breno at google.com> wrote:
>>
>>> On Wed, Apr 3, 2013 at 9:56 AM, Breno de Medeiros <breno at google.com> wrote:
>>>> On Wed, Apr 3, 2013 at 1:54 AM,  <Axel.Nennker at telekom.de> wrote:
>>>>> Here are two use cases that would not work under the
>>>>> “${issuer}/.well-known/openid-configuration” assumption.
>>>>>
>>>>> 1)      The issuer has no control over the top level domain’s files
>>>>> e.g. you rented some hosting space at
>>>>> https://geocities.yahoo.co.jp/KafkaTamura and this is the iss. Kafka can not
>>>>> change the top level openid-configuration only
>>>>> https://geocities.yahoo.co.jp/KafkaTamura/.well-known/openid-configuration
>>>>>
>>>>> 2)      A self-issued OP on a phone
>>>>> The issuer could dynamically register its keys or provide the public key
>>>>> with the first token. The consumer would then ensure that the key is the
>>>>> same in subsequent tokens.
>>>>
>>>> I am not interested in supporting either of these cases if it comes at
>>>> the expense of generalized insecurity on the common case. If the spec
>>>> wants to support these cases, it needs to be very careful on how to
>>>> coach the language.
>>>
>>> And why can't _both_ of these cases be achieved though PKI-based means?
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: openid-specs-ab-bounces at lists.openid.net
>>>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Tim Bray
>>>>> Sent: Tuesday, April 02, 2013 11:55 PM
>>>>> To: Hannes Tschofenig
>>>>> Cc: <openid-specs-ab at lists.openid.net>
>>>>>
>>>>>
>>>>> Subject: Re: [Openid-specs-ab] jku and x5u
>>>>>
>>>>>
>>>>>
>>>>> From where I sit, the most obvious thing to do is look at the issuer claim,
>>>>> resolve ${issuer}/.well-known/openid-configuration, extract the jwk-url
>>>>> claim, fetch the jwk, and validate using that.  For the kind of
>>>>> consumer/internet stuff we do, wouldn't that nearly always be the right
>>>>> choice?
>>>>>
>>>>> -T
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 2, 2013 at 11:48 AM, Hannes Tschofenig
>>>>> <hannes.tschofenig at gmx.net> wrote:
>>>>>
>>>>> Hi Tim,
>>>>>
>>>>> There are three ways to shuffle keys around:
>>>>>
>>>>> * per value: you include the key in the message
>>>>> * per reference: you include a pointer to the key (e.g., a URL)
>>>>> * out-of-band: here you just give the key a name without telling where to
>>>>> find it.
>>>>>
>>>>> Needless to say that you have to be careful with all three mechanisms when
>>>>> it comes to security.
>>>>>
>>>>> You are already thinking about a complete use case that goes beyond what
>>>>> these header parameters by itself are able to answer.
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 04/02/2013 09:35 PM, Tim Bray wrote:
>>>>>
>>>>> Sorry, I’m probably failing to understand because I’m a crypto moron,
>>>>> but if I want to use keys to validate a JWT allegedly from example.com
>>>>>
>>>>> <http://example.com>, I’m not going to believe anything in the JWT until
>>>>> I’ve checked using example.com <http://example.com>’s keys, so why
>>>>>
>>>>>
>>>>> should I believe the JWT’s assertion about where to get the keys to
>>>>> validate it?  -T
>>>>>
>>>>>
>>>>> On Tue, Apr 2, 2013 at 11:27 AM, Mike Jones <Michael.Jones at microsoft.com
>>>>>
>>>>> <mailto:Michael.Jones at microsoft.com>> wrote:
>>>>>
>>>>>    Yes, that’s exactly it.  If you already know where the keys are or
>>>>>    what they are (for instance, if you’ve established that information
>>>>>    at registration time), there’s no need to use these parameters.  But
>>>>>    for some use cases, this is valuable information that can be
>>>>>    dynamically provided.  (The Key ID (“kid”) can also be dynamically
>>>>>
>>>>>    provided, if appropriate to the use case.)____
>>>>>
>>>>>    __ __
>>>>>
>>>>>                                                                     --
>>>>>    Mike____
>>>>>
>>>>>    __ __
>>>>>
>>>>>    *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:openid-specs-ab-bounces at lists.openid.net>] *On Behalf Of
>>>>>    *Tim Bray
>>>>>    *Sent:* Tuesday, April 02, 2013 11:19 AM
>>>>>    *To:* <openid-specs-ab at lists.openid.net
>>>>>    <mailto:openid-specs-ab at lists.openid.net>>
>>>>>    *Subject:* [Openid-specs-ab] jku and x5u____
>>>>>
>>>>>    __ __
>>>>>
>>>>>
>>>>>
>>>>>    Almost certainly I’m just missing something obvious, but I’m having
>>>>>    trouble understanding why the jku and x5u header claims exist.  The
>>>>>    idea is I get a message and believe the message’s assertion about
>>>>>
>>>>>    where I should go to get the cert to validate the message?  -T____
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>
>
>
> --
> --Breno
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab


More information about the Openid-specs-ab mailing list