...
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
What happens during the use case.
...
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.
...
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" every one 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 |
|---|---|
| AliceHolder | |
| BobIssuer | |
| etceteraVerifier |
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> | |
...