[Openid-specs-ab] jku and x5u
Breno de Medeiros
breno at google.com
Wed Apr 3 17:06:03 UTC 2013
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
More information about the Openid-specs-ab
mailing list