diff --git a/index.html b/index.html index 0ce5f60..022d459 100644 --- a/index.html +++ b/index.html @@ -1,6 +1,7 @@ + Verifiable Credentials Use Cases @@ -580,29 +581,141 @@

Assert Claim

-

Verify Claim

+

Verify Credential

Requirement
-It MUST be possible for a verifier to verify that the credential is an -authentic statement of an issuer's claims about the -subject. The verifying entity must have the capability to -connect the issuer’s identity to its credential identifier and the -subject's identity to their identifier as indicated in the credential. -The issuer’s verification information, such as its public key, must be -discoverable from the credential record and verifiably linked to the issuer. -It MUST be possible to do this in an automated fashion. + It is expected to be possible for a verifier to verify that the + credential is an authentic statement of an issuer's + claims about the + subject. Verifiers MUST have the capability to + cryptographically prove that a credential has not been tampered + with since issuance (authenticity) and that the issuer continues + to assert the claims as true (currency). +

+ To check authenticity, the issuer's verification method(s), such as + a public key, must be discoverable from the credential itself. It + is expected that the issuer identifier either is + itself cryptographically verifiable, or that it can be used to + reliably discover the cryptographic material necessary to confirm + that the content of a credential has not been changed since + issuance. It is understood that verification depends on the + verifier's acceptance of the robustness of the cryptographic + mechanisms used for testing authenticity and for discovering + verification methods. An untrusted verification method cannot be + relied upon for verification. +

+ Verifiers must also be able to + inquire about the current status of a credential without + revealing to the issuer +
    +
  1. The entity requesting that status
    2. +
  2. The credential for which status is being checked
    3. +
  3. The subject of the credential being checked
    4. +
+ Requiring that verifiers perform this status check + is what enables issuers to revoke, suspend, or otherwise + moderate the status of the credential. +

+ Similarly, if a discovery mechanism is used to retrieve + verification methods for a given issuer, verifiers must be able + to do so without revealing unnecessary information to the issuer. +

+ In short, it must be possible to fully verify a credential + without leaking usage data to the issuer or anyone else. This + is to avoid the so-called "phone home" problem. +
+
Motivations
+
+ In many environments (such as order processing), information — such + as a payer's address, citizenship, or age — needs to be + automatically verified to complete the transaction. +

+ It MUST be possible to verify these in an automated fashion. +
+
Needs
+
+ F.2, C.1, E.2, R.1 + , + F.5, H.2, C.6 +
+
+
+
+

Validate Claim

+
+
Requirement
+
+ It MUST be possible for a verifier to check whether a + given claim is appropriate for a particular use. That is, given + a credential that is authentic and current, the verifier needs to + interpret the claims in the context of their own 'business rules' + concerning, for instance, which parties are acceptable authorities, and which + cryptographic mechanisms are acceptable for what situations. +
    +
  1. Is the issuer someone we know?
    2. +
  2. Are the claims made by this issuer appropriate for this + particular issuer's authority?
    3. +
  3. Is the holder's presentation an appropriate use of the + credential?
    4. +
+ The first and second questions will be answered because either the + verifier already knows the public identifiers for the issuers it + recognizes for specific claims, or there is a discovery mechanism + whereby verifiers can find appropriate issuers given their + business requirements. +

+ The business rules may allow the use of certain credentials for + specific situations, even when verification fails. For example, a + suspended or expired professional license may be accepted by an employer as + evidence of past experience without it being treated as a current + qualification for roles that require that license. For this + reason, current status (as part of verification) only deals with the + status of the credential as maintained by the Issuer. Timeliness + is the domain of validation. +

+ It's important to note that the bounds of authority for a given + issuer are specific claim types made by them and relied upon by + others. While a region's DMV (Department of Motor Vehicles) + or equivalent agency might be an acceptable authority for an + individual's driving privilege, it should probably not be treated + as authoritative for an individual's hair color or current + address, even though DMVs regularly include such claims in + today's driver's licenses. +

+ Unlike verification, it may not always be possible to + automate validation. Some use cases require human review before accepting + a particular credential for a particular use. For example, a + digital proof of age system might need a trusted human agent to + visually compare the holder/presenter in real-space to a + reference photo securely referenced in the VC, before accepting a + credential as valid.
Motivations
-In many environments (such as order processing) information such as a payer's -address, citizenship, or age need to be automatically verified in order to -complete the transaction. + Verifiers need to be able to apply their own policies and rules + to the information they rely on to run their "business" (which we + mean broadly, to encompass all activity focused towards a goal). +

+ Given this need, any given VC might be verified but not usable in a + particular situation. For example, a self-issued driver's license + would likely not be acceptable for a car rental by most car + rental agencies, even though the verification succeeds. +

+ Even so, in other cases, such as at a go-cart racing facility, it + may be entirely appropriate to accept the name and image from a + self-issued license for the purpose of leaderboards, + announcements, and correspondence. +

+ These business rules are entirely the province of the verifier. Only after + satisfying their rules should a verifier rely upon a claim as an + accepted fact for specific use.
Needs
-F.2, C.1, E.2, R.1, -F.5, H.2, C.6 + F.2, C.1, E.2, R.1 + , + F.5, H.2, C.6