5 min. | 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 |
30 minutes | Requirements Report - Individual Requirements Discussion
1.1 Selected Data Release | All | 1.1 Selected Data Release (Issuers) Status |
---|
colour | Green |
---|
title | Candidate |
---|
|
Ongoing discussion: Added related and matching requirements for Verifiers and Providers Added non-controversial change to 1.1 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
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?
Will be splitting out requirements into V,I,P 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 1.3 Consent for Verifier Processing 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” Do we need a separate requirement for Verifiers that says that they won’t bundle things together that are for different purposes? 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? Should we also remove “purposes” - implies you can ask for more than one thing at the same time. 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 Added example to requirement CA DL as issued today has optional capability like this. Different things, but it’s a single request. 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
1.5 Selected Data Release (Providers) |