Specify guarantees that all securing mechanisms must provide.

[msporny]

In PR #1338, @awoie noted:

It would be immensely helpful if we could establish precise requirements for this [robust requirements for securing mechanisms], as verifiers would then have at least some baseline security guarantees.

This PR is to track that concern and possibly add guarantees that all securing mechanisms must provide in order to be "conforming securing mechanisms".

[msporny]

@awoie, would making these normative requirements on securing mechanism specifications work for you? For example:

• Securing mechanism specifications MUST have protected all the data in the conforming document returned by the securing mechanism verification algorithm. ALTERNATIVE: Non-protected data MUST NOT be returned in the conforming document returned by the securing mechanism verification algorithm.
• Securing mechanism specifications SHOULD protect information referenced by a URL that is critical to validation. Mechanisms that can achieve this protection include: relatedResource, digestSRI, digestMultibase, well-known permanently cached URLs (such as JSON-LD Context URLs), and RDF Canonicalization (for JSON-LD Context URLs).

[OR13]

I am concerned about the "verifiable presentation" side of this.

In relation to securing protocols that use "audience / domain", "nonce / challenge".

If these protocol parameters are not secured, or checked during presentation verification, there can be serious security issues impacting authentication.

[msporny]

@OR13 wrote:

If these protocol parameters are not secured, or checked during presentation verification, there can be serious security issues impacting authentication.

Yes, and the language that has been proposed covers those cases. What concrete text are you looking to have added to the specification to cover your concern?

[msporny]

PR #1380 has been raised to address this issue. This issue will be closed once PR #1380 has been merged.

[awoie]

I'd also miss something like the following:

• A securing mechanism MUST protect the integrity of the verifiable credential
• A securing mechanism MUST verify the authorship of the verifiable credential (although this could be a requirement for the algorithm but in the VCDM)

Are we intentionally allowing strange securing mechanisms? These are extreme examples but the current definition would allow securing mechanisms such as phoning home to the issuer; having to call some random number on the phone etc.

[awoie]

From a verifier perspective especially now that we have the verification algorithm in the VCDM, I want to know what I get when I execute the security mechanism verification algorithm successfully.

[awoie]

If we cannot make such general statements about securing mechanism verification algorithms, then we should add to the specification that the verifier MUST understand how the securing mechanism secures the verifiable credential and verifiers SHOULD not treat all securing mechanisms as equal.

[awoie]

I made some suggestions in the PR

[iherman]

The issue was discussed in a meeting on 2023-12-13

• no resolutions were taken

View the transcript

2.13. Specify guarantees that all securing mechanisms must provide. (issue vc-data-model#1374)

See github issue vc-data-model#1374.

Brent Zundel: specify requirements for securing mechanisms.
… a PR exists.

See github pull request vc-data-model#1380.

Brent Zundel: there is a request for changes from oliver.

Manu Sporny: seems we are on a good trajectory, one thing that is concerning, he is saying verifier needs to know who the issuer of a VC is.
… that sounds like validation.
… I will try to make that a part of it, but I don't want to cover trust frameworks, or trust lists.
… the current text can be made clearer... the securing mechanism should not need to understand our data model.
… I will try to address oliver's suggestions.

[msporny]

PR #1380 has been merged, remaining concerns tracked in issue #1386, closing.