[Openid-specs-ab] jku and x5u

Wed Apr 3 17:03:01 UTC 2013

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.   

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

-------------- 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/543d5b49/attachment.p7s>