PROPOSAL: Spec will recommend AGAINST Issuer <> Verifier flows over https

[OR13]

• https://w3c.github.io/vc-data-model/#identifier-based-correlation
• https://w3c.github.io/vc-data-model/#usage-patterns
• https://w3c.github.io/vc-data-model/#subject-holder-relationships
• https://w3c.github.io/vc-data-model/#issuer-authorizes-holder

I am unable to find a single case where an issuer connects directly to a verifier, or where a verifier asks for a credential directly from an issuer without the holder consent... in particular:

https://w3c.github.io/vc-data-model/#lifecycle-details

^ this image implies that when the verifier connects to the issuer, it destroys privacy.

https://w3c.github.io/vc-data-model/#ecosystem-overview

I cannot find evidence to support a direct connection between a Verifier and an Issuer outside of a credential status check in the entire W3C VC Data Model Spec.

@msporny Can you point us to the strongest argument in favor of adrian's proposal?

[msporny]

@msporny Can you point us to the strongest argument in favor of adrian's proposal?

For the record, I think direct issuer -> verifier without subject consent or authorization delegation is a dangerous flow to even consider supporting and doesn't actually exist in even @agropper's use case (even though he seemed to be insisting that it did during the call yesterday).

It might be fine for IoT use cases where you're just trying to discover a bunch of things that have just come off of the assembly line and have no rights... but even then, I expect the manufacturers of the IoT devices would have something to say about delegation and authorization there.

The use case, if I understand it correctly, is a patient authorizing a primary care provider to access one of their medical records (an immunization record, for example). It is possible for a "verifier" to reach out directly to an "issuer" and request the VC... I'm putting those in air quotes because it's really an application that does that... there is application logic beyond the issuer and verifier that's involved here.

There is an assumption in the use case that the patient has already consented, or there is some regulation in place that suggests that the patient doesn't have to consent (they are unconscious and timely retrieval of the record could be a matter of life and death). So, fundamentally, there is authorization to access the record (either by regulation or via the patient), it just devolves into the same app<->holder<->app flow where the the holder has authorized one of the apps to retrieve the data from the other app.

In any case, I'm not keen to speak for others that want use cases that seem to violate some fundamental principles associated with Verifiable Credentials in the name of "self-sovereign" (when in reality, it enables the very opposite dystopian future that all of us are attempting to avoid).

I'd rather @agropper clearly provide a direct issuer -> verifier use case.

[agropper]

There are three use-cases:

• The prescription use-case needs ways to revoke if the prescription is changed or dispensed. The easiest way to do this is to have the verifier take the prescription directly from the issuer once the patient has chosen a pharmacy and provided a link to the protected resource. This would be a huge improvement over the current "digital" practice, that I suspect you have all experienced, where the issuer asks you to tell them which verifier they should send the prescription to. This limits the person's ability to shop for what are too often very expensive things.
• The second use-case is a letter of recommendation that must accompany an educational credential but not be accessible to the subject themselves.
• The third use-case is IoT sensor streams such as from a continuous glucose monitor on a 12 year-old child with diabetes.

All three examples have a primary authorization component and the second and third also need delegation.

I'm genuinely surprised by the push-back form members of our community. These use-cases are not esoteric and they all benefit from standardized VCs. A lag in revocation standards and insistence that control and possession concerns are always combined will be a drag on adoption.

[agropper]

A sequence diagram might be helpful:

[kayaelle]

I've been told there are other system-to-system use cases for education data but unable to find them at this time. That said, from what I recall, those use cases required authorization from the students prior to transmitting the data and it's unclear to me why that data was needed in a verifiable credential format.

I'm wondering the same about Adrian's use cases. Do any of these examples require the verifiable credential format? If there is no holder, then why is a VC needed at all? Isn't then just simply a transfer of data that should be authorized by the individual? In each of the use cases, human intervention is necessary. In use case 1, the patient chooses the pharmacy. In use case 2, the student informs who the recipient of the recommendation is. In #3, the IoT sensor streams should be authorized by the user of the glucose monitor.

[msporny]

In each of the use cases, human intervention is necessary. In use case 1, the patient chooses the pharmacy. In use case 2, the student informs who the recipient of the recommendation is. In #3, the IoT sensor streams should be authorized by the user of the glucose monitor.

Yes, this is exactly the point I was trying to make on the call -- every use case requires authorization by the subject (either explicit -- a delegation, or implicit -- a regulation)... and thus, there are no direct issuer to verifier use cases where the verifier doesn't provide the authorization (delegation or direct authorization). On the call, it seemed as if @agropper was arguing for no authorization/delegation -- that's why people were surprised, @agropper... but it seems like your diagram above (which is slightly confusing, but MUCH more helpful than prose) shows authorization all throughout the process.

