Credential Policy Coordination
Description (User Story)
This is the user journey for credentials that have short expiration times. One goal of a PEMC is that the issuer is not notified when the credential is used. One way that the mDL standard accomplishes this is to make one part of the license have a short duration and expect that it will be updated "frequently".
Narrative
The user typically goes through an automated turnstile or other unattended site, taps their phone, and is admitted to the site.
When the user goes through the turnstile, they are informed as the expiration date on the card, but this data IS NOT stored by the verifier.
The verifier may have a policy about when they will stop accepting the mDL. If it is strict, they will probably allow refresh either in line or nearby. The location of the refresh site IS NOT communicated to the issuer.
The user has a variety of convenient places where they go for lots of reasons, like the local supermarket or bank, where they can tap their phone and get a refreshed token.
Anti Pattern Use Case
The user journey to be avoided in that the user gets to a place where the credential is checked and it has expired. Two paths are open, neither of them is privacy enhancing.
- The user allows a refresh of the credential at that point which give the issuer information about where the credential was used.
- The user is not allowed to access the desired resources.
Here is an actual user journey that is to be avoided. Holder goes to get a new driver's license at the stipulated interval at a physical license issuing site. The existing physical license has a hole punched in the card indicating that it is no longer useful for the purpose of driving, but is explicitly told that the license is still valid for identification. The holder is also issued a temporary license as an 8 x 11 piece of paper which is placed in the car's glove box. The holder goes to a restaurant which apparently has been shut down for liquor license violation and has been told to "card" everyone regardless of their age. The card with a hole in it is rejected by the manager in the restaurant. The problem is that the policy as enunciated by the license issuing authority does not match the policy applied by the restaurant. The holder is rejected by the verifier because the policies are not coordinated. The holder is not happy. The restaurant loses a customer.
Actors
| Actor | Role in the use case |
|---|---|
| Holder | |
| Issuer | |
| Verifier |
User Stories
| Element | Detail | Notes |
|---|---|---|
| As a, | <description of user> | |
| I want | <functionality> | |
| so that | <benefit> | |
| Acceptance Criteria | ||
| Given | <how things begin> | |
| When | <action taken> | |
| Then | <outcome of taking action> | |
Prerequisites / Assumptions
Use Case Details
Privacy
Data Provided
Data Retained
Diagram
In the diagram the Verifier is shown as two parts: (1) the Policy Definition Point where the policy to be applied is synthesized from the various inputs, and (2) the Policy Executions Point (PEP) where that synthesized policy is applied to grant access.
Steps
Primary Use Case
The anticipated normal sequence
| # | Step | Description |
|---|---|---|
| 1 | ||
| 2 | ||
| 3 | ||
| 4 |
Secondary Use Case(s)
Alternate or variant sequences
| # | Step | Description |
|---|---|---|
| 1 | ||
| 2 | ||
| 3 | ||
| 4 |
Sequence Diagram
End State
The desired outcome has no data retained in the verifier beyond what is legally mandated.
Success
- The holder gets access to the desired resource or venue.
- The verifier retains no user data.
Failure
- The holder does not get access and is embroiled in a bureaucracy to gain access.
References
Champion / Stakeholder
Tom Jones
Related Material
Resources and Links