Claim and attestation as two separate concepts #98
Comments
|
Hi David,
We are implementing this use-case where the VC is a prescription signed by
a doctor in HIE of One http://hieofone.org/ (watch the 2-minute video)
Copies of the prescription itself are accessible to the physician, the
patient, and a pharmacy but only a hash of the prescription is on a public
blockchain. The physician has separate Verifiable Credentials that may be
linked in the prescription. Can you explain your point in this context? Are
you concerned about the privacy of the physician or the patient? What could
we be doing differently?
Adrian
…On Wed, Nov 29, 2017 at 2:08 PM, David Ammouial ***@***.***> wrote:
My understanding of the VC concepts is still basic as I joined recently
and I might not be getting everything properly, but there is a thought I
would like to share, in the hope it is aligned with the work made so far.
A verifiable claim is a claim with an embedded signature. If two entities
attest the same claim, then they would both need to issue the claim
separately, meaning there would be redundancy. Also, you cannot issue a
verification without divulgating the claim itself.
What about separating conceptually a claim from its attestations? One way
to think of it is signing the hash of a claim rather than the claim itself,
for instance. As a doctor, I could be certifying the medical condition of a
patient somewhere, while letting the patient decide whom to share their
actual condition with. The attestation would only make sense to those with
whom the claim was shared.
That would imply introducing a new "attester" role. An attester is not
necessarily authoritative, it's just someone that says a given claim is
true, provided you already know the claim. An attestation would simply mean
"I'm stating that claim with fingerprint XXX is true about subject with
fingerprint YYY".
Here I'm not discussing the advantages of using an attestation separated
from the claim in the different real-life use cases. I'm simply suggesting
the idea that those might be separated conceptually.
What do you think?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#98>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIeYb3qTaSgCmqxelNCi7f-ft2hKbn9ks5s7avCgaJpZM4QvePq>
.
--
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/
|
|
I'm not familiar with exactly how HIE of One works (I've only watched that 2-minute video), but one way of sharing and verifying a prescription would be for the physician to:
Am I making sense? To clarify again, just in case: I'm not suggesting that this is the only way of doing it right. Claims with an embedded signature are perfectly OK. I'm merely saying that conceptually you can think of a claim as something separate from an attestation, as the latter can sometimes exist independently from the former. For that reason I'm proposing to separate the two concepts in the Data Model. |
|
In 3, how does the pharmacy check that the physician signed the JSON object?
Adrian
…On Thu, Nov 30, 2017 at 10:58 AM, David Ammouial ***@***.***> wrote:
I'm not familiar with exactly how HIE of One works (I've only watched that
2-minute video), but one way of sharing and verifying a prescription would
be for the physician to:
1. Generate the plain (i.e. unsigned) JSON object for the prescription
and share it with the patient
2. Post a blockchain transaction containing a hash of that JSON object
3. Let the pharmacy get the JSON object by any way (QR code, email, it
doesn't matter as long as they obtain the JSON), calculate its hash on
their own and check on the blockchain that the physician has signed it
Am I making sense?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#98 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIeYS5zZ0ncsrqCaDHZ0wFD4tCS5gTTks5s7tCwgaJpZM4QvePq>
.
--
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/
|
By posting a blockchain transaction containing the hash of the JSON object he essentially already signed the JSON object. By verifying the transaction that the physician made a pharmacy would check if he indeed signed the object. |
For blockchains with signed transactions (and where the physician controls the key). Fit-for-purpose blockchains (those that aren't financial blockchains that have been adapted for other use cases) may put the signature elsewhere. |
|
I think this is related to #118. |
|
This may have been addressed in PR #141 |
|
outcome of F2F meeting: #141 isn't being merged |
|
Discussion at F2F meeting: You could accomplish this by doing something like The group plans to close this issue in 7 days as there are no spec changes in scope that we could make to address your issue. The way to address it is via the signature suite, and that is out of scope for the group. |
|
The context is digitally signed agreements related to privacy in various
domains. My goal is to promote broader understanding and use of VCs.
I’m trying to explain to others the benefits of linked data for
interoperability as compared to always having to create a more formal
specification in a standards organization model. When is LD preferred and
when is a formal specification better?
Can anyone suggest one or two brief references to point to? One might be
generic or tutorial in nature and the other might mention VC work to
accommodate both JWT and JSON-LD specifically.
Thank you,
Adrian
…--
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/
|
My understanding of the VC concepts is still basic as I joined recently and I might not be getting everything properly, but there is a thought I would like to share, in the hope it is aligned with the work made so far.
A verifiable claim is a claim with an embedded signature. If two entities attest the same claim, then they would both need to issue the claim separately, meaning there would be redundancy. Also, you cannot issue a verification without divulgating the claim itself.
What about separating conceptually a claim from its attestations? One way to think of it is signing the hash of a claim rather than the claim itself, for instance. As a doctor, I could be certifying the medical condition of a patient somewhere, while letting the patient decide whom to share their actual condition with. The attestation would only make sense to those with whom the claim was shared.
That would imply introducing a new "attester" role. An attester is not necessarily authoritative, it's just someone that says a given claim is true, provided you already know the claim. An attestation would simply mean "I'm stating that claim with fingerprint XXX is true about subject with fingerprint YYY".
Here I'm not discussing the advantages of using an attestation separated from the claim in the different real-life use cases. I'm simply suggesting the idea that those might be separated conceptually.
What do you think?
The text was updated successfully, but these errors were encountered: