[OAUTH-WG] Following up on token exchange use case

[Brian Campbell]

During the meeting in Berlin Tony voiced concern about a use case he had
for token exchange. Honestly, it's still not entirely clear to me what that
use case is or what would need to change in support of it. I'd like to
better understand the use case and see if it's something that can
reasonably be accommodated with Token Exchange. During the meeting Tony
referred back to an earlier email where he said, "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."

The want_composite parameter came about during some iterative work on the
document (between I-D publications) last year. At first the client could
express that it wanted a composite token, one containing delegation
semantics, with the inclusion of the actor_token parameter. One of the
other editors suggested, however, that the actor_token token might be
necessary for authorization in cases even when the client wasn't asking for
a composite token and that placing the desire for delegation semantics on
it was overloading the parameter too much. I introduced the want_composite
parameter to give the client such a signal independent of the actor_token
parameter. My (admittedly incomplete) understanding of WS-Trust is that the
client/requester can make such an indication and I was trying to follow
that model. However, I'm not sure it's needed or even makes much much
sense. Ultimately it's the server's decision about how to construct the
issued token and what to include in it. It is the server's policy, not a
client signal, which makes the determination. So the want_composite
parameter is really just noise that makes the spec longer. And, from the
quote above, seems might also lead some readers to incorrect conclusions
about what can and cannot be returned in a token exchange.

I'd propose then that the want_composite parameter be dropped from the
document.

[Brian Campbell]

Looking for two things here:

1) Any objections to removing the want_composite request parameter? Please
explain, if so. I plan to remove it in the next draft barring an outpouring
of support to keep it.

2) Tony to explain his use case and describe what changes would be needed
to accommodate it.

Post by Brian Campbell
During the meeting in Berlin Tony voiced concern about a use case he had
for token exchange. Honestly, it's still not entirely clear to me what that
use case is or what would need to change in support of it. I'd like to
better understand the use case and see if it's something that can
reasonably be accommodated with Token Exchange. During the meeting Tony
referred back to an earlier email where he said, "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."
The want_composite parameter came about during some iterative work on the
document (between I-D publications) last year. At first the client could
express that it wanted a composite token, one containing delegation
semantics, with the inclusion of the actor_token parameter. One of the
other editors suggested, however, that the actor_token token might be
necessary for authorization in cases even when the client wasn't asking for
a composite token and that placing the desire for delegation semantics on
it was overloading the parameter too much. I introduced the want_composite
parameter to give the client such a signal independent of the actor_token
parameter. My (admittedly incomplete) understanding of WS-Trust is that the
client/requester can make such an indication and I was trying to follow
that model. However, I'm not sure it's needed or even makes much much
sense. Ultimately it's the server's decision about how to construct the
issued token and what to include in it. It is the server's policy, not a
client signal, which makes the determination. So the want_composite
parameter is really just noise that makes the spec longer. And, from the
quote above, seems might also lead some readers to incorrect conclusions
about what can and cannot be returned in a token exchange.
I'd propose then that the want_composite parameter be dropped from the
document.

[Justin Richer]

No objections. Simplification is better, and this spec is already fairly convoluted with all the options turned on.

— Justin

1) Any objections to removing the want_composite request parameter? Please explain, if so. I plan to remove it in the next draft barring an outpouring of support to keep it.
2) Tony to explain his use case and describe what changes would be needed to accommodate it.
During the meeting in Berlin Tony voiced concern about a use case he had for token exchange. Honestly, it's still not entirely clear to me what that use case is or what would need to change in support of it. I'd like to better understand the use case and see if it's something that can reasonably be accommodated with Token Exchange. During the meeting Tony referred back to an earlier email where he said, "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."
The want_composite parameter came about during some iterative work on the document (between I-D publications) last year. At first the client could express that it wanted a composite token, one containing delegation semantics, with the inclusion of the actor_token parameter. One of the other editors suggested, however, that the actor_token token might be necessary for authorization in cases even when the client wasn't asking for a composite token and that placing the desire for delegation semantics on it was overloading the parameter too much. I introduced the want_composite parameter to give the client such a signal independent of the actor_token parameter. My (admittedly incomplete) understanding of WS-Trust is that the client/requester can make such an indication and I was trying to follow that model. However, I'm not sure it's needed or even makes much much sense. Ultimately it's the server's decision about how to construct the issued token and what to include in it. It is the server's policy, not a client signal, which makes the determination. So the want_composite parameter is really just noise that makes the spec longer. And, from the quote above, seems might also lead some readers to incorrect conclusions about what can and cannot be returned in a token exchange.
I'd propose then that the want_composite parameter be dropped from the document.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Anthony Nadalin]

Things have gotten so muddled not sure where to begin, the original goal of this draft was to provide the function that we use in daily high volume production of WS-Trust as we transition to Oauth. WS-Trust provided many options, one was ActAs and the other was OnBehalfOf, these were 2 distinct functions but could be combined (and thus the results are of a composite nature). There were also other options like delegateTo, Forwardable and Delegatable. So we have use cases for all these.

