[Openid-specs-ab] jku and x5u

Tim Bray tbray at textuality.com
Wed Apr 3 16:58:04 UTC 2013


Well, you’re discussing OAuth 2.0 in the general case, and what’s
motivating me is something much simpler:  ID Tokens are useful, but
they need to be validated, so what is a reliable, deterministic
procedure for validating them?

>From where I sit, we’re assuming the use of TLS, so integrity
protection is the key thing.  So all I’m really looking for is the
recipe for retrieving the OP’s certs so I can do validation.  There’s
one that’s very clear, via ${issuer}/.well-known/openid-configuration.
 Are there others? -T

On Wed, Apr 3, 2013 at 6:45 AM, Hannes Tschofenig
<hannes.tschofenig at gmx.net> wrote:
> Hi Tim,
>
> It is good that you raised this issue. We need to have a shared
> understanding of how these things work since otherwise me might leave some
> loose ends in our specs (as we had done in the past already).
>
> Just to make sure that we are on the same page. We are talking about the
> case where the authorization server creates the access token and the
> resource server verifies it.
>
> The access token is integrity protected (or experiences integrity and
> confidentiality protection). The keys used to apply that protection may be
> symmetric or asymmetric.
>
> For symmetric keys we are talking about the case of distributing a long term
> key between the authorization server and the resource server.
>
> For the asymmetric key case we have to differentiate between integrity
> protection and confidentiality protection:
>
>  a) For integrity-only protection: in this case the authorization server
> applies his private key to the access token to compute the digital
> signature. The resource server needs to obtain the public key of the
> authorization server to verify the digital signature.
>
>  b) For confidentiality protection: the authorization server needs to obtain
> the public key of the resource server when it creates the access token in
> order to encrypt it.
>
> Today, there is a very close relationship between the authorization server
> and the resource server. They may be located at different servers but they
> are within the same organization. Hence, the problem to distribute the keys
> isn't particularly difficult.
>
> In the future these two parties may be looser connected, but still belong to
> the same trust framework. There may be a story on how to distribute keys
> within that specific community (as part of the trust framework).
>
> Or: Are you considering the case where the authorization server interacts
> with an unknown, completely random party on the Internet?
> This sounds like the UMA case to me, right?
>
> Does this make any sense or have I had too much coffee today?
>
> Ciao
> Hannes
>
> PS: Some of that stuff should actually be captured in the OAuth security
> work, such as in
> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/
>
>
>
>
> On 04/03/2013 11: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
>>
>> <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?
>>
>> -T
>>
>> 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.
>>
>> 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>
>>
>>     <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.)____
>>
>>          __ __
>>
>>
>> --
>>          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>>
>>          [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>
>>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>


More information about the Openid-specs-ab mailing list