Added ability to load custom demos on the fly using a json file. The demo will load the custom character and add the schema/credDef to the ledger if needed. The new character will then be in the demo's state and the user can interact with it as needed. I refactored a lot of the existing code to make the existing characters more in line with JSON configs:
The json configurations are structured like so:
Every character has the following attributes: name, type, image, description (optional), revocationInfo, progressBar, onboarding and useCases
progressBar:
The progress bar is use to track where the user currently is in the onboarding process. Here is the structure of the progressBar:
The name attribute serves as the progress id, the light and dark icons are what should be displayed in the light and dark mode of the demo. The onboardingStep attribute references the screenId of any of the onboarding screens. In this screenshot we are at the SETUP_START onboarding screen, so everything in the progress bar is highlighted up to that point:
onboarding:
The onboarding section is where the user goes through and receives credentials, it's also where the showcase educates the user about verifiable credentials and the business flow. Here is some of the onboarding structure:
The basic screen contains 4 key attributes: screenId (used to track the screen and perform various actions when the user is on a screen), title (the text to display as the page title), text (the main page text that describes what is going on in the business flow), and image (the main image)
Special onboarding screens:
There are 6 types of special onboarding screens. The type of screen is dictated by it's screenId
PICK_CHARACTER: Every character configuration must have this screen, and it must be the first screen in the onboarding array. This screen gives the content for the character selection screen when you click on your character.
SETUP_START (OPTIONAL): Usually used as a preamble to describe to the user the purpose of the verifiable credentials and a little bit about the showcase.
CHOOSE_WALLET (OPTIONAL): This screen is used to instruct the user on what wallet technology they should use and where they can download it.
CONNECT* (OPTIONAL): If the screenId starts with CONNECT then there will be a QR code that the user can scan to form a connection. The showcase assumes that the next screen is an ACCEPT* screen and will skip to the next screen once the connection is completed. This screen has some additional attributes: issuer_name the name of the connection alias to use, this will show up in the wallet as the name of the issuer.
ACCEPT* (OPTIONAL): If the screenId starts with ACCEPT then the showcase will try and issue a set of credentials to the current connection id (formed during the CONNECT step). This screen has some additional attributes: credentials the list of credentials to issue the user on this screen. Here is the structure of the credential object: The showcase will automatically publish the schema and credential definition ID to the ledger. If you want to make any changes to the structure of the schema (ie: adding attributes, changing the name, etc), you will need to increment the version field so that you aren't trying to push a duplicate schema to the ledger. Note you do not need to increment the version if you are only changing the attribute values, for instance, changing the student_first_name from Bob to Mike
SETUP_COMPLETED: This screen is required and must be the last screen in the onboarding list. This screen usually gives a summary of the credentials that the user received and what they can do with them.
If the screen has any other screenId then it will just be treated as a regular screen without any special functionality
useCases:
The UseCase section is where the user proves things about themselves using the credentials they were given during onboarding. Like the onboarding section, the useCase section has a list of screens, the base screen object has 4 attributes: screenId, title, text, image. Here is some of the useCase structure:
useCase screens:
There are 6 different useCase screens, all of them have at least 4 attributes (screenId, title, text, image). Like the onboarding screens, the type of screen is dictated by the screenId.
START: This screen is required and must be the first screen in the useCase screen list. This screen describes what the user will be doing in the useCase.
INFO* (OPTIONAL): If the screenId starts with INFO then this screen provides generic information if you want to give the user extra details.
CONNECTION* (OPTIONAL): If the screenId starts with CONNECTION then the showcase will create a QR code to allow the user to connect. This screen has some additional attributes: verifier contains a name and an optional icon attribute, this lets the wallet know who the proof request is coming from.
PROOF* (OPTIONAL): If the screenId starts with PROOF then the showcase will issue a proof request to the connection formed at the CONNECTION screen. This screen has some additional attributes: requestOptions this attribute tells the showcase what to request in the proof request. Here are two example requestOptions objects: The title and text attributes here show up in the bc wallet on the proof request screen. The requestedCredentials object can request both attributes or predicates from a credential. The name attribute is the schema name of the credential to request, and the icon is used in the showcase proof request screen. The requestedAttributes object is used to request the value of a certain attribute, the requestedPredicates object is used for predicate proofs (to verify that a credential attribute is over or under a certain value).
PROOF_OOB* (OPTIONAL): If a screenId starts with PROOF_OOB then the showcase will do the same thing as in the PROOF screen except it doesn't require a connection.
STEP_END: This screen is required and must be at the end on the useCase screen list. This screen provides a summary of what the user did throughout the usecase.
revocationInfo:
The revocation info is mainly used to add wording and images to the revocation section of the demo. Here if the structure:
Added ability to load custom demos on the fly using a json file. The demo will load the custom character and add the schema/credDef to the ledger if needed. The new character will then be in the demo's state and the user can interact with it as needed. I refactored a lot of the existing code to make the existing characters more in line with JSON configs:
The json configurations are structured like so: Every character has the following attributes:
name,type,image,description (optional),revocationInfo,progressBar,onboardinganduseCasesprogressBar:
The progress bar is use to track where the user currently is in the onboarding process. Here is the structure of the progressBar:
The
nameattribute serves as the progress id, the light and dark icons are what should be displayed in the light and dark mode of the demo. TheonboardingStepattribute references the screenId of any of the onboarding screens. In this screenshot we are at theSETUP_STARTonboarding screen, so everything in the progress bar is highlighted up to that point:onboarding:
The onboarding section is where the user goes through and receives credentials, it's also where the showcase educates the user about verifiable credentials and the business flow. Here is some of the onboarding structure:
The basic screen contains 4 key attributes:
screenId(used to track the screen and perform various actions when the user is on a screen),title(the text to display as the page title),text(the main page text that describes what is going on in the business flow), andimage(the main image)Special onboarding screens:
There are 6 types of special onboarding screens. The type of screen is dictated by it's screenId
PICK_CHARACTER: Every character configuration must have this screen, and it must be the first screen in the onboarding array. This screen gives the content for the character selection screen when you click on your character.SETUP_START (OPTIONAL): Usually used as a preamble to describe to the user the purpose of the verifiable credentials and a little bit about the showcase.CHOOSE_WALLET (OPTIONAL): This screen is used to instruct the user on what wallet technology they should use and where they can download it.CONNECT* (OPTIONAL): If the screenId starts withCONNECTthen there will be a QR code that the user can scan to form a connection. The showcase assumes that the next screen is anACCEPT*screen and will skip to the next screen once the connection is completed. This screen has some additional attributes:issuer_namethe name of the connection alias to use, this will show up in the wallet as the name of the issuer.ACCEPT* (OPTIONAL): If the screenId starts withACCEPTthen the showcase will try and issue a set of credentials to the current connection id (formed during the CONNECT step). This screen has some additional attributes:credentialsthe list of credentials to issue the user on this screen. Here is the structure of the credential object:The showcase will automatically publish the schema and credential definition ID to the ledger. If you want to make any changes to the structure of the schema (ie: adding attributes, changing the name, etc), you will need to increment the version field so that you aren't trying to push a duplicate schema to the ledger. Note you do not need to increment the version if you are only changing the attribute values, for instance, changing the
student_first_namefromBobtoMikeSETUP_COMPLETED: This screen is required and must be the last screen in the onboarding list. This screen usually gives a summary of the credentials that the user received and what they can do with them.If the screen has any other screenId then it will just be treated as a regular screen without any special functionality
useCases:
The UseCase section is where the user proves things about themselves using the credentials they were given during onboarding. Like the onboarding section, the useCase section has a list of screens, the base screen object has 4 attributes:
screenId,title,text,image. Here is some of the useCase structure:useCase screens:
There are 6 different useCase screens, all of them have at least 4 attributes (
screenId,title,text,image). Like the onboarding screens, the type of screen is dictated by the screenId.START: This screen is required and must be the first screen in the useCase screen list. This screen describes what the user will be doing in the useCase.INFO* (OPTIONAL): If the screenId starts with INFO then this screen provides generic information if you want to give the user extra details.CONNECTION* (OPTIONAL): If the screenId starts with CONNECTION then the showcase will create a QR code to allow the user to connect. This screen has some additional attributes:verifiercontains a name and an optional icon attribute, this lets the wallet know who the proof request is coming from.PROOF* (OPTIONAL): If the screenId starts with PROOF then the showcase will issue a proof request to the connection formed at theCONNECTIONscreen. This screen has some additional attributes:requestOptionsthis attribute tells the showcase what to request in the proof request. Here are two examplerequestOptionsobjects:The title and text attributes here show up in the bc wallet on the proof request screen. The
requestedCredentialsobject can request both attributes or predicates from a credential. The name attribute is the schema name of the credential to request, and the icon is used in the showcase proof request screen. TherequestedAttributesobject is used to request the value of a certain attribute, therequestedPredicatesobject is used for predicate proofs (to verify that a credential attribute is over or under a certain value).PROOF_OOB* (OPTIONAL): If a screenId starts with PROOF_OOB then the showcase will do the same thing as in the PROOF screen except it doesn't require a connection.STEP_END: This screen is required and must be at the end on the useCase screen list. This screen provides a summary of what the user did throughout the usecase.revocationInfo:
The revocation info is mainly used to add wording and images to the revocation section of the demo. Here if the structure: