Nesting Signatures with JWT about vc-data-model

[jonnycrunch]

uPort may have solved this by wrapping the hash of the content using IPFS and signing the hash. I will look up the solution and update this issue.

uPort whitepaper describing the ipfs hash: https://uport.me/library/pdf/whitepaper.pdf

I may be mistaken...looks like it is an array of JWTs that are atomic attestations (with signatures), not nested as that would obviously change the ipfs hash.

Nesting is accomplished by creating new attestation with content:

{ ...
"subject":{"uportId":"0xf25a8c2ec....057db9f7"}
"claim" : { .... }
...
}

This is stored as a separate ipfs file and then linked via the ethereum smart contract.

Overall, elegant solution. However, as @msporny pointed out during the call privacy would be an issue and thus not all implementers would use ipfs.

[coder5876]

@jonnycrunch: Yeah in uPort we haven't dealt with multiple signature on the same data yet. I guess a question here is if a verifiable claim needs to be a JWT? You could imagine a scenario where you interpret an array of JWTs as a multisig on the same data.

[msporny]

The latest Linked Data Signatures spec supports multisig sets and chains: https://w3c-dvcg.github.io/ld-signatures/#multiple-signatures

The latest RsaSignature2018 cryptography suite supports JOSE JWS-style signatures: digitalbazaar/jsonld-signatures@f583bd4

Given that it's been 4+ years and there isn't a spec for Verifiable Credentials expressed as a JWT, and given that no one is implementing JWT-based Verifiable Credentials. I'm suggesting that we close this issue for the 1.0 work. We can always support JWT-based VCs later if someone decides to write a spec encapsulating VCs in JWTs.

Notice: Closing this issue on or after 2018-2-20.