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 <[email protected]> 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 [email protected]https://www.ietf.org/mailman/listinfo/oauth > > -- > Vladimir Dzhuvinov > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
