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] > <mailto:[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
