Subject: Re: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?

From: Mike Jones <[email-masked]>
Date: Wed, 23 Apr 2014 16:42:00 +0000

The assertions draft is only trying to describe how to perform assertion-based authentication at the Token Endpoint.  Other drafts, such as the introspection draft, could explicitly say that this can also be done in the same manner there, but that's an extension, and should be specified by the extension draft, if appropriate - not in the assertions draft.

Justin may have more to say about the applicability or lack of it to the introspection draft, but I'm personally not familiar with it.

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, April 23, 2014 5:09 AM
To: [email-masked]
Subject: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?

Hi all,

in a discussion about re-using the client authentication part of the assertion framework for other specifications currently in progress I ran into the following question:

Section 6.1 of
http://tools.ietf.org/html/draft-ietf-oauth-assertions-15 talks about the client using the assertion with the **token endpoint**.

Now, it appears that one cannot use the client authentication with other endpoints, such as the introspection endpoint defined in
http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2

Am I reading too much into Section 6.1 of the assertion draft?

Ciao
Hannes

---

From: Justin Richer <[email-masked]>
Date: Wed, 23 Apr 2014 12:49:50 -0400

For introspection, we really just wanted to say "you can authenticate 
the caller (client or RP) just like you would to the token endpoint". So 
if you've got the means to do that with the assertion draft or with 
client secrets or TLS certs or anything else, go for it. I would not 
read the text of the assertions draft as restricting this other use case.

  -- Justin

On 04/23/2014 12:42 PM, Mike Jones wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Wed, 23 Apr 2014 16:58:24 -0600

Just to pile on here - the Assertions draft(s) do define client assertion
authentication only for the token endpoint (and register token endpoint
parameters). But it certainly doesn't preclude it from being profiled for
use elsewhere.

FWIW we used the token endpoint in our implementation of token
introspection/validation partly because all supported forms of client
authentication come along for free by doing so. My esteemed colleague, Dr.
Paul Madsen, posted a rough draft of what we've implemented in product a
while back: http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html

On Wed, Apr 23, 2014 at 10:49 AM, Justin Richer <[email-masked]> wrote:

> For introspection, we really just wanted to say "you can authenticate the
> caller (client or RP) just like you would to the token endpoint". So if
> you've got the means to do that with the assertion draft or with client
> secrets or TLS certs or anything else, go for it. I would not read the text
> of the assertions draft as restricting this other use case.
>
>  -- Justin
>
>
>> The assertions draft is only trying to describe how to perform
>> assertion-based authentication at the Token Endpoint.  Other drafts, such
>> as the introspection draft, could explicitly say that this can also be done
>> in the same manner there, but that's an extension, and should be specified
>> by the extension draft, if appropriate - not in the assertions draft.
>>
>> Justin may have more to say about the applicability or lack of it to the
>> introspection draft, but I'm personally not familiar with it.
>>
>>                                 -- Mike
>>
>> in a discussion about re-using the client authentication part of the
>> assertion framework for other specifications currently in progress I ran
>> into the following question:
>>
>> Section 6.1 of
>> http://tools.ietf.org/html/draft-ietf-oauth-assertions-15 talks about
>> the client using the assertion with the **token endpoint**.
>>
>> Now, it appears that one cannot use the client authentication with other
>> endpoints, such as the introspection endpoint defined in

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Apr 2014 11:01:12 +0200

I believe that Mike is right that we might need to describe these
aspects in the token introspection document.

Ensure proper authentication of the resource server to the authorization
server is extremely important for the security (particularly in context
of the PoP work we are doing right now). If everyone is able to retrieve
the session key for the respective PoP-enable access token then the
additional security value goes to null.

Ciao
Hannes

On 04/23/2014 06:49 PM, Justin Richer wrote:
>> assertion-based authentication at the Token Endpoint.  Other drafts,
>> such as the introspection draft, could explicitly say that this can
>> also be done in the same manner there, but that's an extension, and
>> should be specified by the extension draft, if appropriate - not in
>> the assertions draft.
>>
>> Justin may have more to say about the applicability or lack of it to
>> the introspection draft, but I'm personally not familiar with it.
>>
>>                 -- Mike
>>
>> assertion framework for other specifications currently in progress I
>> ran into the following question:
>>
>> Section 6.1 of
>> Now, it appears that one cannot use the client authentication with
>> other endpoints, such as the introspection endpoint defined in

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Apr 2014 11:09:06 +0200

