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.

Privacy Enhancing Mobile Credentials (PEMC)

Credential Policy Coordination