clarify text about intent_to_retain

[jogu]

MUST it always be present or MUST the wallet support it and the verifier can use it?

Originally posted by @tlodderstedt in #228 (comment)

[GarethCOliver]

What does it mean for a wallet to 'support' it? I don't think there any requirements on what a Wallet should actually do with it.

While mdoc does mandate the request include this, it seems weird for HAIP to make a different choice around the optionality of it to VP. My assumption is empty => false, so it's just a change in easy of verifiers constructing a request. (No strong opinions but having inconsistent requirements seems like it'll lead to more practical inter-op issues).

[Sakurann]

wg discussion:

• option 1: suggestion is to remove this requirement and say that this parameter is optional (ie do not say anything) and maybe add that cosystems MAY mandate intent_to_retain individually.
  • Can we just say Verifiers SHOULD/MAY include “intent to retain” based on the use cases they support?
• option 2: keep it mandatory, and clarity that mandatory would mean that the verifier must include this in the request and ecosystems may define additional meanings to this.
  • will stick to option 2, conditional to finding evidece of previous communications to ISO to mandate this.

[Sakurann]

this is what I could find on intent_to_retain in the [updated 2025-April-23] ISO-OIDF alignment on the mdoc profile of OID4VP over the Browser API document shared with DCP WG and ISO SC17 WG10, which is not exactly evidence of previous communications to ISO to mandate this.

[Sakurann]

wg discussion:

• will clarify with ISO what is their understanding of the "agreement"
• one option might be to have an mDL specific annex in haip where intent_to_retain in mandated? or mandate it only for mdocs?

[jogu]

From discussion at ISO WG 10th September 2025: OID4VP makes intent_to_retain optional (and refers to the definition in ISO 18013-5):

intent_to_retain OPTIONAL. A boolean that is equivalent to IntentToRetain variable defined in Section 8.3.2.1.2.1 of ISO.18013-5.

However it does not define a default value when it is absent. ISO 18013-5 has it as a required value, so does not define a default value. (DavidZ has filed an issue against OID4VP: openid/OpenID4VP#669 )

It was reported that privacy people said that wallet needs to clearly understand if there is an intent to retain or not, any solution where it is 100% clear to the wallet what the intent of the mdoc reader is. Consensus in that meeting that defining the default value as false would be fine. (But how do we do this in HAIP1.0 vs VP we need to figure out)

[GarethCOliver]

One thing worth noting as discussed in ISO: if a Wallet can not distinguish between a HAIP 1.0 request and an OpenId4VP 1.0 request (which in some cases they can't), then specifying a default in only HAIP is insufficient for a Wallet to determine that intent to retain is intended to be false by the RP.

So if we want to achieve that we'll need to mandate it in HAIP and then specify the default in OpenId4VP 1.1.

[Sakurann]

WG discussion:
three options. please continue the discussion in the issue.

1. defining the default value as false in HAIP, without any changes in openid4vp
2. keep it optional in HAIP. if it is not present, behavior is undefined.
3. mandate it in HAIP
   note that changing default behavior might impact interpretation of the request by the wallets/RPs from the legal perspective.

[Sakurann]

another suggestion from @GarethCOliver

say that, if absent, wallets must treat it as if it was true. Wallets that don't care will have no impact, and for wallets that do, the existing RP declaring nothing should be treated as though they are retaining it.

[martijnharing]

another suggestion from @GarethCOliver

say that, if absent, wallets must treat it as if it was true. Wallets that don't care will have no impact, and for wallets that do, the existing RP declaring nothing should be treated as though they are retaining it.

This would only work if we also have a way to say that a request is created according to the HAIP profile. Without that information the absence of intent_to_retain would be ambiguous, since the request could be made according to a different profile that doesn't define this default interpretation, or it could be made according to a profile that defines a different default interpretation.

[jogu]

I'm presuming Gareth's thinking was along the lines that treating "intent to retain" being missing as "the verifier will retain the data" is "failing safe" - i.e. won't result in a situation where the verifier has permission to retain the data longer than the user believed they were authorising. (It might result in user drop off if the user doesn't want the data retained, but if verifiers are worried about that they can explicitly set it to "intent to retain" to false.)

[Sakurann]

wg discussion:

• seems to be agreement on
  • in general, without any additional info, if absent, wallet has no info on intent to retain; but ecosystems (like AAMVA) can define that default behavior is to retain when this parameter is absent
  • say recommended not to use intent to retain because it is wallet conveying verifier's intent and privacy reasons.
• still discussion on-going: (obviously) wallet rejects the request when ecosystem requires this to be present and if this is not present, wallet.
• we need to make it easy for the developers

[paulbastian]

I think we should not use intent_to_retain for the same arguments that purpose was removed from the dcql_query:

• it is an unverified signal from the Verifier that is being displayed by the Wallet and may give a false sense of security to the user
• the meaning of the signal is much under-specified anyway