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

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:

   {
     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.

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
>      >
> 
>

Received on Friday, 15 December 2017 12:46:25 UTC