This is why I keep asserting that we're all talking about the same thing (more or less) and it's really the initiator of the Verifiable Presentation Request that's in question... in any case, need to dig into @agropper's diagram a bit more to understand it.

[agropper]

@kayaelle - A Separation of Concerns (SoC) perspective recognizes that semantics and authenticity depend on separable tooling. The tools for managing semantics (JSON-LD) will be of great value to the Verifier regardless the tools of authenticity (which include revocations as well as proofs). This aspect of SoC is just a productivity and adoption pitch.

The human rights perspective is also important. The tools we promote are never neutral. They can favor the Issuer or the Subject. The protocol standards we're discussing are nothing less than a definition of the tools. Standards imply constraints. Let's try to apply more constraints on the Issuer and give the Subject meaningful options. I think the Robustness Principle applies. Specifically, the Issuer should be liberal in the kinds of requests it accepts and strict in responding in a (VC) standardized format. That puts more of the cost on the Issuer and makes delegated and semi-autonomous processing cheaper for the Subjects. That is essential to ethical treatment of Subjects.

[msporny]

We discussed this on the 2022-04-12 telecon. @jandrieu said this was a good thing to put in the spec (warn against direct issuer->verifier communication). The use cases, other than status check, do not show that direct issuer-verifier communication is necessary for the proper operation of the system. This should be placed in the privacy considerations section, should talk about this warning applying to exchanges as well (don't phone home), and that the group considered this and, in general, feels like it's a bad idea.

[mavarley]

Some Credentials may have a realtime component - for example, how many Reward Points does the subject have 'right now'? However, I believe what this statement/issue is trying to cover is that for such scenarios where a Verifier needs to contact the Issuer for some business process reason - those API calls and interactions are outside the scope of SSI and this VC API spec.

That is, for real-time API access, Issuers and Verifiers are going to fall back into existing API relationships and/or federated use cases... and that is all well and good, just outside the scope of the realm of VCs and VC API.

Exchanging Time-Sensitive Credentials in an SSI model requires that the time-sensitive credentials must still be exchanged through the Holder (for example, a subject must go to the Issuer, collect a time-sensitive Credential, and deliver it in near-real-time to the Verifier, who will be required to evaluate the issued at time and the expiry time).

@jandrieu @OR13 @msporny @dlongley @tplooker and others: does the above seem an accurate description of what the issue is trying to capture?

[jandrieu]

I think the "realtime" component is likely a mismatch with the conceptual model of VCs.

What we can put into a VC is a statement that "at point in time XYZ, subject A had 27,000 reward points".

What we don't have is any sort of double-spend protection on the reliance on that information. It would be easy to take that rewards VC and give it to two different parties, both of whom might believe they can debit 25,000 reward points in exchange for some perk. VCs don't solve for that.

The approach you propose, with reliance on near real-time delivery of "just-in-time" credentials is a reasonable approach for many use cases, and unless double spend is a real issue, it is likely a fine approach. However, if I were the verifier in that case, I would treat the VC as evidence that a debit against the rewards system is likely to succeed... but I definitely would NOT treat the VC as proof that such a debit would succeed (because someone else might beat me to the debit).

The one additional caveat you could add to the business logic is to have a statusCheck property that allows verifiers to check to see if that rewards VC is still considered timely. In that case, the verifier (assuming RevocationList2019 semantics) downloads the revocation list in realtime and could check to see if that VC has already been "spent" or not. But that's just an extra check to confirm that at a particular point in time, so many reward points exist in A's account. It can never reduce the race condition of two parties both trying to use those rewards at the same time. That's the essence of the double spend problem. (Which can be solved either with a DLT or a centralized server/service.)

In short, I do think the best you can do with VCs is the "just-in-time" issue & present pattern, but the core use case will not be fully addressed entirely by VCs in that fashion because the core use case still needs to address double-spend and VCs, unfortunately, were not designed to do that.

[msporny]

does the above seem an accurate description of what the issue is trying to capture?

While what you say has some truth to it, it is kinda-sorta out of scope, any communication from the Verifier back to the Issuer creates a correlation and privacy risk that this issue raised. That is, you're explaining a use case that we're afraid of. Phoning home to the issuer will probably violate someone's privacy (they might not know about the pre-existing relationship and that when they deliver something that it'll kick off some kind of phone-home process).

IOW, SSI is about putting the Holder in control of the release of information and the level of correlation. What you're describing, while technically out of scope to the VC API, takes that power away from the Holder. Now, will Verifiers and Issuers do that anyway -- of course -- but the spec should warn against doing that and that it's a privacy violation/risk if the Holder isn't aware that that's happening.

