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. On Thu, Sep 8, 2016 at 4:52 PM, Anthony Nadalin <[email protected]> wrote: > 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:[email protected]] *On Behalf Of *Justin Richer > *Sent:* Saturday, August 27, 2016 3:26 PM > *To:* Brian Campbell <[email protected]> > *Cc:* <[email protected]> <[email protected]> > *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 <[email protected]> > 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 <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
