Page Status: DRAFT
Description (User Story)
For this case we consider the mobile verifier. Note that this may turn out to be an anti-pattern that is disallowed by the spec.
Note that this could also be called peer-to-peer trust validation or self-sovereign did-comm wallet (ie wallet<=>wallet) connection use case.
The following is an actual use case for a Louisiana Driver's license Verify You. (click there to see their web page. Following is quote from that page.)
VerifyYou™ is a unique feature that allows one LA Wallet user to validate another LA Wallet license holder. By scanning a custom generated QR code, a “Verifier” can validate the license validity, coarse age, full name and/or driver’s license number of another LA Wallet user. Meanwhile, the “Presenter” maintains full possession of his or her phone and controls which information is temporarily presented. Only the information the "Presenter" allows to be communicated is visible to the "Verifier." The received information is securely presented and not stored.
Specific Use Case
One specific use case is a delivery person that requires age verification. The same app that the holder uses for verifying their age can be used to verify another's age.
Another use case is a bouncer at a bar.
Alternate Use Case
It is fairly easy for anyone to build a smartphone app that will ask the user for access to their mDL. It's hard to imagine how this will not be perverted to any use the user of the verifier app wants. For an example see the SCYTÁLES ISO MOBILE VALIDATOR BETA APP. Or just down-load it and try it your self.
|Actor||Role in the use case|
|Holder||Of the license to be scanned.|
|Verifier||Using the same app to scan another.|
|As a,||per trip driver|
|I want||delivery regulated goods like alchhol|
|so that||make more deliveries and get home|
|Given||An order to be delivered that needs a user over the age of (say) 21|
|When||the delivery requires proof of age|
|Then||when the customer has a mobile driver's license on their phone, I can get approval more quickly|
Prerequisites / Assumptions
- Both Holder and Verifier have the "official" LA wallet.
Use Case Details
As pointed out in the alternate use case above it is hard to create a model where such an app is not misused.
Since the user has not control over the app in the hands of the verifier, the manner in which the app requests data is critical to the user's privacy. Here some strict limitations on the requests from such an app must be carefully defined so that the user has no choice about what data is provided if the user wants whatever it is that the verifier is delivering to the user.
The received information is securely presented and not stored. (according to the web site.)
Primary Use Case
A gig driver comes to the door with a bottle of wine.
Secondary Use Case(s)
A young woman goes to a bar.
Very transactional - two user's touch phone and walk away.
If the verifier accepts the response, the holder gets what she wants.
- The verifier accepts the data.
- The verifier is unable to connect to the holder.
- The verifier will not accept the data presented as adequate to the purpose.
Champion / Stakeholder
Tom Jones and the state of Louisiana
Resources and Links
- Type your task here, using "@" to assign to a user and "//" to select a due date