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-secret...@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 > i...@ietf.org mailing lists by 2018-08-06. Exceptionally, comments may be > sent to i...@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.zandb...@zmartzone.eu ZmartZone IAM - www.zmartzone.eu
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
