Selective disclosure for credentials and presentations using RSS signatures

[edchapman88]

• Presentations containing partially redacted credentials.
• Issuer to issue a credential with an RSS signature
• Holder to derive a 'redacted' RSS signature to put on a redacted credential

[edchapman88]

A look at the existing ssi credential proof/verification code:

• Credentials include Proofs
  • A Proof must have the field type_:String populated
  • The proof_value field is of type Option<String>
• Credential's are verified with the .verify() method - though this is marked with a TODO to be factored out of the Credential api
  • The method calls .verify() on the Proof(s) in the credential
  • Proof.verify() calls LinkedDataProofs::verify() which uses a function to parse the type_ field on the proof.

This function is a problem because it prevents us from adding a new proof type.

• The function returns an &dyn ProofSuite which could potentially be implemented for an RSS proof.
• The rest of the LinkedDataProofs::verify() function uses the verify method on ProofSuite (which would work if ProofSuite was implemented for RSS).

Suggestion:

• Implement ProofSuite for RSS
• Amend TrustchainAPI::verify_credential function to factor out 'to-be-removed' Credential.verify(), the new implementation should:
  • Check the type_ field of the proofs on the credential:
  • If RSS, verify directly with RSS.verify(proof) (where RSS implements ProofSuite)
  • If !RSS, call .verify() on the proof which will use the existing proof suite selection fucntion and support all of the existing proofs.
• TrustchainAPI::verify_presentation() function already calls TrustchainAPI::verify_credential() on each of the credentials which will work with RSS proofs without amendment.

Additional notes:

• There is a .verify() method on Presentation that is not used in our TrustchainAPI::verify_presentation() implementation. It is marked as 'to be factored out of VC and VP' along with the Credential.verify() as mentioned above.

[edchapman88]

Update:

• Reviewing the RSS implementation, it will not be possible to use the ssi Credential struct for redactable VC's because it contains unordered HashMaps.
• An additional benefit to creating a new credential type (using BTreeMaps in place of the HashMaps) is the previously developed CanonicalFlatten macro can be derived on any new "crate-local" types
• External types used within the new credential type may implement a new "crate-local" Flatten trait to manually implement the behaviour and api of CanonicalFlatten without encountering the orphan rule.

[sgreenbury]

Additional requirements:

• New endpoint on trustchain-http to issue RSS specific credentials
  • dummy implementation on branch 56-http-verifier-rss with route "vc_rss/issuer/:id", which uses the same dummy RSS key pair to sign all credentials
• Mechanism for retrieving the RSS public key in a verifiable way: is it compatible with SSI types? If not, is there a way to embed in the DID document (as the Trustchain attestor proof is currently) and get the resolver to find e.g. TrustchainRSSPublicKeys service.
• Solution required for signing a presentation containing an RSS credential:
  • Presentation.generate_proof() errors due to linked data checks on both the fields in credential_subject and the proof.type_ field.
  • Eg. signing an RSS presentation of the degree credential works if the degree>type field is not redacted to "null", which fails the linked data check; and if the proof.type is hacked to be "EcdsaSecp256k1Signature2019" instead of "RSSSignature".
  • Currently in the RSS case, the presentation is not signed by the holder during presentation - and this will require an edit to TrustchainAPI::verifyPresentation to skip the check on the (non-existent) holder's proof in the RSS case.
    • The RSS case should be distinguished using the type field on the credential embedded within the presentation.
    • The type could perhaps be set to [ 'VerifiableCredential', 'RSSCredential' ] when the credential is created (and crucially before the issuer signs the credential).
    • This prevents an attack where an edited non-RSS credential is presented to the verifier as an RSS credential in order to bypass holder proof verification. (The attack is not prevented if the proof.type field is used by the verifier to branch on the RSS case, because this field is not signed by the issuers proof).

[edchapman88]

A frozen version of the end of hack week demo of this feature-limited RSS integration is documented here.

Development of a new version, building with a fork of ssi, has started on 115-selective-disclosure-ssi-update.

115-selective-disclosure branch remains open, with unsuccessful attempts at using JWS signatures to authenticate RSS presentations (the solution is not reliable, because the ssi implementation for jws-encoding presentations is non-deterministic due to the use of unordered HashMaps).