Making explicit the binding of the holder to a VC

[swcurran]

This PR is an attempt to address #789 , adding, where appropriate (at least in my opinion), explicit references to the binding of a the holder (who will often be the subject) of the VC such that in a verifiable presentation the verifier can authenticate that the holder was issued the verifiable credential.

I've tried to follow the use of links to glossary items, but no doubt under- or over-used those links in places. Likewise for where I have tagged JSON properties with the "code" tag. Any guidance on that would be appreciated.

My main concern about this PR comes from the @David-Chadwick comment that credentialSubject.id may have become the de facto way to authenticate the holder, rather than using holder.id. Starting from scratch, I think it makes far more sense to use holder.id, but I wonder if it is too late. IMHO, I would much prefer that the VC Data Model had no opinion on the contents of the credential (it's just data) vs. explicitly saying there must be a subject and forcing all use cases to map (sometimes artificially) to the structure. However, I understand that is not appropriate to change in the V1.x context. IMHO the use of credentialSubject.id vs. holder.id is a by-product of that decision.

---

Preview | Diff

[swcurran]

I've linked my W3C and GitHub accounts. Do I need to submit a new PR? @msporny

[agropper]

I would like to keep this issue open. It's confusing for the VC specification to consider a Holder as separate from a Subject. This distinction was useful in explaining one way to use VCs but it is not the only way to use VCs. To the extent that VCs are linked to VPs, that is still not a reason to introduce Holder as a normative concept. Please see https://github.com/decentralized-identity/waci-presentation-exchange/issues/93 for one of the reasons. As we have seen over five years of discussion on this Holder vs. Subject issue, there are many other considerations.

…

On Tue, Aug 17, 2021 at 1:26 PM Stephen Curran ***@***.***> wrote: Closed #794 <#794>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#794 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YMWHUBU6YTQQJBZAU3T5KLTPANCNFSM5CKI6HBA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[swcurran]

This is a PR not the issue #789. I closed this and opened #795 to try to address the IPR issue in this PR, but I still have that problem. I'm contacting @msporny (via email) for help.

[David-Chadwick]

I would like this PR to add a credentialHolder property with identical syntax to the credentialSubject property i.e. the credentialHolder can contain an optional id and optional holder properties. In this way the issuer can identify the holder by either an id (linked to cryptographic material) or via human readable properties (e.g. name, address, passport number) or both.

[msporny]

I would like this PR to add a credentialHolder property with identical syntax to the credentialSubject property i.e. the credentialHolder can contain an optional id and optional holder properties. In this way the issuer can identify the holder by either an id (linked to cryptographic material) or via human readable properties (e.g. name, address, passport number) or both.

Can of worms: Opened. :)

Wouldn't this cause all of the fields in credentialSubject to be duplicated in credentialHolder? How does this interact with the existing holder property? What about the evidence property?

@David-Chadwick, also note that this PR is closed, and you might want to comment here: #795