SSI-Streetcred: Creation of the Streetcred entities

[FarrandTom]

Context: We will be using Streetcred as an easy way to get up and running with a Hyperledger Aries cloud controller and wallet. Streetcred has a number of different concepts which we will be required to implement:

• Organisations: Act as the issuers of verifiable credentials (VCs).
• Credential definitions: Define the format which VCs can take.
• Verification templates: Define what data to request from a wallet when a verification is required.

Issue: Unsure on how these entities should be managed across the development efforts, and how their credentials, e.g. the access tokens for an organisation, should be shared.

• Is it best practice that each developer will have a dummy organisation, and set of their own templates?
• We will need to create a master account which represents the true Opus account for when users begin to sign up. Who owns this account? Can we add multiple developers to this account?
• How flexible are credential definitions to modification further down the line?
• Do you want a single master credential definition for each usage pattern or can you have duplicates? Does it make a difference?

Next steps: This is a discussion point more than anything and so thoughts and feedback would be greatly appreciated.

[wip-abramson]

Couple of points from me.

For development purposes:

• We should between us come to a decision of the (single?) schema that we will use at least for development purposes.
• The ID for this schema should then be included in the repo .env-template file.
• Each developer should create their own organisation on streetcred.
• They then must write a credential definition against the schema identifier as defined in the Readme.
• Verifications is a bit different as nothing is stored on the ledger, but I suggest we create a template and include in the repo so all devs can write the same template their cloud agent.

There is a syntax issue here too. We might want a single master credential schema, but every organisation must create a credential definition against this schema before they can issue them.

For production, it is possible to version credential schema however every time a schema is updated organisations that wish to issue that schema must write new definitions to the ledger.