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

From: [email-masked]
Date: Fri, 20 Sep 2019 05:28:26 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : JWT Response for OAuth Token Introspection
        Authors         : Torsten Lodderstedt
                          Vladimir Dzhuvinov
	Filename        : draft-ietf-oauth-jwt-introspection-response-08.txt
	Pages           : 18
	Date            : 2019-09-20

Abstract:
   This specification proposes an additional JSON Web Token (JWT)
   secured response for OAuth 2.0 Token Introspection.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 24 Sep 2019 09:03:22 +0300

When implementing 08 a question came up:

* The token has multiple audiences (aud), e.g ["rs1", "rs2", "rs3"].

* The RS "rs1" is in the expected audience.

Are there any considerations (privacy, etc) about returning the full
audience list ["rs1", "rs2", "rs3"] in the introspection response?
Theoretically, the RS shouldn't be interested which other RSs may
legally consume the token, so those may be excluded from the list,
returning only ["rs1"]?

Vladimir

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 24 Sep 2019 11:48:51 +0200

Hi Vladimir,

> On 24. Sep 2019, at 08:03, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
> returning only ["rs1”]

From a privacy perspective, I would expect the AS to reduce the data to the minimum required for the particular RS. In your case, the AS should narrow down the audience to ["rs1”].

From a security perspective, this also reduces the risk for replay at other RSs. https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08#section-8.1

best regards,
Torsten. 

> ?

> Vladimir
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Travis Spencer <[email-masked]>
Date: Thu, 26 Sep 2019 11:26:31 +0200

Some feedback on this draft compared to the last one that I read:

* The acronym RS and the term "resource server" are used
inconsistently. It would read better IMO if the acronym was always
used after being defined or if resource server was always spelled out.
Same for AS, but less so. Maybe this is just me, so take it as you
will.

* In section 3, is it saying that JWE is MTI? From the end of section
5, it seems not. If so, this statement should be clarified IMO:

> To support encrypted token introspection response JWTs, the authorization server MUST also be provided with the respective resource server encryption keys and algorithms.

Maybe just change it to "If the AS supports encrypted token
introspection response JWTs..."

* Instead of issuing an expired JWT (or in addition) I think it should
be valid for the AS to reply with a 201, no content. For this reason,
I think that section 5 should be updated thusly:

> If the access token is invalid, expired, has been revoked, or is not intended to be consumed by the calling resource server (audience), the authorization server MUST set the value of the response claim
"active" to "false" if it chooses to issue a JWT. Otherwise, this
claim is set to "true". If it does not issue a JWT, the AS MUST reply
with an HTTP 204, no content, status code. If it does include a JWT
with an "active" claim of "false", the AS MAY reply with an HTTP 204,
no content, status code.

The rational is that the AS may not want to exert effort to make a
signed/encrypted JWT that is expired. Not having the token is usually
as good or better than having an expired one.

* This statement makes the audience sound too narrow IMO:

> The value of the "aud" claims MUST identify the resource server receiving the token introspection response.

Because the AS's policy may stipulate that the audience could be
others in addition to the RS some wording should be added like "the
'aud' claim MUST identify the resource server receiving the token
introspection response and MAY contain other values based on its
policy."

* The "M" in email in section 5 should not be capitalized IINM.

* In section 5, this is very broad.

> The AS determines based on the RS-specific policy what claims about the resource owner to return in the token introspection response. The AS MUST ensure that the release of any privacy-sensitive data is legally based.

So, an AS must follow the law? Is that all that it's saying? Section 9
seems to restate this point. Is conformance to the law really up to
this doc to stipulate? If the AS breaks the law, it don't conform to
the protocol. This seems very meta.

* 1st in section 9 should be spelled out as "first" and IINM it should
be "first-party" since it's being used as an adjective.

* 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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 27 Sep 2019 15:51:06 -0700

> 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

---

From: Travis Spencer <[email-masked]>
Date: Sat, 28 Sep 2019 15:36:02 +0200

> 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)

> 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.