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.

Sign up for GitHub

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 placeholder algorithms #190

Merged
merged 9 commits into from
Dec 21, 2023
Merged

Add placeholder algorithms #190

Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
145b821
Add placeholder algorithms
OR13 Nov 30, 2023
58230fc
Update index.html
OR13 Nov 30, 2023
7f39c8d
Update index.html
OR13 Nov 30, 2023
8b813b1
Update index.html
OR13 Nov 30, 2023
6d0d4e1
Update index.html
OR13 Nov 30, 2023
e13bddc
Update index.html
OR13 Nov 30, 2023
48f0eab
Update index.html
OR13 Nov 30, 2023
7445f48
Update index.html
OR13 Nov 30, 2023
efa789a
Update index.html
OR13 Dec 2, 2023
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
66 changes: 66 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1644,6 +1644,72 @@ <h2>
</section>
</section>
</section>

<section>
<h2>Verification Algorithm</h2>
<p>
This specification might be used with many different key discovery protocols.
As such, discovery of verification keys is described in a different section of this document,
and is assumed to have succeeded prior to beginning the verification process.
Comment on lines +1651 to +1653
Copy link
Member

Choose a reason for hiding this comment

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

This is exactly what I'm hoping for. Do you think you can make it that verifiers MUST NOT attempt to discover or retrieve keys during the process of verifying signatures or issuers?

Copy link
Contributor Author

@OR13 OR13 Dec 1, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

We can state something like that... although I am not sure how normative we can make it....

All verification keys are assumed to have been previously dereferenced, keys SHOULD not be resolved at verification time, resolving verification keys at verification time leaks metadata.

The challenge is that for the 3 party model, verifiers do not know up front every issuer or holder they will encounter.

As a practical matter, you may need to do key discovery, if you had not previously done it... but how you do that and when you do that, can be separated from the verify algorithm to a certain degree.

</p>
<p>
As a general rule, verifiers SHOULD strive to minimize the processing of untrusted data.
This includes minimizing any processing of the protected header, unprotected header, or payload as part of the key discovery procedures.
</p>

<p>
When verifying a credential or presentation secured with SD-JWT, the algorithm defined in
<a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-06#name-verification-of-the-sd-jwt">
Verification of the SD-JWT
</a> MUST be followed.
</p>

<p>
When verifying a credential or presentation secured with COSE_Sign1, the algorithm defined in
<a data-cite="RFC9052#section-4.4">
Signing and Verification Process
</a> MUST be followed.
</p>

<p>
After verification has succeeded, additional validation checks SHOULD be performed.
Copy link
Member

Choose a reason for hiding this comment

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

Where do the interdependencies between iss and the issuer and holder properties need to be checked? They seem like verification to me, since they establish that there's an unambiguous issuer or presenter.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would call any checking of specific deserialized members "validation" not "verification".

As a verifier, I might have a policy that allows me to verify credentials from acme, with a known public key regardless of what the string values for "iss" or "issuer" are.

validating the "verified payload" conforms to the core data model, is shared logic between all securing formats... and I prefer to cite it from this document, not duplicate it.

</p>

</section>

<section>
<h2>Validation Algorithm</h2>

<p>
All claims expected for the <code>typ</code> MUST be present.
Copy link
Member

Choose a reason for hiding this comment

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

Is there a specification somewhere that maps from typ codes to the expected set of claims?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thats typically done in the specification that registers the media type, for example:

Given the uncertainty of the multiple suffixes draft, and the possibility that specific credential token formats might be registered in the future, I am trying not to pin this down in the W3C spec.

I would expect any registered media type to define required parameters, in this specification we only require header parameters, since the entire payload is dedicated to application/vc+ld+json which can have redundant claims, see:

https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L18

All claims that are understood MUST be evaluated according the verifier's validation policies.
All claims that are not understood MUST be ignored.
</p>

<p>
The verified payload MUST be a well formed compact JSON-LD document, as described in
<a data-cite="VC-DATA-MODEL-2.0/#conformance">Verifiable Credentials Data Model v2.0</a>.
</p>

<p>
Schema extension mechanisms such as <code>credentialSchema</code> SHOULD be checked.
If the extension mechanism <code>type</code> is not understood,
this property MUST be ignored.
</p>

<p>
Status extension mechanisms such as <code>credentialStatus</code> SHOULD be checked.
If the extension mechanism <code>type</code> is not understood,
this property MUST be ignored.
</p>

<p>
Based on the validation policy of the verifier and the type of credentials and type of securing mechanism,
additional validation checks might be applied. For example, dependencies between multiple credentials,
ordering or timing information associated with multiple credentials, and/or multiple presentations
could cause an otherwise valid credential or presentation to be considered invalid.
</p>
</section>
</body>

</html>