I stand with Ben’s contention that introspection should be about getting information :about: a token, and not about getting a new token. In fact, this was one of the core issues that I had with the draft as originally proposed.
If there are problems with token exchange, they should be fixed with token exchange and not piggybacked as an after-thought on this work. — Justin On Sep 27, 2019, at 3:51 PM, Benjamin Kaduk <ka...@mit.edu<mailto:ka...@mit.edu>> wrote: On Thu, Sep 26, 2019 at 11:26:31AM +0200, Travis Spencer wrote: * Last but certainly not least is the restriction that the current version places on disallowing of the introspection JWT response as an access token. This is done in numerous places (the note in section 5, 8.1, etc.). I understand that there are some objection to this usage, but we have had this protocol deployed for years, and it's running in dozens of customer's facilities. This will break real applications of this specification without a clear alternative. As we discussed in London last year at the IETF meeting, token exchange isn't a viable alternative (even still in its current draft form to the best of my knowledge). Without a workable alternative to move to, I emphatically but humbly request that this specification remove this restriction. I don't think I was in the London session, so would you mind saying a bit more about why token exchange isn't viable for your scenario? As an AD, I support the efforts to be explicit about what token flow/usage is being defined, which in effect means keeping introspection just introspection and not "producing new tokens". Thanks, Ben _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
