Defining constraints on the signer of a Verifiable Presentation in a Presentation Definition

[gerardsn]

In the current PEX matching we implicitly require all VCs to have te same subject.id, and we require the signature on the VP to be the same as the subject.id of the VCs. When moving to the Subject (instead of DID) approach we need to make (some) of these requirements explicit. The main requirement for now is to add a constraint on the signer of a VP.

Issue summary

Example: (migration scenario)
At some point a use-case decides did:web is no longer safe enough. Instead they would like to use did:something-safer. The use-case requires an OrganizationCredential which is issued by an external party which will keep issuing to did:web identifiers. They only thing a use-case has control over is the credentials they issue, and the VP signatures that are accepted.

Below is the VP a use-case would like to receive:

{
	type: VerifiablePresentation
	vcs: [
		{
			type: [VerifiableCredential, OrganizationCredential],
			issuer: "fixed but out of our control",
			subject.id: did:web:example.com
		},
		{ // optional
			type: [VerifiableCredential, ThisUseCaseCredential],
			issuer: "issued by use-case, so what ever we want",
			subject.id: did:something-safer:this-is-me
		}
	]
	holder: "optional and unused in practice"
	proof: {
		verificationMethod: did:something-safer:this-is-me#key-1
	}
}

This contains the OrganizationCredential issued to did:web:example.com. It contains a proof signed by DID Method did:something-safer:.... And optionally it may contain a ThisUseCaseCredential which is issued to whatever the DID Method the use-case wants to issue to, in this case it is issued to did:something-safer:this-is-me which is part of the same Subject as the did:web ID.

PEX has limit options to add constraints on the VP. This is mainly because each input_descriptor in a Presentation Definition adds constraints on a single container object. The container objects here would be the 2 VCs and the VP. Since the VP encapsulates the other container objects, adding a constraint on the VP (holder field) would collapse the constraints of all VCs and the VP into a single input_descriptor. This could be fine for validation of a Presentation Submission, but the steps required to untangle all these constraints to their individual container targets in order to build the submission is way to complex (if even possible). So, it does not seem possible to directly add constraints on a VP in the Presentation Definition.

PEX Relational Constraint Features , on the other hand, describe relationships between the individual container objects. We are currently implicitly applying the is_holder constraint to all VCs in a VP. Making this constraint explicit is the easiest way to add a constraint on the signer of a VP. For this to work we need to define what holder means in our context. If this means that the proof.verificationMethod MUST be on the DID Document of the DID in the subject.id field of the VC containing the is_holder constraint, only then can we constrain the signer to a specific (set of) DID Method(s). So 'holder == DID' and 'holder != Subject'.

Proposal

Broaden the existing implicit requirement on all VCs in a VP so that they now must be part of the same Subject.

Implement Relational Constraint Feature is_holder. Other relational constraints are currently not required and may be obsoleted before they are used if PEX is to be replaced with a different scripting language. (See discussions in OpenID4VP Github repo)

To reduce the number of possible failures, a VP should not be signed by a different DID method than those already used in the VCs??? Not sure how to select this. First that matches preferred DID methods list?

Implementation thoughts:
For each input_descriptor

• if it contains the is_holder constraint, the proof.verificationMethod (or jwt_vc equivalent) MUST be on the DID Document of the DID in the subject.id that can be resolved in the container object satisfying the input_descriptor.
• if it does NOT contain the is_holder constraint, the DID of the VC must be part of the same Subject as the signer of the VP. (Linkable through AKA fields in their DID documents.)

Number of input_descriptor with an is_holder constraint:

• 0: All VCs and the VP signature MUST be linkable through the AKA field in their DID Documents.
• 1: Same as above, but key material for the signing the VP should be resolvable on the DID Document of the subject.id of the VC with the is_holder constraint.
• n: Same as above, but this may result in multiple VPs if the is_holder constraint is placed on different subject.ids.

Notes on Writing Presentation Definitions

• Adding is_holder constraint is optional.
• Use the is_holder constraint sparingly to prevent Presentation Submissions with multiple VPs .
• If none of the issuers issues to the same set of DID Methods as the use-case would like to accept for the VP signer, issue a use-case credential that fits your needs.

[woutslakhorst]

Using the PEX features as constraint might be a waste of time if PEX is replaced...

[woutslakhorst]

We'll add a did_methods field to the discovery service definition.

[woutslakhorst]

What has been discussed:

• AkA will be removed
• VCs will be linked to a single DID
• VCs can't be used in a VP signed by another DID
• Migration from one DID method to another is done by taking enough time for natural expiration of old VCs