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 verification check instructions. Relates to #9. #44

Merged
merged 2 commits into from
Apr 14, 2017
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -1381,6 +1381,47 @@ <h3>Highly Dynamic Information</h3>
</section>
</section>

<section>
<h2>Verification</h2>

<p>
This section describes a number of checks required to verify a claim.
Some checks are essential for all verifiable claims, while some are applicable to only some claims.
</p>
<section>
<h3>Structural Validity</h3>
<p>
<ul>
<li>Document is valid JSON-LD.</li>
<li>Required properties are present. For example, for a Credential, <code>id</code>, <code>type</code>, and <code>claim</code> are required.</li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

id isn't required, even for a Credential (bearer token). So, we will want to remove 'id' as a requirement.

<li>Property values match expectations described in the specification. For example, the document type for a verifiable claim must contain the class "Credential".</li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrap all lines to 75 characters (try to follow the format of the rest of the document). It is inevitable that we'll need to reformat the spec at some point because of inconsistencies that sneak in, but we try to more or less maintain the same format throughout the spec.

</ul>
</p>
</section>
<section>
<h3>Entity Validity</h3>
<p>A number of checks </p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like an incomplete sentence?

<p>
<ul>
<li>The <code>issuer</code> id must match expectations. Likely, that means it is the id of a known and trusted <a>identity profile</a>.</li>
<li>The <a>claim id</a> must match expectations. Likely, that means it is the id of a known and trusted <a>identity profile</a> for the subject of the claim. If the entity that is subject of a claim has transmitted it to the inspector, the subject may be able to prove ownership of key identifyin properties such as email address(es) and public key(s).</li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo - 'identifyin'

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'claim id', should probably be 'subject identifier' or 'subject of the claim'. We need to make sure this terminology exists in the terminology section (I'm working on that and will make sure we have whatever you put in here in the terminology section).

<li>The <code>issued</code> date must be in the expected range. For example, an inspector may wish to ensure that the recorded issued date of valid claims is not in the future.</li>
<li>The document signature is available in the form of a known signature suite.</li>
<li>The public key associated with the signature is available and a trustworthy link between this signing key and the issuer's <a>identify profile</a> may be established.</li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo - 'identify'

We may also want to say that verifiers should check the signature according to the signature verification algorithm associated with the signature suite in use. Different signature suites will have different things that need to be checked/verified.

<li>If revocation instructions are present, the claim must not have been revoked.</li>
</ul>
</p>
</section>
<section>
<h3>Fitness for Purpose</h3>
<p>
<ul>
<li>The <a>custom properties</a> in the <a>claim</a> are appropriate for the inspector's purpose. For example if an inspector needs to determine that a subject is older than 21 years of age, they may accept claims of specific birthdate or abstract properties such as <code>ageOver</code>.</li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"are" -> "should be"?

<li>The issuer is trusted by the inspector to make the claims at hand. For example, Fast Food Resturant A will not be trusted to make a claim that an individual may enjoy a lifetime 10% discount to its competitor Fast Food Restaurant B.</li>
</ul>
</p>
</section>
</section>
</body>
</html>