Subject: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 08 Jul 2014 14:08:59 +0200

Hi all,

in my earlier review I had noted that the semantic of the fields is
underspecified, i.e., it is not clear what these fields are used for.

In private conversations I was told that an informal reference to a
potential use case will be added. I don't see such reference with
version -18.

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Tue, 8 Jul 2014 19:04:36 +0000

Was there specific language that had been discussed to be added for this?  If not, could someone please create some?

				Thanks,
				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Tuesday, July 08, 2014 5:09 AM
To: [email-masked]
Subject: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri

Hi all,

in my earlier review I had noted that the semantic of the fields is underspecified, i.e., it is not clear what these fields are used for.

In private conversations I was told that an informal reference to a potential use case will be added. I don't see such reference with version -18.

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Tue, 8 Jul 2014 15:33:29 -0400

In Connect these public keys are used to:
1 verify the signature of request objects (Signed Requests), something not in OAuth yet, and part of what the description calls higher level protocols.
2 encrypt the responses from the user_info endpoint or id_token (also not part of OAuth directly at this point)

3 validate requests to the token endpoint authenticated by the JWT assertion profile I think this is legitimate OAuth use.

Whew for the PoP specs:
4 used to encrypt the symmetric proof key in a JWK sent  to the client http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01#page-7 
5 used to provide a PoP key for the client to the AS as part of registration rather than passing the JWK on each request to the token endpoint.

So the keys in the JWK can be used a number of ways by the AS.

I think we could reference 3 and 4 as examples to be safe.

John B.

On Jul 8, 2014, at 3:04 PM, Mike Jones <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Tue, 8 Jul 2014 12:43:27 -0700

+1 to John's #3. The others could maybe be described in somewhat
abstract terms as examples of those "higher level protocols that use
signing or encryption."

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2014 11:42:10 +0200

What about the following text:

jwks_uri

  .... <previous text in Section 2 of
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18> .....

"The public key(s) referenced by jwks_uri (or contained in the jwks) can
be used in a variety of use cases. For example, the AS can use the
indicated public key to verify a request to the token endpoint that
utilizes the JWT assertion profile as described in Section 4.2 of
[I-D.ietf-oauth-assertions]. Another use case is for the AS to use the
public key of a client to encrypt a symmetric proof-of-possession key
sent to the client, as described in Section 4.2 of
[I-D.bradley-oauth-pop-key-distribution]."

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Mon, 14 Jul 2014 16:16:47 +0000

I'd rather that we stayed with working group drafts in the examples.  So I would counter-propose the following text:

"The public key(s) referenced by "jwks_uri" (or contained in the "jwks") can be used in a variety of use cases. For example, the signature of a JWT [I-D.ietf-json-web-token] signed by the client can be verified by the authorization server using these keys.  Another example is that the authorization server can use the indicated public keys to verify a request to the token endpoint that utilizes the JWT assertion profile as described in Section 4.2 of [I-D.ietf-oauth-assertions]."

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, July 14, 2014 2:42 AM
To: Brian Campbell; John Bradley
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri

jwks_uri

"The public key(s) referenced by jwks_uri (or contained in the jwks) can be used in a variety of use cases. For example, the AS can use the indicated public key to verify a request to the token endpoint that utilizes the JWT assertion profile as described in Section 4.2 of [I-D.ietf-oauth-assertions]. Another use case is for the AS to use the public key of a client to encrypt a symmetric proof-of-possession key sent to the client, as described in Section 4.2 of [I-D.bradley-oauth-pop-key-distribution]."

Ciao
Hannes

On 07/08/2014 09:43 PM, Brian Campbell wrote:
>> 2 encrypt the responses from the user_info endpoint or id_token (also 
>> not part of OAuth directly at this point)
>>
>> 4 used to encrypt the symmetric proof key in a JWK sent  to the 
>> client 
>> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-0
>> 1#page-7

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2014 19:45:05 +0200

Hi Mike,

sticking with working group document is fine.

However, the first example does not make sense to me.
[maybe my brain is a bit empty at the moment]

When is a JWT signed by the client and then sent to the Authorization
Server other than in the Assertion draft that I mention in the second
example?

Ciao
Hannes

