...
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". It is similar to the "Identity Bundle" in the FI 5.2.4 except that a broader coalition of issuers and relying parties need to establish the purpose and the data to be contained in the purpose. It is possible, but ugly, for each purpose to be a single datum. It is more likely that a purpose would be to "create a reward account" or similar. It must be clear whether the purpose is required or optional as per the CA privacy regulations. |
| 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) |
| consent receipt | seems like a good idea to let the user know what data was collected and where it was retained by the verifier or other parties. |
| payment provider | This is optional and not further covered in this use case - perhaps another use case for payment would be helpful. |
User Stories
| Element | Detail | Notes | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| As a, | User of a web site | |||||||||
| I want | to acquire access to some resource | |||||||||
| so that | So that i can download content of physically access some venue | |||||||||
| Acceptance Criteria | Given | <how things begin> | When | <action taken> | Then | <outcome of taking action>- 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 | |||||||||
Prerequisites / Assumptions
- The user has a smartphone (or similar) that has access to the internet with a operating system that can protect user credentials and other data.
- The user has access to one or more wallets that will hold their credentials in the protected data store.
- The user has an expectation that they have loaded the credentials that will be needed to access the resource of interest to them.
Use Case Details
Privacy
Data Provided
...
The user gets some sort of receipt as to what data was provide and what was retained.
Biometric template data should be assumed to be discarded after use unless some specific account to allow future use is created.
Diagram
Steps
Primary User Journey
...
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 | state policies | what is the verifier required to do by regulation |
| 2 | biz policies | what optional information is the verifier requesting |
| 3 | ||
| 4 |
Sequence Diagram
End State
Describe what measures or signifies the end of the case
Success
Markers or metrics that indicate success
Failure
Markers or metrics that indicate failure
- User is give access to the resources request
- User is satisfied that only the data absolutely required was taken from them
Failure
- user device is not operational with the verifiers device
- user does not provide sufficient data for acceptance
- User is unable to learn what data is kept
- User is unable to remove personal data at a verifier
References
Champion / Stakeholder
List of the people that created the use caseTom Jones
Related Material
Resources and Links
...