Authenticators for nodes

[RieksJ]

There are lots of use-cases in which a VC that contains claims about different subjects is to be used in situations where more than one of these subjects need to be authenticated. For example, in the case of a marriage credential both persons need to be authenticated in order to determine whether are not they are married. In case of a guardianship credential, a guardian should only be allowed to exercise its rights regarding someone else after the other has been authenticated as the dependent in the guardianship relationship.

In a credential, the 'payload' typically consists of tree-like structures as shown e.g. in Figure 4 of the VC Data model:

As a JSON object, it would be something like this:

In this figure, 'Pat' and 'Sam' are identifiers that only the issuer knows how to dereference. If the issuer wants anyone else, e.g. verifiers, to know which real-world entities correspond with these identifiers, the issuer must provide means by which such entities can be authenticated.

In this issue, I only propose to add a section 'Authenticators' to chapter 4 (Basic Concepts), and have it specify that each node in an information graph that is contained in a VC MAY have a property authenticator, which links to a data object (to be further defined) that allows verifiers to authenticate the entity that is represented by that node.

---

If accepted, further/other discussions can be started as to what the authenticator object might/should/must look like.

There may be a link with #756.

For example, Example University may decide to allow authentication of people by means of a DID they control, a student or employee card, or a set of physical characteristics. The JSON object of Pat and Sam might then look something like this:

[David-Chadwick]

On 14/12/2020 09:31, Rieks wrote: There are lots of use-cases in which a VC that contains claims about different subjects is to be used in situations where more than one of these subjects need to be authenticated.

I would rather say 'needs to prove possession' rather than 'be authenticated'. It is the responsibility of the VC Issuer to authenticate the subject(s) that it includes in the VCs it issues. How it does this is its responsibility. It might put details in an Evidence property, but it may not. Its a question of trust by the verifier as to what it requires when validating the VCs it is given by the holder. The verifier needs the holder to prove possession of the VC. That's all. This could be directly or indirectly via a chain of VCs. Kind regards David

…

For example, in the case of a marriage credential both persons need to be authenticated in order to determine whether are not they are married. In case of a guardianship credential, a guardian should only be allowed to exercise its rights regarding someone else after the other has been authenticated as the dependent in the guardianship relationship. In a credential, the 'payload' typically consists of tree-like structures as shown e.g. in Figure 4 of the VC Data model: image <https://user-images.githubusercontent.com/8522589/102058864-7045cc80-3df0-11eb-8fd5-d55c8367bc18.png> As a JSON object, it would be something like this: image <https://user-images.githubusercontent.com/8522589/102062363-e9dfb980-3df4-11eb-93ce-61816a1a46af.png> In this figure, 'Pat' and 'Sam' are identifiers that /only/ the issuer knows how to dereference. If the issuer wants anyone else, e.g. verifiers, to know which real-world entities correspond with these identifiers, the issuer must provide means by which such entities can be authenticated. In this issue, I *only* propose to add a section 'Authenticators' to chapter 4 (Basic Concepts), and have it specify that each node in an information graph that is contained in a VC MAY have a property *authenticator*, which links to a data object (to be further defined) that allows verifiers to authenticate the entity that is represented by that node. ------------------------------------------------------------------------ If accepted, further/other discussions can be started as to what the authenticator object might/should/must look like. For example, Example University may decide to allow authentication of people by means of a DID they control, a student or employee card, or a set of physical characteristics. The JSON object of Pat and Sam might then look something like this: image <https://user-images.githubusercontent.com/8522589/102064273-64113d80-3df7-11eb-904f-52777ea1e900.png> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#760>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA33R7ZU76EQR7LJUP6RA23SUXLONANCNFSM4U2OIZDQ>.

[RieksJ]

I can see that the Pat & Sam example is confusing.

Consider the case in a hospital, where a patient is in a coma. Then, another person arrives and tells a doctor to stop that patient's treatment, and that (s)he must do so because the person is the patient's guardian. The doctor would then need to ensure:

• that the guardianship credential that the person produces verifies;
• that the person is indeed the person that fulfills the guardian role in that credential;
• that the person in a coma fulfills the dependent role in that credential.
  The doctor needs a way to establish all of this, and cannot rely on all entities having credentials for that (the credential that the person produces should suffice).

[David-Chadwick]

I completely agree with your example. This is called Power of Attorney in the UK. The person in a coma (called the donor in the UK) has an identity (note, not an identifier) and the doctor can check the identity of the comatose person/donor with what the PoA certificate says the donor's identity is. No special authentication property is needed for this. The PoA certificate only needs to state the identity of the donor. VCs are designed to state someon'e identity. Kind regards David

…

On 14/12/2020 10:04, Rieks wrote: I can see that the Pat & Sam example is confusing. Consider the case in a hospital, where a patient is in a coma. Then, another person arrives and tells a doctor to stop that patient's treatment, and that (s)he must do so because the person is the patient's guardian. The doctor would then need to ensure: * that the guardianship credential that the person produces verifies; * that the person is indeed the person that fulfills the guardian role in that credential; * that the person in a coma fulfills the dependent role in that credential. The doctor needs a way to establish all of this, and cannot rely on all entities having credentials for that (the credential that the person produces should suffice). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#760 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA33R73NOBRPWIT6Q2F5WETSUXPK3ANCNFSM4U2OIZDQ>.

[RieksJ]

I'm quite confident that in the UK you can't just go in waving a PoA, claim that you are the guardian mentioned in the PoA, claim that this patient here is the donor of the PoA, and then have his life support systems cut off. Before even considering this request, the doctor will need to make sure that you are the person that the PoA calls the guardian (which I consider as authentication of the guardian) and that this patient here corresponds with what the PoA calls the donor (authentication of the donor).

