Re: [OAUTH-WG] RT treatment in Token Exchange

[Justin Richer]

+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 
 
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

Re: [OAUTH-WG] RT treatment in Token Exchange

[Anthony Nadalin]

So I think the proposed wording is still too specific and limits the use case , 
I also don’t understand the usage of “credential” in your description as this 
does not have to be a credential. So suggest that this be simple and if you 
want you can explain in the security considerations section why one may not 
want to return a refresh_token

OPTIONAL.  The refresh_token for the issued token in the token_exchange request

access_token (response), this does not have to be an access_token so this is a 
bad name


Also it’s unclear why the subject_token is required, is it being suggested that 
the subject_token is also being used as an access_token ? The actor_token if 
specified could also be the subject_token

The term “security_token” I assume is not limited to access_token since there 
is a subject_token_type.

want_composite is not really the effect we are looking for since it provides 
for a single token, the use case we have is where you want the ability to use 
the subject_token and the actor_token in combination and not as a composite of 
only the claims.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, July 5, 2016 11:16 AM
To: oauth 
Subject: [OAUTH-WG] RT treatment in Token Exchange

I gave a short presentation about OAuth 2.0 Token 
Exchange<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.slideshare.net%2fbriandavidcampbell%2foauth-20-token-exchange-an-sts-for-the-rest-of-us&data=01%7c01%7ctonynad%40microsoft.com%7c36da9d499be34762740a08d3a5007e31%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5a5Ca7pHESmgzq36BmJDtQH%2f564QTbk1JQzFNfasnJU%3d>
 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-WG] RT treatment in Token Exchange

[Brian Campbell]

I gave a short presentation about OAuth 2.0 Token Exchange

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