Add intent_to_retain to DCQL

[martijnharing]

The presentation exchange supports the intent_to_retain parameter to indicate whether the RP intends to retain the received data element / claim. A similar parameter should be added to the DCQL.

A solution would be to add it to the claims query, either as a generic option or as an mdoc specific option.

[leecam]

Is there a more precise definition of intent_to_retain? If I retain the data for an hour, a year or 2 seconds, are any of these considered retained?

What if don't store the value but I derive long lived state from it. e.g I asked for age_over_18, I don't store the value directly but I use it to decide to create a kids account or not. Even more subtle, say I'm an adult website that collects age_over_18 as an anonymous age check, which i don't store, but I do record web traffic logs. As such I would be retaining that the user of a given IP was over 18.

As an RP I think we'd need clear guidance on when it should be set. And as a Wallet/OS we'd need to be able to explain to the user what it means when this is true or false

Does ISO have a precise definition for it?

[martijnharing]

ISO 18013-5 has the following definition for retain: “to store for a period longer
than necessary to conduct the transaction in realtime” and indicates that this requirement includes derived data from the data elements.

[leecam]

To me still seems hard for an RP to reason over when to set it and when not too. I think it will be a subjective call and we'll see inconsistent decisions. As such I find it difficult to think how a wallet could show it authoritatively to the user. I think for almost all cases of online presentment there will be some state derived from the data elements that will last longer than real time. Even a simple case of visiting an mature content website which requests age_over_18. Even if they don't store or create any web logs, they will mint a cookie which will record their age status and allow them to browse the website for some period of time.

I think an RP would find it hard to figure out if that counts as the retention of derived data or not. Maybe for online this field will almost always have to be set and then it likely ceases to be useful for the user when making informed consent to share the data or not.

For In-person presentation I do get that it might be easier (and I'm guessing this is the angle ISO was coming from). E.g going in a bar, a reader might just check your age at the moment and give a yes/no answer with nothing retained beyond that moment. But these situations seems more like the edge case vs the norm, so again I wonder if its just confusing when we also include all the online use-cases.

So if we do include this param I think we need to be clear to RPs when they should set it and how they deal with derived data (which i think will be tricky to word)

[Sakurann]

WG discussion. Current questions for ISO from this WG:

• where did this requirement come from when intent_to_retain was added to an ISO spec originally? legal text?
  • how is this used/rendered right now? Special flag/display in the credential selector?
• there are DCP WG members who do not see much benefit in online use-cases the way it is specified right now. Is it possible for ISO to remove intent_to_retain requirements for online transactions in ISO?
• If DCP WG will specify it, it might want to specify this in more details than is currently in ISO.
• If it is required to be added to OID4VP, does it have to be intent_to_retain boolean exactly, or can an equivalent mechanism be satisfactory?

those who see benefit in this please comment

[Sakurann]

from the discussion with ISO:

• where it comes from is.... desire to help inform the holder what happens to the data after it is released. there are no implementation requirements how to handle it - whether intent_to_retain is displayed to the holder varies from implementation to implementation. result of a long discussion in ISO was a minimum intent_to_retain boolean. ISO is currently also looking into how to better inform the holder - feedback welcome. intent_to_retain is bare minimum, would like to keep a mechanism to communicate if RP intends “to store for a period longer than necessary to conduct the transaction in realtime”. as long as bare minimum is supported, can go beyond.
• suggestion to distinguish how to communicate and what it means

Below is the text from 18013-5:

For each requested data element, the IntentToRetain variable indicates whether the mdoc verifier intends to retain the received data element. The mdoc verifier shall not retain any data, including digests and signatures, or derived data received from the mdoc, except for data elements for which the IntentToRetain flag was set to true in the request. To retain is defined as “to store for a period longer than necessary to conduct the transaction in realtime”.

[c2bo]

That sounds like an overlap with the discussion around purpose to me? Would it make sense to try to align the intent_to_retain discussion with the purpose discussion to make sure we have one mechanism that properly conveys the information we want/need?