Subject: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE

From: Mike Jones <[email-masked]>
Date: Thu, 28 Jan 2016 19:27:22 +0000

The OAuth Discovery specification has been updated to add metadata values for revocation<http://tools.ietf.org/html/rfc7009>, introspection<http://tools.ietf.org/html/rfc7662>, and PKCE<http://tools.ietf.org/html/rfc7636>.  Changes were:

*       Added "revocation_endpoint_auth_methods_supported" and "revocation_endpoint_auth_signing_alg_values_supported" for the revocation endpoint.

*       Added "introspection_endpoint_auth_methods_supported" and "introspection_endpoint_auth_signing_alg_values_supported" for the introspection endpoint.

*       Added "code_challenge_methods_supported" for PKCE.

The specification is available at:

*       http://tools.ietf.org/html/draft-jones-oauth-discovery-01

An HTML-formatted version is also available at:

*       http://self-issued.info/docs/draft-jones-oauth-discovery-01.html

                                                          -- Mike

P.S.  This note was also published at http://self-issued.info/?p=1531 and as @selfissued<https://twitter.com/selfissued>.

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 29 Jan 2016 04:55:22 +0000

Thanks!

2016年1月29日(金) 4:28 Mike Jones <[email-masked]>:

> The OAuth Discovery specification has been updated to add metadata values
> for revocation <http://tools.ietf.org/html/rfc7009>, introspection
> <http://tools.ietf.org/html/rfc7662>, and PKCE
> <http://tools.ietf.org/html/rfc7636>.  Changes were:
>
> ·       Added “revocation_endpoint_auth_methods_supported” and “
> revocation_endpoint_auth_signing_alg_values_supported” for the revocation
> endpoint.
>
> ·       Added “introspection_endpoint_auth_methods_supported” and “
> introspection_endpoint_auth_signing_alg_values_supported” for the
> introspection endpoint.
>
> ·       Added “code_challenge_methods_supported” for PKCE.
>
>
>
> ·       http://tools.ietf.org/html/draft-jones-oauth-discovery-01
>
>
>
> ·       http://self-issued.info/docs/draft-jones-oauth-discovery-01.html
>
>
>
>                                                           -- Mike
>
>
>
> P.S.  This note was also published at http://self-issued.info/?p=1531 and
> as @selfissued <https://twitter.com/selfissued>.
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 29 Jan 2016 12:23:38 +0000

Thanks Mike, the updated spec looks good!

I have a question related to PKCE:

The PKCE spec seems to imply that an AS may require public clients to
use a code challenge:

https://tools.ietf.org/html/rfc7636#section-4.4.1

If an AS has such a policy in place, how is this to be advertised? Or is
that supposed to the enforced when the client gets registered (there are
no reg params for that at present)?

-- 
Vladimir Dzhuvinov

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 29 Jan 2016 13:15:47 +0000

Good question.

It's probably a good idea to be able to advertise this policy in the
discovery.

Perhaps in the line of

pkce_required or rfc7636_required?
The value should be Boolean.

Nat from iPhone

2016年1月29日(金) 21:23 Vladimir Dzhuvinov <[email-masked]>:

> The PKCE spec seems to imply that an AS may require public clients to use
> a code challenge:
>
> that supposed to the enforced when the client gets registered (there are no
> reg params for that at present)?
>
>
> The OAuth Discovery specification has been updated to add metadata values for revocation<http://tools.ietf.org/html/rfc7009> <http://tools.ietf.org/html/rfc7009>, introspection<http://tools.ietf.org/html/rfc7662> <http://tools.ietf.org/html/rfc7662>, and PKCE<http://tools.ietf.org/html/rfc7636> <http://tools.ietf.org/html/rfc7636>.  Changes were:
>
> P.S.  This note was also published at http://self-issued.info/?p=1531 and as @selfissued<https://twitter.com/selfissued> <https://twitter.com/selfissued>.
>
>
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Vladimir Dzhuvinov
>

---

From: John Bradley <[email-masked]>
Date: Fri, 29 Jan 2016 11:11:16 -0300

The only problem with that is the client may only require it for some types of clients (public) or response types.

It may need to be finer grained than that, or define it as required for all public clients using the token endpoint.

John B.

