Re: [Agenda] Tokenization task force call on 12 December

On 15 December 2017 at 14:45, Anders Rundgren <anders.rundgren.net@gmail.com
> wrote:

> On 2017-12-15 11:06, Adrian Hope-Bailie wrote:
>
>> For example, I would recommend we don't allow clear JSON at all but only
>> the base64 encoded data that has been signed.
>>
>
> Then you are all set because JWS gives you exactly what you propose.
> Current [2017-12-14] W3C writeup:
>

I agree.


>
>   {
>     supportedMethods: "https://example.com/bobpay";,
>     data: {
>       signedData: {
>         merchantIdentifier: "XXXX",
>         bobPaySpecificField: true
>       },
>       unsignedData: {...},

      dataSecurity: {
>         signature: {...},
>         signatureCertPath: "public.pem"
>       }
>     }
>   }
>
> After applying JWS in a fully standard-conformant way:
>
>   {
>     supportedMethods: "https://example.com/bobpay";,
>     data: {
>       signedData: "Base64UrlData.Base64UrlData.Base64UrlData",
>       unsignedData: {...}
>     }
>   }


> The only functional difference from the original is that the URL to the
> certificate path (supplied in an "x5u" property somewhere in the Base64Url
> data...), would have to be absolute.  This is hardly a showstopper or
> reason for creating a custom scheme.
>
> I don't recommend supporting multiple approaches this simply serves to
>> increase the attack surface.
>>
>> As Anders points out this is a contentious area or discussion even among
>> the "experts". My suggestion would be to follow the standards that are
>> gaining the most traction and adopt a profile of one of these (likely JWS)
>> that limits the options available and places some specific restrictions on
>> implementors and users to avoid known weaknesses.
>>
>>
> The core issue has not been about security but about interoperability.
> All signature schemes are open to content attacks; in the end it really
> boils down to the quality of the implementation.
>
> JWS's support of the algorithm "none" spurred a lot of (very
> uninteresting) security discussions.  I would simply have dropped that
> option and moved on.
>

Agree. I would suggest we have a profile of JWS that:

1. Rejects unsignedData. (i.e. There is only the encoded binary version so
developers can't mistakenly use the clear text without verifying it matches
the binary data that was signed.)
2. Has a limited set of allowed algorithms


>
> thanx,
> Anders
>
>
>> On 14 December 2017 at 22:15, Matt Saxon <matt.saxon@gmail.com <mailto:
>> matt.saxon@gmail.com>> wrote:
>>
>>     So you are happy with the concepts, but you’d like a different
>> encoding method for the signatures?
>>
>>     What the view in this if we could/should support multiple approaches?
>>
>>     Sent from my iPhone
>>
>>      > On 12 Dec 2017, at 06:23, Anders Rundgren <
>> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>
>> wrote:
>>      >
>>      >> On 2017-12-11 22:07, Matt Saxon wrote:
>>      >> Anders,
>>      >> I understand your point and it will be addressed when we get
>> further into the proposal.
>>      >> At the moment, we are trying to get agreement to the principles,
>> not the detailed encoding format.
>>      >> As you suggest we will need to address the encoding of signed
>> data, but I don’t believe this interferes with the principles.
>>      >
>>      > Right.  However, Base64Url-ecoding signed JSON data violently
>> interferes with my "esthetics" :-)
>>      >
>>      > I'm not [at all] alone thinking that.
>>      >
>>      > JSON-LD Signatures by Manu Sporny and the credentials folks:
>>      > https://w3c-dvcg.github.io/ld-signatures/ <
>> https://w3c-dvcg.github.io/ld-signatures/>
>>      >
>>      > JCS (JSON Cleartext Signature) by yours truly, here presented in
>> an on-line test/demo setup:
>>      > https://mobilepki.org/jcs/home
>>      >
>>      > These schemes are reusing parts of the JOSE stack but are actually
>> quite different.
>>      >
>>      > Shameless plug: JCS builds on JWK + JWA + ES6 + "New Stuff".  JCS
>> only needs JSON.parse() and JSON.stringify() for processing.  In addition,
>> JCS permits signatures to be expressed as JavaScript objects.
>>      >
>>      > Regards,
>>      > Anders
>>      >
>>      >
>>      >> Regards,
>>      >> Matt
>>      >> Sent from my iPhone
>>      >>> On 11 Dec 2017, at 18:51, Ian Jacobs <ij@w3.org <mailto:
>> ij@w3.org>> wrote:
>>      >>>
>>      >>> com
>>      >
>>
>>
>>
>