So we have straight forward scenarios for (1) a token request to be on behalf of a given/specified token, we also have a straight forward scenario for (2) requesting a token based upon a specific token. We also have complex scenarios for combining the semantics of both (1) and (2) where the token request is on behalf of a specific token and the request is based upon a specific token, this happened a lot in our server to server scenarios for access to backend documents and services. Where we have chained services this is where the delegateTo, Forwardable and Delegatable options come into the scenario.

The way that this current specification is structured and written the Subject is always required which is a not a good thing since there may not be a subject, as basic token requests don’t have to have subjects (just authentication credentials), thus you can’t get the semantics of (2) without (1). Now the semantics of combing (1) and (2) seem to be not understood and wanting to be removed.


From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Justin Richer
Sent: Saturday, August 27, 2016 3:26 PM
To: Brian Campbell <***@pingidentity.com>
Cc: <***@ietf.org> <***@ietf.org>
Subject: Re: [OAUTH-WG] Following up on token exchange use case

No objections. Simplification is better, and this spec is already fairly convoluted with all the options turned on.

— Justin

On Aug 26, 2016, at 1:30 PM, Brian Campbell <***@pingidentity.com<mailto:***@pingidentity.com>> wrote:

Looking for two things here:
1) Any objections to removing the want_composite request parameter? Please explain, if so. I plan to remove it in the next draft barring an outpouring of support to keep it.
2) Tony to explain his use case and describe what changes would be needed to accommodate it.

On Mon, Aug 1, 2016 at 2:00 PM, Brian Campbell <***@pingidentity.com<mailto:***@pingidentity.com>> wrote:
During the meeting in Berlin Tony voiced concern about a use case he had for token exchange. Honestly, it's still not entirely clear to me what that use case is or what would need to change in support of it. I'd like to better understand the use case and see if it's something that can reasonably be accommodated with Token Exchange. During the meeting Tony referred back to an earlier email where he said, "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."
The want_composite parameter came about during some iterative work on the document (between I-D publications) last year. At first the client could express that it wanted a composite token, one containing delegation semantics, with the inclusion of the actor_token parameter. One of the other editors suggested, however, that the actor_token token might be necessary for authorization in cases even when the client wasn't asking for a composite token and that placing the desire for delegation semantics on it was overloading the parameter too much. I introduced the want_composite parameter to give the client such a signal independent of the actor_token parameter. My (admittedly incomplete) understanding of WS-Trust is that the client/requester can make such an indication and I was trying to follow that model. However, I'm not sure it's needed or even makes much much sense. Ultimately it's the server's decision about how to construct the issued token and what to include in it. It is the server's policy, not a client signal, which makes the determination. So the want_composite parameter is really just noise that makes the spec longer. And, from the quote above, seems might also lead some readers to incorrect conclusions about what can and cannot be returned in a token exchange.
I'd propose then that the want_composite parameter be dropped from the document.


_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

Despite not fully following all of that, I would like to try and understand
if there are reasonable changes that could be made to accommodate what
you're looking for.

What if we changed the subject_token parameter from REQUIRED to OPTIONAL
and then require at least one of subject_token or actor_token? That would
seem to allow for the 2 distinct functions you mention.

Post by Anthony Nadalin
Things have gotten so muddled not sure where to begin, the original goal
of this draft was to provide the function that we use in daily high volume
production of WS-Trust as we transition to Oauth. WS-Trust provided many
options, one was ActAs and the other was OnBehalfOf, these were 2 distinct
functions but could be combined (and thus the results are of a composite
nature). There were also other options like delegateTo, Forwardable and
Delegatable. So we have use cases for all these.
So we have straight forward scenarios for (1) a token request to be on
behalf of a given/specified token, we also have a straight forward scenario
for (2) requesting a token based upon a specific token. We also have
complex scenarios for combining the semantics of both (1) and (2) where
the token request is on behalf of a specific token and the request is based
upon a specific token, this happened a lot in our server to server
scenarios for access to backend documents and services. Where we have
chained services this is where the delegateTo, Forwardable and Delegatable
options come into the scenario.
The way that this current specification is structured and written the
Subject is always required which is a not a good thing since there may not
be a subject, as basic token requests don’t have to have subjects (just
authentication credentials), thus you can’t get the semantics of (2)
without (1). Now the semantics of combing (1) and (2) seem to be not
understood and wanting to be removed.
*Sent:* Saturday, August 27, 2016 3:26 PM
*Subject:* Re: [OAUTH-WG] Following up on token exchange use case
No objections. Simplification is better, and this spec is already fairly
convoluted with all the options turned on.
— Justin
1) Any objections to removing the want_composite request parameter? Please
explain, if so. I plan to remove it in the next draft barring an outpouring
of support to keep it.
2) Tony to explain his use case and describe what changes would be needed
to accommodate it.
During the meeting in Berlin Tony voiced concern about a use case he had
for token exchange. Honestly, it's still not entirely clear to me what that
use case is or what would need to change in support of it. I'd like to
better understand the use case and see if it's something that can
reasonably be accommodated with Token Exchange. During the meeting Tony
referred back to an earlier email where he said, "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."
The want_composite parameter came about during some iterative work on the
document (between I-D publications) last year. At first the client could
express that it wanted a composite token, one containing delegation
semantics, with the inclusion of the actor_token parameter. One of the
other editors suggested, however, that the actor_token token might be
necessary for authorization in cases even when the client wasn't asking for
a composite token and that placing the desire for delegation semantics on
it was overloading the parameter too much. I introduced the want_composite
parameter to give the client such a signal independent of the actor_token
parameter. My (admittedly incomplete) understanding of WS-Trust is that the
client/requester can make such an indication and I was trying to follow
that model. However, I'm not sure it's needed or even makes much much
sense. Ultimately it's the server's decision about how to construct the
issued token and what to include in it. It is the server's policy, not a
client signal, which makes the determination. So the want_composite
parameter is really just noise that makes the spec longer. And, from the
quote above, seems might also lead some readers to incorrect conclusions
about what can and cannot be returned in a token exchange.
I'd propose then that the want_composite parameter be dropped from the document.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

