extension grants can allow unidentified clients

[bc-pi]

I apologize in advance for this one... I really do.

It has always been my reading that OAuth 2.0 allows for client identification/authentication to be omitted in extension grants (if the grant type defines it that way), basically allowing (subject to policy and the grant type definition) token endpoint calls without any client identification in certain extension grant types The text around this is admittedly somewhat ambiguous and hard to follow. And has some history to it. It could be argued that it's even open to different interpretations. But allowing for unidentified clients in extension grants was my reading and it has been codified in RFCs 7521, 7522 & 7523 for SAML and JWT assertion grants with text like this in the grant definition (and examples with no client_id or any client auth).

  Authentication of the client is optional, as described in
   Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the
   "client_id" is only needed when a form of client authentication that
   relies on the parameter is used.

This is some of the text from Section 3.2.1 that it refers to:

   A client MAY use the "client_id" request parameter to identify itself
   when sending requests to the token endpoint.  In the
   "authorization_code" "grant_type" request to the token endpoint, an
   unauthenticated client MUST send its "client_id" to prevent itself
   from inadvertently accepting a code intended for a client with a
   different "client_id".  This protects the client from substitution of
   the authentication code.  (It provides no additional security for the
   protected resource.)

refs:
https://www.rfc-editor.org/rfc/rfc7521#section-4.1
https://www.rfc-editor.org/rfc/rfc7522#section-2.1
https://www.rfc-editor.org/rfc/rfc7523#section-2.1
https://www.rfc-editor.org/rfc/rfc6749?#section-3.2.1
https://www.rfc-editor.org/rfc/rfc6749?#section-4.5

Also the pre-authorized_code grant being defined in OpenID for Verifiable Credential Issuance is another extension grant type that needs to allow for use by unidentified /anonymous clients. https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-11.html#name-token-request

I think the text for "client_id" in https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-08.html#section-3.2.2 precludes the above cases (because it is for all token endpoint requests in 2.1 but came from the code grant in 2.0 https://www.rfc-editor.org/rfc/rfc6749?#section-4.1.3 ).

It's ugly and hard to capture the subtly here but maybe something like this instead for client_id in the Token Request section of v2.1?:

  "client_id":    
    REQUIRED, if the client is not authenticating with the authorization server as described
     in Section 3.2.1. and the grant_type requires client identification.

or:

  "client_id":    
    REQUIRED, unless the client is authenticating with the authorization server as described
     in Section 3.2.1. or the grant_type allows for unidentified clients.

or maybe:

  "client_id":    
    OPTIONAL.  The client identifier is needed when a form of client authentication that
   relies on the parameter is used or the grant_type requires identification of public clients. 

or something better but in the spirt thereof.

Also maybe adding that "client_id": REQUIRED, if the client is not authenticating with the authorization server as described in Section 3.2.1. text to the authz code grant section https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-08.html#section-4.1.3 to be explicit like w/ v2.0 that client_id is needed in code grant for public clients.

[aaronpk]

Seems reasonable to me. We added it to the agenda for IETF 116.