...
This is a generical 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 case.
...
Term | Definition |
|---|---|
| Holder | The human user of the mobile credentials. The first person (I, we) of this story. |
| Device | A smartphone or other mobile computing device including the operating system (OS) software. |
| Wallet | An application running on the OS that has access to protected storage on the device. Often called a native app. |
| Issuer | of a mobile credential. |
| Verifier | of one or more mobile credentials. |
| Credential | A protected structure given by the issue to the holder's wallet. For example the mdoc from ISO 18013-5 |
| Presentation | A protected message given by the holder's wallet to the verifier. It will contain only that user data that is needed for the purpose of the transaction. |
| Purpose | A structured list of attributes and the retention permissions from some trusted authority. For example the US TSA list of attributes needed to enter an airport. FI 2.8.12 call this a "type of data use" |
| PDP | Policy Definition Point (aka policy issuer) This could be a government or the business that owns the Verifier) |
| PEP | Policy Enforcement Point (aka policy verifier) |
...
Data Retained
Diagram
Steps
Primary
...
User Journey
| # | 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 |
Secondary Use Case(s)
...
| 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 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 |
Verifier User Journey - establishing the policies to present to the user by the verifier
This can be performed by any relying party at any time but must be prior to the request sent to the user.
| # | Step | Description |
|---|---|---|
| 1 | ||
| 2 | ||
| 3 | ||
| 4 |
Sequence Diagram
...