How to prevent a Verifier from acting as an unauthorised Holder

[David-Chadwick]

Say a holder (who may or may not be the subject) sends a VC to a Verifier that it trusts to use the VC for a particular purpose, and puts a limitation in the Terms of Use of the Verifiable Presentation to this effect, then what is to stop an untrustworthy Verifier from stripping off the Verifiable Presentation and then presenting the VC to another verifier, wrapped in a new Verifiable Presentation, asserting that it (the first verifier) is the rightful holder who is allowed to present this VC to the second verifier?

Terms of Use in the verifiable presentation do not protect against this.

Terms of Use in the issued VC could protect against this, but this would necessarily restrict how the holder could use or present the VC. For example, SAML introduced an audience restriction into the issued SAML assertion to limit the target/verifiers who are authorised to receive the assertion, but this on its own is not sufficient for our situation, as the second verifier may be within the set specified by the audience restriction. So there is a tension between:
a) allowing the holder the flexibility to present the VC to any verifier, and
b) stopping the first verifier from re-presenting the VC to a second verifier, whilst
c) allowing a VC to be chained between processes e.g. in a supply chain, where the end verifier is given proof of who the subject is.

I do not think we currently have any text that covers this issue.

[msporny]

What is to stop an untrustworthy Verifier from stripping off the Verifiable Presentation and then presenting the VC to another verifier, wrapped in a new Verifiable Presentation, asserting that it (the first verifier) is the rightful holder who is allowed to present this VC to the second verifier?

The verification software that Digital Bazaar is writing expects the DID specified for verifiableCredential.claim.id to be associated with verifiablePresentation.proof.creator (i.e. subject is holder). If it is not, the linkage between the Verifiable Credential and the holder must be established in some other way. If the linkage can't be established, and the establishing the linkage is important for the use case, the verification process would fail (because the verifier has no idea if the holder should have that particular credential).

You are correct in that we don't really go into details about this use case, but there is a way to use the existing values in the data model to prevent this from happening.

As for supporting the use case of "delegating credentials"... that's something that I haven't seen a compelling solution for yet. I expect that the solution may have to do with a certain type of verifiable credential that asserts the delegation of a credential to a different subject. I'm thinking through a solution wrt. that currently... still a bit fuzzy on some of the attack vectors if we enable this... working through those.

[dlongley]

As for supporting the use case of "delegating credentials"... that's something that I haven't seen a compelling solution for yet. I expect that the solution may have to do with a certain type of verifiable credential that asserts the delegation of a credential to a different subject.

I don't think "delegation" of a VC makes any logical sense. A VC is a statement of identity about a subject. How do you "delegate" that? Delegation is the act of granting authority (that one already has) to another party. What authority you have is determined by the verifier, not the issuer (the one making statements about identity).

With the existing data model anyone can already say anything about anyone else. No one needs to be delegated that authority. Rather, there are use cases where you need a chain of trust. For example, where a verifier receives a transcript from a student from university X -- but the verifier does not know university X. However, a system can be engineered such that the verifier can dereference university X's identifier and find a document with another VC (or that leads to it via another protocol) that states that the university has been accredited by board Y and the verifier does trust board Y. We should support this (and do, I believe), but this is not "delegation", it is chain of trust.

What we haven't done is specify any protocols around this ... because we're not chartered to do so. We could potentially write some non-normative examples, though.

"Delegation" is the in the realm of authorization and there is another spec the CCG is working on for that -- OCAP-LD.

[agropper]

I find it hard to follow this issue along with #198 and #204. Maybe someone can help by mapping to the Prescription Use Case. - I'm working on the assumption that a prescription can be a VC. If that's wrong, the rest changes. - The prescription can be for either a normal or controlled substance. In the latter case, there are additional accountability requirements. - The issuer is a physician with 3 credentials - wherever they are held - a gov verified (biometrically) ID, a medical license, a DEA number. The DEA number only matters for controlled substance prescriptions. - The verifier is a pharmacy. - Upon delegation by the subject, the prescription may be presented to the pharmacy by anyone else who claims a relationship to the subject. - The claim of a relationship to the subject may be verified to the extent there's a common address, last name, or some verifiable proof of delegation. To make this a little more complicated, we should consider the full HIE of One use-case where the issuer writes the prescription VC and then caches it in the subject's medical record (said record could be at the hospital or at the patient's holder). At some point, some Identity comes by wherever the prescription is being held and seeks authorization to present the prescription to the pharmacy. The patient grants said authorization using UMA. - The pharmacy gets the prescription directly from whatever medical record is caching it. Adrian