> On Jan 29, 2016, at 10:15 AM, Nat Sakimura <[email-masked]> wrote:
> 
> Good question. 
> 
> It's probably a good idea to be able to advertise this policy in the discovery. 
> 
> Perhaps in the line of 
> 
> 2016年1月29日(金) 21:23 Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>>:
> The PKCE spec seems to imply that an AS may require public clients to use a code challenge:
> 
> https://tools.ietf.org/html/rfc7636#section-4.4.1 <https://tools.ietf.org/html/rfc7636#section-4.4.1>
> 
> If an AS has such a policy in place, how is this to be advertised? Or is that supposed to the enforced when the client gets registered (there are no reg params for that at present)?
> 
> 
>> *       http://tools.ietf.org/html/draft-jones-oauth-discovery-01 <http://tools.ietf.org/html/draft-jones-oauth-discovery-01>
>> 
>> *       http://self-issued.info/docs/draft-jones-oauth-discovery-01.html <http://self-issued.info/docs/draft-jones-oauth-discovery-01.html>
>> 
>>                                                           -- Mike
>> 
>> P.S.  This note was also published at http://self-issued.info/?p=1531 <http://self-issued.info/?p=1531> and as @selfissued<https://twitter.com/selfissued> <https://twitter.com/selfissued>.
>> 
>> 
> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> -- 
> Vladimir Dzhuvinov
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: William Denniss <[email-masked]>
Date: Fri, 29 Jan 2016 09:54:24 -0800

Thanks for the update Mike.

---

From: Mike Jones <[email-masked]>
Date: Fri, 29 Jan 2016 23:22:21 +0000

Do the PKCE authors want to make a concrete proposal for how to represent this in discovery metadata?

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Friday, January 29, 2016 6:11 AM
To: Nat Sakimura <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE

John B.

On Jan 29, 2016, at 10:15 AM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

Good question.

Perhaps in the line of

Nat from iPhone

2016年1月29日(金) 21:23 Vladimir Dzhuvinov <[email-masked]<mailto:[email-masked]>>:
Thanks Mike, the updated spec looks good!

The OAuth Discovery specification has been updated to add metadata values for revocation<http://tools.ietf.org/html/rfc7009><http://tools.ietf.org/html/rfc7009>, introspection<http://tools.ietf.org/html/rfc7662><http://tools.ietf.org/html/rfc7662>, and PKCE<http://tools.ietf.org/html/rfc7636><http://tools.ietf.org/html/rfc7636>.  Changes were:

                                                          -- Mike

P.S.  This note was also published at http://self-issued.info/?p=1531 and as @selfissued<https://twitter.com/selfissued><https://twitter.com/selfissued>.

OAuth mailing list

[email-masked]<mailto:[email-masked]>

--

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 31 Jan 2016 13:13:38 +0100

Hi Mike,

the current revocation RFC does not support request signing. So what is 
the intention of revocation_endpoint_auth_signing_alg_values_supported?

best regards,
Torsten.

Am 28.01.2016 um 20:27 schrieb Mike Jones:
>
> The OAuth Discovery specification has been updated to add metadata 
> values for revocation <http://tools.ietf.org/html/rfc7009>, 
> introspection <http://tools.ietf.org/html/rfc7662>, and PKCE 
> ·Added “revocation_endpoint_auth_methods_supported” and 
> “revocation_endpoint_auth_signing_alg_values_supported” for the 
> revocation endpoint.
>
> ·Added “introspection_endpoint_auth_methods_supported” and 
> “introspection_endpoint_auth_signing_alg_values_supported” for the 
> introspection endpoint.
>
> ·Added “code_challenge_methods_supported” for PKCE.
>
> ·http://tools.ietf.org/html/draft-jones-oauth-discovery-01
>
> ·http://self-issued.info/docs/draft-jones-oauth-discovery-01.html
>
> -- Mike
>
> P.S.  This note was also published at http://self-issued.info/?p=1531 
> <http://self-issued.info/?p=1531> and as @selfissued 
> <https://twitter.com/selfissued>.
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Sun, 31 Jan 2016 08:47:07 -0500

It would be for client authentication to the revocation endpoint, if the 
client were to use client_secret_jwt or private_key_jwt methods to 
authenticate. Our implementation actually allows this, but we don't let 
clients choose more than one authentication method across three 
endpoints (token, revocation, and introspection).

