Review of process being proposed to deal with requirements. (See link to Google Doc above)
Status
title
Draft
When a requirement is first added to the Google Doc, it is in draft.
Status
colour
Blue
title
Submitted
When a requirement is ready to be discussed by the group and is on the agenda for a workgroup meeting it is moved to submitted status at that meeting. A link to the meeting note or notes where the requirement is discussed is added to the requirement in the document. Also, individuals may take on tasks related to the requirement which will be tracked in the Google Doc.
Status
colour
Yellow
title
Under Review
Once a requirement has been discussed at a meeting, it is Under Review until the workgroup completes the discussion and changes to the requirement. When that is done the workgroup will vote or reach consensus that the requirement should either be included in the recommendation report or excluded.
Status
colour
Green
title
Candidate
Discussion on the requirement is complete and it will be part of the recommendation report.
Status
colour
Red
title
Excluded
Discussion on the requirement is complete and it will not be part of the recommendation report.
When initially added, DRAFT
Post-discussion, SUBMITTED - under open consideration
Comments welcome in Google Doc and during meetings
Concern with the real human experience around the requirement. It is difficult to stand up in public and especially in a crowded place and refuse to share data.
Operational circumstances may mitigate against selective disclosure. How do we want to deal with this? Initially, we said all requirements would be phrased as a “must”. We can add something to the statement that says “unless operationally infeasible” - but this leaves room for verifiers to say “we don’t have the right hardware, so not going to do this”
We could also put a note in the description saying that this one may be disregarded under certain conditions
The issuer should ensure…
One of the benefits of the digital credential is that you don’t have to disclose everything in the credential. We’ve been referring to this as selective data release. Relying party only requests a subset.
We want to see if there’s a different way to convey that you shouldn’t have to always release all of the data that you have
Another way to do this, would be to say what the purpose is rather than what the data is.
Purpose should be clear
Maybe we should write this as a paired requirement - the purpose should be stated, the provider agrees, and grants access only to those elements.
Maybe we rewrite it and it applies to Verifiers, Issues, and Providers
For all 3, must take steps to ensure that the data released and the data collected is only the data for the purpose
Does legal requirements up front simplify definition?
We are trying to avoid legal requirements - technical and business doc.
Need a statement saying, if we say “must”, but your legalities do not allow that, then the requirement does not apply to you
Ensure that request is presented to holder so that the holder can understand what is requested, and choose to respond to it yes/no. The method by which is not the issue. The issue is that the use has to be informed about what is being requested.
If we don’t address how to respond to request, it leaves open the door. The important part is to have the request clear for the holder to react to. The manner in which the holder reacts can vary.
Even when they don’t, maybe there is a requirement that there is a record of this. In each case, the thing we are talking about is part of a record.
Issuing authorities - requirement for transaction log
Verifier has to make request not knowing if it’s ever seen this person before. Wallet needs to make the decision.
Pre-defined “bundles” - the idea of pairing the two comments together for must allow of selective data release + pre-consent data bundles
We could say “The issuer must ensure functionality allowing selective data release unless the entity and use case conforms to the requirements of an approved data bundle”
Should we change requirement 1.1 to put it on issuers to only collect data needed for the purpose
There can be more than 1 purpose in a request. Some of the data requested may be required and some of it may be optional.
Privacy-enhancing - we should come down against blanket purposes. If you are asking for it and you don’t need it, then it’s not a PEMC.
Challenges with “selective disclosure”
I shouldn’t have to hand over all of the data in my credential if someone who needs some of the data - this is a pro of the digital world
How we implement that could have different forms
The user actions that proceed the disclosure of data has become the focus, and it shouldn’t be
Keep the requirement on the issuer, but don’t call it selective data release
Issuer must ensure credential can be partially shared - whatever standard it follows, allows some of the data to be shared, not all of it
Wouldn’t this lead to different outcomes for users? Some wallets could be more privacy preserving than others. Is it appropriate that the user may be “tricked” into releasing more data in one transaction than another? There’s a place for UX, but also a high bar for privacy.
There are other places where standards for wallets are being debated
The nature of the releases of data would be under the control of the holder
For it to be privacy-enhancing, the ecosystem to which that is issued, makes decisions about how they’re going to implement selective disclosure from holder or provider side. On part of verifier, they only request what is appropriate. This would be a related requirement for provider to holder, and another for the verifier, so that these 3 things hang together?
Only requirement for wallet is that it allows user choice
The idea of requirements being linked together if they need to be “back to back”