Re: JWT credentials

We would like to support jsonld as we like certain aspects of it.

There are however certain issues with it:

- library has no built in support for DIDs yet afaik . I’m sure it can be
manually wired up to support it
- single JavaScript implementation
- very verbose which unfortunately leaks over into the json version of Vc
as well
- reliance on external linked data without any cryptographic integrity
guarantees
- very complex for new developers to understand, which could cause security
problems down the line

It is more composable than JWTs. I see that as jsonlds biggest advantage.
But composability I feel is less important outside the http world.

We see most usecase as best implemented as smaller self contained VCs and
that JWTs are superior for that.

P

On Fri, Oct 5, 2018 at 7:01 AM Carlos Bruguera <cbruguera@gmail.com> wrote:

> Thanks guys for your valuable input.
>
> In this regard, how "production-ready" is the current LD signatures
> library for use in a DID/Creds system? Any limitations known? Perhaps Manu
> or someone else involved could provide a summary of its current state?
>
> Regards,
> Carlos
>
> On Thu, Oct 4, 2018 at 11:59 PM Anders Rundgren <
> anders.rundgren.net@gmail.com> wrote:
>
>> Hi Christopher,
>>
>> The scheme obviously only supports signing JSON "as is".
>> However, this is compatible with JSON-LD as well.
>>
>> If you want to support LD canonicalization that is also possible but it
>> would have to be supplied as a "crit" extension like:
>>
>> {
>>     "Some properties to be signed":...,
>>      .
>>      .
>>     "__cleartext_signature" {
>>       "crit": ["json-ld-canonicalization"],
>>       "json-ld-canonicalization": {
>>         "algorithm": "JSON-LD Algorithm Identifier",
>>         "sha256hash": "h64slk97gG9Ff7gg"
>>       },
>>       .
>>       .
>>       "signature": "h5e4se3w3wfgr5566d5e5s44w4waa33a3a3a3a33q"
>>     }
>> }
>>
>>
>> Regarding the state of this work-item from a standards perspective, the
>> question seems to be "who is your customer" which I don't have a good
>> answer to.  The JSON and JOSE WGs have ceased their activities and the
>> members appear to rather be targeting CBOR these days.  Personally, I don't
>> believe there is a need for CBOR for dealing with "Information Systems".
>>
>> There is an even simpler solution in the workings:
>> https://github.com/cyberphone/jws-jcs#combining-detached-jws-with-jcs-json-canonicalization-scheme
>> on-line
>> <https://github.com/cyberphone/jws-jcs#combining-detached-jws-with-jcs-json-canonicalization-schemeon-line>
>> demo: https://mobilepki.org/jws-jcs/home
>>
>> Regards,
>> Anders
>>
>> On 2018-10-04 09:25, Christopher Allen wrote:
>> > (resending CC'ing all as I didn't in first iteration of this)
>> >
>> > On Thu, Oct 4, 2018 at 3:39 AM Anders Rundgren <
>> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>
>> wrote:
>> >
>> >     There is yet another alternative based on "pure JSON":
>> >     https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01
>> >
>> >     It seems to address the issues below.
>> >
>> >
>> > On Wed, Oct 3, 2018 at 8:39 PM Anders Rundgren <
>> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>
>> wrote:
>> >
>> >     On 2018-10-04 03:27, Kim Hamilton Duffy wrote:
>> >     There is yet another alternative based on "pure JSON":
>> >     https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01
>> >
>> >     It seems to address the issues below.
>> >
>> >
>> > The challenge is that this draft is completely dependent on the
>> canonicalization scheme, which is
>> >
>> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
>> >
>> > What I’ve heard repeatedly is that this canonicalization scheme doesn’t
>> address some number of other requirements, including supporting graph data
>> models.
>> >
>> > I too would like to understand more precisely what these other
>> requirements are so I can effectively articulate them.
>> >
>> > -- Christopher Allen
>> >
>>
>>