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

From: George Fletcher <[email-masked]>
Date: Fri, 1 Jun 2018 11:41:01 -0400

What is the expectation if the RS requests a signed JWT response but the 
AS doesn't support it? Should getting a signed response require both? 
(meaning the Accept header and an AS config that that RP wants it)? That 
may be the safest from a backward compatibility perspective.

I have some concerns around relying on 'iss' and 'aud' to prevent abuse 
and wonder if a JWT Header claim describing the context of the JWT might 
be better.

Thanks,
George

On 5/28/18 12:58 PM, Torsten Lodderstedt wrote:
> Hi all,
>
> I just published a new revision of the JWT Introspection response 
> draft. Based on the feedback in London, the draft entirely focuses on 
> use cases where the RS requires stronger assurance that the respective 
> AS issued the token, including cases where the AS assumes liability 
> for the token’s content.
>
> We incorporated the following changes:
> • fixed typos in client meta data field names (thanks Petteri!)
> • added OAuth Server Metadata parameters to publish algorithms 
> supported for signing and encrypting the introspection response
> • added registration of new parameters for OAuth Server Metadata and 
> Client Registration
> • added explicit request for JWT introspection response
> • made iss and aud claims mandatory in introspection response (thanks 
> Neil!)
> • Stylistic and clarifying edits, updates references
>
> Thanks to all reviewers!
>
> Vladimir and I are on the fence whether the Introspection Response 
> format should be determined by the AS based on its policy and/or 
> RS-related registration metadata or whether the RS should explicitly 
> request a JWT response by including an Accept header „application/jwt“ 
> in the respective request.
>
> What do you think?
>
> kind regards,
> Torsten.
>
>> Anfang der weitergeleiteten Nachricht:
>>
>> *Von: [email-masked] <mailto:[email-masked]>
>> *Betreff: **New Version Notification for 
>> draft-lodderstedt-oauth-jwt-introspection-response-01.txt*
>> *Datum: *28. Mai 2018 um 18:48:02 MESZ
>> *An: *"Vladimir Dzhuvinov" <[email-masked] 
>> <mailto:[email-masked]>>, "Torsten Lodderstedt" 
>> <[email-masked] <mailto:[email-masked]>>
>>
>>
>> A new version of I-D, 
>> draft-lodderstedt-oauth-jwt-introspection-response-01.txt
>> has been successfully submitted by Torsten Lodderstedt and posted to the
>> IETF repository.
>>
>> Name:draft-lodderstedt-oauth-jwt-introspection-response
>> Revision:01
>> Title:JWT Response for OAuth Token Introspection
>> Document date:2018-05-28
>> Group:Individual Submission
>> Pages:10
>> URL: 
>> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-01.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-01
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response
>> Diff: 
>> https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-jwt-introspection-response-01
>>
>> 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 
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 4 Jun 2018 18:29:48 +0200

Hi George, 

> Am 01.06.2018 um 17:41 schrieb George Fletcher <[email-masked]>:
> 
> What is the expectation if the RS requests a signed JWT response but the AS doesn't support it? Should getting a signed response require both? (meaning the Accept header and an AS config that that RP wants it)? That may be the safest from a backward compatibility perspective.

we assume the RS is set up with the AS in advance, so the RS should know whether the AS supports signing. 

> I have some concerns around relying on 'iss' and 'aud' to prevent abuse

It’s iss + aud + all replay prevention means you can think of (including token binding).

> and wonder if a JWT Header claim describing the context of the JWT might be better. 

Any suggestions (cty)? I’m not sure abuse can be prevented that way since developers need to consider this header claim.

best regards,
Torsten. 

>> I just published a new revision of the JWT Introspection response draft. Based on the feedback in London, the draft entirely focuses on use cases where the RS requires stronger assurance that the respective AS issued the token, including cases where the AS assumes liability for the token’s content. 
>> 
>> 	• added OAuth Server Metadata parameters to publish algorithms supported for signing and encrypting the introspection response
>> 	• added registration of new parameters for OAuth Server Metadata and Client Registration
>> 	• made iss and aud claims mandatory in introspection response (thanks Neil!)
>> Vladimir and I are on the fence whether the Introspection Response format should be determined by the AS based on its policy and/or RS-related registration metadata or whether the RS should explicitly request a JWT response by including an Accept header „application/jwt“ in the respective request. 
>> 
>> What do you think?
>> 
>> kind regards,
>> Torsten.
>> 
>>> Von: [email-masked]
>>> Betreff: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-01.txt
>>> Datum: 28. Mai 2018 um 18:48:02 MESZ
>>> An: "Vladimir Dzhuvinov" <[email-masked]>, "Torsten Lodderstedt" <[email-masked]>
>>> 
>>> 
>>> A new version of I-D, draft-lodderstedt-oauth-jwt-introspection-response-01.txt
>>> Name:		draft-lodderstedt-oauth-jwt-introspection-response
>>> Revision:	01
>>> Title:		JWT Response for OAuth Token Introspection
>>> Document date:	2018-05-28
>>> Group:		Individual Submission
>>> Pages:		10
>>> URL:            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-01.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-01
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-jwt-introspection-response-01
>>> 
>>> 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.
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> 
>>