extensibility: defining a new constraint

Sakurann commented 2 years ago

If I need to add an additional constraint unique to the scenario (in this case "intent-to-retain" boolean), do I need to request that property to be added to the core spec every single time?

Also, how could it be expressed if you want to specify a credential not based on one schema URI, but several components (like combination of "doctype" and "namespace")

csuwildcat commented 2 years ago

I think a will_retain or intent_to_retain flag would be a generally useful addition, and we should get it in the an appropriate place in the spec. Maybe you can do a PR once Kim lands hers?

Sakurann commented 2 years ago

Yes, I am waiting for Kim's big PR to be merged to do a PR. The claim name should be intent_to_retain to be consistent with the mDL spec.

bumblefudge commented 2 years ago

LG

csuwildcat commented 2 years ago

Happy to include this, but we will need a PR by next Thursday, May 26th.

nklomp commented 2 years ago

I will take a stab at this. What might be a bit controversial though is that it will be MUST boolean flag. Reason is that I really like the MDL usage of it. Meaning they protect the holder from the verifier, by requiring that any verifier needs to supply this flag, so the holder knows whether their data might be retained or not. It forces the verifier to make it known.

With the privacy of subjects in mind, I think it would be very good for us to follow the same path.

Obviously any verifier could choose to not honor what was in the intent to retain flag, but then you can have serious discussions if that comes out.

nklomp commented 2 years ago

PR has it at the Input Descriptor level, allowing a verifier to retain certain data but not all of it. Does it make sense to also do it at the PD level? The drawback of that would be that it might confuse a holder, since then you would need to be able to override it at the descriptor level, or loose the support at the descriptor level alltogether, meaning you cannot communicate at a fine grained level anymore whether data is going to be retained

nklomp commented 2 years ago

As discussed in todays meeting @csuwildcat and @kimdhamilton will write some of there questions down.

We need to discuss whether it makes sense to change the level. So what if you wan't to apply this at the field level, or at the whole VP level for instance?
What are the exact use cases?
How does it relate to the work being done for Automate Data Agreements?

@Sakurann @JanLin, your input is also helpful

JaceHensley commented 2 years ago

I think the verifier would want to be able to know that the holder has acknowledge the intent to retain. Similar to how the verifier can enforce the limit_disclosure constraint.

There could be an intent_to_retain_acknowledged: true set in the presentation submission's descriptor map. If intent_to_retain_acknowledged isn't set then the verifier can reject the submission

nklomp commented 2 years ago

As promised a bit more clarification on 'intent to retain' from my side.

Background/intro I believe that we as creators of new specs and technology, which brings an inversion of power/control of data to users, should also carefully consider potential future ramifications of the technology (not saying we don't to be clear). Let's assume that VC tech and PEx becomes wildly popular over next few years (EU eSSIF, OpenID etc), you will run into several issues between a holder and a verifier. Some of them have been described in this TNO blogpost, which I suggest to read: https://blockchain.tno.nl/blog/verify-the-verifier-anti-coercion-by-design/ The more popular the tech will become, the more PII information might be exchanged, the more organizations are going to ask from holders, as it simply is convenient. A lot of organization don't even know why they are asking certain data.

A little real world example of the 900 pound Gorilla. mentioned in the TNO blog, happening without VC tech:

A hotel abroad wanting to create a copy of your driver's license or passport.
Personal experience recently: The Dutch government taking a copy of my Dutch passport on Curacao to get a Govid19 test. If I would refuse I would not be able to travel to the US.

The good thing of PEx is of course that a holder gets insight into what the verifier would like to request. The good thing is also that it allows for selective disclosure. The good thing is that the tech in certain cases wouldn't even require to store PII anymore by a verifier, as long as it can prove that it received/verified the data sent in from a holder. This greatly reduces privacy issues/risks. In the future. I expect standards to emerge about audit-trails held by issuers, holders and verifiers respectively.

Although the exchange process could be fully automated, in most cases I expect the user/holder to be involved in the process by approving sending in the data, after a careful review. This is also the important touch-point for the intent to retain

Different use cases The beauty of PEx being integrated into other protocols like DIDComm, OpenID Connect and others, means all are using the same spec to get the data exchanged and in an expected format. For some use cases the Verifier will want or even need to keep the data from the VP, in others it is a short lived process. Take for example a Covid19 Credential to get access to a venue like a bar/restaurant. In this case the VP could contain a binary answer whether someone is vaccinated, tested or recently recovered, next to a bit of identifying information. The verifier should not be keeping a record of the actual VP data in this case. The person at the door simply needs an indication whether the holder can pass or not.

Intent to retain The intent to retain would be included in the Presentation Definition by the Verifier/RP. It indicates whether the Verifier will be storing the submitted data part of the VP. Since the holder would be informed it can decide whether it believes the verifier should be allowed to store the data for the particular use case. The MDL ISO spec has a similar required property which also describes that Verifiers should not store data elements, digests, signatures, derived data unless that value is set to True. I like that approach as with a technical exchange of data it becomes real easy for Verifiers to create databases/statistics without users knowing.

Introducing intent to retain brings several questions:

GDPR, legislation and Automated Data Agreements Especially in the EU there are laws about how to handle data about it's citizens as a company. There are rules about what data is allowed to be kept, how retention of data should be handled, that data should be retained as short as possible, how a citizen can get access to all data collected about them and for instance the right to be forgotten (which is greatly misunderstood, but that is a different subject). This subject ties into the Automated Data Agreements work @JanLin and others for instance are working on, which they would like to integrate a bit more into PEx. It might make sense to have this subject as part of that group, as they will be bringing agreements between parties about data handling and legislation to begin with.

Granularity In current PR the boolean is introduced at the Input Descriptor level. One could argue that it might make sense to have richer support per claim for instance, as a Verifier might retain only a subset of (derived) data.

Introduce duration Instead of a boolean denoting whether a verifier intents to retain data, it might make sense to have a Verifier indicate what its intended retention duration will be for the data element(s)

Acknowledgement by holder As mentioned by @JaceHensley it might be worthwhile for a Verifier to have an acknowledgement by the holder. This helps also from a legal point of view, although that does bring questions about whether these properties (and also the intent to retain itself), should be covered by a signature to begin with.

Sorry for the long post. It might be worthwhile to postpone this for the next version of the spec, on the other hand history has proven that we need to take the privacy of users into account, especially since the Presentation Exchange is about Verifier/Holder interactions it makes sense to start ASAP

@kimdhamilton @csuwildcat

nklomp commented 2 years ago

Okay had some time to listen to the recording of last week. It seems some of the points mentioned above have already been discussed. :)

Updated the PR to make it a Feature.

During next meeting I guess we should discuss whether we are going to stick to a boolean, or make it an object with a duration for example.

nklomp commented 2 years ago

Based upon current PR, which has the intent_to_retain as a boolean field, I created a version which replaces the boolean with an object, and for now only 2 dates, indicating the minimum and maximum dates a verifier would like to retain certain data:

https://hackmd.io/xY3Bx_oGTuuJaSy2acRQNg

The Retention [[ref:Feature]] extends the [[ref:Input Descriptor Object]]'s _field_ 
object, allowing a Verifier to indicate it will retain the submitted value for the
specific field.    

A [[ref:Verifier]] must not retain any data, including digests, signatures,
and derived data received, except for claims from the [[ref:Presentation Submission]] descriptors
for which the accompanying [[ref:Input Descriptor Object]]'s _field_ `intent_to_retain`
property was set to true.

Retain is defined as: “to store for a period longer than necessary to conduct the
exchange between [[ref:Holder]] and [[ref:Verifier]] in realtime”.

When using this [[ref:Feature]]:
  - `retention` - The _fields_ object inside an [[ref:Input Descriptor Object]] ****MAY****
    contain an `retention` property.
    If present, its value ****MUST**** be an object that indicates the [[ref:Verifier]]
    intents to retain the [[ref:Claim]]'s data being requested. 
    If not present, this feature is not enabled.
    - _retention objects_ ****MUST**** include a `maxRetentionDate` indicating the maximum date and time
      the verifier intents to retain the particular field value
    - _retention objects_ ****MAY**** include a `minRetentionDate`, indicating the minmail date and time
      the verifier intents to retain the particular field value

    ```json
    "retention": {
      minRetentionDate: "2022-04-20T16:42:45Z"
      maxRetentionDate: "2024-02-01T12:01:24Z"
    }

nklomp commented 2 years ago

During today's call we decided to not go down the object route, as this probably should become part of another spec, like for instance the Automated Data Agreements. We are staying with a boolean intent_to_retain as in the PR.

PR is ready for "final" review

brentzundel commented 2 years ago

PR #335 has been merged, closing

decentralized-identity / presentation-exchange

extensibility: defining a new constraint #289