Present as many credentials of type 'foobar' that you have in your wallet

[Sakurann]

How can I express "Present as many credentials of type 'foobar' that you have in your wallet" using PE?
my understanding is that it's not possible - would be good to explore how it can be made possible.

[bumblefudge]

all the matching VCs in your wallet, not oneOf them, you mean?

[David-Chadwick]

I dont think this is a particularly good feature to support for a number of reasons.
Firstly it is a way of asking a user to reveal too much PII, more than can reasonably be required according to GDPR.
Secondly there is no way of knowing how many VCs of type foobar actually do exist in a user's wallet and whether the user is telling the truth or not when she reveals "n" of them.

[ThierryThevenet]

Bizarre use case. If meet somebody in the street who asks me that i avoid him.

[nklomp]

Maybe first ask what the use case is about? I can think of several. Also remember that VCs are not only about people.

@David-Chadwick Although I do agree that one has to be very careful about asking too much data. On the other hand PE typically will have a user confirming what will be send to the RP. Current PE already allows for optional and min, max type of credentials.

@Sakurann I think this could be partially accomplished using the pick and min support in submission_requirements. Normally this works against distinct input descriptor objects. So if you want to use current spec you would have to provide multiple copies with a different id. Which of course isn't nice.

[ThierryThevenet]

100% agree with @David-Chadwick This use case is very close to "The thief use case", i mean a verifier acting as a thief. From my point of view it is great that PE does not support easily requests which are not specifics. One can combine different parameters to get as much data as possible from a wallet with PE but from our side as a wallet provider we do not implement those possibilities as it is just dangerous. SSI is becoming mainstream with projects like EBSI, we are not far from seeing this "use case".

[Sakurann]

The use case is the user has to upload all of the credentials to a portal.

I don't file issues just for fun.

And I don't think you would tell your large customer "that's bizarre. if you ask me that again, I will avoid you". Tone that is a little more constructive would be appreciated.

[ThierryThevenet]

Hello @Sakurann , I spend my time for years to explain SSI to future issuers and verifiers and specially how PE is great. SSI is great according to me because we tend to approach what we do in real life in some situations. You know more than I that the best way to explain SSI is to take real life examples. That is the way I do. From my opinion a protocol must not be pushed to limits as it is not a modélisation of real life but a support of a limited number of use cases. Sorry if that hurts you It was not my intention !

But maybe the use case "I want to upload my credentials to a portal" should be covered by another type of protocols as it is more or less a backup./recivery issue ?

[David-Chadwick]

"The use case is the user has to upload all of the credentials to a portal."
This is just too vague as a use-case. All of which credentials? All of all type of credentials? Or all of just one type of credential?
If you want the user to empty their wallet to a portal this requires huge trust on the part of the user. Or a policeman.
So what precisely is the use-case? If its for backup/recovery then this does not need PE. The protocol can perform this task.

[nklomp]

2 things to note here:

1. Your worries are of course valid. On the other hand, any agent, wallet not showing the user what they will be sending in, especially if it is the full contents of the wallet has to do some soul-searching. In other words, it is also a wallets task to protect users from doing things they shouldn't.
2. With current PE I can already create a definition that literally does what Kristina is asking for. The protocol would allow for it. The only thing I need to do is create a filter that matches against any credential and then create an enormous amount of similar input descriptor objects with a min match and different ids. So the argument that the protocol should not allow for it is a bit moot. Similar like PE cannot protect against RPs fishing for certain credentials they shouldn't. That is a problem to be solved at another layer

[nklomp]

Overasking is a problem to be solved in trust establishment, not something PE can do anything about

[David-Chadwick]

@nklomp In the paper we are currently writing about 'trust in the verifier' using TRAIN, then we have a solution for the overasking problem.

[nklomp]

I know :)

[bumblefudge]

NB @decentralgabe @andorsk -- "overask detection/notification" sounds like potential use-case for the TOIP spec, particularly if the TRAIN paper is listed as prior art and feature parity with other architectures/implementations of a trust-est layer is a design goal!

[andorsk]

totally agreed. thanks @bumblefudge. Let's start the conversation at DIF, and move it over to ToIP if it makes sense.

[decentralgabe]

agree with this being a trust problem. i also think PE does solve for this technically, because you can have any number of credentials that fulfill a given input descriptor.

this would implicitly allow all even if it does not explicitly request it. the explicit request could be at a different layer..

perhaps this is worth adding into a new version the idea of 'n credentials' without needing to repeat the same input descriptor n times

[bumblefudge]

I'd recommend we keep the issue open cuz PEv3 is on low-key hiatus while gathering implementation feedback (of which this is a good example) and focusing on related specs (like cred-man and wallet-rendering) before setting goals for v3

[bumblefudge]

@brentzundel brought up the good point that even if a NEW FEATURE gets put off til v3, vNow could include a little non-normative guidance or explanation of how to do this with today's spec, or what you can't do with it? Any help refining that meantime ask welcome

[Sakurann]

With current PE I can already create a definition that literally does what Kristina is asking for. The protocol would allow for it. The only thing I need to do is create a filter that matches against any credential and then create an enormous amount of similar input descriptor objects with a min match and different ids.

This is what I was looking for. thank you @nklomp.

vNow could include a little non-normative guidance or explanation of how to do this with today's spec

adding a clarification text to v2 would be great. thank you. absolutely does not have to be v3. (would like to see v3 label removed)

@ThierryThevenet I was asking how to make a certain use-case we have from a real customer work. if the answer is "it is not supported by the PE for this reason", that is fine. I just was not asking for the evaluation of whether the use-case itself is valid or not: "Bizarre use case. If meet somebody in the street who asks me that i avoid him."

[bumblefudge]

@Sakurann -- We discussed on today's call, and debated a bit whether this use-case could be supported by a feature or by core functionality. Reluctant to make such a consequential decision with so few people in the room! Could I ask you PR in a use-case and we can debate it a bit more in that PR thread against a more concrete example?

A tiny bit more detail than

The use case is the user has to upload all of the credentials to a portal.

Would be great! Like, all credentials that match what kind of constraint? We discussed on the call the privacy/attack vector of asking for all credentials matching a too-generate constraints (like, all verifiable credentials, or all credentials containing a "name" property), so giving examples in the PR of constraints where "all matching credentials" would be reasonable/safer would really help! User expectation of privacy is my main concern here...

[ottonomy]

Just dropping in to say this capability would make sense for a product I'm working on and match a use case that it'll serve, around the type OpenBadgeCredential. It is quite reasonable for a skills platform to desire to see all/any Open Badges a user has, and then let them select which ones they'd like to express to that particular verifier.

For example, a job board or talent marketplace might want to look through a large number of skills credentials to match you with jobs that you might qualify for. And a user would likely find it reasonable (and not a significant data privacy issue) to share a large number of these credentials with the platform. Users who attend competency-focused higher education programs may have 5 or more credentials for each course they took, representing granular learning outcomes.