…

On Thu, Jul 19, 2018 at 11:29 AM, Dave Longley ***@***.***> wrote: As for supporting the use case of "delegating credentials"... that's something that I haven't seen a compelling solution for yet. I expect that the solution may have to do with a certain type of verifiable credential that asserts the delegation of a credential to a different subject. I don't think "delegation" of a VC makes any logical sense. A VC is a statement of identity about a subject. How do you "delegate" that? Delegation is the act of granting authority (that one already has) to another party. What authority you have is determined by the verifier, not the issuer (the one making statements about identity). With the existing data model anyone can already say anything about anyone else. No one needs to be delegated that authority, rather, there is a question of trust. There are use cases where you need a chain of trust. For example, where a verifier receives a transcript from a student from university X -- but the verifier does not know university X. However, a system can be engineered such that the verifier can dereference university X's identifier and find a document with another VC (or that leads to it via another protocol) that states that the university has been accredited by board Y and the verifier *does* trust board Y. We should support this (and do, I believe), but this is not "delegation", it is chain of trust. What we haven't done is specify any protocols around this ... because we're not chartered to do so. We could potentially write some non-normative examples, though. "Delegation" is the in the realm of authorization and there is another spec the CCG is working on for that -- OCAP-LD. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#203 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIeYfXm7J9tAnNxLVpRSHYlomHpUBYkks5uIKXMgaJpZM4VWKn1> .

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: https://patientprivacyrights.org/donate-3/

[David-Chadwick]

@dlongley "What authority you have is determined by the verifier, not the issuer (the one making statements about identity)".

This is not always the case. There are plenty of VC examples where the issuer is authorising you and granting you certain rights. First, every case where the issuer and the verifier are the same authority, the issuer typically determines what rights you have. For example, when roles are assigned in organisations, the issuer determines the role you have, and the verifiers that are typically distributed throughout the organisation, honor this by giving you access to their various resources.
Secondly, when I get a driving licence, the issuer gives me authority to drive a car. A policeman, the verifier, honours this. The verifier does not authorise me to drive a car.
Thirdly, electronic prescriptions, issued by a doctor, authorise me to collect drugs from a pharmacy. The pharmacy verifier has no authority to change the prescription or stop me accessing the drugs. Furthermore I can go to any pharmacy. Who the verifier is, is largely unimportant.
I could go on, but I hope you agree the point.

[David-Chadwick]

@agropper. I agree that a prescription can be a VC (see my comment above). I also agree that the holder may not be the subject, and therefore the pharmacy needs to know if the holder is authorised to present the prescription (and it is not some drug addict who has stolen it from the patient). Knowing that the holder is authorised could be via a variety of mechanisms, for example:

i) the subject delegates to a relative or friend using one of the mechanisms described in the delegation section of Subject NE Holder

ii) the issuer (doctor) could give the prescription VC directly to the relative, say if the patient is bedridden, and uses the mechanism described in the section "Holder Acts on Behalf of Subject"

iii) The holder could physically present him/herself to the pharmacist and show other credentials (not necessarily electronic ones) to prove they are acting on behalf of the subject (patient). This is outside the scope of the current data model.

[stonematt]

Is this strictly related to the scope of Data Model? This discussion seems to invoke protocol type details that we shouldn't be trying to solve at this point.

[David-Chadwick]

@stonematt We already include protocol related content in both the VC and VP, for example, Terms of Use, which states what a verifier is expected to do when receiving the VC/VP. I guess we have two choices:
a) strip everything from the existing data model that relates to protocol and passing VCs and VPs between different entities, or
b) continue as we have been doing, and show how the data model can be used to control the transfer and use of VCs and VPs between the different entities.
This issues assumes we have chosen path b), and indicates where we still have a void in our document.

[stonematt]

@David-Chadwick @dlongley I agree that there are elements of the data model spec that support the protocol work. But this seems to go beyond that. An issue like this could very well be identified in the issue tracker or in the specification as a problem that the protocol will solve. This is particularly true since we decided to defer the delegation discussion.