-
Notifications
You must be signed in to change notification settings - Fork 5
Content and Actions Model
**Note: Mentions of "list" could be displayed as "table" or in other display visual design.
- Default page for app, i think
- EG A doc preview screen for a List PDF
User Profile info page (lowest priority)
- Lists current PDF documents (would be other doc types in future)
- Any requests for signatures on files should be conspicuous and the user should be able to say "don't show notice or alert to sign this again" sort of thing but the file should still carry the "state" of "signature requested".
- This page (or view) shows a list of the Attestations and Claims for that user at that time.
- See: https://github.com/alexfigtree/CoreID/wiki/Potential-Claims-and-Attributes for the current list.
- In future this would include other data types (KML/location data of the user, contacts, calendar, receipts, health records, etc)
Would be list of files like this:
- Verification of Employment
- Verification of Deposits
- Verification of Insurance
- FICO Score
- Address
- Blockchain Public Key
When user inspects any one of these pages they will see content as described here for each item listed above and other: https://github.com/alexfigtree/CoreID/wiki/Potential-Claims-and-Attribut
-
This a HTML/CSS display of the contents of the JSON attestations and claims file objects, named on that wiki page here https://github.com/alexfigtree/CoreID/wiki/Potential-Claims-and-Attributes
-
EG For Employment will show name of employerm addy of employer years and
-
We need to figure out a visual display that indicates this data is verified
- The user can 1 select a file to sign from the file list (and also perhaps from the file view directly if we wish) and 2 take an action to "sign the file".
- The above action should display the file to use for the to inspect and provide a "sign" action if/when they are ready to execute their digital signature on that file.
- The result of the signature function changes the "state" of the file in the file list from unsigned to signed by the user.
- This requires selection of a file and use takes action to share file.
- When above happens the user should be presented a type-in filed to identify the other user with whom to share the file. This would presumably email or otherwise transmit the file.
- This requires selection of a file and use takes action to sign file.
- When above happens the user should be presented a input field to identify the other user to whom a request for signature is to be transmitted. This will be an email for our demo and could be a name.id, CU Member ID or public key or other identifier in future.
This is a "notice" action that requires only that the user has seen the information on screen that they have a received a request to sign a file.
- This action is another way for a file to be added to the users file store (a PDF for example from external user)
- The notice should include a method (like a thing to click) for the user to 1 see the file they are requested to sign (it should appear in a doc list too) and 2 be able to sign it if they so choose.