Subject: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 18 Mar 2018 20:33:01 +0100

Hi all,

I just submitted a new draft that Vladimir Dzhuvinov and I have written. It proposes a JWT-based response type for Token Introspection. The objective is to provide resource servers with signed tokens in case they need cryptographic evidence that the AS created the token (e.g. for liability). 

I will present the new draft in the session on Wednesday.

kind regards,
Torsten. 

> Anfang der weitergeleiteten Nachricht:
> 
> Von: [email-masked]
> Betreff: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt
> Datum: 18. März 2018 um 20:19:37 MEZ
> An: "Vladimir Dzhuvinov" <[email-masked]>, "Torsten Lodderstedt" <[email-masked]>
> 
> 
> A new version of I-D, draft-lodderstedt-oauth-jwt-introspection-response-00.txt
> has been successfully submitted by Torsten Lodderstedt and posted to the
> IETF repository.
> 
> Name:		draft-lodderstedt-oauth-jwt-introspection-response
> Revision:	00
> Title:		JWT Response for OAuth Token Introspection
> Document date:	2018-03-15
> Group:		Individual Submission
> Pages:		5
> URL:            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/
> Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response
> 
> 
> Abstract:
>   This draft proposes an additional JSON Web Token (JWT) based response
>   for OAuth 2.0 Token Introspection.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
>

---

From: "Brock Allen" <[email-masked]>
Date: Sun, 18 Mar 2018 15:40:07 -0400

Why is TLS to the intospection endpoint not sufficient? Are you thinking there needs to be some multi-tenancy support of some kind?

-Brock

On 3/18/2018 3:33:16 PM, Torsten Lodderstedt <[email-masked]> wrote:
Hi all,

kind regards,
Torsten. 

Von: [email-masked] [mailto:[email-masked]]

An: "Vladimir Dzhuvinov" <[email-masked] [mailto:[email-masked]]>, "Torsten Lodderstedt" <[email-masked] [mailto:[email-masked]]>

Name: draft-lodderstedt-oauth-jwt-introspection-response
Revision: 00
Title: JWT Response for OAuth Token Introspection
Document date: 2018-03-15
Group: Individual Submission
Pages: 5
URL:            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt [https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt]
Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/ [https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/]
Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00 [https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00]
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response [https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response]

