[Openid-specs-ab] jku and x5u

John Bradley ve7jtb at ve7jtb.com
Wed Apr 3 17:22:50 UTC 2013


That is the only mechanism we have other than saying do it out of band somehow.

If Google doesn't publish a .well-known/openid-configuration then you could probably get people to manually enter it as you do now.

The only dynamic method we have is  .well-known/openid-configuration

(self issued is a special case because the assertion is self contained and there is no discovery)

John B.

On 2013-04-03, at 2:10 PM, Tim Bray <tbray at textuality.com> wrote:

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130403/00201086/attachment.p7s>


More information about the Openid-specs-ab mailing list