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

[Torsten Lodderstedt <[e-mail]>]

Hi George, 

> Am 01.06.2018 um 17:41 schrieb George Fletcher <[e-mail]>:
> 
> 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. 

> 
> 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: [e-mail]
>>> 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" <[e-mail]>, "Torsten Lodderstedt" <[e-mail]>
>>> 
>>> 
>>> 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.
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> 
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>