List all validity checks that should be performed

[msporny]

We should make it clear that an inspector (e.g. corporation) is required to check revocation via the Issuer (e.g. government). In fact, there are many different types of validity checks that should be performed on data, such as the revocation status of an Issuer's signing key, the expiration date of the claim, etc.

[erickorb]

+1

[David-Chadwick]

This is not exactly true. The issuer may delegate the issuing of revocation information to a TTP. And if several issuers use a common TTP this is much better for privacy protection, as it makes it much more difficult for the issuer or the TTP to know which user/holder has contacted which inspector.

Change text to "is required to check revocation via the Issuer or its delegate"

Perhaps we should also recommend that revocation lists should preferably be published by TTPs that do not inform the issuer which inpsectors have contacted it, and that a TTP may merge the lists of multiple issuers.

[msporny]

@David-Chadwick We're also working on Blockchain-based revocation lists to achieve the same result as using an HTTP-based TTP.

[jonnycrunch]

By TTP, you mean Trusted Third Party. Can you give an example of a revocation performed by a TTP? A lot of TTP that I know of only aggregate the credentials and point the use to the source of truth, including revocation of the credential. Typically the TTP covers themselves by giving a valid period or expiration date and upon renewal, they perform a validity check before issuing a new credential.

[msporny]

By TTP, you mean Trusted Third Party

Yes.

Can you give an example of a revocation performed by a TTP?

Company A outsources all their credential management to Outsource B. Outsource B issues credentials under Company A's private key, and places the revocation list information in a bulk revocation list (for all customers). For example, the Department of Motor Vehicles outsources the issuance of digital drivers licenses , which are good for 7+ years. The outsourced firm maintains a revocation list for multiple DMVs, as that is their business model.

[ottonomy]

I think the discussion gets a little into the weeds. Revocation will be checked in the manner that the credential tells the inspector to check for it. There will be multiple methods, but that doesn't change the task in the ticket, which is to list the checks that must be performed. Revocation is one of them (if the credential offers a method to check for revocation -- some may not).

Here are some validity checks to consider when verifying a Verifiable Claim:

• Document is valid JSON-LD.
• Required properties are present in the document.
• The issuer's @id may be accessed.
• The issued date is published and is in the expected range (i.e. not in the future).
• There is an @id of the claim subject identified. This @id matches expected recipient.
• The document signature is available. It is in the form of a known signature suite.
• The @id of the key that signed the claim is included or otherwise may be determined.
• Descriptive information about the signing key is discoverable.
• The public key value of the key that signed the claim may be accessed.
• Metadata about the issuer, published by the issuer, may be accessed.
• A trustworthy link between the issuer and the signing key may be established.
• The issuer's authorization of this signing key's validity has not expired.
• The issuer's authorization of this signing key has not been revoked.
• If revocation instructions are present, it is possible to determine that the claim has not been revoked.
• The custom properties claimed about the subject are fit for the inspector's purpose.

[dlongley]

@ottonomy,

There is an @id of the claim subject identified. This @id matches expected recipient.

I don't believe you meant for the above list of checks to be mandatory for every credential, but to leave no doubt, I can imagine a case where this is no such @id (i.e. bearer credentials).

[ottonomy]

👍 , @dlongley. This item should be adjusted to indicate that @id may not be required and that this check should only apply when it is used.

If there is an @id identifying the subject of a claim, it matches the expected identity profile.

[msporny]

@ottonomy Could you create a PR from your proposed text so we can do a review? That's the next step here, imho.

[msporny]

I'm taking this up in the spec now and authoring text to implement @ottonomy's list.

[msporny]

Check to make sure all of these concepts are in the spec:

• Document is valid JSON-LD.
• Required properties are present in the document.
• The issuer's @id may be accessed.
• The issued date is published and is in the expected range (i.e. not in the future).
• There is an @id of the claim subject identified. This @id matches expected recipient.
• The document signature is available. It is in the form of a known signature suite.
• The @id of the key that signed the claim is included or otherwise may be determined.
• Descriptive information about the signing key is discoverable.
• The public key value of the key that signed the claim may be accessed.
• Metadata about the issuer, published by the issuer, may be accessed.
• A trustworthy link between the issuer and the signing key may be established.
• The issuer's authorization of this signing key's validity has not expired.
• The issuer's authorization of this signing key has not been revoked.
• If revocation instructions are present, it is possible to determine that the claim has not been revoked.
• The custom properties claimed about the subject are fit for the inspector's purpose.

[msporny]

I have verified that all checks listed by @ottonomy are now in the specification. Closing this issue.

[David-Chadwick]

I would request one further check please

• If the issuer has placed any policy information about the use of the credential e.g. intended inspectors, expiration date etc that this policy is adhered to

[msporny]

@David-Chadwick done - 0eac371

I added another one based on your comment, where the holder is able to annotate w/ usage rights as well.