Consider adding use-cases to the explainer

[krgovind]

While the explainer makes the goals of the API very clear; it does not list use-cases/applications. Understanding the use-cases can help the reader better reason through the prevalence, user understanding / consent flow, privacy implications, etc. For example, is the API intended to be used for age verification (which can be served by providing a low-entropy/boolean response), for identity verification on loan applications, or something else?

[davidz25]

This is a good idea. For those of us who has been working on 18013-5 and in-person presentation it's probably more clear but I'll list a few and then maybe we can create a PR and add this to README.md or other suitable document:

• rent a car: RP requests driving_privileges, given_name, family_name
• age restricted content: RP requests age_over_21. If that doesn't exist in the mDL, RP requests age_in_years. If that doesn't exist RP requests birth_date
• purchase alcohol w/ subsequent in-person delivery: RP requests birth_date, portrait with intent_to_retain set to 1 day. The portrait image is stored on the delivery person's device and checked against holder's appearance at delivery time.

There's probably more (for example KYC) but these three often come up in discussions...

[davidz25]

(you can also see we really need some kind of way to ask express critical(age_over_21 OR age_in_years OR birth_date) which is to be interpreted as: it is business critical that the RP get either age_over_21 OR age_in_years OR birth_date ... where "business critical" is defined as the transaction the user is wishing to do cannot succeed without this being satisfied. Unfortunately we don't have a good way to express that right now and I think there's consensus to keep it simple for now.)