[Openid-specs-fapi] I-D: draft-jordan-jws-ct-00

[Stuart Low]

If I understand this spec correctly the intent is to place a signature as
an inline attribute to the original payload (ie. add a `signature` key)?

I'm not so sure I'm onboard with inline modification of the original
payload for a signature of the payload itself. I raise this because parsing
then modifying a payload to return it back to it's original state before
being able to verify it in the first place seems counter intuitive.

Have you considered a "JWS/JWE like" envelope instead? ie:

{
  "signature": "abc"
},
{
  "payload1": "x"
  "payload2": "y"
}

Thanks,

Stuart

On Fri, Nov 20, 2020 at 10:42 PM Anders Rundgren via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> https://www.ietf.org/archive/id/draft-jordan-jws-ct-00.html
>
> Abstract:
>     This document describes a method for extending the scope of the JSON
>     Web Signature (JWS) standard, called JWS/CT.  By combining the
>     detached mode of JWS with the JSON Canonicalization Scheme (JCS),
>     JWS/CT enables JSON objects to remain in the JSON format after being
>     signed (aka "Clear Text" signing).
>
> On-line service for testing/evaluation: https://mobilepki.org/jws-ct
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20201122/ee0af562/attachment.html>