Hi Brian,

does it sound reasonable for you to add text to the token introspection
endpoint regarding the use of the JWT bearer assertion for the token
introspection endpoint?

Ciao
Hannes

On 04/24/2014 12:58 AM, Brian Campbell wrote:
> Just to pile on here - the Assertions draft(s) do define client
> assertion authentication only for the token endpoint (and register token
> endpoint parameters). But it certainly doesn't preclude it from being
> profiled for use elsewhere.
> 
> authentication come along for free by doing so. My esteemed colleague,
> Dr. Paul Madsen, posted a rough draft of what we've implemented in
> product a while back:
> http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html
> 
> 
> On Wed, Apr 23, 2014 at 10:49 AM, Justin Richer <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     For introspection, we really just wanted to say "you can
>     authenticate the caller (client or RP) just like you would to the
>     token endpoint". So if you've got the means to do that with the
>     assertion draft or with client secrets or TLS certs or anything
>     else, go for it. I would not read the text of the assertions draft
>     as restricting this other use case.
> 
>      -- Justin
> 
> 
>         assertion-based authentication at the Token Endpoint.  Other
>         drafts, such as the introspection draft, could explicitly say
>         that this can also be done in the same manner there, but that's
>         an extension, and should be specified by the extension draft, if
>         appropriate - not in the assertions draft.
> 
>         Justin may have more to say about the applicability or lack of
>         it to the introspection draft, but I'm personally not familiar
>         with it.
> 
>                                         -- Mike
> 
>         From: OAuth [mailto:[email-masked]
>         <mailto:[email-masked]>__] On Behalf Of Hannes Tschofenig
>         To: [email-masked] <mailto:[email-masked]>
>         in a discussion about re-using the client authentication part of
>         the assertion framework for other specifications currently in
>         progress I ran into the following question:
> 
>         Section 6.1 of
>         http://tools.ietf.org/html/__draft-ietf-oauth-assertions-15
>         <http://tools.ietf.org/html/draft-ietf-oauth-assertions-15>
>         talks about the client using the assertion with the **token
>         endpoint**.
> 
>         Now, it appears that one cannot use the client authentication
>         with other endpoints, such as the introspection endpoint defined in
>         http://tools.ietf.org/html/__draft-richer-oauth-__introspection-04#section-2
>         <http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2>
> 
>         _________________________________________________
>         OAuth mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/oauth
>         <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
>     _________________________________________________
>     OAuth mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
> 
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 24 Apr 2014 06:44:30 -0600

Perhaps it'd be more appropriate for this introspection endpoint to say
that it accepts the same client authentication mechanisms as the token
endpoint rather than describing specific methods itself in the document?

On Thu, Apr 24, 2014 at 3:09 AM, Hannes Tschofenig <
[email-masked]> wrote:

> >         <
> http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2>
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Apr 2014 14:50:01 +0200

I will leave it to Justin to come up with the right wording.

Ideally, we shouldn't have too many ways for the resource server to
authenticate to the authorization server to avoid interoperability
problems.

On 04/24/2014 02:44 PM, Brian Campbell wrote:
> On Thu, Apr 24, 2014 at 3:09 AM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Brian,
> 
>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     <mailto:[email-masked]>
>     >         <mailto:[email-masked]
>     <mailto:[email-masked]>>__] On Behalf Of Hannes Tschofenig
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 24 Apr 2014 09:56:04 -0400

This is the intent of my draft (and results of my implementation), and 
if the WG ever picks up token introspection as a work item then we can 
make sure it says that.

  -- Justin

On 04/24/2014 08:44 AM, Brian Campbell wrote:
> Perhaps it'd be more appropriate for this introspection endpoint to 
> say that it accepts the same client authentication mechanisms as the 
> token endpoint rather than describing specific methods itself in the 
> document?
>
>
>     > On Wed, Apr 23, 2014 at 10:49 AM, Justin Richer
>     <[email-masked] <mailto:[email-masked]>