Remove the "claims" parameter from authorizastion_details in SD-JWT/mdoc

[paulbastian]

Selective-Disclosure enabled credential formats give the inherent mechanism for data minimization.

Therefore, the need to specify the claims that shall be in a credential (done in authorization_details) adds unnecessary complexity, as issuers can issue credential containing all claims and wallets can use selective disclosure to release a subset to Verifiers.

Furthermore, I think this feature is hard to implement and hard to understand for users. Hence, I guess it will rarely be implemented for SD-JWT/mdoc.

Proposal: Delete the claims parameter for SD-JWT VC and mdoc from Authorization Details and Credential Request

[peppelinux]

Your proposal simplifies a lot the implementations. Considering that SD-JWT has decoys I don't see any problem in having a predefined number of attributes in the credentials.

[jogu]

I feel there are potential concerns we should discuss before removing it.

The claims parameter allows the wallet to avoid being exposed to PII that it does not wish to receive (in contrast to the suggested solution, which I believe is that the wallet receives all the PII then discards that which it does not want). Hence removing the claims parameter might violate the data minimisation principle of GDPR and similar regulations?

[TakahikoKawasaki]

The specification will continue to undergo breaking changes until it finds a way to enable the illustrated concept.

[peppelinux]

Starting from a real-world or user perspective I love the story of the user that obtains the physical digital identity card. There, there's no way to decide which claims to be included, the credential is one with a predefined set of attributes.

from the data minimization perspective I wouldn't see impacts since the data minimization is related to the presentation. The resource owner is the user and the credential and the data contained in it is in possession of the user and these can be selectively disclosed during the presentation phase.

data minimization is related to the scope of the request, if the scope is obtaining data for what we're the owners I don't see any problem.

@fmarino-ipzs WDYT? ^

Another point would be reducing the feature that other implementation may require, where custom/customizable sub set of attributes might be requested.

simplification here costs reduction of feature. the discussion is: is this feature needed or interesting for the future?

[paulbastian]

Agree with @peppelinux , my arguments:

• its very hard to do this in a good UX
• its very hard for users to udnerstand
• its complicated for issuers and wallets to implement
• its probably not going to be used by most issuers
• issued credentials may not match to the schema in the credential issuer metadata

[TakahikoKawasaki]

My personal thought is as follows, which is close to Giuseppe's opinion.

If users want to have control over their data using wallets for that purpose, applying a data minimization policy between wallets and issuers is conceptually strange. If a data minimization policy is applied there, it conceptually implies that issuers are the primary owners of users' data.

I prefer a simpler spec as an implementer, so I won't object this proposal. Rather, this proposal aligns with what I've already addressed in my published article. However, I should confess that I'm not familiar with real-world regulations, which may require complex specifications.

[cobward]

+1. This feature leads to terrible UX where users must understand all of the claims in their credentials AND every context where those claims could be presented to make an informed decision about whether or not they wish to procure those claims.

I am not a GDPR expert, but if the only motivation to keep this feature is to satisfy these kinds of regulations, then I believe these regulations can be met through a compliant implementation of the wallet on the user's device (i.e. the PII is never stored on infrastructure owned by the wallet vendor without permission of the user).

[jogu]

Just because there is a feature in the spec that allows a confusing UX doesn't mean that wallets have to implement a confusing UX.

The important question is whether there are use cases where wallets will want to request less than the full set of available claims, or use cases where the wallet knows it never needs the full set of claims. This could be because of (for example) a policy rather than a user decision.

[cobward]

Just because there is a feature in the spec that allows a confusing UX doesn't mean that wallets have to implement a confusing UX.

I think that is a fair point. However, that isn't the only reason to remove the feature. Having a spec that is more obvious and easier to implement is also a major benefit, in my opinion.

The important question is whether there are use cases where wallets will want to request less than the full set of available claims

I haven't seen any such use cases yet, but I would point out that this feature may not be the only way to solve the problem for those use cases.

[jogu]

I am not a GDPR expert, but if the only motivation to keep this feature is to satisfy these kinds of regulations, then I believe these regulations can be met through a compliant implementation of the wallet on the user's device (i.e. the PII is never stored on infrastructure owned by the wallet vendor without permission of the user).

I never replied to this bit, but I don't think this part helps. From a GDPR point of view I don't think it matters at all whether the PII is stored purely in the app vs sent to a backend, nor does it matter in some cases whether the user has given permission or not - the wallet obtaining data it doesn't need is sufficient to be a breach of the law. (Because if the data is present in the app, a breach at the wallet provider that results in a new version of the app being published can still result in the PII being leaked to the attacker, or if PII was obtained from the device by an attacker.)

(I'm also not a GDPR expert, but the relevant text from the regulation is "limited to what is necessary in relation to the purposes for which they are processed". Perhaps it might be the case that all wallets are general purpose wallets and hence storing all available attributes makes sense.)

What are the other ways to solve the problem?

I perhaps wouldn't be opposed to removing the feature until such time as we have someone come up with a firm use case that needs it.

[David-Chadwick]

The fact that the credential is sd-jwt is irrelevant because it must have been accompanied by disclosures. Otherwise none of the PII can be released by the wallet. So storing an sd-jwt plus disclosures in a wallet is equivalent to storing a credential in the clear. Therefore the claims parameter is just as relevant to the sd-jwt use case as to the credential in the clear user case. Wrt to the GUI, the wallet that we implemented does allow the user to choose which attributes to keep and which to discard during issuing and we did not find it difficult to implement this, nor did users find it difficult to use.

[cobward]

@jogu

the wallet obtaining data it doesn't need is sufficient to be a breach of the law

Maybe I have a different definition of wallet. In my understanding, a wallet is not an application built for the sole purpose of storing and presenting particular credential claims in particular scenarios. I would define a wallet (using the general-purpose definition you mentioned) as an application responsible for general credential storage and presentation. To that effect, any and all credential claims are "data it does need" in order to fulfill it's responsibility as a wallet, in my opinion.

I don't think it matters at all whether the PII is stored purely in the app vs sent to a backend

I agree, the stipulation you might have missed is "without permission of the user". The portion of GDPR that I was referencing there is the "right to be forgotten".

What are the other ways to solve the problem?

If we are talking about use-cases where there a well-defined classes of subsets of credential claims, then I would suggest breaking those up into individual credential types. Of course, if there is a usecase that needs to make highly custom claim requests then this does not solve the problem.

@David-Chadwick

the claims parameter is just as relevant to the sd-jwt use case as to the credential in the clear user case

That is true if you only consider the storage of the credential on the device. When we talk about presenting the credential it is a completely different story, as an SD-JWT will be able to withhold claims from the verifier, but other credential formats may not.

Wrt to the GUI, the wallet that we implemented does allow the user to choose which attributes to keep and which to discard during issuing and we did not find it difficult to implement this, nor did users find it difficult to use.

Could you share a little more about this use-case? I'd like to know:

1. What attributes are being issued in these credentials? How many attributes? Are all the attributes human-readable?
2. Would removing this parameter for mdoc and SD-JWT break your implementation?

I think it gets a little harder for users when the attributes become more numerous and esoteric.

@paulbastian

Thinking about this from the other point of view, if the text doesn't change at all then I see no problem in keeping this parameter. It is optional, and there is no requirement for the issuer to respect the request for certain claims from the wallet, so either party can ignore this parameter if they deem it too complex to consider.

[David-Chadwick]

@cobward To answer your questions

What attributes are being issued in these credentials? How many attributes? Are all the attributes human-readable? They were all attributes meant for human consumption, so all human-readable. We had various credentials such as driving licenses, credit cards, degree certificates, residency cards etc. The most complex was the JFF plugfest educational credential, available here https://w3c-ccg.github.io/vc-ed/plugfest-3-2023/unsigned-badge-example-p3-issuer-logo-url.json The underlying principle was 'the user is in control'. So the user can determine which optional attributes to not have in the wallet (obviously mandatory ones cannot be removed).

Would removing this parameter for mdoc and SD-JWT break your implementation? Our implementation pre-dated both the mdoc and SD-JWT integration i.e. we implemented the W3C VCs format. Conceptually I do not see any difference from a GUI perspective whether the credential is transferred to the wallet as a W3C VC or a sd-jwt because the wallet will need to convert the latter into something like the former in order to display it to the user. I would not want the user to know anything about the sd-jwt format and to believe that all the attributes are visible to him/her. Similarly for presenting to a verifier, I would expect the GUI to be same in both cases and to only show to the user the attributes that are being requested by the verifier. In our implementation, the wallet then requested a short lived selectively disclosed VC from the issuer, in order to not disclose attributes that are in the wallet credential. But once sd-jwt is added this can be presented to the verifier with only the required number of disclosures. So no new credential will need to be issued (unless of course you only want to present an sd-jwt once to any verifier so as to prevent linkability, in which case you might still want a new short lived sd-jwt each time.)

[jogu]

@cobward

Maybe I have a different definition of wallet. In my understanding, a wallet is not an application built for the sole purpose of storing and presenting particular credential claims in particular scenarios. I would define a wallet (using the general-purpose definition you mentioned) as an application responsible for general credential storage and presentation. To that effect, any and all credential claims are "data it does need" in order to fulfill its responsibility as a wallet, in my opinion.

I guess this is the key thing. There are definitely different definitions around where the wallet is essentially not general purpose and has awareness of many of the credentials it can hold - e.g. see OIX's ideas on how wallets would become a crucial "smart" component when the user is crossing between different trust frameworks: https://openidentityexchange.org/a-guide-to-trust-frameworks-for-smart-digital-id?page=identity-rules (I'm not sure that's the best description, but I also can't find a non-paywalled version of Nick's presentation - possibly this one but it's a bit out of date now: https://www.youtube.com/watch?v=2wrNN0twlL4 )

[selfissued]

I believe that @jogu hit the nail on the head here:

The important question is whether there are use cases where wallets will want to request less than the full set of available claims, or use cases where the wallet knows it never needs the full set of claims.

And @TakahikoKawasaki's comment is also spot on.

Unless we never want to down-select from the possible set of claims to be issued to the set the Wallet actually wants to be issued, keeping the claims parameter makes sense.

[paulbastian]

I haven't seen a solid use case description in this issue yet.

If an issuer is interested in doing such a thing, then he can realize this also by mechanisms outside the protocol, i.e. having a selection dialog in the browser before pre-auth code flow starts or within the auth code flow inside the brother.

The feature is in my opinion a niche and will be used by very few issuers and wallets. What this optionality means for wallets is also unclear, is it optional for Wallets to implement this? I think most wallets today don't have it and some likely will not implement it, therefore opting for the given solution outside the protocol anyway. I would go for simplicity here.

[jogu]

@paulbastian did you have a look at the video I mentioned in one of my previous comments, https://www.youtube.com/watch?v=2wrNN0twlL4 ?

If an issuer is interested in doing such a thing, then he can realize this also by mechanisms outside the protocol, i.e. having a selection dialog in the browser before pre-auth code flow starts or within the auth code flow inside the brother.

That is not sufficient to prevent wallets receiving claims they don't want. Maybe it helps to talk about concrete examples of claims wallets might not want to hold or even receive? Ones that spring to mind would be things that are highly sensitive and potentially open the user to persecution and hence increase liability to wallet creator or might contravene the law, e.g. sexual orientation or HIV status.

The feature is in my opinion a niche and will be used by very few issuers and wallets. What this optionality means for wallets is also unclear, is it optional for Wallets to implement this? I think most wallets today don't have it and some likely will not implement it, therefore opting for the given solution outside the protocol anyway. I would go for simplicity here.

The spec says 'claims' is optional to send in the request so the wallet can simply not send it if it doesn't need the feature.

If we do remove the claims parameter as suggested we can possibly also remove the mandatory flag from the issuer metadata as I'm struggling to see what useful actionable information it could convey to the wallet / wallet developer. (Or at most it would become an indication of what claims the issuer might allow the user to deselect, so we could clarify the meaning.)

I think there is an argument that for the authorization code flow it'd be better to have this kind of "I don't need/wants claim " information earlier on (i.e. in the authorization_details) so the issuer is able to show the user the claim won't be released to the wallet, but for the pre-authorised code flow the claims parameter in the credential request seems to be the only way the wallet can express it's needs?

[cobward]

That is not sufficient to prevent wallets receiving claims they don't want. Maybe it helps to talk about concrete examples of claims wallets might not want to hold or even receive? Ones that spring to mind would be things that are highly sensitive and potentially open the user to persecution and hence increase liability to wallet creator or might contravene the law, e.g. sexual orientation or HIV status.

@jogu Are you saying the wallet can decide what fields should be provisioned into the credential, regardless of user consent? The user wishes to receive a credential that contains sensitive PII, but the wallet does not want the liability for that, so omits those fields?

I don't understand this argument. If a wallet vendor does not want to assume responsibility for the secure management of PII, why are they in the business of making credential wallets?

This cuts both ways: by enabling a wallet vendor to choose data elements to receive, it also allows vendors to discriminate against specific groups of people. Should we design a protocol that allows wallet vendors to act in such a way?

I think the disagreement here stems from a lack of consensus on the definition of a wallet, the responsibilities of a wallet, and the requirements that the wallet might impose on the protocol. Is this something that has previously been discussed?

What this optionality means for wallets is also unclear, is it optional for Wallets to implement this?

@paulbastian The way I read the text as it currently stands, is that there is no requirement for either the Wallet or Issuer to implement this. If the wallet does not implement it, it simply omits the claims param. If the Issuer does not implement it, it simply ignores the claims param.

[jogu]

@jogu Are you saying the wallet can decide what fields should be provisioned into the credential, regardless of user consent? The user wishes to receive a credential that contains sensitive PII, but the wallet does not want the liability for that, so omits those fields?

Yes, exactly.

I don't understand this argument. If a wallet vendor does not want to assume responsibility for the secure management of PII, why are they in the business of making credential wallets?

Different kinds of PII fall under different laws, and generally certain types of PII essential infer costs for the wallet vendor that they might not want to pay (a somewhat contrived example would be that in some cases a wallet might need to pay to be audited for PCI-DSS compliance if it wanted to hold a credential that had a credit card number etc in it). It seems sensible to me that if a wallet knows it is not legally allowed to receive a particular attribute, it should be able to indicate it does not want to receive it. (There perhaps is a question whether this needs to be done at the attribute level, or if it's preferable for the wallet to just completely refuse to request a credential that might have unwanted claims.)

This cuts both ways: by enabling a wallet vendor to choose data elements to receive, it also allows vendors to discriminate against specific groups of people. Should we design a protocol that allows wallet vendors to act in such a way?

I'm struggling to understand this - could you give an example of a way a wallet can discriminate using the claims parameter that can only be achieved with the claims parameter and not by any other mechanism please?

I think the disagreement here stems from a lack of consensus on the definition of a wallet, the responsibilities of a wallet, and the requirements that the wallet might impose on the protocol. Is this something that has previously been discussed?

Not that I am aware of.

@paulbastian The way I read the text as it currently stands, is that there is no requirement for either the Wallet or Issuer to implement this. If the wallet does not implement it, it simply omits the claims param. If the Issuer does not implement it, it simply ignores the claims param.

The issuer should also set the mandatory flag on all the attributes in that case I believe.

[paulbastian]

@David-Chadwick do you have a video showing the implemented mechanism?

@jogu The video you provided gave me zero clues unfortunately.

First question: Is this feature optional for the Issuer to implement? If not, I think the burden is too high, if yes then most Issuers might not implement it and wallets can not rely on it. My further argumentation: If you really want to offer this as an Issuer, you can have the dialogue about optionally included claims on your website and then get the credential offer afterwards, no need to implement this in the protocol. Especially if its optional feature for Wallets, because in that way the issuer can offer this feature even to Wallets that don't support the claims thingy in the Credential Request.

The mandatory flag says, that an issuer is always able to provide this data and he will always include it into every credential. If the mandatory flag is not set, then the issuer may either not have the data for that claim or for some reason he chose not to include it. This could also be the user saying he does not want a certain claim being included.

But this mechanism must not be included into the protocol, because the

Just think about all the weird errors that could take place (also in conformity tests) because a user for some reason chose not to include his birthdate in his PID and he cannot prove his age at the bar although he has a credential that all his friends use to prove age. It is a recipe for non-understandable failures.

[ju-cu]

I agree with @jogu. I think, the wallet should be able to explicitly request certain claims. In particular, the Wallet should be able to notify the issuer that it explicitly wants a credential to include an optional claim. The wallet could then already reject a Credential or show an error if the Credential does not contain that optional claim because it knows that it won't be able to fulfill the use-case, e.g. presentation request.

For example, I actually believe that the claims member inside authorization_details can help in the use case that you describe, @paulbastian. If a Wallet cannot find a Credential that fulfills the presentation request ("prove age"), it may start an Issuance flow (see use case E.4). As part of that flow it can explicitly request that the Credential should contain the claim (or claims) that match the presentation request. If the newly issued Credential does not contain the requested claims (for whatever reason, e.g. the user did not authorize it, the Issuer did not have the data...), then it can throw an error. Note, that this is only relevant for optional claims as a Credential always contains the mandatory claims. In any case, I expect the Verifier (or Wallet) to output helpful error messages to the End-User.

[David-Chadwick]

@paulbastian Yes we have demos from a few years ago when we used W3Cs to implement COVID-19 certificates. This video is for a PC based wallet https://www.youtube.com/watch?v=wwWsGQEc-TI

This video is for an iPhone based app - the Android one was almost identical. https://www.youtube.com/watch?v=rBeY7sCdQ18 The user simply clicks on the ticks to deselect attributes he does not want.

In both demos all properties were optional, but it would be trivial to add mandatory ones.

[paulbastian]

Thanks for the demo David. I believe this is asking too much from the average user and might do more harm than good, most people just "want to get through" and they will get more frustrated if there are options that may result in not getting access to certain services because they unknowingly deselected certain claims.

So issuers are anyway able to avoid that by doing everything mandatory?

I have the feeling that the mandatory flag seems unclear then.

[David-Chadwick]

The way that mandatory would be reflected in the GUI is that the tick option would not be there for those attributes. So if all attributes are mandatory then the user would not be able to make any choices (other than to reject the entire credential). This seems pretty clear to me.

[jogu]

@paulbastian

I have the feeling that the mandatory flag seems unclear then.

Agreed, based on above I think we should try to more fully define the mandatory flag.

[Sakurann]

what is the suggestion how to clarify the current definition of mandatory that I quoted below?

Boolean which, when set to true, indicates that the Credential Issuer will always include this claim in the issued Credential. If set to false, the claim is not included in the issued Credential if the wallet did not request the inclusion of the claim, and/or if the Credential Issuer chose to not include the claim. If the mandatory parameter is omitted, the default value is false.

[paulbastian]

This popped up again in LSP POTENTIAL Track 1.

I urge to clarify and in the best case remove the claims parameter. Otherwise the following questions are open:

• What happens if the Issuer does not support this?
• How does the Wallet get to know the possible claims?
• What happens if the Wallet does not support this or does not send claims?

The latter case happened to us, and we received an empty credential, which is not how we understood the spec.

In particular for 3 Party Ecosystem with long-lived credential, we may end up in the interop-hell if credentials only include arbitrary subsets of claims.

[jogu]

What happens if the Issuer does not support this?

The issuer ignore it and you don't get the privacy property but things work.

How does the Wallet get to know the possible claims?

Aren't they listed in the credential metadata? The example in https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-11.2.3 certainly lists claims.

What happens if the Wallet does not support this or does not send claims?

I think clarifying this should be an easy & uncontentious win.