New user/issuer task - Offer Claim

[RieksJ]

Requirement: It MUST be possible for issuers to publish what we here call a 'claim offer', which is a piece of information that not only states (the syntax and semantics of) the claim itself, but also additional information that verifiers may need to determine whether or not they want to request for such claims for a particular purpose.

Motivations: Verifiers need (the contents of) claims so that they can use/process them for a particular purpose and/or to make decisions (such as whether or not to enroll someone in a course). To do that, they need to be able to construct presentation requests (or similar), in which they request the holder to present claims of specific types that are issued by particular issuers. In order to be able to construct such requests, it MUST be possible for the verifier to (a) learn which (kinds of) claims are being issued by which issuers, and (b) determine whether or not (the contents of) such a claim 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.

[TallTed]

You said —

what we here call a 'claim offer'

— but this issue is titled "Offer Claim". Why the word order flip?

[RieksJ]

That's easy. They are different things.

• 'Offer Claim' is intended to become part of a section header, similar to existing sections (e.g., 'Issue Claim', 'Assert Claim')
• 'Claim Offer' is intended as a term that refers to "a piece of information that not only states (the syntax and semantics of) the claim itself, but also additional information that verifiers may need to determine whether or not they want to request for such claims for a particular purpose."

[jandrieu]

After some discussion, I think I'm coming around to support this. I didn't initially, I think because it suggests a search-driven mechanism for finding credentials which feels like it opens the entire ecosystem for spidering, hoarding, and various forms of "search engine optimization". My desired world would be one where the evaluation of whether or not a given issuer is acceptable for a given claim be entirely out-of-band, likely through issuer lists curated by the verifier, likely supported by institutional lists that form their own root of trust, e.g., the state of Utopia publishing a list of all issuers certified to issue EMT credentials in the state of Georgia. And for individuals, the discovery is likely going to be through a website where they learn that these credentials are available. In other words, I expect the web to be the starting point for holders seeking guidance on who to use for which credential.

All that said, I think there is a viable use here, if we can assume that wallets have a list of known issuers for the current user. That is, the user has indicated that certain issuers are special and the way in which they are specifal is that the wallet will interactively query those issuers if a VC request cannot be completed with existing credentials. For example, if the user has a VC2.0 from their university, but their candidate employer can only handle a VC 1.0, the wallet can, perhaps, automatically request a new VC in the desired format.

So, I can see the use case. I'm just not sure the VCDM has anything to do with it, as this is a protocol enhancement.

TODAY, any issuer can offer claims on their website. They can do everything this issue is trying to add to the VCDM.

The real question is how would the VCDM need to change to support this?

To my mind, it's already supported so I'm not sure its a use case relevant to the VCDM.

It is a use case related to the VC-API, where protocol questions are firmly in play. But I'm not sure how the VCDM would change to support this, except perhaps by standardizing a "claim offer". Which opens up a bunch of fun questions about how you indicate any restrictions or requirements on such an offer.

@RieksJ How were you expecting this use case to change the VCDM?

[RieksJ]

I am not aware of a requirement saying that a vc-use-case SHOULD have an impact on the VCDM, or suggest changes. I was thinking that use-cases are documented so as to make sure the VCDM, when complemented with other stuff to make it work such as protocols for the requesting and presentation of VCs/VPs and possibly other stuff, would result in a usable whole.

The single point I'm making here is that a verifier can only request for claims (within VCs (within VPs) if it knows there are issuers that issue VCs that have such claims, so that it can then decide which of these issuers to trust for (claims in) such VCs.

There are many ways that this can be realized, ranging from private communications between parties to the publicly collecting of such information and providing searching facilities that can be ethically correct or questionable. This use-case does not prefer, include or exclude any of these. The specification of such means are outside the scope of the vc-use-cases document.