jandrieu
commented
8 months ago This may be conflating two things.
First, the editors agree verifiers need to be able to construct a request.
However, we think this issue is not about generating that request, which we can do a VPR or similar, but rather transmitting that VPR to the holder.
Similar to our concerns in #140, verifiers are not expected to be initiating flows.
Perhaps:
Verifiers must be able to respond to Holder requests for services by requesting related verifiable credentials. This includes describing the types of credentials that could satisfy the verifier's business rules. The holder then has the chance to decide how they want to respond.
Requirement: It MUST be possible for verifiers to construct a request for data that they need in order to produce a particular result, such as, but not limited to, a decision.
Motivations: One of the core problems that we try to solve is to enable verifiers to use data that it doesn't have itself, but is readily and electronically available from other parties. Knowing what data is available from which issuers is covered by #138. Using information from such claim offers may, however, not be sufficient to (a) create a request for such a claim and (b) validate the response, i.e. determine that the data provided in the response is valid for processing as the verifier intends (where 'valid' means that if the result of such processing is incorrect, or comes with a risk for the verifier that it finds unacceptable, that is not because of (the contents of) that claim.