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 <tors...@lodderstedt.net> > 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. > > 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 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. >>> >>> 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 >>>> <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>http://tools.ietf.org/html/draft-jones-oauth-discovery-01 >>>> <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>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>. >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