Would your use-case be better accommodated by changing the requiredness of
the request parameters so that it'd be sufficient to provide either the
subject_token or the actor_token?

I've always felt that it was simpler and more straightforward to always
have the subject token. And that cases where the requesting system or
server was the only entity involved could simply use the subject_token to
represent themselves. But perhaps that's too narrow of a view. I'm trying
to work with you on this.

Are there opinions one way or the other from others in the WG? I'd like to,
of course, get some level of consensus around this.

I'd like to publish a -06 draft soon and move things forward. I've got a
few other smallish changes queued up but this has been sitting for 3+
weeks. So I'm looking to get to a resolution.

Post by Brian Campbell
Despite not fully following all of that, I would like to try and
understand if there are reasonable changes that could be made to
accommodate what you're looking for.
What if we changed the subject_token parameter from REQUIRED to OPTIONAL
and then require at least one of subject_token or actor_token? That would
seem to allow for the 2 distinct functions you mention.

Post by Anthony Nadalin
Things have gotten so muddled not sure where to begin, the original goal
of this draft was to provide the function that we use in daily high volume
production of WS-Trust as we transition to Oauth. WS-Trust provided many
options, one was ActAs and the other was OnBehalfOf, these were 2 distinct
functions but could be combined (and thus the results are of a composite
nature). There were also other options like delegateTo, Forwardable and
Delegatable. So we have use cases for all these.
So we have straight forward scenarios for (1) a token request to be on
behalf of a given/specified token, we also have a straight forward scenario
for (2) requesting a token based upon a specific token. We also have
complex scenarios for combining the semantics of both (1) and (2) where
the token request is on behalf of a specific token and the request is based
upon a specific token, this happened a lot in our server to server
scenarios for access to backend documents and services. Where we have
chained services this is where the delegateTo, Forwardable and Delegatable
options come into the scenario.
The way that this current specification is structured and written the
Subject is always required which is a not a good thing since there may not
be a subject, as basic token requests don’t have to have subjects (just
authentication credentials), thus you can’t get the semantics of (2)
without (1). Now the semantics of combing (1) and (2) seem to be not
understood and wanting to be removed.
*Sent:* Saturday, August 27, 2016 3:26 PM
*Subject:* Re: [OAUTH-WG] Following up on token exchange use case
No objections. Simplification is better, and this spec is already fairly
convoluted with all the options turned on.
— Justin
1) Any objections to removing the want_composite request parameter?
Please explain, if so. I plan to remove it in the next draft barring an
outpouring of support to keep it.
2) Tony to explain his use case and describe what changes would be needed
to accommodate it.
On Mon, Aug 1, 2016 at 2:00 PM, Brian Campbell <
During the meeting in Berlin Tony voiced concern about a use case he had
for token exchange. Honestly, it's still not entirely clear to me what that
use case is or what would need to change in support of it. I'd like to
better understand the use case and see if it's something that can
reasonably be accommodated with Token Exchange. During the meeting Tony
referred back to an earlier email where he said, "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."
The want_composite parameter came about during some iterative work on the
document (between I-D publications) last year. At first the client could
express that it wanted a composite token, one containing delegation
semantics, with the inclusion of the actor_token parameter. One of the
other editors suggested, however, that the actor_token token might be
necessary for authorization in cases even when the client wasn't asking for
a composite token and that placing the desire for delegation semantics on
it was overloading the parameter too much. I introduced the want_composite
parameter to give the client such a signal independent of the actor_token
parameter. My (admittedly incomplete) understanding of WS-Trust is that the
client/requester can make such an indication and I was trying to follow
that model. However, I'm not sure it's needed or even makes much much
sense. Ultimately it's the server's decision about how to construct the
issued token and what to include in it. It is the server's policy, not a
client signal, which makes the determination. So the want_composite
parameter is really just noise that makes the spec longer. And, from the
quote above, seems might also lead some readers to incorrect conclusions
about what can and cannot be returned in a token exchange.
I'd propose then that the want_composite parameter be dropped from the document.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth