[Openid-specs-ab] jku and x5u

Axel.Nennker at telekom.de Axel.Nennker at telekom.de
Wed Apr 3 08:54:31 UTC 2013

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.

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?


On Tue, Apr 2, 2013 at 11:48 AM, Hannes Tschofenig <hannes.tschofenig at gmx.net<mailto: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.


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>
<http://example.com>, I'm not going to believe anything in the JWT until
I've checked using example.com<http://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>
<mailto: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.)____

    __ __


    __ __

    *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>>
    [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<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>
    <mailto: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<mailto:Openid-specs-ab at lists.openid.net>

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

More information about the Openid-specs-ab mailing list