W3C home > Mailing lists > Public > public-payments-wg@w3.org > December 2017

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

From: Matt Saxon <matt.saxon@gmail.com>
Date: Thu, 14 Dec 2017 20:15:04 +0000
Cc: Ian Jacobs <ij@w3.org>, Payments WG <public-payments-wg@w3.org>, "Ahuja, Sachin" <Sachin.Ahuja@mastercard.com>
Message-Id: <6F26FC31-7BC4-4347-A003-DD1EF34F874A@gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
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> 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/
> 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> wrote:
>>> com
Received on Thursday, 14 December 2017 20:15:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:28 UTC