Unstated expectations and assumptions about subject-holder relationships #68
Comments
Agreed, @jandrieu, excellent analysis and spot on. Remember also that the spec doesn't outline how a holder asserts "I am this DID" - that is, by counter-signing the profile. Again, the implementations Digital Bazaar has done over the past 3+ years support profile counter-signatures, but we have yet to put that into the spec. |
|
@jandrieu and @David-Chadwick volunteered to write an issue marker for this in the Milestone 1 spec during our 29 Aug 2017 telecon. |
|
Suggested language:
|
|
I was thinking that we should have two pieces of text in the current
specification as follows.
The first piece should state:
The current version of this specification is restricted to use cases
where the holder of the VC is the subject of the VC. A subsequent
version of this specification will consider use cases where the holder
of the VC is not necessarily the subject of the VC.
The second piece of text should state:
The inspector-verifier should [may? - definitely not 'must' as it
depends upon the risk model adopted by the inspector as to whether it
adopts POP or not] implement a 'proof of possession' protocol to confirm
that the holder is the subject. This specification does not mandate any
particular 'proof of possession' protocol.
regards
David
…On 08/09/2017 21:13, Joe Andrieu wrote:
Suggested language:
The current language leaves the issue of identity proofing to the> inspector-verifier when the holder's presentation implicitly asserts
they are also the subject of the presented claim. There is currently
nothing in the data model that allows a claim to specify how an
inspector-verifier should ascertain that a holder is the subject.
Several use cases implicitly depend on such assurance, e.g., when an
individual (the holder) presents a digital driver's license as
demonstration of their (the holder's) license to drive. Other use
cases do not depend on the presumption that the holder is the
subject, e.g., an assistant providing that same digital driver's
license to a travel agency on behalf of the traveller. In the latter
case, the travel agency will match the name on the driver's license
to the name on the travel documents, e.g., a plane ticket, without
needing identity assurance for the assistant.
Some identifiers, such as Decentralized Identifiers (DIDs), allow
for an explicit assurance mechanism, e.g., through proof of
ownership of a private key in the case of DIDs. However, there is no
requirement for Verifiable Claims to use DIDs, nor is there a
general assurance mechanism defined for arbitrary URIs.
As such, the current Verifiable Claims specification does not
require that verification includes identity assurance. Any
inspector-verifiers who depend on such assurance must provide their
own means to do so. The Working Group continues to discuss possible
approaches for supporting various identity assurance methods within
the Verifiable Claims data model.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#68 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADe4_z55cD544VRTF3zXmS7pWkqAxUvCks5sgZ_VgaJpZM4OutSB>.
|
|
Except the current data model has no support for use cases where Subject is presumed to be the Holder. The only verification mechanism defined for Verifiable Claims is a cryptographic analysis of the signature and checking an optional revocation mechanism. In contrast, as the data model is now, it works fine when there is no presumption that the Subject is the Holder. Claim verification is completely independent of identity proofing. The harder problem is supporting the use case where the verifier-inspector depends on identity proofing of the Holder as the Subject. If you want to support that, you need to update the data model. |
|
I would argue the contrary, that whilst the data model does not state definitively who the holder is, it implies the holder is the subject viz "In this process, the holder asks for the benefit and the inspector-verifier grants or denies the benefit based on verification of the holder’s qualification from a trusted issuer." This sentence implies the holder is the subject, and that for verification the inspector-verifier needs to do two things:
Credential verification is a necessary but not sufficient process for granting the benefit to the requestor (holder). Consequently the data model needs to explicitly state this. |
|
There are many of those, including me, who were drawn to this work because it does not depend on a flawed presumption about the identity of the holder. That said, I agree completely with your last statement. In order to support reliance on identity proofing, the data model needs to explicitly state this. It does not at this point. There is no property that specifies how such proofing would be performed. There isn't even a property that would allow proofing mechanisms to be specified in the future. In a sincere attempt to find common ground, this missing property is why there is such a disconnect. The data model says nothing about how to verify holder==subject, but several contributors, with good reason, have that expectation. The narrative, both in the spec and in discussions, is ambiguous, with statements in both directions: simultaneously acknowledging (as you did) that the spec doesn't require proofing (nor registries) but in other places clearly building on the assumption that proofing is a solved problem. This ambiguity is what we need to resolve. Either remove the presumption that holder==subject or specify how exactly an inspector-verifier verifies that holder==subject. Since the current data model, and the bulk of the text works without that presumption, removing it would allow us to publish the FPWD sooner. The problem with presuming that identity proofing is "solved" without solving it is that this confusion has already led to misunderstanding by practitioners in the field. If the solution is proof of ownership, that solves identity in a particular way. If the solution is biometric, that's another. If it depends on real-time interactive services, yet another. Each of these approaches has fundamentally different privacy and security implications. IMO, we can't just punt on the problem of proofing and expect Verifiable Claims to be considered a solution where proofing is inherent in the applicability of a claim. In the meantime, we can publish a spec that works where such proofing is not part of the promise. |
|
Currently there is a flawed presumption in the data model document about the identity of the holder, because it is ambiguous. Hence different people make different presumptions about this. Hence it is flawed. What I am arguing for is that we eventually support both scenarios: holder is subject, and holder is not subject. And that the data model has built in explicit mechanisms for this. But we start with the simplest model first: holder is subject, and then progress to holder is not subject in V2 of the data model. And we have text in the document to say how holder==subject can be validated by the inspector. |
|
Agreed that it is flawed due to ambiguity in the document. However, the data model already supports the simplest model, where the subject is not necessarily the holder. In those cases, all you need to do is check signature and revocation. Which is well defined and fully documented. What's more complicated to define how to verify that the holder==subject. Outside of the DID effort in the community group, there has barely been any consensus conversation about how to do this and even less documentation of what that consensus might be. I'm puzzled why you think figuring out identity proofing is somehow easier than omitting identity proofing. Identity proofing is not only an industry-wide challenge, it is explicitly outside the scope of our charter. For example, there is recognition that there are multiple ways you can do it, including registries, but for many, pushing identity to potentially interactive registries creates more privacy problems than it solves. (To many, we may as well just use SAML if VCs depend on interactive registries to identity proof). The question then becomes, in the face of the goals of the group, "What are the different proofing mechanisms that the data model is going to support?" Right now, the data model doesn't support any proofing mechanisms except, potentially DIDs, assuming that specification results in a URL with a built-in proofing method. What it does support are uses where verification is not dependent on proofing. That's the simplest case and it is already supported by the JSON in the examples. |
Not exactly correct, @jandrieu, but discovering this would require years of immersion in the specs and I can understand why one would assert what you did. The "identity proofing" (if you can call it that) mechanism that /is/ supported by the data model (and implementations have supported it to varying degress in the past) is this one:
This asserts that /some form/ of proof of possession has been achieved. Whether or not it is good enough for the task at hand is another question, but it's not correct to say that the data model does not support this today. It's certainly not documented in full because this whole exchange is out of scope (it's mostly part of a protocol definition). However, there are bits here that we need to elaborate upon in the Verifiable Profile section of the data model spec (to highlight that proofs attached to the verifiable profile could (and are) be used to do things like proof of possession). This sort of stuff doesn't just work in DIDs, it works in traditional PKI trust systems as well. |
|
Ok. That's interesting. Given the confusion in other discussions about profiles, and the recent emergence of the term "verifiable profiles", I suppose it isn't surprising that this isn't obvious. Is it correct to say that a Verifiable Claim is not verifiable unless in a Verifiable Profile where the creator of the profile signature is also the subject of the claim? Or would it be more correct to say that a Verifiable Claim which depends on holder==subject must be in a Verifiable Profile where the creator of the signature is the subject of the claim? Is is possible for a claim to be properly verified outside a Verifiable Profile? I don't think these are protocol issues, I think they are directly implicated in the data model. If, as David advocates, we only support holder==subject, then verification requires a Verifiable Profile and the creator of the signature on that profile must be the subject of the claim. That restriction is supported in the current examples--I appreciate the correction--but not stated explicitly. I believe this highlights the mistake we've been making in talking about issuing claims, sharing claims, and verifying claims, as discussed in issue #46. For example. the poll we did on issuer/holder/inspector used "claims" as the defining object throughout, but (1) claims aren't issued, credentials are and (2) claims aren't shared, profiles are, and, now apparently, (3) verification has no meaning except in the context of a profile which is signed by the subject, which is taken to mean subject==holder. My frustration with this is twofold. First, the ambiguous and incomplete language confuses and obfuscates rather than leaves options open. If VCs are dependent on the limited notion that proof-of-ownership is the sole means of identity assurance, we should make that very clear because it hasn't been to date. Second, I personally find proof of ownership an extremely narrow form of identity proofing. It says almost nothing about the human body between the keyboard and chair, nor does it allow an accreted identity based on assertions which themselves provide the information for assurance. You rightly point out that "Whether or not it is good enough for the task at hand is another question". Reducing VCs to this use limits them rather significantly, IMO. For example, I don't see how Joram 1.0.0 could have been realized with the limited notion that proof of ownership = proof of identity. If proof-of-ownership is the explicit means for demonstrating holder==subject, and this use is the only one supported by verifiable claims, we should make that much clearer at the outset. |
|
I agree that clarity is needed. But I would also say that proof of ownership is out of scope as this requires a way of validating the link between the person and the client software that creates and transfers the profile to the inspector. Proof of possession is the most we can do, i.e. that the client software that obtained the credentials on behalf of the subject is the same one that is sending them to the inspector. We can only assume that the client software is under the control of the subject, but we have no way of validating it at present. |
|
@manu. There is a weakness between your steps 4 and 5 related to issue 55. If issue 55 is not nailed down to mandate that all claims in a credential must refer to the same subject, and all credentials in a profile must refer to the same subject, then we can have the cases that |
|
@jandrieu wrote:
It depends on how you define "verifiable". Certain parts are still verifiable, where "verifiable" means "there are certain things that you can check to see if they're true or not"... like a digital signature, for instance. A Verifiable Credential (which contains verifiable claims) is verifiable outside of a Verifiable Profile. A Verifier can check that the digital signature on the 3rd party supplied signature of a Verifiable Credential, thus making the verifiable claim and verifiable credential... verifiable. So, the short answer to your question above is "No, that's not correct."
Yes, this would be more correct.
Yes, that's possible and I tried to explain how above in this comment.
Note that I never said that these are purely protocol issues.
They are not dependent on that limited notion. I'll explain why in the next comment. |
|
I haven't finished reading all of the comments in this thread just yet, but it's becoming clear to me that the spec needs to clearly lay out that there is an intentional decoupling -- a separation of concerns -- regarding the subject's identifier format, the proof mechanism used to assert authorship of the claims, and the proof mechanism used to assert ownership or control over the subject's identifier. I think this would be a better approach than stating some (temporary) assumptions. From there, we need to lay out, in the verification section, recommendations for each of these things including how and when certain types of verification should be performed, i.e. If you want to prove to the verifier that you are in possession/control of a particular subject identifier then use a Verifiable Profile. If you do not need to prove this you may present a Verifiable Credential or a Profile (with multiple credentials) that contains no proof of possession. And, similarly, from the verifier's perspective: If you need to know that the presenter owns (or controls) the subject identifier (i.e. you need to authenticate them as the entity the subject identifier refers to) then they must present a Verifiable Profile. And so on. In my view we should just enumerate the core, common requirements of each case -- and bind them to what a reader needs to use from the data model to fulfill them. This won't necessarily mean we will say a particular type of proof must be used (though we may make recommendations per the charter), but we will say the purpose of each element of the data model, with respect to authentication/verification. This approach would allow us to make it more obvious why things exist in the data model without defining some kind of prescriptive protocol (which we aren't chartered to do). Some sample language: A Credential is used when... or A Credential adds capabilities X... We should list out the building blocks and then talk about what new capabilities are provided by them (and, therefore, it should become obvious which use cases they help address). |
Joram can be realized because we don't have a limited notion of proof of ownership == proof of identity. Lets talk about something more specific than "proof-of-ownership" as we need to at this stage of the conversation. Let's instead start talking about "authentication", which we've started doing here: w3c-ccg/did-method-v1#1. How does Joram authenticate with a system? There can be at least three ways, which are all supported by the current VC Data Model:
This is all enabled by the "authenticationCredential" portion of a DDO per w3c-ccg/did-method-v1#1. We need to figure out a way to express that in the VC Data Model spec w/o overstepping our charter. I suggest we do it in Section 5: Advanced Concepts: https://w3c.github.io/vc-data-model/#advanced-concepts |
|
@David-Chadwick wrote:
We currently don't make that assumption in the data model, and we do have a way (as explained above) of validating some aspect of what you're talking about.
I don't think we can logically limit claims in that way. Linked Data is open world assumption, and as such, we can't stop people from putting whatever they want to in a claim. We COULD assert that verifiers should throw errors if the same subject ID isn't in the profile and at the root of all claims, but that has been a disastrous approach when done in other W3C specs. The problem you create when you do that is an upgrade path problem, all of a sudden the old systems reject perfectly valid verifiable profiles once we do support the feature and we create a protocol upgrade nightmare. In other words, if we want to make the limitation that you're supporting, we should put that limitation in protocol specs and not the data model spec. You can always limit functionality at the protocol layer, but it's rarely a good approach to create a limitation at the data model layer. For example, we don't say "You can only use characters a-z, A-Z, and 0-9 of UTF-8 (data model) when exchanging data on the Web (protocol) ". Rather, we say "if you're doing X over HTTP, then these are the valid inputs". It's not a perfect analogy, but I hope it helps illustrate the point I'm trying to make. We should be very careful about putting limitations on the data model. Rather, we may want to put warnings instead. |
|
I think there is a strong link between the protocol and the data model. After all, the data model defines a credential which is essentially a signed message that has to be carried in some protocol from the issuer to the inspector via the subject/holder. Because the holder can be an attacker, and is in control of the protocol exchange with the inspector, there needs to be some binding between the credential and the protocol to stop an attacker taking a copy of someone else's credential and purporting that it belongs to him. |
|
Thus in order to protect against this type of MITM attack, I dont think you can logically put all the controls in the holder-inspector protocol, because the attacker has full control of this. The attacker does not have control of the credential, so a control must be in the data model. |
Yes
Yes, and this control is the "authenticationCredential" field in the DDO (or somewhere in the subject's graph), at a minimum... IF you need to verify that the holder is the subject. |
|
Where is DDO in the current data model specification? Where is authenticationCredential? DDOs are not mandatory. Consequently a field such as this needs to be in the data model spec, then we have solved the issue |
Perfect. That's exactly what I think is missing. Will there be a way other than a DID to provide these types of assurances/proofing? Personally, I think relying on DIDs is a fine idea, but it hasn't been explicit in the specification, and I'm wondering if that's even possible at this stage, given where that specification is in its lifecycle. My advocacy here is that the As you discuss in terms of protocol level versus data model, I would push the requirement for holder==subject into policy. That is, it should be entirely up to the verifier-inspector whether or not they check for that. That seems like a policy decision rather than a matter of verifiability of the claim itself. The claim asserts that this subject has certain attributes. It's a separate question, IMO, to verify that the current holder is the subject. With proof of possession and DIDs/DDOs, I think we have a reasonable, and reasonably limited approach when proof is necessary. Apropos of this thread, I just had a chat with Adrian Gropper about his prescription use case. For him, there is no requirement that the holder==subject. It's completely acceptable, for example, for a wife to pick up a prescription from the pharmacy without any explicit delegation. He's more concerned about verification that the issuer is authorized to prescribe and potentially that the prescription of a controlled substance is properly registered (checking the VC against a registry). I think a DID and DDO can handle his requirement for the issuer's credentials, but I'm curious if there is a way to programmatically verify the registry requirement--or if that is a policy-level issue where the verifier-inspector would use an industry practice to check against the VC ID or hash or something. In any case limiting VC verification to require proof that the holder==subject would preclude using VCs for Adrian's prescription use case. |
|
@dlongley Much support for your proposal for better illustrative examples for the different parts in the data model and why we have decoupled where we have. |
|
@David-Chadwick wrote:
The Decentralized Identifier Object (DDO) is not a part of the data model specification, you get it by dereferencing the subject identifier (if the subject identifier is a Decentralized Identifier). The DID spec is here: https://w3c-ccg.github.io/did-spec/
w3c-ccg/did-method-v1#1 (comment)
The necessary field in the VC Data Model spec is the subject identifier |
|
@jandrieu wrote:
Yes, basically when you dereference the subject identifier (e.g.
It's fine, but we don't want to limit it to DIDs. We also want to ensure that people can deploy this purely over HTTPS, so we support that too. Again, this is currently supported by the data model.
We can always say non-normative stuff in the spec and point elsewhere for readers that want to learn more.
Agreed.
Yes, best to delegate the right thing to do to market verticals (and you can support multiple market verticals each having multiple ways of authenticating people based on what they are trying to do). For example, software-based digital signature may be fine for some stuff, but secure element signature might be necessary for others, or biometric implant may be necessary for the really scary stuff (missile launch codes, etc.). |
|
I think the e-prescribing use-case can help inform this discussion. I'm in
the process of updating the white-paper based on our work on this use-case
in the past year and being clear about DID, DDO, and VC in the update would
be nice, but may be a stretch. In any case, here it is:
- The *Verifiable Claim* is a prescription. The process is subject to
federal rules under the DEA.
- The prescription is presented by the *Holder* to the pharmacy as
the *Inspector
/ Verifier*
- The presentation is either in digital or paper form to make sure
that pharmacies don't have to update their systems in order for
self-sovereign IDs to be a thing.
- The Holder is not always the subject since it's often the case that
family members pick up the drugs.
- The *Issuer* is a licensed physician that has a DID and a
corresponding DDO. It's important that the DID be standardized. I'm not
sure how important it is for the DDO to be standardized.
- The physician has at least three kinds of public metadata
associated with her DID:
- A National Provider Identifier (A very public and not very
secure database that stores some current metadata about the
physician.)
Here's mine:
http://www.npinumberlookup.org/getResultDetails.php?npinum=1891022661
or
my daughter's
http://www.npinumberlookup.org/getResultDetails.php?npinum=1922392042
- A state and medical license (Here's my daughter because my
license is not current) number:
http://profiles.ehs.state.ma.us/Profiles/Pages/PhysicianProfile.aspx?PhysicianID=101177
- A DEA Number - The DEA numbers are semi-private and checks cost
a few pennies. The pharmacy already has ways for them to check the DEA
number if one is written in the prescription.
- It's important NOT to need any of these three metadata registrars
to do anything different from what they are already doing. They
have little
incentive to care about DIDs or VC and we don't want to wait for that to
change.
- The *Subject* is the patient. If necessary, it's up to the Issuer to
verify the patient's DID and associated claims by looking at the patient's
driver's license vs. information in the DDO. In theory, this should be
automated by having the physician's mobile scan the barcode on the back of
the license.
- It would be critical not to require the state DMV to change
anything about how they do things. Also, unless the drug is a controlled
substance, there may be no requirement for the physician to
verify anything
about the Subject's DID. This gets more complicated when there's
insurance
involved but let's not go there for the simple use-case.
One more very important thing:
The reason we're eager to use standard self-sovereign IDs is because we
want to avoid unnecessary federation requirements typical of OpenID Connect
IDPs and because we want the Issuer to be able to sign the Verifiable Claim
in a convenient and non-repudiable way. Here's a screen shot of our Login
screen for either the physician or the patient:
[image: Inline image 1]
Note that there are 4 ways to authenticate to patient Alice that owns the
domain shihjay.xyz as her identity container. One is local, two are
federated with the mdNOSH one representing an OIDC IdP whitelisted by
patient Alice. The critical one from our use-case perspective is uPort or
whatever DID-standard self-sovereign ID anyone wants to use. It's very
important that the Verifiable Claim that's about to be created when the
Issuer physician uses her uPort to sign in to the patient's self-sovereign
health record (via Alice's UMA Authorization Server) be standard enough so
that the software just works and results in a practical prescription.
*TL;DR:*
From a self-sovereign perspective, it's important that the physician and
patient have standardized DIDs. From an adoption perspective, it's
important that only these two principals be required to install or use
software that is DID or VC-aware.
Hope this helps,
Adrian
On Mon, Sep 11, 2017 at 8:27 PM Manu Sporny ***@***.***> wrote:
@jandrieu <https://github.com/jandrieu> wrote:
Will there be a way other than a DID to provide these types of
assurances/proofing?
Yes, basically when you dereference the subject identifier (e.g.
https://example.com/people/jandrieu or
did:v1:9646ec67-3660-4936-9f9e-91c885ebb1a3), if the document you
dereference has an authenticationCredential then a Verifier MAY use any
authentication credential listed (that's acceptable to the Verifier) to
authenticate the subject. This is how you can either use digital signatures
to authenticate Joram, or a template-based pseudonymous biometric to
authenticate Joram.
Personally, I think relying on DIDs is a fine idea
It's fine, but we don't want to limit it to DIDs. We also want to ensure
that people can deploy this purely over HTTPS, so we support that too.
Again, this is currently supported by the data model.
I'm wondering if that's even possible at this stage, given where that
specification is in its lifecycle.
We can always say non-normative stuff in the spec and point elsewhere for
readers that want to learn more.
That seems like a policy decision rather than a matter of verifiability of
the claim itself.
Agreed.
if that is a policy-level issue where the verifier-inspector would use an
industry practice to check against the VC ID or hash or something.
Yes, best to delegate the right thing to do to market verticals (and you
can support multiple market verticals each having multiple ways of
authenticating people based on what they are trying to do). For example,
software-based digital signature may be fine for some stuff, but secure
element signature might be necessary for others, or biometric implant may
be necessary for the really scary stuff (missile launch codes, etc.).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#68 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIeYUDu3pSAPw_M0_GkPqBb334tFF9sks5shc_ZgaJpZM4OutSB>
.
--
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/
|
|
@ manu. The necessary field in the VC Data Model spec is the subject identifier id, which already exists. Agreed, but what does not exist is text in the data model spec that says how the subject id should be matched to the holder id in the presentation protocol, when subject==holder. The text could say that this matching is done either directly, when the IDs are the same, or indirectly via a DID or equivalent when the IDs are different. It is non-normative text such as this that would help in removing some of the current ambiquities in the data model document. @joe My advocacy here is that the I agree. If we can remove ambiguities from the current spec and make it clear how both of the above are supported this is the best outcome. My worry was that it would take too long to do this and therefore it would be expedient for v1 of the spec to support b, and v2 to support a. |
|
@David-Chadwick wrote:
Yes, as I mentioned to @jandrieu above, I suggest we do so in Section 5: Advanced Concepts: https://w3c.github.io/vc-data-model/#advanced-concepts . We should add a section on "Authentication" and say that one MAY authenticate the subject by receiving a Verifiable Profile with a proof on it and then matching the proof to the subject identifier by processing the So, now that raises the question... do we focus on just putting issue markers in the spec, or do we just write the section that explains how to do this. :) I think we could most likely do the latter at this point. |
|
Hey @agropper, I'm going to go line by line and point out what the data model supports and doesn't support today from your use case: @agropper wrote:
The proper terminology is Verifiable Credential at this point (sorry, this has been a moving target, but we're getting clarity on terminology as of late).
Supported. Since we don't need to verify the subject in this case, the Verifiable Credential can be provided in a variety of ways (email, FTP, USB thumb drive, back-end system integration, etc.)
Supported, and +1 wrt. the approach.
Supported.
Supported. The DID being standardized goes hand-in-hand with the DDO being standardized. Both need to be standardized, which the DID spec aims to do.
Supported by the data model. We do need to create a JSON-LD Context for healthcare things of this sort (NPI number, DEA number, etc.)... but that's easy and can be done in a day.
Supported, no need for registrars to support DIDs or VCs to make progress.
Supported, but also note that the subject identifier doesn't need to be a DID. It can be a proprietary identifier shared between the doctor and pharmacy. I know we don't want to do this, as it defeats the self-sovereign nature of the solution, but the data model supports proprietary identifiers (by design).
Supported and +1.
I'd like us to document how it gets more complicated because there may be simple solutions given the more distributed and automated nature of DIDs/DDOs. |
|
Once you introduce insurance, complexity explodes, but since you asked,
here are some of the permutations:
- Before the VC (prescription or order) is finalized, a draft might be
submitted to a payer for a formulary check
- The return would provide the patient with information like out-of-pocket
cost based on their actual deductible
- Of course, the actual out of pocket cost also depends on the choice of
pharmacy (verifier)
- Now the drug co. steps in and offers a rebate coupon in order to mess
with the payer (through an intermediary much of the time)
- The next step might be pre-authorization by the payer of the final order
- Then, the patient still has a choice of pharmacies
- The pharmacy might be out of stock so the patient has to take the VC to
another pharmacy
- At the pharmacy, the patient has a co-pay and maybe decides to use their
savings account instead of cash which involves a bank and taxes
- The payer, often has a rebate program for the pharmacy as well
- And sometimes there's a payer (a pharmacy benefits manager) that's
separate from the insurance company (the contracts between the insurance
co, the PBM, and the pharmacy are secret, of course, because this is the
land of the Free).
- Speaking of cash, the patient has a right to keep the payer from knowing
the contents of the VC if they choose to pay cash in full
- But, the pharmacy is usually not setup to honor requests for anonymity
relative to their internal systems and external data brokers
- So, the patient might ask the prescriber to order the prescription so
that the pharmacy doesn't know the patient's name
- Also, the drug company might give the prescriber a rebate depending on
the outcome of the treatment (does the patient get a rebate too?)
- And some states run All Payer Claims Databases in a futile attempt to
drive policy based on actual data
I probably missed a few permutations because this is not my area of
expertise. There are a couple of intermediaries and clearing houses in the
middle of the above that I did not describe.
And along the way most of the participants sell the data in the VC
(including the prescriber ID) to as many people as they can because the
prescriber has no right to privacy. The patient has some right to privacy
but in reality there is no accounting for disclosures even though it's in
the law and certainly there is no enforcement so why would any of the
participants bother?
Aren't you glad you asked.
Adrian
On Tue, Sep 12, 2017 at 9:23 AM Manu Sporny ***@***.***> wrote:
Hey @agropper <https://github.com/agropper>, I'm going to go line by line
and point out what the data model supports and doesn't support today from
your use case:
@agropper <https://github.com/agropper> wrote:
- The *Verifiable Claim* is a prescription. The process is subject to
federal rules under the DEA.
The proper terminology is *Verifiable Credential* at this point (sorry,
this has been a moving target, but we're getting clarity on terminology as
of late).
- The prescription is presented by the *Holder* to the pharmacy as the
*Inspector / Verifier*
Supported. Since we don't need to verify the subject in this case, the
Verifiable Credential can be provided in a variety of ways (email, FTP, USB
thumb drive, back-end system integration, etc.)
- The presentation is either in digital or paper form to make sure
that pharmacies don't have to update their systems in order for
self-sovereign IDs to be a thing.
Supported, and +1 wrt. the approach.
- The Holder is not always the subject since it's often the case that
family members pick up the drugs.
Supported.
- The *Issuer* is a licensed physician that has a DID and a
corresponding DDO. It's important that the DID be standardized. I'm not
sure how important it is for the DDO to be standardized.
Supported. The DID being standardized goes hand-in-hand with the DDO being
standardized. Both need to be standardized, which the DID spec does.
-
- The physician has at least three kinds of public metadata associated
with her DID:
-
- A National Provider Identifier
- A state and medical license
- A DEA Number
Supported by the data model. We do need to create a JSON-LD Context for
healthcare things of this sort (NPI number, DEA number, etc.)... but that's
easy and can be done in a day.
- It's important NOT to need any of these three metadata registrars to
do anything different from what they are already doing. They have little
incentive to care about DIDs or VC and we don't want to wait for that to
change.
Supported, no need for registrars to support DIDs or VCs to make progress.
- The *Subject* is the patient. If necessary, it's up to the Issuer to
verify the patient's DID and associated claims by looking at the patient's
driver's license vs. information in the DDO. In theory, this should be
automated by having the physician's mobile scan the barcode on the back of
the license.
Supported, but also note that the subject identifier doesn't need to be a
DID. It can be a proprietary identifier shared between the doctor and
pharmacy. I know we don't want to do this, as it defeats the self-sovereign
nature of the solution, but the data model supports proprietary identifiers
(by design).
- It would be critical not to require the state DMV to change anything
about how they do things. Also, unless the drug is a controlled substance,
there may be no requirement for the physician to verify anything about the
Subject's DID.
Supported and +1.
This gets more complicated when there's insurance involved but let's not
go there for the simple use-case.
I'd like us to document how it gets more complicated because there may be
simple solutions given the more distributed and automated nature of
DIDs/DDOs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#68 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIeYbdOyAMPd8fYQsap-hsInutgj2iaks5shoSAgaJpZM4OutSB>
.
--
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/
|
|
Joe, we assigned you basically to review and see what the status is. Please let us know if someone else would be more appropriate as owner. |
|
This is addressed in the new section on token binding section 10.4 and section 5.6 in PR #173 |
As mentioned in the last call, there is confusion driven by presumed relationships between a holder and the subject. This directly relates to the "trust model" for entity profiles.
In some use cases, the inspector-verifier MUST also verify that the holder is the subject, because of downstream reliance upon the verifiable claim, typically associating the statement in the claim with the holder (who is probably logged in to a current session with an identifier specific to the inspector-verifier).
In other use cases, the verifiable claim (and the profile it is presented in) stands alone, like a passport or drivers license which can be verified as valid independent of the presenter.
The challenge is that, as in most driver's license and passport scenarios, there is an additional assertion made, often implicitly, in the presentation of the credential. When asked for ID by a police officer or immigration official, presenting a particular driver's license or passport is the equivalent of asserting that the subject in the credential is the holder presenting it. However, for some use cases, such as those credentials presented by an assistant to a travel agent, it is understood the presenter is not the subject. In those cases, alignment of field data like "name" with the name of the travel itinerary is sufficient.
For some, this additional assertion that the subject==holder is taken as axiomatic. If the subject is not the holder, then some form of delegation "must" be proven.
For others, the additional assertion is exogenous to the profile and any given verifiable claim can be verified in the sense that the statement by the issuer can be assured cryptographically and its non-revocation can be assured procedurally.
In other words, what inspector-verifiers must do before they can trust a profile is caught in different assumptions about whether or not the holder MUST prove some kind of relationship with the subject.
The current docs are ambiguous on this, including the latest update. For example, there is, in Figure 1 The roles and information flows that form the basis for this specification, there is an Identifier Registry which is apparently used by holders to register identifiers and for issuers and inspector-verifiers to verify ownership.
How this ownership is verified is unspecified. There are no hooks in the data model and no discussion in privacy or elsewhere. Additionally, none of the stated requirements include verifying the holder is the subject. The assumption that there is verification of ownership is snuck in without explaining that this optional for use cases where the holder is additionally asserting they are the subject and fundamentally not required for other use cases.
This hidden assertion is, IMO, the crux of clarifying what is and is not in the VC specification.
Similarly, the assumption that there exists an identity registry is, imo, complicating the conversation.
Yes, registries can be extremely useful. Whether it is a block-chain based self-sovereign identifier like a DID or a record in the DNS, registries provide great ways to look up meta-data that may help assure the identity of a given issuer or holder.
But they are not required. Even if proof of ownership is needed by an inspector-verifier, this can be done with a challenge-response using key pairs shared through out-of-transaction means, similar to the original web-of-trust models. I understand there is strong support that VCs should also work in those classic use cases where there are no registries.
Consider an analogy. IP packets can be transmitted using UDP or TCP, just like Verifiable Claims can be used with or without proof of ownership or identifier registries.
Just like the additional overhead of TCP is worth it for some use cases and not for others, the same is true for the overhead of proving identity ownership through registries. And just like the IP datagram enables both UDP and TCP without precluding the other, so too should the VC data model enable use cases that don't depend on proving ownership through registries.
To the point of our current docs, the language should be clear that the underlying data model for VCs neither depends on nor precludes proving ownership and registries.
Unless, of course, it does. Then we should make that clear.
The text was updated successfully, but these errors were encountered: