Page Status
...
:
| Status | ||||||
|---|---|---|---|---|---|---|
|
Priority: Status subtle true colour Green title P2
...
This is one of the broad list of abstract user stories focused on Privacy Enhanced Mobile Credentials (PEMC) on a mobile device platform.
...
Description (User Story)
This is a generical generic use journey that involves the verifier submitting a request for user information and the user responding with the data that they are willing to share. Comparisons with other recommendations include FI = https://www.future-identity.org/recommendations
Narrative
What happens during the use caseSince this is a generic use case it only talks at a high level about the user acquiring a phone, wallet and appropriate credentials and then using them to access a desired resource.
Secondary Use Case (optional)
...
| Element | Detail | Notes |
|---|---|---|
| As a, | User of a web site | |
| I want | to acquire access to some resource | |
| so that | So that i I can download content of or physically access some venue | |
| Acceptance Criteria - what the user should know | ||
| Verifier or Brand | and who else sees the data (that may be in the TOU) | |
| Purposes that they can understand | and whether they are required or optional | |
| Retention Time | if longer that the life of the transaction | |
...
| # | Step | Description | Issues |
|---|---|---|---|
| 1 | acquire device | typically a smartphone from a telco | |
| 2 | acquire wallet | can be resident on the phone or acquired from a app store. | |
| 3 | acquire creds | from issuers like state DMV's or healthcare providers | |
| 4 | determine a goal | typically travel to another country, go to a ball game or get access to a video | |
| 5 | go to a web site for access ticket | only needed if access requires check-in or if the user wants assured access | |
| 6 | go to location of resource | either physical site or digital site | |
| 5 | select type of access | optional depending on resource, the purpose for the visit may be established here | |
| 6 | verifier sends request for data | at this point the purpose of the visit and the policy of the rules engines are queried | This is a bundled request which violate violates FI 2.8.12 |
| 7 | user wallet presents to user | the wallet converts the requestor name and purposes into a UI for the user to see | |
| 8 | user chooses | if some purposes have been added at the option of the verifier, the user can remove them | |
| 9 | presentation of user data | the wallet sends the presentation to the verifier based on the user request | |
| 10 | acceptance by verifier | this is the PEP = policy enforcement point, the user is granted access or not | |
| 11 | remediation | if the user is not granted access they should know why and how this can be rectified, usually by directing the user to acquire additional credentials. |
Verifier User Journey - establishing the policies to present to the user by the verifier
...
Tom Jones
Related Material
Resources and Links
The following is taken from the Future Identity document (see above) and seems relevant to this use case.
- Some messages suitable to deliver in plain English during provision process (not just in T&C): (2.7.1)
“Your [Insert name of App] data will not be released from your device [or the issuing authority] without your permission.”
“If you are asked to release data you feel uncomfortable sharing, do not share it”
“If your [mDL] data changes on record with the state, it will be updated on your [app] shortly after is is received by the [issuing authority]”
“If you believe your digital identity data is being misused, report it [here]” - User receives Digital ID lifecycle notifications, for example: (4.4.3)
“Driving privilege suspended pending renewal of physical credential, credential may be used for Identity purposes only”
“Driving privilege suspended as per state law, credential may be used for Identity purposes only” - The follow is considered to be bad advice is is to be avoided. It will not usually be of any use to the user (through too much detail or too technical collections of terms) and will be very annoying.
- User receives notice of each data field being requested by the relying party and has the user has the option to approve or decline sending each field before sending the data to the relying party. (4.4.4)
- User Consent to release each field of data, or decline transaction in physical domain, consistent with the ISO 18013-5 standard supported. (5.2.2)
...
Page Tasks
- Type your task here, using "@" to assign to a user and "//" to select a due date