Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add user task 'Trust claim' #95

Open
RieksJ opened this issue May 8, 2019 · 4 comments
Open

Add user task 'Trust claim' #95

RieksJ opened this issue May 8, 2019 · 4 comments

Comments

@RieksJ
Copy link
Contributor

RieksJ commented May 8, 2019

The Motivation section in 4.1 Issue claim says "Individuals and organizations need a way to issue claims about themselves or others that can be verified and trusted.". While there is a user task Verify claim, there is no such thing for trusting claims. Here is a proposal for a section that fills in this omission:

4.7 Trust claim

Requirement: it must be possible for an inspector to determine what pairs of (credential type, issuer) it accepts as valid, i.e. trusts to be valid. Consequently, it must also be possible for an issuer to advertise (publish) the credentials that it is willing and capable of issuing. Such advertisements must contain all information that typical inspectors would need to make their trust decision. This would typically include syntax and semantics of the claims in the credential, an endpoint at which the issuer issues these credentials, and (optionally) other meta-data, such as liability that the issuer takes, compensations for issue/use of such credentials, procedures that the issuer has followed to verify the truthfulness of issued claims, etc.
Motivation: Whenever a holder requests an inspector to provide a product or service, the inspector must return a query for the claims (from issuers that the inspector trusts) that it needs to determine whether or not to provide that product or service. In order for the inspector to decide whether or not it trusts some credential that is issued by some issuer, it needs information about the claims in the credential, the way that the issuer has verified them, and more. This requirement becomes increasingly important as the transaction that the inspector must decide on, comes with a higher value (and hence a higher risk).
Needs: every use-case

@TallTed
Copy link
Member

TallTed commented May 8, 2019

Without addressing the rest of this, please note that "inspector" is a deprecated term; these should all be changed to "verifier".

@jandrieu
Copy link
Collaborator

jandrieu commented May 5, 2023

@RieksJ The editors are considering adding a "Validate Claim" task that we believe would essentially address this use case.

We, as a community, have made a distinction between verifying and validating, but the use case document doesn't speak to that. I think adding Validate as a task would let us speak to the requirement of applying business rules before relying on, or trusting, a VC.

I see we had further discussion in #103 and we deferred that. Now we are accepting contributions again, we want to revisit the conversation. https://lists.w3.org/Archives/Public/public-vc-wg/2023Apr/0000.html

@jandrieu
Copy link
Collaborator

jandrieu commented Apr 5, 2024

We've added validate claim to the diagram, which is where we think this initial proposal goes. Trust claim => Validate claim.

However, there is also an interesting notion here of standardizing an "advertisement" of credentials issued by a given issuer.

@KDean-GS1 argued convincingly that it would be a reasonable, decentralized approach for an issuer to be able to add to the credential a standard way for verifiers to retrieve additional information about the issuer and why the verifier might trust it.

Given where we're at in the standards timeline, post feature-freeze, such a new property should be deferred to a future VC specification. We'll create a new issue to track that opportunity.

@jandrieu
Copy link
Collaborator

jandrieu commented Apr 5, 2024

We'll close once we have that other issue about advertising in place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants