Section 6.3.1 says:

"The following rules apply for selecting claims via claims and claim_sets:
If claims is absent, the Verifier requests all claims existing in the Credential."

So I'd say currently you would have to return everything.
But I think this is probably a bad idea to have as an option. It makes it easier for the RP to just go for the 'simplest' option and request everything, which is bad in a number of ways:

• You will very likely over ask
• It will get data that it's unlikely to parse, since if you don't know how to request a data element, you are unlikely to be able to parse it meaningfully.
• The user will likely see this as "the RP requested x, y and z" even though the RP didn't explicitly ask for it and may not even be aware that is effectively asking for more elements than it though (e.g. if additional elements are present).
• Doesn't work well with credential selection, since every credential of the correct type will always match the request, even if it doesn't in reality.

I'd propose to make the presence of claims mandatory

Not sure where we want to discuss this - here or in #367?

I agree that requesting a "full" credential might be dangerous, but I guess that also depends heavily on the context/use-case. There should be security mechanisms in place to make sure this is not abused, but imho the biggest question is where that is dealt with - in the Query Language or in the user interaction (the consent requested from the user).

I can see cases where you would want to request the full payload of a credential (especially for credentials without a lot different claims) and in principle the protocols also support credential formats without selective disclosure support (in which case it wouldn't make sense to specify specific claims).

This question also seems to overlap to some degree with the topic of RP authentication/authorization. If you have a trust ecosystem that also requires RP registration, then requesting/returning everything becomes much less of a problem because within that ecosystem, there was some process that checked and approved that kind of request.

Not sure where we want to discuss this - here or in #367?

let's discuss here

Feedback at today's ISO meeting was that they don't want the "requesting no claims means return all claims".

This would mean removing/changing the text Martijn mentioned above:

If claims is absent, the Verifier requests all claims existing in the Credential.

WG discussion:

• there are use-cases that might benefit from keeping claims optional
• there are credential formats that do not support selective disclosure
• motivation to make claims mandatory is preventing oversharing so that RP always has to specify all the claims it needs
• if we want to take a strong stance on this, that would mean making claims and claim_sets (?) mandatory and not empty.
• but there might be a use-case where RP is not requesting any data elements, just trying to confirm that the user has the credential? in which case empty might make sense? transaction data helps in that use-case?

there are use-cases that might benefit from keeping claims optional

Some use cases to consider:

1. Proof of personhood or similar credentials where the burden of privacy sits with the credential issuer. The RP doesn't need to specify specific claims
2. Academic transcripts, employment roles, skills attestations, payroll slips for building career, social or financial profiles for recruiters, employers, educational institutions, or the individual themselves. Should the RP need to specify each claim on each type?

It sounds like there are cases for both options:

• present no claims (just base credential without any disclosures)
• present everything

If we want to support both options, it would make sense to make the "empty" case (no claims / claim_sets) the show nothing case -> we present no claims that are selectively disclosable. That would mean that we probably would want to introduce something explicit that means "give me everything" within the credential query - that might also be of help for wallet implementations to warn the user accordingly as it is more explicit? I guess a boolean flag in the Credential Query would be the easiest option then? If that flag is set, neither claims nor claim_sets may be present.

• I support the "empty" case with containing no claims in the response. E.g., there is value in just proving someone has the license to drive without revealing any claims, or proof of personhood.
• I'm against reversing the semantic above.
• I support making it more explicit what claims/claim sets RPs request to prevent oversharing. An RP should be aware of the specific information they need, and I believe introducing a "select all" flag does not improve privacy. In my opinion, this would encourage RPs to use it carelessly.

The "empty" case would actually also solve the problem with formats that do not support selective disclosure - they would then share everything that is not selectively disclosable, so everything.

I would propose to add the "empty" case as a first step:
Be explicit that if both claims and claim_sets are absent, the expectation is to only share the "base" credential without any additional claims.

That way we

• have a clear definition for that case
• support use-cases that seem to introduce no further problems from a privacy perspective
• do not break things for credential formats that do not allow for selective disclosure

@danielfett any thoughts?

We actually noticed a lot oof cases from RPs where limit_disclsoure (PEX) was not set (I don't think on purpose), but that initially resulted in our wallet implementation disclosing everything for e.g. SD-JWT VCs. We changed our implementation now so that no matter whether limit_disclosure is specified we always perform selective disclosure.

So I agree with @c2bo, it makes sense that the "empty" case should only disclose the base credential. If you need an attribute you have to request it.

WG discussion

• split disclose everything and disclose nothing from the rest
  • if claims and claim_sets are both absent, the credential format that supports selective disclosure will return nothing, and the credential format that does not support selective disclosure will return everything.
  • defining this in OpenID4VP and profiling it further in HAIP to, for example say that for mdocs claims and claim_sets always must be present might be a good compromise
  • while adding privacy considerations that minimum information should always be requested.
• most systems in production request specific credentials?

I can create a draft PR for the "empty" case if that helps the discussion

I support the notion that when not requesting specific claims, a wallet should disclose the least amount of information possible. From a privacy by design perspective, this feels obvious. Two things I did want to add to the discussion:

I wonder how such a request can be explained to a user (but that's probably out-of-scope here)

Another interpretation is that when not specifying any claims or claim_sets, the request should be interpreted exactly like that. Meaning that if the wallet (and credential format used) does not support this, it should NOT respond to it. The burden than lies with the RP to make a requests that either

• includes the claims that are non-disclosable
• exclude credential formats that do not support this (e.g. jwt_vc_json)

This interpretation can also help to protect the RP to not receive any information that it didn't want to see in the first place.

if claims and claim_sets are both absent, the credential format that supports selective disclosure will return nothing, and the credential format that does not support selective disclosure will return everything.

I think this would lead to confusing semantics for both the RP and wallet with polymorphic behaviour based on credential types and proof type (eg. ldp with bbs+). I suggest keeping the default as per the working group consensus but i think an everything flag needs to be there to be able to be used with any credential type and MUST be used if the credential types doesn't support selective disclosure.

Wallets can choose to support or not support this kind of disclosure

I think this would lead to confusing semantics for both the RP and wallet with polymorphic behaviour based on credential types

Not really right, if the default is "Disclose the least amount of data possible" that would work the same for all credential types. The end result might differ per credential type, but not the behaviour. I guess for formats that don't support selective disclosure "nothing" and "everything" means the same.

if claims and claim_sets are both absent, the credential format that supports selective disclosure will return nothing, and the credential format that does not support selective disclosure will return everything.

I think "nothing"/"everything" can be misunderstood here, my interpretation would be "return the base credential, but no selectively disclosable attributes".

That means for an SD-JWT only return the base JWT + KB-JWT, or for mdoc only return mso and Device Auth. For a format that supports no selective disclosure, the "return base credential" would automatically return the whole thing.

It would imho also fit well to multi-message based variants like BBS:
There is some information that will always be disclosed (header, mandatory claims etc.) and there are attributes/messages that can be disclosed on demand. If no claims/claim_sets are provided you would onlydisclose the mandatory claims & header.

@c2bo I would take up on your offer as the discussion seems to have entered the area of bikeshedding and concrete text would really help. thank you so much in advance.

I can create a draft PR for the "empty" case if that helps the discussion