Add verification check instructions. Relates to #9. #44
Conversation
index.html
Outdated
| <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> |
There was a problem hiding this comment.
id isn't required, even for a Credential (bearer token). So, we will want to remove 'id' as a requirement.
index.html
Outdated
| <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> |
index.html
Outdated
| <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> | ||
| <li>Property values match expectations described in the specification. For example, the document type for a verifiable claim must contain the class "Credential".</li> |
There was a problem hiding this comment.
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.
index.html
Outdated
| </section> | ||
| <section> | ||
| <h3>Entity Validity</h3> | ||
| <p>A number of checks </p> |
There was a problem hiding this comment.
This looks like an incomplete sentence?
index.html
Outdated
| <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> |
There was a problem hiding this comment.
'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).
index.html
Outdated
| <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> | ||
| <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> |
There was a problem hiding this comment.
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.
index.html
Outdated
| <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> |
|
@msporny I think I've responded to all the requested changes. I didn't disagree with any of them. Thanks! |
Adds some verification check instructions to page. Abstracts some text from the list I originally drafted in #9 about how profiles and keys are discovered to account for different possible ways these may be retrieved, accessed, and trusted.
@dlongley the data model for claim above does declare
idis a required property, so I described it as such here as well. If the bearer token case you mentioned is to be taken into account, it'll require a change above as well.