On 07/14/2014 06:16 PM, Mike Jones wrote:
> I'd rather that we stayed with working group drafts in the examples.
> So I would counter-propose the following text:
> 
> "The public key(s) referenced by "jwks_uri" (or contained in the
> "jwks") can be used in a variety of use cases. For example, the
> signature of a JWT [I-D.ietf-json-web-token] signed by the client can
> be verified by the authorization server using these keys.  Another
> example is that the authorization server can use the indicated public
> keys to verify a request to the token endpoint that utilizes the JWT
> assertion profile as described in Section 4.2 of
> [I-D.ietf-oauth-assertions]."
> 
> -- Mike
> 
> -----Original Message----- From: OAuth
> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig Sent:
> Monday, July 14, 2014 2:42 AM To: Brian Campbell; John Bradley Cc:
> [email-masked] Subject: Re: [OAUTH-WG] Dynamic Client Registration:
> jwks / jwks_uri
> 
> "The public key(s) referenced by jwks_uri (or contained in the jwks)
> can be used in a variety of use cases. For example, the AS can use
> the indicated public key to verify a request to the token endpoint
> that utilizes the JWT assertion profile as described in Section 4.2
> of [I-D.ietf-oauth-assertions]. Another use case is for the AS to use
> the public key of a client to encrypt a symmetric proof-of-possession
> key sent to the client, as described in Section 4.2 of
> Ciao Hannes
>> abstract terms as examples of those "higher level protocols that
>> use signing or encryption."
>> 
>>> In Connect these public keys are used to: 1 verify the signature
>>> of request objects (Signed Requests), something not in OAuth yet,
>>> and part of what the description calls higher level protocols. 2
>>> encrypt the responses from the user_info endpoint or id_token
>>> (also not part of OAuth directly at this point)
>>> 
>>> 3 validate requests to the token endpoint authenticated by the
>>> JWT assertion profile I think this is legitimate OAuth use.
>>> 
>>> Whew for the PoP specs: 4 used to encrypt the symmetric proof key
>>> in a JWK sent  to the client 
1#page-7
>>> 5 used to provide a PoP key for the client to the AS as part of
>>> registration rather than passing the JWK on each request to the
>>> token endpoint.
>>> 
>>>> Was there specific language that had been discussed to be added
>>>> for this?  If not, could someone please create some?
>>>> 
>>>> Thanks, -- Mike
>>>> 
>>>> -----Original Message----- From: OAuth
>>>> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig 
>>>> Sent: Tuesday, July 08, 2014 5:09 AM To: [email-masked] 
>>>> in my earlier review I had noted that the semantic of the
>>>> fields is underspecified, i.e., it is not clear what these
>>>> fields are used for.
>>>> 
>>>> In private conversations I was told that an informal reference
>>>> to a potential use case will be added. I don't see such
>>>> reference with version -18.
>>>> 
>>>> Ciao Hannes
>>>> 
>>>> _______________________________________________ OAuth mailing
>>>> list [email-masked] 
>>> _______________________________________________ OAuth mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________ OAuth mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/oauth
>> 
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 14 Jul 2014 17:55:46 +0000

One example is when used as a signed request to the authorization server, as is done in http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05.

				-- Mike

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Monday, July 14, 2014 10:45 AM
To: Mike Jones; Brian Campbell; John Bradley
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri

Hi Mike,

When is a JWT signed by the client and then sent to the Authorization Server other than in the Assertion draft that I mention in the second example?

Ciao
Hannes

On 07/14/2014 06:16 PM, Mike Jones wrote:
> -----Original Message----- From: OAuth [mailto:[email-masked]] 
> On Behalf Of Hannes Tschofenig Sent:
> can be used in a variety of use cases. For example, the AS can use the 
>>> In Connect these public keys are used to: 1 verify the signature of 
>>> request objects (Signed Requests), something not in OAuth yet, and 
>>> part of what the description calls higher level protocols. 2 encrypt 
>>> the responses from the user_info endpoint or id_token (also not part 
>>> of OAuth directly at this point)
>>> 
>>> 3 validate requests to the token endpoint authenticated by the JWT 
>>> assertion profile I think this is legitimate OAuth use.
>>> 
>>> Whew for the PoP specs: 4 used to encrypt the symmetric proof key in 
>>> a JWK sent  to the client
1#page-7
>>>> Was there specific language that had been discussed to be added for 
>>>> this?  If not, could someone please create some?
>>>> 
>>>> Thanks, -- Mike
>>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2014 19:57:28 +0200

That would then be a reference to an individual draft ;-)

---

From: Mike Jones <[email-masked]>
Date: Mon, 14 Jul 2014 17:59:01 +0000

I'm not suggesting that we reference it.  We reference JWT using the language I already provided.  I was just giving you another example of a signed JWT sent to the authorization server, since you couldn't think of any off the top of your head.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Jul 2014 20:36:43 +0200

Hi Mike,

there is no problem referencing an individual draft particularly when
that reference gives some hint about how the stuff is used (particularly
when the referenced document might be a working group draft at the time
when the dynamic client registration document gets published as an RFC).

In this specific case I haven't even thought about that
draft-sakimura-oauth-requrl-05...

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Mon, 14 Jul 2014 16:26:44 -0400

If we can reference individual drafts then https://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution/  is an example of encryption to the client by the AS in sec 4.2.

If we want to reference an encryption example.  I think signing is covered by the assertion reference.

John B.