Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nesting Signatures with JWT #1

Closed
msporny opened this issue Nov 28, 2016 · 3 comments
Closed

Nesting Signatures with JWT #1

msporny opened this issue Nov 28, 2016 · 3 comments
Labels
security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response.

Comments

@msporny
Copy link
Member

msporny commented Nov 28, 2016

There is a concern that nesting multiple signatures with JWT results in an exponential increase in the amount of data that needs to be stored. Each "envelope" needs to encapsulate the entirety of the signed data as a base-64 encoded blob. This is an issue for endorsements, counter-signatures, and M-of-N signature schemes. How will nested signatures be supported using JWTs?

@msporny msporny added the security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. label Nov 28, 2016
@jonnycrunch
Copy link
Contributor

jonnycrunch commented Nov 29, 2016

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

@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
Copy link
Member Author

msporny commented Feb 13, 2018

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.

dlongley pushed a commit that referenced this issue Oct 29, 2018
msporny pushed a commit that referenced this issue Dec 12, 2018
Merging head fork back into mine
msporny added a commit that referenced this issue Nov 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response.
Projects
None yet
Development

No branches or pull requests

4 participants