[Openid-specs-ab] jku and x5u

[Breno de Medeiros]

On Tue, Apr 2, 2013 at 4:22 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> 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.

I am absolutely sure we need to 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
>



--
--Breno