+1 to the proposed wording change. It's clear and allows for use cases
where your inputs aren't as replayable as you might otherwise expect.
-- Justin
On 7/5/2016 2:15 PM, Brian Campbell wrote:
I gave a short presentation about OAuth 2.0 Token Exchange
<http://www.slideshare.net/briandavidcampbell/oauth-20-token-exchange-an-sts-for-the-rest-of-us>
at a recent identity conference, which seemed well received and a lot
of folks expressed their support for it and a desire to see support
for it in offerings out in the wild.
However, I did get some feedback from Vittorio Bertocci of Microsoft
that he felt that the language around issuing refresh tokens was
overly restrictive based on real world deployment experience they have
with a token exchange like interaction that they are currently
offering. He described it as follows:
"To summarize our main use case: we use [a token exchange like
protocol] for achieving user impersonation thru tiers, or delegation
for confidential clients which do not have any web UX.
Those cases do call for the ability of the middle tier to access the
resource also when the original credential is no longer valid (e.g.
there is no longer any user entertaining an active session with the
middle tier).
Think of a hypothetical new feature of the Uber mobile app, which can
monitor your Exchange calendar and book a ride whenever a suitable
slot opens up within a certain time range. The Uber app would call an
Uber-owned middle tier, in form of Web API, and the Web API would
itself be a client of the Exchange API. Given that the Uber API
doesn’t offer any browser ready surface, as it is meant to be accessed
only via oauth2 bearer token, the [token exchange] is the only way
through which it can obtain a token for the Exchange API; and the
scenario definitely call for offline access, as the uber API should be
able to monitor the Exchange calendar of the user even if the user
closed the app on his/her phone."
While the current text in the draft allows for this kind of thing, it
stigmatizes it somewhat with a "NOT RECOMMENDED" on sending an RT in
the response. So the proposal here is to make refresh tokens OPTIONAL
and change the accompanying text in sec 2.2.1 to the following:
refresh_token
OPTIONAL. A refresh token will typically not be issued when the
the exchange is of one temporary credential (the subject_token)
for a different temporary credential (the issued token) for use in
some other context. A refresh token can be issued in cases where
the client of the token exchange needs the ability to access a
resource even when the original credential is no longer valid
(e.g. user-not-present or offline scenarios where there is no
longer any user entertaining an active session with the client).
Profiles or deployments of this specification should clearly
document the conditions under which a client should expect a
refresh token in response to "urn:ietf:params:oauth:grant-
type:token-exchange" grant type requests.
I plan to make the aforementioned change and get a new draft published
with that and some other updates later this week before the Internet
Draft submission cut-off on Friday.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
