Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt

[Travis Spencer <[e-mail]>]

On Sat, Sep 28, 2019 at 12:51 AM Benjamin Kaduk <[e-mail]> 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.