On Sat, Sep 28, 2019 at 12:51 AM Benjamin Kaduk <[email protected]> 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?
A few reasons: 1. There is no way to do content negotiation in token exchange as there is in this protocol. For some clients, this is preferable and easier. 2. The desired response body is not a simple stream that can be processed quickly and efficiently (like the one defined by this protocol). The exchanged token must be parsed out of the token exchange response. 3. Creating the payload of the request is slightly more involved, and the client is often limited in its capabilities[1] 4. HTTP cache controls that are tied to the input token validity period can't be applied as easily to the token endpoint response because the client has to parse the token exchange response (slower) or cache the entire reply (more memory) 5. The HTTP status code I mentioned in my last mail isn't defined as a way of communicating to the client that the input token is expired. This provides a client with the fastest way of knowing that a token is expired (that I can determine at least). 6. Migration of the clients and deployments using JWT introspection response will be costly and time consuming with little gain (in my judgement at least) > 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". I can appreciate this, but I don't see what I'm proposing as producing new tokens. Instead, I see it as re-encoding the same token in a different form. The subject is the same, the audience(s) is/are the same, the expiration time is the same, the claims are the same. They're just signed and have a new issuance time. In our implementation, the original token and the JWT version both stem from the same "delegation", so both are traceable back to the same end-user authorization, implying that both are invalidated when that delegation is expired or is revoked (which the end user can do or the client can do if it revokes a refresh token if it was given one). The use case we're using this protocol for is about re-encoding an access token in another form that is also used as an access token. [1] This argument is admittedly weak, as discussed at the IETF meeting. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
