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

[William Denniss <[e-mail]>]

On Fri, Jan 29, 2016 at 3:22 PM, Mike Jones <[e-mail]>
wrote:

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

We don't need to represent this property in the discovery metadata.

All non-confidential clients should be using PKCE (and in the draft native
apps best practice, we say it's a MUST
<https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-01#section-7.2>
if
you want to follow the BCP).  It's OK to send PKCE to a server that doesn't
support PKCE (assuming standards compliance, they won't error on unknown
params), and now we have a way that clients can discover PKCE support and
send it only those those ASes who disclose this.

If a server decides to fail all non-PKCE requests for non-confidential
clients (which is fine), indicating this in discovery actually doesn't add
a whole lot.  Because if the client knows about PKCE it should have been
sending it based on code_challenge_methods_supported anyway, and if it
doesn't know about PKCE then it will always fail, discovery or not.

The thing is, there is no reason for a public client to *not* send PKCE if
the server indicates PKCE support, but then marks it as optional through
this mechanism.  If the client knows PKCE it should just always send PKCE –
so knowing that the request would succeed even if it didn't doesn't add any
value, and may cause harm.



>
>
> *From:* OAuth [mailto:[e-mail]] *On Behalf Of *John Bradley
> *Sent:* Friday, January 29, 2016 6:11 AM
> *To:* Nat Sakimura <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [OAUTH-WG] OAuth Discovery metadata values added for
> revocation, introspection, and PKCE
>
>
>
> 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 <[e-mail]> wrote:
>
>
>
> 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 <[e-mail]>:
>
> 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)?
>
> On 28/01/16 19:27, Mike Jones wrote:
>
> 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:
>
>
>
> *       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> <https://twitter.com/selfissued>.
>
>
>
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --
>
> Vladimir Dzhuvinov
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>