Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663)

2021-08-23 Thread Justin Richer
I personally don’t agree with this errata. Token Revocation was never meant to 
act as a protected resource, but rather as a function of the AS. The client is 
known to the AS and so authentication is expected here.

 — Justin

> On Aug 22, 2021, at 5:14 AM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC7009,
> "OAuth 2.0 Token Revocation".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6663
> 
> --
> Type: Technical
> Reported by: Ashvin Narayanan 
> 
> Section: 2.1
> 
> Original Text
> -
> The client constructs the request by including the following
>   parameters using the "application/x-www-form-urlencoded" format in
>   the HTTP request entity-body:
> 
>   token   REQUIRED.  The token that the client wants to get revoked.
> 
>   token_type_hint  OPTIONAL.  A hint about the type of the token
>   submitted for revocation.  Clients MAY pass this parameter in
>   order to help the authorization server to optimize the token
>   lookup.  If the server is unable to locate the token using
>   the given hint, it MUST extend its search across all of its
>   supported token types.  An authorization server MAY ignore
>   this parameter, particularly if it is able to detect the
>   token type automatically.  This specification defines two
>   such values:
> 
>   * access_token: An access token as defined in [RFC6749],
> Section 1.4
> 
>   * refresh_token: A refresh token as defined in [RFC6749],
> Section 1.5
> 
>   Specific implementations, profiles, and extensions of this
>   specification MAY define other values for this parameter
>   using the registry defined in Section 4.1.2.
> 
>   The client also includes its authentication credentials as described
>   in Section 2.3. of [RFC6749].
> 
>   For example, a client may request the revocation of a refresh token
>   with the following request:
> 
> POST /revoke HTTP/1.1
> Host: server.example.com
> Content-Type: application/x-www-form-urlencoded
> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
> 
> token=45ghiukldjahdnhzdauz_type_hint=refresh_token
> 
>   The authorization server first validates the client credentials (in
>   case of a confidential client) and then verifies whether the token
>   was issued to the client making the revocation request.  If this
>   validation fails, the request is refused and the client is informed
>   of the error by the authorization server as described below.
> 
> Corrected Text
> --
> The client calls the revocation endpoint using an HTTP
>   POST [RFC7231] request with the following parameters sent as
>   "application/x-www-form-urlencoded" data in the request body:
> 
>   token   REQUIRED.  The token that the client wants to get revoked.
> 
>   token_type_hint  OPTIONAL.  A hint about the type of the token
>   submitted for revocation.  Clients MAY pass this parameter in
>   order to help the authorization server to optimize the token
>   lookup.  If the server is unable to locate the token using
>   the given hint, it MUST extend its search across all of its
>   supported token types.  An authorization server MAY ignore
>   this parameter, particularly if it is able to detect the
>   token type automatically.  This specification defines two
>   such values:
> 
>   * access_token: An access token as defined in [RFC6749],
> Section 1.4
> 
>   * refresh_token: A refresh token as defined in [RFC6749],
> Section 1.5
> 
>   Specific implementations, profiles, and extensions of this
>   specification MAY define other values for this parameter
>   using the registry defined in Section 4.1.2.
> 
>   The client MUST also include in the request, the access token it received 
>   from the authorization server. It must do so in the same way as it  would  
>   when accessing a protected resource, as describe in [RFC6749], Section 7.
> 
>   The following is a non-normative example request in which the client uses 
>   its access token to revoke the associated refresh token:
> 
> POST /revoke HTTP/1.1
> Host: server.example.com
> Content-Type: application/x-www-form-urlencoded
> Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW
> 
> token=45ghiukldjahdnhzdauz_type_hint=refresh_token
> 
>   The following is a non-normative example request in which the client uses 
>   its access token to revoke the same access token:
> 
> POST /revoke HTTP/1.1
> Host: server.example.com
> Content-Type: application/x-www-form-urlencoded
> Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW
> 
> token=czZCaGRSa3F0MzpnWDFmQmF0M2JW_type_hint=access_token
> 
>   The 

[OAUTH-WG] Invitation: OAuth Security Workshop 2021

2021-08-23 Thread Daniel Fett
Hi all,

I would like to invite you to the OAuth Security Workshop 2021, a
fully-virtual, two-day event on

 *November 30 and December 1, 2021 (UTC).*

The OAuth Security Workshop (OSW) aims to improve the security of OAuth,
OpenID Connect, GNAP and related Internet protocols by facilitating
direct exchange among academic researchers, standardization group
members and industry experts.

For this edition of the OSW, we use a simplified submission process:
Session proposals will be collected online before the event. The
schedule will be assembled by the organziation committee from these
session proposals.

Please submit a session proposal if

 * you want to give a talk or tutorial,
 * you are interested in convening a working session on a topic,
 * or if you want to discuss a topic or question, whether you are an
expert in that topic or not.

Every participant can propose and conduct a session. We explicitly
invite newcomers to submit a session proposal.

OSW welcomes all topics that roughly fit into the areas OAuth, OpenID
Connect, and GNAP, be it from a standardization, application, or
research perspective.

Thanks to our sponsor yes.com, the event will be free of charge. A prior
registration is required.

Please find more information at https://oauth.secworkshop.events.

-Daniel
m...@danielfett.de


-- 
https://danielfett.de

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth