Describe or give examples of what kinds of tokens a client would exchange

[aaronpk]

Currently the text says "its token" without giving any guidance on where this token came from or what kind of token it is. (ID token? access token? refresh token?) While not being prescriptive about the type of token is useful to enable more use cases, there should at least be some clues about how this token was obtained in the first place.

[arndt-s]

I agree that the text is not clear here.

A few questions arise to me when thinking about it:

• Does it make sense to limit the subject_token to access tokens? Are there reasons to allow id or refresh tokens?
• Should we further specify the other parameters, in particular "actor_token" and "actor_token_type"? Allowing everyone to exchange access_tokens to an authorization_grant of another domain can be critical and I believe the spec would benefit of making the actor parameters required in this case.

[PieterKas]

@aaronpk and @bc-pi would there ever be a use case for using the refresh token?

I think this is either the access or the ID token (what would be the use case for ID Tokens in this case and would it be an abuse of the ID Token if we allowed it)?

The other thing to clarify is whether this is the subject or actor token in the token exchange protocol. The subject token (per RFC rfc8693) is mandatory, but the way this is written suggest that it is the client's token ("It's token"), which raises the question if this is the actor token and if we need to make the actor token mandatory.

If the client is running without user interaction (batch job), it would need to submit the same token for both the subject token and the actor token.

[bc-pi]

I don't think we should be prescriptive or restrictive about the kinds token(s) a client would exchange. Rather maybe just provide a bit more context and explanation about some of the situations and how the client might have come by the "initial" token(s).

[aaronpk]

My use case involves ID tokens and SAML assertions. I can easily imagine a use case for refresh tokens (basically any time you would exchange an access token but the access token might be expired, e.g. long running tasks, etc). I don't think this spec should add any restrictions on token types, since the Token Exchange spec already provides the flexibility needed. My original comment was more that a reader would have no context for how an initial token would be obtained by reading the current text. (Also "its token" is slightly misleading because it might be a delegated token in which case who does the token actually belong to? the client or the user?)

[PieterKas]

I agree we don't need to be more prescriptive here and leave it to profiles to be specific about how certain tokens are handled. I suggest we close this issue. @aaronpk do you agree?

[aaronpk]

I agree with Brian's comment earlier. We don't need to be prescriptive, but my initial comment was that there is no context for what the text is describing at that point in the document. Also I'd like to reiterate my comment above that "its token" isn't even accurate since the token doesn't necessarily belong to the client using it at this stage.

[PieterKas]

@aaronpk - I proposed some text - take a look and see if helps. If not, please suggest alternative text.