Skip to end of metadata
Go to start of metadata

Page Status: DRAFT

Priority: P2


This is one of the broad list of abstract user stories focused on Privacy Enhanced Mobile Credentials (PEMC) on a mobile device platform.


Description (User Story)

This is a generic 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

Since this is a generic use case it only talks at a high level about the user acquiring a phone, wallet and appropriate credentials and then using them to access a desired resource.

Secondary Use Case (optional)

Taxonomy

Term

Definition

HolderThe human user of the mobile credentials. The first person (I, we) of this story. 
DeviceA 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.

Issuerof a mobile credential.
Verifier of one or more mobile credentials.
CredentialA protected structure given by the issue to the holder's wallet. For example the mdoc from ISO 18013-5
PresentationA 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.
PurposeA 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.
PDPPolicy Definition Point (aka policy issuer) This could be a government or the business that owns the Verifier.
PEPPolicy Enforcement Point (aka policy verifier)
consent receiptseems 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 providerThis is optional and not further covered in this use case - perhaps another use case for payment would be helpful.


User Stories

ElementDetailNotes
As a,User of a web site
I wantto acquire access to some resource
so thatSo that I can download content or physically access some venue
Acceptance Criteria - what the user should know
Verifier or Brandand who else sees the data (that may be in the TOU)
Purposes that they can understandand whether they are required or optional
Retention Timeif 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

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

#StepDescriptionIssues
1acquire devicetypically a smartphone from a telco
2acquire walletcan be resident on the phone or acquired from a app store.
3acquire credsfrom issuers like state DMV's or healthcare providers
4determine a goaltypically travel to another country, go to a ball game or get access to a video
5go to a web site for access ticketonly needed if access requires check-in or if the user wants assured access
6go to location of resourceeither physical site or digital site
5select type of accessoptional depending on resource, the purpose for the visit may be established here
6verifier sends request for dataat this point the purpose of the visit and the policy of the rules engines are queriedThis is a bundled request which violates FI 2.8.12
7user wallet presents to userthe wallet converts the requestor name and purposes into a UI for the user to see
8user choosesif some purposes have been added at the option of the verifier, the user can remove them
9presentation of user datathe wallet sends the presentation to the verifier based on the user request
10acceptance by verifierthis is the PEP = policy enforcement point, the user is granted access or not
11remediationif the user is not granted access they should know why and how this can be rectified, usually by directing the user to acquire additional credentials.


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.

#StepDescription
1state policieswhat is the verifier required to do by regulation
2biz policieswhat optional information is the verifier requesting
3

4


Sequence Diagram


End State

Describe what measures or signifies the end of the case


Success

  • 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

Tom Jones


Related Material

The following is taken from the Future Identity document (see above) and seems relevant to this use case. 

  • Some messages suitable to deliver in plain English during provision process (not just in T&C): (2.7.1)
    “Your [Insert name of App] data will not be released from your device [or the issuing authority] without your permission.”
    “If you are asked to release data you feel uncomfortable sharing, do not share it”
    “If your [mDL] data changes on record with the state, it will be updated on your [app] shortly after is is received by the [issuing authority]”
    “If you believe your digital identity data is being misused, report it [here]”
  • User receives Digital ID lifecycle notifications, for example: (4.4.3)
    “Driving privilege suspended pending renewal of physical credential, credential may be used for Identity purposes only”
    “Driving privilege suspended as per state law, credential may be used for Identity purposes only” 
  • The follow is considered to be bad advice is is to be avoided. It will not usually be of any use to the user (through too much detail or too technical collections of terms) and will be very annoying. 
    • User receives notice of each data field being requested by the relying party and has the user has the option to approve or decline sending each field before sending the data to the relying party. (4.4.4)
    • User Consent to release each field of data, or decline transaction in physical domain, consistent with the ISO 18013-5 standard supported. (5.2.2)

Page Tasks

  • Type your task here, using "@" to assign to a user and "//" to select a due date
  • No labels