# A Blockchain Self-Sovereign Identity for Open Banking Secured by the Customer's Banking Cards
## 4 Proposed Solution
### SSBI Components  
The main platform components are:  
* Mobile app and agent operations;
* Server-side application to handle communication between parties, access to Blockchain, and smart card connections;
* Applet to install on the banking card;
* Veramo layer for DID and VC management.  
Figure 5 shows the UML diagram presenting the designed classes to implement the SSBI platform. The off-chain class handles the storage of verifiable credentials and identity attributes, in addition to allowing the interface with agent application calls and providing one instance per entity. For the customer, this application is deployed as a smartphone app,  
Figure 4: Proposed architecture customized for SSBI, extended from the model in [7].  
although it can be implemented as a PC application. The identity operations include DID operations and connectivity with Blockchain during registration, modification, and DID revocation. The entity class has an interface to the pairwise DID class. The JavaCardApplet class provides several functions to perform cryptographic operations, such as signing DIDs and VCs, and holding and generating keys, in addition to state and PIN management. The connector provides handling and exchange of the APDU command (main application protocol data unit) between the app and the card through NFC connections or a USB smart card reader.  
According to [PERSON] [35], the content of a certified document must include:  
* URI for a unique identity credential (a set of claims by the issuer about a subject);
* such a credential is associated with a DID.
* URI to identify the issuer (issuer DID).
* URI for credential type.
* URI for protocols and terminology to help parties read the credentials.
* Cryptographic proof of the issuer.
* Claims data, and the statement or characteristics about a subject (metadata).
* Issuance date.
* Expiration date.
* Location of the credential status (such as a smart contract reference).  
The format of VC and certificate exchange has to be in a protected and secure digital channel such as JSON-LD, as proposed by European Blockchain technical specifications [36] and according to the DID standards of W3C [17], as follows:  
Figure 5: UML class diagram adapted from [7].  
* The context of data description inside JSON-LD to ensure common understanding between parties.
* Identifiers--according to W3C, a DID should be used to identify issuers, credential subjects, persons, things, and verifiable IDs or attestations.
* Types, such as W3C (Verifiable Credential), in addition to other types.
* Issuer--the public institution, government entity, or an organization that is trusted to issue a specific type of VC, typically a bank or financial institute for our case.
* Credential subject, which is a DID to identify a person, thing, or organization.
* Claims, which constitute a verifiable ID or attestation for a semantic statement to a certain value about an attribute of a DID subject such as (.dateOfBirth).
* Issuance date is the date the claim becomes valid, and it is not mandatory that it be the same as the issuance date of the VC. Expiration date is the date when the claim should become false or expire. Status is the current claim status, such as active, suspended, or revoked.
* Proofs--at least one proof mechanism should exist to allow the verify operations.
* Optional extensibility--as per W3C, extensions of the data model can be used to add more attributes.  
Moreover, [PERSON] (2016) considers it a mandatory feature to allow public querying and resolving in the Blockchain of all involved parties' DIDs.