Abstract:

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 [http://tools.ietf.org].

The IETF Secretariat

---

From: LARMIGNAT Louis <[email-masked]>
Date: Mon, 19 Mar 2018 08:25:55 +0000

Hi,

The draft Signing HTTP Messages (https://tools.ietf.org/html/draft-cavage-http-signatures-09) could not meet this requirement in a more generic way ?

Regards,
Louis

De : OAuth <[email-masked]> De la part de Brock Allen
Envoyé : dimanche 18 mars 2018 20:40
À : Torsten Lodderstedt <[email-masked]>; [email-masked]
Objet : Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

-Brock

On 3/18/2018 3:33:16 PM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

kind regards,
Torsten.

Von: [email-masked]<mailto:[email-masked]>
Betreff: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt
Datum: 18. März 2018 um 20:19:37 MEZ
An: "Vladimir Dzhuvinov" <[email-masked]<mailto:[email-masked]>>, "Torsten Lodderstedt" <[email-masked]<mailto:[email-masked]>>

Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response<https://datatracker..ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response>

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

The information transmitted in the present email including the attachment is intended only for the person to whom or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete all copies of the material.

Ce message et toutes les pièces qui y sont éventuellement jointes sont confidentiels et transmis à l'intention exclusive de son destinataire. Toute modification, édition, utilisation ou diffusion par toute personne ou entité autre que le destinataire est interdite. Si vous avez reçu ce message par erreur, nous vous remercions de nous en informer immédiatement et de le supprimer ainsi que les pièces qui y sont éventuellement jointes.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 19 Mar 2018 08:57:55 +0000

This draft has similar issues to https://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01

Rather than *try* sign HTTP, a signed JWT object is more reliably returned.

Phil

> On Mar 19, 2018, at 8:25 AM, LARMIGNAT Louis <[email-masked]> wrote:
> 
> Hi,
>  
> The draft Signing HTTP Messages <> (https://tools.ietf.org/html/draft-cavage-http-signatures-09 <https://tools.ietf.org/html/draft-cavage-http-signatures-09>) could not meet this requirement in a more generic way ?
>  
> Regards,
> Louis
>  
> De : OAuth <[email-masked] <mailto:[email-masked]>> De la part de Brock Allen
> À : Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On 3/18/2018 3:33:16 PM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi all,
>  
> Von: [email-masked] <mailto:[email-masked]>
> An: "Vladimir Dzhuvinov" <[email-masked] <mailto:[email-masked]>>, "Torsten Lodderstedt" <[email-masked] <mailto:[email-masked]>>
>  
> 
> URL:            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt <https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/ <https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/>
> Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00 <https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response <https://datatracker..ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response>
> 
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
>  
> Ce message et toutes les pièces qui y sont éventuellement jointes sont confidentiels et transmis à l'intention exclusive de son destinataire. Toute modification, édition, utilisation ou diffusion par toute personne ou entité autre que le destinataire est interdite. Si vous avez reçu ce message par erreur, nous vous remercions de nous en informer immédiatement et de le supprimer ainsi que les pièces qui y sont éventuellement jointes. _______________________________________________
> OAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 19 Mar 2018 11:14:55 +0100

> Am 18.03.2018 um 20:40 schrieb Brock Allen <[email-masked]>:
> 
> Why is TLS to the intospection endpoint not sufficient?

TLS is sufficient, if AS and RS want to ensure the integrity of the token data (on transit). But there are use cases, where the RS wants evidence (== digital signature over the token) who created the token. This is for non-repudation/liability.

> Are you thinking there needs to be some multi-tenancy support of some kind?

With respect to what party? The draft allows every RS to choose the response type and if JWT, the algorithms to use. 

kind regards,
Torsten.   
 
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response <https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response>
>>> 
>>> 
>>> Abstract:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 19 Mar 2018 11:16:58 +0100

We explicitly want the token (JSON object) to be signed not the HTTP response. I think using JWS is the most generic way to achieve that goal.

> Am 19.03.2018 um 09:57 schrieb Phil Hunt <[email-masked]>:
> 
> This draft has similar issues to https://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01 <https://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01>
> 
>> On Mar 19, 2018, at 8:25 AM, LARMIGNAT Louis <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 19 Mar 2018 10:22:53 +0000

+1.  This is what I expected.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Mar 19, 2018, at 10:16 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 
>> Am 19.03.2018 um 09:57 schrieb Phil Hunt <[email-masked] <mailto:[email-masked]>>:
>>

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 19 Mar 2018 12:41:00 +0100

Hi,

Adding an additional proposal to the table. Mike Jones, Anders Rundgren and
I have created a version of JWS there the signed JSON data does not have to
be Base64url encoded (the JSON is signed using ES6 serialization rules).
One of the benefits to this approach would be that the introspection data
is transferred in cleartext while still fully protected. Since it is
transferred in the response body and not in a URL there is no need for the
Base64url encoding.

The draft can be fond here
https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00

And the example from your draft would look like this (the signature is not
valid, I just copied it from another place)
{
  "sub": "Z5O3upPC88QrAjx00dis",
  "aud": "https://protected.example.net/resource",
  "extension_field": "twenty-seven",
  "scope": "read write dolphin",
  "iss": "https://server.example.com/",
  "active": true,
  "exp": 1419356238,
  "iat": 1419350238,
  "client_id": "l238j323ds-23ij4",
  "username": "jdoe"
  "__cleartext_signature": {
    "alg": "ES256",
    "kid": "example.com:p256",
    "signature": "pXP0GFHms0SntctNk1G1pHZfccVYdZkmAJktY_hpMsI
                  AckzX7wZJIJNlsBzmJ1_7LmKATiW-YHHZjsYdT96JZw"
  }
}

On Mon, Mar 19, 2018 at 11:22 AM, Phil Hunt <[email-masked]> wrote:

> www.independentid.com
> [email-masked]
> We explicitly want the token (JSON object) to be signed not the HTTP
> response. I think using JWS is the most generic way to achieve that goal.
>
> This draft has similar issues to https://tools.ietf.org/
> html/draft-richer-oauth-signed-http-request-01
>
> The draft *Signing HTTP Messages** (https://tools.ietf.org/html/draft-cavage-http-signatures-09
> <https://tools.ietf.org/html/draft-cavage-http-signatures-09>)* could not
> meet this requirement in a more generic way ?
>
> Regards,
> Louis
>
> *De :* OAuth <[email-masked]> *De la part de* Brock Allen
> *Envoyé :* dimanche 18 mars 2018 20:40
> *À :* Torsten Lodderstedt <[email-masked]>; [email-masked]
> *Objet :* Re: [OAUTH-WG] Fwd: New Version Notification for
> draft-lodderstedt-oauth-jwt-introspection-response-00.txt
>
> Why is TLS to the intospection endpoint not sufficient? Are you thinking
> there needs to be some multi-tenancy support of some kind?
>
> -Brock
>
>
> I just submitted a new draft that Vladimir Dzhuvinov and I have written.
> It proposes a JWT-based response type for Token Introspection. The
> objective is to provide resource servers with signed tokens in case they
> need cryptographic evidence that the AS created the token (e.g. for
> liability).
>
> *Von: [email-masked]
> *Betreff: New Version Notification for
> draft-lodderstedt-oauth-jwt-introspection-response-00.txt*
> *Datum: *18. März 2018 um 20:19:37 MEZ
> *An: *"Vladimir Dzhuvinov" <[email-masked]>, "Torsten
> Lodderstedt" <[email-masked]>
>
>
>
> URL:            https://www.ietf.org/internet-drafts/draft-
> lodderstedt-oauth-jwt-introspection-response-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-
> lodderstedt-oauth-jwt-introspection-response/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-
> lodderstedt-oauth-jwt-introspection-response
> <https://datatracker..ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response>
>
>
> Abstract:
> The information transmitted in the present email including the attachment
> is intended only for the person to whom or entity to which it is addressed
> and may contain confidential and/or privileged material. Any review,
> retransmission, dissemination or other use of, or taking of any action in
> reliance upon this information by persons or entities other than the
> intended recipient is prohibited. If you received this in error, please
> contact the sender and delete all copies of the material.
>
> Ce message et toutes les pièces qui y sont éventuellement jointes sont
> confidentiels et transmis à l'intention exclusive de son destinataire.
> Toute modification, édition, utilisation ou diffusion par toute personne ou
> entité autre que le destinataire est interdite. Si vous avez reçu ce
> message par erreur, nous vous remercions de nous en informer immédiatement
> et de le supprimer ainsi que les pièces qui y sont éventuellement jointes.
>  _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 19 Mar 2018 11:55:51 +0000

And let us not forget about JWS unencoded payload
https://tools.ietf.org/html/rfc7797

On Mar 19, 2018 11:41 AM, "Samuel Erdtman" <[email-masked]> wrote:

> Hi,
>
> Adding an additional proposal to the table. Mike Jones, Anders Rundgren
> and I have created a version of JWS there the signed JSON data does not
> have to be Base64url encoded (the JSON is signed using ES6 serialization
> rules). One of the benefits to this approach would be that the
> introspection data is transferred in cleartext while still fully protected.
> Since it is transferred in the response body and not in a URL there is no
> need for the Base64url encoding.
>
>> Am 19.03..2018 um 09:57 schrieb Phil Hunt <[email-masked]>:
>>
>> This draft has similar issues to https://tools.ietf.org/html
>> /draft-richer-oauth-signed-http-request-01
>>
>> <https://tools.ietf.org/html/draft-cavage-http-signatures-09>)* could
>> not meet this requirement in a more generic way ?
>>
>> Regards,
>> Louis
>>
>> URL:            https://www.ietf.org/internet-drafts/draft-lodder
>> stedt-oauth-jwt-introspection-response-00.txt

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*

---

From: Petteri Stenius <[email-masked]>
Date: Mon, 26 Mar 2018 09:02:59 +0000

Hi all,

I want to show my support for this proposal

I believe the two use cases presented at the IETF meeting [1] are important:

1. implementing application level end-to-end integrity protection of the introspection response
2. simple conversion of by-reference access tokens into by-value JWT encoded tokens

This proposal adds three fields to the client metadata. I think there are two issues that should be addressed:

1. Remove double "response" from field names. Replace "introspection_response_signed_response_alg" with "introspection_signed_response_alg". Also address two other fields
2. Add corresponding fields to provider metadata. For client metadata field "introspection_signed_response_alg" there should exist "introspection_signing_alg_values_supported" in provider metadata. The two other fields need corresponding fields as well.

Relationship with OpenID Connect

In OpenID Connect the userinfo endpoint is very similar to introspection endpoint of OAuth. Userinfo supports JWT signing and encryption. Adding JWT signing and encryption to introspection endpoint fills the gap between the two specifications.

Best regards,
Petteri Stenius

[1] https://datatracker.ietf.org/meeting/101/materials/slides-101-oauth-sessb-jwt-introspection-response-01

From: OAuth <[email-masked]> On Behalf Of Torsten Lodderstedt
Sent: sunnuntai 18. maaliskuuta 2018 21.33
To: oauth <[email-masked]>
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

Hi all,

kind regards,
Torsten.

Abstract:

The IETF Secretariat

---

From: Neil Madden <[email-masked]>
Date: Wed, 28 Mar 2018 16:41:50 +0100

I like this draft, but I want to clarify if it is intended that the response JWT could be interpreted as an OpenID Connect ID Token? As the set of claims can overlap (in particular, all required ID token claims are valid token introspection response fields) and it seems highly likely that an AS will use the same keys for signing both (and it definitely will when the client_secret is used for signing), the signed response JWT could well be indistinguishable from an ID token (for the resource owner) with some additional claims.

If this is not the case, then maybe consider adding a “crit”: [“scope”] claim to the response (https://tools.ietf.org/html/rfc7515#section-4.1.11 <https://tools.ietf.org/html/rfc7515#section-4.1.11>) to indicate that the scope claim must be understood.

I can think of one potential use-case (I’ll let you decide the merits of it) where it might actually be useful to explicitly allow the response to be an ID Token. Consider an application (RS) that uses a traditional authorization model: it authenticates a user, sets a cookie, and then based on who that user is makes dynamic access control decisions to see what they are allowed to do (e.g., ACLs, RBAC, whatever). An easy way to upgrade this app to modern standards would be to replace the home-spun authentication system with OIDC, but leave the rest in place. Now the system uses OIDC to authenticate the user, sets the ID token as the cookie, and then still applies the same access control decisions that it always has done.

Now imagine that a new requirement comes in to support OAuth 2.0 access tokens to allow delegation to third-party apps. A really simple way to achieve that would be to put a filter/reverse proxy in front of the RS that extracts access tokens coming in, performs signed JWT token introspection against the AS to validate the token and then checks the the scopes are appropriate for the request. It can then simply replace the access token in the original request with the signed token introspection response (as ID token) and forward it on to the original RS server. As the introspection response is a valid ID token for the resource owner, the RS will then apply all its normal access control checks to ensure that the resource owner actually has the permissions that they have delegated to the client.

I think potentially that is quite an interesting application of this draft, but I don’t think it was intended! I think probably a decision should be made as to whether that kind of usage should be allowed and explicitly adjust the draft to either allow or deny it. If it is allowed, then possibly there should be a way for the caller to hint that they want the response to be a valid ID token.

Kind regards,

Neil

> On 18 Mar 2018, at 19:33, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Neil Madden <[email-masked]>
Date: Thu, 29 Mar 2018 17:41:48 +0100

I’ve just realised that “crit” is for headers while the “scope” claim is in the payload, so a different approach would be needed in that case (or the scope would need to be duplicated into the headers).

Kind regards,

Neil

--

> On Wednesday, Mar 28, 2018 at 4:41 pm, Neil Madden <[email-masked] (mailto:[email-masked])> wrote:
> If this is not the case, then maybe consider adding a “crit”: [“scope”] claim to the response (https://tools.ietf.org/html/rfc7515#section-4.1.11) to indicate that the scope claim must be understood.
>
> > On 18 Mar 2018, at 19:33, Torsten Lodderstedt <[email-masked] (mailto:[email-masked])> wrote:
> > Hi all,
> >
> > > Von: [email-masked] (mailto:[email-masked])
> > > An: "Vladimir Dzhuvinov" <[email-masked] (mailto:[email-masked])>, "Torsten Lodderstedt" <[email-masked] (mailto:[email-masked])>
> > >
> > >
> > > until the htmlized version and diff are available at tools.ietf.org (http://tools.ietf.org/).
> > >
> > > The IETF Secretariat
> > >
> >
> > [email-masked] (mailto:[email-masked])