Support for different Subject-Holder relationships

[Santiago de Diego]

This issue is a question rather than a proposal.

I am trying to develop a quick Proof of Concept where the subject of a Verifiable Credential is not the same as the Holder, as is specified in the W3C Verifiable Credentials Data Model.

This would essentialy require three technical conditions:

1. A Holder must be able to store VCs whose subject is not him
2. A Holder must be able to generate a VP containing a VC whose subject is not him
3. A Verifier must be able to look into a Relationship Credential issued to the Holder (as specified in the W3C Verifiable Credentials Data Model) and check if the Holder is authorised to present this VC, considering he is not the original subject.

I have been reviewing the code to do a quick check if it would be currently possible to support this scenario and I do not see any constraints in the code that forbit 1 and 2, which means it should be possible to fulfill 1 and 2 with with no changes in the current code. I don´t know if I am correct with this point, may be you can prove me wrong.

Also, regarding the number 3, I see from this line in validators.ts file that the only verification made currently by a Verifier regarding the subject of a VC is if the subject field is empty, so I guess it should be possible to implement the needed logic for 3 with minor changes in the code.

Am I correct with my thoughts or am I missing something? is it in the roadmap to add support for this kind of scenarios?

[Bumblefudge]

Non-subject holders are a tricky business, and often relegated to the domain of "implementation-specific"-- specs are often frustratingly silent on the subject! I would mention that there is some talk of including [potentially non-subject] holder functions in the VC-HTTP-API at W3C-CCG, so if this is a major research area or a central design question, stay tuned to the CCG mailing list for announcements of a topic call in the coming weeks. As for the roadmap of this specific repo, I would say to reach out to the chairs of DIF C&C WG to see if there is ongoing work on it or if it is just in "maintenance mode"-- if you have upgrades to suggest that you're willing to implement, join or initiate that work!

[Santiago de Diego]

Thanks for the prompt answer!

I´ll deeply study the code in the VC-HTTP-API repo. I found that some support might already be implemented in verifyPresentation.spec.js file, but I´ll also stay tune to the CCG mailing list.

[Mircea Nistor]

@santidediego you are correct about 1 & 2, currently there is no enforcement of the holder/subject relationship during validation. This is mostly because, as @bumblefudge is saying it is complicated to verify generically.

Technically, since recent versions of this library support specifying verification options, I suppose that an option to check for this relationship could be added.
As I understand from your proposal, when this option would be on, the library would need to validate that the credentials contained in the presentation are issued to the holder that is signing the JWT or that the presentation also contains one of these relationship credentials with the correct link.

But, I think that this kind of validation should be done on a higher layer since several things may not align properly:

• the Relationship Credential may not be JWT (currently a requirement for this library)
• the verification requirements for the Relationship Credential may be different (different domain?)
• ...

If you do come up with a POC for this kind of validation, perhaps you could share more thoughts here.
A PR for this would be welcome ;)

[Santiago de Diego]

Sure! thanks again for the answer