Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-token-exchange-14.txt> (OAuth 2.0 Token Exchange) to Proposed Standard

Hi Hans,

Yes, I suppose it's somewhat implicit (although the Terminology
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14#section-1.3>
section does say that the term "client" is used as defined by RFC 6749) but
the intent is that the client in a token exchange is an OAuth client and it
authenticates to the token endpoint via whatever token endpoint
authentication method it has configured/registered with the respective AS.
And that includes being a be a public/unauthenticated client that would
just send the client id.  Also it could be an unidentified/anonymous client
where no client id is sent at all. But whether or not to allow
unauthenticated or unidentified clients to make token exchange requests is
up to the AS, which might be configuration or deployment policy or might
even be coded into the AS.

I think the text from §2.1 copied below says that reasonably clearly.

   Client authentication to the authorization server is done using the
   normal mechanisms provided by OAuth 2.0.  Section 2.3.1
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14#section-2.3.1>
of The OAuth
   2.0 Authorization Framework [RFC6749
<https://tools.ietf.org/html/rfc6749>] defines password-based
   authentication of the client, however, client authentication is
   extensible and other mechanisms are possible.  For example,
[RFC7523 <https://tools.ietf.org/html/rfc7523>]
   defines client authentication using JSON Web Tokens (JWTs) [JWT
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14#ref-JWT>].
   The supported methods of client authentication and whether or not to
   allow unauthenticated or unidentified clients are deployment
   decisions that are at the discretion of the authorization server.

On Sun, Aug 26, 2018 at 9:00 AM Hans Zandbelt <hans.zandbelt@zmartzone.eu>
wrote:

> Hi all (and Brian :-)),
>
> Whilst implementing the client side of OAuth 2.0 Token Exchange into an
> Apache module I ran into some questions wrt. authentication to the token
> exchange endpoint as specified in section 2.1:
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14#section-2.1
>
> 1. the spec talks about "client" but it does not explicitly state that a
> token exchange client is in fact an OAuth 2.0 Client; IMHO this is done
> only implicitly since section 2.1 does refer to OAuth 2.0 client
> authentication methods (alternatively, if the spec editors believe that a
> token exchange client is different from a "classic" OAuth 2..0 Client, that
> should be made explicit)
> 2. the spec leaves it open as to whether the client is actually forced to
> authenticate (it is up to the authorization server's discretion); yet it is
> not clear - in that case - whether or not a client_id should be added to
> the token request (as in OAuth 2.0 token requests); alternatively one may
> argue that token exchange for public clients makes no sense - I think I
> favor that - because it makes it impossible to distinguish between the
> presenter of the original token and the token exchange client
>
> Any comments to that?
>
> Hans.
>
> On Mon, Jul 23, 2018 at 3:22 PM The IESG <iesg-secretary@ietf.org> wrote:
>
>>
>> The IESG has received a request from the Web Authorization Protocol WG
>> (oauth) to consider the following document: - 'OAuth 2.0 Token Exchange'
>>   <draft-ietf-oauth-token-exchange-14.txt> as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final
>> comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2018-08-06. Exceptionally, comments may be
>> sent to iesg@ietf.org instead. In either case, please retain the
>> beginning of
>> the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>    This specification defines a protocol for an HTTP- and JSON- based
>>    Security Token Service (STS) by defining how to request and obtain
>>    security tokens from OAuth 2.0 authorization servers, including
>>    security tokens employing impersonation and delegation.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> hans.zandbelt@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._