The text that the group agreed to, I believe, was a privacy warning that when a Verifier contacts an Issuer with information that is specific to the Holder, then they are enabling correlation and tracking at the Issuer.

[mavarley]

Thanks @jandrieu

What we can put into a VC is a statement that "at point in time XYZ, subject A had 27,000 reward points".

What we don't have is any sort of double-spend protection on the reliance on that information. It would be easy to take that rewards VC and give it to two different parties, both of whom might believe they can debit 25,000 reward points in exchange for some perk. VCs don't solve for that.

I think that is what I was trying to get at, although in a clumsy way. Credentials can capture "This is a valid Rewards Card no., and it is being presented from the same subject DID (key) that it was issued to" (and maybe "it was a Gold card at the beginning of the month...")but any real-time activity with that information goes over different "rails". Payment rails, API rails, etc... these are not Credential "rails".

@msporny :

The text that the group agreed to, I believe, was a privacy warning that when a Verifier contacts an Issuer with information that is specific to the Holder, then they are enabling correlation and tracking at the Issuer.

Ok - I agree with this text as a general "beware" without trying to point readers to another solution.
👍

[msporny]

The group has started PR #349 to address this issue. This issue will be closed once that PR is merged.

[msporny]

PR #349 has been raised to address this issue. This issue will be closed once PR #349 has been merged.

[David-Chadwick]

• The prescription use-case needs ways to revoke if the prescription is changed or dispensed. The easiest way to do this is to have the verifier take the prescription directly from the issuer once the patient has chosen a pharmacy and provided a link to the protected resource. This would be a huge improvement over the current "digital" practice, that I suspect you have all experienced, where the issuer asks you to tell them which verifier they should send the prescription to. This limits the person's ability to shop for what are too often very expensive things.

I agree that the current practice limits the patient's choices.
But there is an alternative that we implemented in a research project 20 years ago and published an academic paper describing it. Namely the prescription is written encrypted to a central repository and the patient is given a paper meta-prescription containing the decryption key. The patient then takes the decryption key to any pharmacy which allows it to download the encrypted prescription and decrypt it. The pharmacy then deletes the prescription from the central repository after dispensation. In this way the doctor and pharmacy never need to communicate

[TallTed]

The current title of this issue — PROPOSAL: Spec will recommend AGAINST Issuer <> Verifier flows over https — suggests that the protocol used for the flow (HTTPS) is the concern, rather than the direct communication between the Issuer and Verifier. I strongly advise a change to that title to make it reflect what's actually being discussed here, which I think is PROPOSAL: Spec will recommend AGAINST direct communications between Issuer and Verifier

Also,

[@agropper] the issuer asks you to tell them which verifier they should send the prescription to. This limits the person's ability to shop for what are too often very expensive things.

In the current system, the consumer (patient, holder) is always able to ask the prescriber (issuer) for a paper prescription, which can be fulfilled by the verifier (pharmacy) of the patient's choice. Also, the patient can contact the pharmacy of their choice and request that they take over an electronic prescription from the original verifier/pharmacy. In other words, the person is always able to shop.

[@David-Chadwick] the patient is given a paper meta-prescription containing the decryption key

The only way this MIGHT be viable is if the decryption key (with link to the digital prescription) is delivered via a scannable code (e.g., QR-code, barcode, etc.). Manually entered keys and URIs are far too prone to user error.

[David-Chadwick]

Remember this was 20 years ago, so I believe it was a barcode.

[agropper]

If we're using a prescription as an example... Generally speaking, the Issuer and Verifier are service providers to the Subject. As such, the service providers SHOULD offer the subject a capability that can be delegated and attenuated. Period. As we learned in the TruAge example presented a month ago, regulated activities like , prescriptions, cannabis dispensaries, and money laundering require "calling home" to either the Issuer or a regulated mediator. My point is that VCs are useful across a broad range of privacy domains ranging from completely public medical licenses to prescriptions for mental health treatment. Only a capabilities-style foundation can serve both "self-sovereign" privacy and business / regulatory constraints. Adrian

…

On Mon, Jan 8, 2024 at 1:07 PM David Chadwick ***@***.***> wrote: Remember this was 20 years ago, so I believe it was a barcode. — Reply to this email directly, view it on GitHub <#186 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YK46HX2D3DSLPSD54TYNQYWBAVCNFSM443FYMDKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBYGE2TQMZUGA3A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[msporny]

PR #349 has been merged, closing.

We have also recently merged PR #359 on delegation, which urges implementers to support the sort of delegation that @agropper is suggesting.

If we need to say more, open a new issue, please.