How to prevent a Verifier from acting as an unauthorised Holder #203
Comments
The verification software that Digital Bazaar is writing expects the DID specified for 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. |
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. |
|
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/
|
|
@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. |
|
@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. |
|
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. |
|
@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: |
|
@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. |
|
Need to fix the title to represent this discussion |
|
From TPAC 2018:
|
|
Decision at Barcelona F2F:
|
|
Issue opened on the impl. guide - w3c/vc-imp-guide#2 This issue here can be closed. |
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.
The text was updated successfully, but these errors were encountered: