Re: JWT credentials

Thanks Anders. It does seem to address all of those points except possibly
the last, which (from what I understand) may not _necessarily_ be high
priority in the scenarios where JWTs tend to be used. I’ve been trying to
pick apart the use cases myself, so everything I say on the topic is
ill-informed and naive...

I’m curious about a couple of things (comments welcome from anyone):
- how the IETF process works, whether this draft is near adoption and
whether this is used currently
- is there any way this can be wedged into the “LD” signature suites, where
LD context is a no-op but there’s a well documented canonicalization process


On Wed, Oct 3, 2018 at 8:37 PM Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2018-10-04 03:27, Kim Hamilton Duffy wrote:
> > Hi Carlos,
> > The main write-up I've seen is the bulleted list in this section:
> >
> https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/blockchain-extensions-for-linked-data-signatures.md#json-normalized-clear-text-signatures
>
> Hi,
>
> 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.
>
> Anders
>
>
> >
> > I'll paste them here:
> >
> >   * JWTs cannot be natively stored in document-based storage engines
> (like MongoDB and CouchDB) without decoding them, which removes the digital
> signature information
> >   * JWTs cannot be nested within each other easily, requiring multiple
> nested base-64 encodings with duplicated data to support nested signatures
> >   * JWTs do not easily support multi-signature schemes, meaning that
> they can't be chained together without duplicating the data for each
> chained signature
> >   * JWTs are not JSON, which most developers expect when publishing,
> consuming, and working with data. While it's true that you can base-64
> decode the data, you then lose the signature and have to track it through
> some other means if the signed object in question needs to be transmitted
> to a remote system.
> >   * You cannot express Linked Data in a syntax-agnostic way and are
> forced to create a signature on a JSON-LD document, which binds the
> signature to the JSON-LD syntax rather than making the signature more
> syntax agnostic.
> >
> > Despite all of this, they are still widely used, and so (I believe it's
> still there) the VC data model mentions how to support them.
> >
> > I'm interested in all of this from an interoperability perspective,
> which is why I'm hoping to refresh discussion on this point.
> >
> > thanks,
> > Kim
> >
> > On Wed, Oct 3, 2018 at 3:32 AM Carlos Bruguera <cbruguera@gmail.com
> <mailto:cbruguera@gmail.com>> wrote:
> >
> >     Hello everyone. Recently I've been evaluating JWT vs JSON-LD
> signatures as the preferred aproach for a Vcreds implementation I'm working
> on, and I just stumbled into this note in the VC data model document <
> https://w3c.github.io/vc-data-model/#json>:
> >
> >         A number of the concerns have been raised around security,
> composability, reusability, and extensibility with respect to the use of
> JWTs for Verifiable Credentials. These concerns will be documented in time
> in at least the Verfiable Claims Model and Security Considerations section
> of this document.
> >
> >
> >     Could anyone provide more details on what are these concerns and
> potential issues with regard to the use of JWT for credentials? Thanks
> beforehand.
> >
> >     Regards,
> >     Carlos
> >
> > --
> > Kim Hamilton Duffy
> > CTO & Principal Architect Learning Machine
> > Co-chair W3C Credentials Community Group
> >
> > kim@learningmachine.com <mailto:kim@learningmachine.com>
> >
>
> --
Kim Hamilton Duffy
CTO & Principal Architect Learning Machine
Co-chair W3C Credentials Community Group

kim@learningmachine.com