Create PSM_Hashes.asc

docs/PSM_Hashes.asc

@@ -0,0 +1,94 @@
+= Private Metadata Sharing - Private Sharing Multi Hashes
+:author: Alastria
+:revnumber: 0.1
+:revdate: 03-10-2019
+:numbered:
+:imagesdir: img
+:icons: font
+:tip-caption: :bulb:
+:note-caption: :information_source:
+:important-caption: :heavy_exclamation_mark:
+:caution-caption: :fire:
+:warning-caption: :warning:
+:toc:
+
+(Version: {revnumber}, Version Date: {revdate})
+
+
+== Introduction: the life cycle of a Credential/Presentation
+The lyfe cycle of Verifiable Credentials (VC) and Verifiable Presentations (VP) should be registered on the blockchain to have digital evidences of the state changes the VC/VP has passed trough. This recording should be done in a privacy preserving way at different levels. As we have seen in the model and interaction definition, VC and VP are sent directly from the Issuer to the Subject (VC) or from the Subject to the Service Provider (VP), so no personal information is exposed.
+
+Recording the state changes does not expose the content of the VC/VP but can potencially expose the relationship between the different parties sharing VC/VP. This potential exposure of the relationship is what must be avoided in the implementation of a Private Metadata Sharing Mechanism that in Alastria Id is implemented using PSM Hashes.
+
+Since an unverifiable credential is useless, all credentials in Alastria ID are verifiable. This is why the terms "Verifiable Credential" and "Credential" can be used interchangeably and are equivalent. Same thing happens with presentations, whose terms are "Verifiable Presentation" and "Presentation". From now on, a Service Provider can also be referred as a SP.
+
+== Summary of Private **Credential** Management Requirements
+- Subject should be able at any time to revoke (withdraw) Presentations, registering the revocation on the blockchain. This is effectively registering the fact that the Subject has revoked consent to the information contained in the individual credentials which comprise the Presentation, for the business purpose that was specified explicitly in the Presentation.
+- The Issuer should request the reception of the registration. If the Subject does not perform it, the Issuer could revoke the VC.
+- Should the issuer request the reception registration and the subject not perform it, the Issuer can revoke the VC.
+- Subject should be able to mark a Credential as deleted in the Registry. Anybody having a copy of the Credential must stop using it and delete its copy.
+- Third parties should not be able to realize any Issuer-Subject relationship from the above actions.
+- The relationship between the registered actions on the blockchain and the Credential must only be known to those having produced or received the Credential off chain.
+** Issuer.
+** Subject (sent by the Issuer).
+** Service Provider (sent by the Subject).
+
+== Summary of Private **Presentation** Management Requirements
+- SP should be able to register a Presentation reception, this will ensure the Subject that the Presentation has been properly received by the SP and for aspecific Purpose.
+- Subject should be able at any time to revoke (withdraw) Presentations, registering the revocation on the blockchain.
+- Should the subject request the reception registration and the SP not perform it, the Subject can revoke the VC.
+- When a Presentation is revoked by the Subject, the SP should perform the deletion (as required by GDPR) and must confirm the deletion on the blockchain.
+- Third parties should not be able to realize any Subject-SP relationship from the above actions. Not even the Issuer could have any clue about Credential usage inside Presentations.
+- Presentations registered actions must be unlinkable to Credentials registered actions.
+- The relationship between the registered actions on the blockchain and the Presentation must only be known to those having produced or received the Presentation off chain.
+** Subject.
+** Service Provider (sent by the Subject).
+
+== Implementation overview
+- Registration is made on the Blockchain by the Credential Registry Smart Contract using the Alastria DID of the Issuer (for Issuer actions over VC), the Alastria DID of the Subject (for Subject actions over VC and VC) and the Alastria DID of the Service Privider (for Service Provider Actions over VP).
+- To avoid the linking of the Issuer actions and those of the Subject over the very same Credential two **different references** will be used for each Credential.
+- To avoid the linking of the Subject actions and those of the Service Provider over the very same Presentation two **different references** will be used for each Presentation.
+- Those references should not be guesable without the credential/presentation, but easily calculable from the credential/presentation.
+
+== Implementation details: PSM Hashes
+In order to create two different references to the same credential, Alastria Id model will use two Private Sharing Multi (PSM) hashes derived from the Credential:
+
+* IssuerCredentialHash: used to revoke the Credential by the Issuer.
+* SubjectCredentialHash: used to register and delete the Credential by the Subject.
+
+The same applies to Presentations:
+
+* SubjectPresentationHash: used to revoke (withdraw) the Presentation by the Subject.
+* SPPresentationHash: used to confirm reception and deletion of the Presentation by the SP.
+
+=== IssuerCredentialHash
+Is calculated from the concatenation of the Credential and the Issuer Alastria DID.
+
+That is: +
+IssuerCredentialHash == hash (Credential & IssuerAlastriaDID)
+
+Graphically, the IssuerCredentialHash calculation is depicted in the image:
+
+image::IssuerCredentialHash.PNG[issuer, caption="IssuerCredentialHash calculation"]
+
+=== SubjectCredentialHash
+Is calculated from the concatenation of the Credential and the Subject Alastria DID.
+
+That is: +
+SubjectCredentialHash == hash (Credential & subjectAlastriaDID)
+
+Graphically, the SubjectCredentialHash calculation is depicted in the image:
+
+image::SubjectCredentialHash.PNG[issuer, caption="SubjectCredentialHash calculation"]
+
+=== SubjectPresentationHash
+Is calculated from the concatenation of the Presentation and the Subject Alastria DID.
+
+That is: +
+SubjecPresentationHash == hash (Presentation & subjectAlastriaDID)
+
+=== SPPresentationHash
+Is calculated from the concatenation of the Presentation and the SP Alastria DID.
+
+That is: +
+SPPresentationHash == hash (Presentation & SPAlastriaDID)