I think it is beneficial to have generic support for such authentication in VCs that does not require any prerequisite data/information, such as a previously obtained identity of the patient. I think that specifically in credentials that concern different subjects (people, things, ...) this may be quite valuable.

[David-Chadwick]

Have you ever applied for PoA in the UK? I have, so I am familiar with the financial PoA application and use, but not with the health PoA, as they are separate (but similar) applications. In both cases the attorney has to act in the best interests of the donor. So whether switching off the machine is in the patient's best interests or not is independent of the PoA, as relatives are allowed to complete Do Not Resuscitate forms regardless of being an attorney or not. So such discussions are clearly outside the scope of a VC discussion. What should be in scope of VCs, is can we use digital credentials to replace paper-based ones. The answer is no, not without legislation. Assuming that the legislation is in place at some point in the future, then can we mirror today's paper based practices with electronic credentials. Yes we can, and in this process the donor HAS to be identified. The donor is the one that applies for PoA in the UK whilst they are still compos mentis. So identification of both the donor and the attorneys (note plural as multiple are allowed) is mandatory. It is not realistic to assume "does not require any prerequisite data/information" Kind regards David

…

On 14/12/2020 12:21, Rieks wrote: I'm quite confident that in the UK you can't just go in waving a PoA, claim that you are the guardian mentioned in the PoA, claim that this patient here is the donor of the PoA, and then have his life support systems cut off. Before even considering this request, the doctor will need to make sure that you are the person that the PoA calls the guardian (which I consider as authentication of the guardian) and that this patient here corresponds with what the PoA calls the donor (authentication of the donor). I think it is beneficial to have generic support for such authentication in VCs that does not require any prerequisite data/information, such as a previously obtained identity of the patient. I think that specifically in credentials that concern different subjects (people, things, ...) this may be quite valuable. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#760 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA33R75UDT5OXLNZWXPPDDDSUX7LFANCNFSM4U2OIZDQ>.

[agropper]

I understand this issue in terms of notarization and it would be helpful if VC were clear as to how a notary can participate in a signature ceremony or a verification ceremony. In typical usage, a notary co-signs an issuance ceremony and makes a (private) log entry that references the identity proof of one party to the ceremony, e.g. a driver's license. The notary does not care about the actual content of the VC as long as the notary believes they are co-signing something that includes the issuer identity as well as the VC subject's identity. (It's up to the subject, not the notary, to verify the identity of the issuer or counterparty to the VC. Also, it's the subject that chooses the notary but the expectation is that both the issuer and the verifier will trust the notary's log.) The notary's log should include a hash of the VC. (in the paper world, the subject initials each page of the contract). I believe this is the general case for all VCs, except that some forego the use of a notary when issued. To me this mirrors the way VCs handle revocation as an optional thing to specify at issue. To facilitate the use of VC in zero-trust architectures, it would be good to provide explicit support for audit. The notary construct helps the parties agree on an auditor and makes better use of the DLTs when available. Adrian On Mon, Dec 14, 2020 at 7:51 AM David Chadwick <notifications@github.com> wrote:

…

Have you ever applied for PoA in the UK? I have, so I am familiar with the financial PoA application and use, but not with the health PoA, as they are separate (but similar) applications. In both cases the attorney has to act in the best interests of the donor. So whether switching off the machine is in the patient's best interests or not is independent of the PoA, as relatives are allowed to complete Do Not Resuscitate forms regardless of being an attorney or not. So such discussions are clearly outside the scope of a VC discussion. What should be in scope of VCs, is can we use digital credentials to replace paper-based ones. The answer is no, not without legislation. Assuming that the legislation is in place at some point in the future, then can we mirror today's paper based practices with electronic credentials. Yes we can, and in this process the donor HAS to be identified. The donor is the one that applies for PoA in the UK whilst they are still compos mentis. So identification of both the donor and the attorneys (note plural as multiple are allowed) is mandatory. It is not realistic to assume "does not require any prerequisite data/information" Kind regards David On 14/12/2020 12:21, Rieks wrote: > > I'm quite confident that in the UK you can't just go in waving a PoA, > claim that you are the guardian mentioned in the PoA, claim that this > patient here is the donor of the PoA, and then have his life support > systems cut off. Before even considering this request, the doctor will > need to make sure that you are the person that the PoA calls the > guardian (which I consider as authentication of the guardian) and that > this patient here corresponds with what the PoA calls the donor > (authentication of the donor). > > I think it is beneficial to have generic support for such > authentication in VCs that does not require any prerequisite > data/information, such as a previously obtained identity of the > patient. I think that specifically in credentials that concern > different subjects (people, things, ...) this may be quite valuable. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#760 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AA33R75UDT5OXLNZWXPPDDDSUX7LFANCNFSM4U2OIZDQ >. > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#760 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YLQWAGZONNL6IGN4KDSUYC4ZANCNFSM4U2OIZDQ> .

[brentzundel]

The chairs feel that work on this issue is outside the scope of the maintenance working group.
This doesn't mean work cannot continue, but that it would need to be included a future version of the specification.

[OR13]

Seems related to normative requirements for presentations... which really don't exist :)

[iherman]

The issue was discussed in a meeting on 2022-08-10

• no resolutions were taken

View the transcript

4.2. Define v2 context (issue vc-data-model#760)

See github issue vc-data-model#760.

Kristina Yasuda: This is about authentication relationship. Looks like it has been idle for a while, I suggest closing. Anyone can speak up on it?.
… Will mark "pending close".

[brentzundel]

No opposition since makred pending close, closing.