[Openid-specs-ab] jku and x5u

John Bradley ve7jtb at ve7jtb.com
Tue Apr 2 23:22:19 UTC 2013


It is not safe for them to retrieve those objects unless they got them in the IdP discovery document or out of band(I think you intend to do that).

Connect is not supporting those elements in the JWS envelope.  I think we should say that.


On 2013-04-02, at 8:11 PM, Breno de Medeiros <breno at google.com> wrote:

> How we reconcile interoperability with security then? It's not safe
> for Connect clients to use jku or x5u.
> 
> On Tue, Apr 2, 2013 at 4:06 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> Yes for what we are doing. However JOSE needs to support more trust models
>> than Connect.
>> 
>> On 2013-04-02, at 6:54 PM, Tim Bray <tbray at textuality.com> wrote:
>> 
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
> 
> 
> 
> -- 
> --Breno

-------------- 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/20130402/b338d512/attachment.p7s>


More information about the Openid-specs-ab mailing list