From 0c32a56ac2716d9213a7c0d8f5a1a2dea089c16c Mon Sep 17 00:00:00 2001 From: Rieks Date: Mon, 1 Jul 2019 08:44:43 +0200 Subject: [PATCH 1/2] Fixes #95 --- index.html | 73 +++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 50 insertions(+), 23 deletions(-) diff --git a/index.html b/index.html index 7a7a333..baf3c73 100644 --- a/index.html +++ b/index.html @@ -580,29 +580,56 @@

Assert Claim

-

Verify Claim

-
-
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.
-
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.
-
Needs
-
F.2, C.1, E.2, R.1, - F.5, H.2, C.6
-
-
-
+

Verify Claim

+
+
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.
+
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.
+
Needs
+
F.2, C.1, E.2, R.1, + F.5, H.2, C.6
+
+
+
+

Trust Claim

+
+
Requirement
+
It MUST be possible for a verifier 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 SHOULD contain all information that typical verifiers 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.
+
Motivations
+
Whenever a holder requests a verfier to provide a product or service, + the verfier must return a query for the claims (from issuers that it trusts, and) + that it needs to decide whether or not to provide the requested product or service. + In order for the verfier to decide whether or not it trusts credentials from identifiable issuers, + it needs information, e.g. about the kinds of claims in such credentials, the way that the issuer has verified them, and more. + This requirement becomes increasingly important as the transactions that the verfier must decide on, + come with a higher value (and hence a higher risk).
+
Needs
+
every use-case
+
+
+

Store / Move Claim

Requirement
From ee0c9f6e70639840dddab9ebb0d45f1d73ee19ee Mon Sep 17 00:00:00 2001 From: Rieks Date: Mon, 5 Aug 2019 16:53:14 +0200 Subject: [PATCH 2/2] Attempt to address comments by @jandrieu --- index.html | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/index.html b/index.html index baf3c73..d97e0db 100644 --- a/index.html +++ b/index.html @@ -608,15 +608,20 @@

Trust Claim

Requirement
It MUST be possible for a verifier 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 SHOULD contain all information that typical verifiers 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, + i.e. trusts to be valid, for what purposes. + It SHOULD be possible that VCs that may contain the same information, + but that are issued by different issuers, are all acceptable for one purpose, + but only specific issuers would be allowed for another purpose. + Every verifier MUST make its own decisions in this regard. + As a consequence, it MUST be possible for a verifier to obtain + all information that it finds relevant for making such determinations, + and hence also for issuers to publish (advertise) such information. + It is envisaged that such information would 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.
+ to verify the truthfulness of issued claims, etc.
Motivations
Whenever a holder requests a verfier to provide a product or service, the verfier must return a query for the claims (from issuers that it trusts, and)