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 <bcampb...@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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