A value we might want to add for revocation and introspection is 
"bearer_token", since it makes sense in both cases to give a client an 
access token to call these endpoints as opposed to credentials. This 
would need to be added to the token endpoint authentication methods 
registry.

  -- Justin

On 1/31/2016 7:13 AM, Torsten Lodderstedt wrote:
> Hi Mike,
>
> the current revocation RFC does not support request signing. So what 
> is the intention of revocation_endpoint_auth_signing_alg_values_supported?
>
> best regards,
> Torsten.
>
>> P.S.  This note was also published at 
>> <http://self-issued.info/?p=1531>http://self-issued.info/?p=1531 and

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 31 Jan 2016 17:21:51 +0100

sounds reasonable - but is not covered by the current RFC, which would 
be the pre-requisite for interop. That's what I wanted to point out.

kind regards,
Torsten.

Am 31.01.2016 um 14:47 schrieb Justin Richer:
> It would be for client authentication to the revocation endpoint, if 
> the client were to use client_secret_jwt or private_key_jwt methods to 
> authenticate. Our implementation actually allows this, but we don't 
> let clients choose more than one authentication method across three 
>> is the intention of 
>> revocation_endpoint_auth_signing_alg_values_supported?
>>
>> best regards,
>> Torsten.
>>

---

From: Justin Richer <[email-masked]>
Date: Sun, 31 Jan 2016 13:51:20 -0500

Both RFC7009 and RFC7662 just say that the client/protected resource authenticate just like they would at the token endpoint, punting to RFC6749 on how that happens. Since that’s extensible, and has been extended, that’s what we’re going on.

It’s an unfortunate case where the actual definition is now spread across several documents over time. I’d honestly feel bad for someone writing an OAuth2 server from scratch without a guide.

 — Justin

> On Jan 31, 2016, at 11:21 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> sounds reasonable - but is not covered by the current RFC, which would be the pre-requisite for interop. That's what I wanted to point out. 
> 
> kind regards,
> Torsten.
> 
>> It would be for client authentication to the revocation endpoint, if the client were to use client_secret_jwt or private_key_jwt methods to authenticate. Our implementation actually allows this, but we don't let clients choose more than one authentication method across three endpoints (token, revocation, and introspection). 
>> 
>> A value we might want to add for revocation and introspection is "bearer_token", since it makes sense in both cases to give a client an access token to call these endpoints as opposed to credentials. This would need to be added to the token endpoint authentication methods registry.
>> 
>>  -- Justin
>> 
>>> the current revocation RFC does not support request signing. So what is the intention of revocation_endpoint_auth_signing_alg_values_supported?
>>> 
>>> best regards,
>>> Torsten.
>>> 
>>>> The OAuth Discovery specification has been updated to add metadata values for revocation <http://tools.ietf.org/html/rfc7009>, introspection <http://tools.ietf.org/html/rfc7662>, and PKCE <http://tools.ietf.org/html/rfc7636>.  Changes were:
>>>> ·       Added “revocation_endpoint_auth_methods_supported” and “revocation_endpoint_auth_signing_alg_values_supported” for the revocation endpoint.
>>>> ·       Added “introspection_endpoint_auth_methods_supported” and “introspection_endpoint_auth_signing_alg_values_supported” for the introspection endpoint.
>>>> ·        <http://tools.ietf.org/html/draft-jones-oauth-discovery-01>http://tools.ietf.org/html/draft-jones-oauth-discovery-01 <http://tools.ietf.org/html/draft-jones-oauth-discovery-01>
>>>>  
>>>> ·        <http://self-issued.info/docs/draft-jones-oauth-discovery-01.html>http://self-issued.info/docs/draft-jones-oauth-discovery-01.html <http://self-issued.info/docs/draft-jones-oauth-discovery-01.html>
>>>>  
>>>>                                                           -- Mike
>>>>  
>>>> P.S.  This note was also published at  <http://self-issued.info/?p=1531> <http://self-issued.info/?p=1531>http://self-issued.info/?p=1531 <http://self-issued.info/?p=1531> and as @selfissued <https://twitter.com/selfissued>.
>>>>  
>>>> 
>>>>