Re: [OAUTH-WG] oauth-jwt-introspection-response and RFC 7797

Hi Vladimir,

Thank you for your detailed response. Yes, I completely agree with your
point about the issue with encryption.

Regards,
Andrii

On Mon, Feb 8, 2021 at 8:03 AM Vladimir Dzhuvinov <vladimir@connect2id.com>
wrote:

> Hi Andrii,
>
> The unencoded payload JWS from RFC 7797 appears to be harder to get right.
> Web frameworks can for instance make serialization and parsing of JSON and
> text in general in HTTP unpredictable or difficult to control. A single \n
> introduced at the end of the body can for instance break the signature
> (been in one such situation). Incorrectly set charsets can also cause
> issues. To mitigate this there has been an effort to canonicalize JSON.
>
> Also note that the JSON payload of the signed introspection response is
> not a 1:1 copy of the RFC 7662 token introspection response. It includes
> claims outside the token_introspection container - iss, aud and iat. So
> where will they go and how is the signature going to include them as well?
>
> There's also the issue with encryption - we don't have a standard way of
> doing JWE over an RFC 7797 style signed text yet.
>
> Vladimir
> On 07/02/2021 11:56, Andrii Deinega wrote:
>
> Hi WG.
>
> draft-ietf-oauth-jwt-introspection-response-10 proposes to return signed
> JWTs as a response from the introspection endpoint... which is making
> me wonder if there are any particular reasons to not avail JSON Web
> Signature (JWS) Unencoded Payload Option (RFC 7797) and the X-JWS-SIGNATURE
> HTTP header in order to achieve the same goals?
>
> Pros would be
>
>    1. a token introspection response remains to be exactly the same as it
>    was before with an exception for a JWT in the X-JWS-SIGNATURE HTTP header
>    (where a detached payload is the actual token introspection response)
>    2. the AS can safely enable it for all responses from the
>    introspection endpoint so clients who don't require or just aren't aware of
>    this header will continue to work as before and accordingly, the clients
>    who require some stronger assurance will require and check a JWT
>    in X-JWS-SIGNATURE HTTP header
>    3. the same approach could also work for other endpoints such as the
>    revocation and OIDC UserInfo endpoints
>
> What do you think?
>
> Regards,
> Andrii
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Vladimir Dzhuvinov
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>