Discuss promotion of requirements from Draft/Under Review to Candidate
All
MOTION: Proposal for 4 requirement statuses:
Draft (when it first comes in)
Under Review (when it goes under discussion in a meeting)
Candidate (voted on with quorum)
Excluded (voted on with quorum)
Anyone can make recommendation for vote. When in Candidate or Excluded status, there is no further discussion on it unless we vote it back down to “Under Review”
DECISION: APPROVED
John Wunderlich to remove “Submitted” status from Google Doc
John added a note - selective data release- when asked for a certain number of elements, person should be able to respond back and only accept individual elements.
Can user also disclose more information than is requested? Concept of additional minimization - additional clarification
in MDL you can only release what’s been requested, but no technical controls to prevent it from happening
Is it always that the user can choose to do less, but never can the user do more? If that is the intent, we need more language to make that clear
Issuer must ensure case where holder does not say “yes” to everything
Is “Choose to Release” always a yes/no answer? Or does holder have the ability to respond with fewer elements than requested.
Yes/No qualify as selective release? Consensus seems to be “no”
If you’re requested to release your DoB, but you want to give data over 21 statement, do you have that ability?
Matching requirements for different parties, or do we combine them all into one requirement?
They need to be separate because they are different requirements.
For verifier, should be “data minimization”
Will be splitting out requirements into V,I,P
Providers: Selected Data Release
Issuers: Selected Data Release Capability
The issuer always has the control to provision. Possible future state - Issuer doesn’t know which wallet it is being provisioned into, because it’s the user’s choice
Issuer needs to know what wallet provisioned into, so it can manage lifecycle
Standard in place so eventually you could write your own wallet that follows the standard
Circumstance where credentials are issued, are time based, and don’t phone home (ideal model)
Issuer could say “I will provision into your wallet if it follows XYZ standard”
Decision:
Requirement 1.1 moved to “Candidate” , via quorum.
1.2 Context for User Processing
Status
title
Draft
1.3 Consent for Verifier Processing
Status
title
Draft
1.4 Selected Data Request (Verifiers)
Status
colour
Yellow
title
Under Review
Add “data elements that are required by policy must be requested. Data elements that are desired for other business purpose may be optionally requested. Optional requests must be opt-in”
User gesture approval for anything that’s not required
Do we need a separate requirement for Verifiers that says that they won’t bundle things together that are for different purposes?
Limit to data on credential vs data that would be outside of it?
Verifier wouldn’t know this
4.1 and 4.2 are related requirements - limiting collection
Statement should only be first sentence. Rest of it should be moved to description, if included at all. We shouldn’t be overloading these requirements - make them as simple as possible.
Can we delete the word “set” as set implies more than 1 transaction?
Yes.
Should we also remove “purposes” - implies you can ask for more than one thing at the same time.
Reality is that it’s a single transaction to avoid overloading holder with multiple requests
Should require more than one gesture to get more info than users are requesting
This works if the holder is made clear about what the current transaction is.
Verifier must ensure that holder knows what the transaction is - different requirement, but related
“Data elements that are desired for other business purpose may must optionally be requested” - is this still accurate?
Intent is “i want your email to send your offers”
Do we need to add “via separate request” to the end of the sentence?
User experience implications to too many requests
Concern with “separate” - might need a different verb, like “Distinguish”
API from verifier - you want verifier to make one request to user, user has one screen with all of the options
Separate request packets makes user have to deal with multiple screens
Added example to requirement
CA DL as issued today has optional capability like this. Different things, but it’s a single request.
How do you convey optionality?
Could other requirement be that once you’ve accepted it, you’ve accepted it - you can’t get data, then give another requirement. Once you’ve given up data, you shouldn’t have to give up more data.
Friction free if only required info
Design pattern - another consent required for optional info
Do it once, and there can never be another request for more required data