Re: VC-HTTP-API - A follow up on the RAR presentation

Interesting 

That New York thing looks like a truly crappy architecture for a covid pass.  

I liked your cruise ship example - literally 100’s of trust domains.  Can’t scale if holders need to join verifiers trust domains or if verifiers need to join issuers trust domains.  Very similar patterns with cross border trade.  Oauth works fine when everyone is in the same trust domain 

I’ll admit my lack of expertise in this space but it looks like this long running discussion has one side trying to define a convenient http api for users inside a trust domain (oauth is fine) and another side saying that it can’t work because a single use case like covid passports has 100’s or 1000’s of trust domains 

Instead of talking about technical protocols should we first be clear about separating within-domain vs cross-domain trust scenarios ?

Steven Capell
Mob: 0410 437854

> On 8 Jul 2021, at 11:32 am, Adrian Gropper <agropper@healthurl.com> wrote:
> 
> 
> https://www.technologyreview.com/2021/07/06/1027770/vaccine-passport-new-york-excelsior-pass/ 
> 
>> On Wed, Jul 7, 2021 at 7:24 PM Adrian Gropper <agropper@healthurl.com> wrote:
>> Thank you Manu, Dave, and Ted for your questions. I will respond to Dave's question below as we wait for others to chime in on the numbered issues. 
>> 
>> Let's look at the "Vaccine Passport" use-case. It's still hot global news and it is also an example of privacy concerns and controversies around the W3C and the broader SSI community.
>> 
>> Definition: A vaccine passport (vc) is a contextual interpretation of a vaccine credential (vp). It's a lucky coincidence that vc / vp parallels VC / VP :-)
>> 
>> 1. Alice receives a vaccine for public health reasons without any specific verification context in mind. The vc / VC is available in a vaccine registry run by the state.
>> 
>> 2. Alice wants to take a cruise with 1,000 strangers. The cruise operator wants people to be safe and feel safe. For the operator, it's the only way to stay out of bankruptcy. As a result, the operator's policy is that 100% of anyone on board is vaccinated _and_ they have had a negative Covid test within 72 hours. This is not an unusual context. Access to hospital procedures, for example, also requires a recent test regardless of vaccination status.
>> 
>> 3. Alice gets tested at some lab 48 hours before boarding the cruise. This allows 24 hours for the lab result and a 24 hr cushion on boarding delays and other schedule mishaps. The test result also ends up in Alice's health record but it is not in the state registry.
>> 
>> 4. The cruise operator (as verifier) has contracted with a Contextual Covid Passport Authority (CCPA, not to be confused with CCP as the passport authority in China) to provide a Yes or No answer when Alice wants to board.  The CCPA has some complicated method of considering the context (2), the vc in the state registry (1), and the test in Alice's health record (3). But it works well enough for all the parties involved.
>> 
>> 5. To process for the Yes / No boarding determination, access will be needed to a VC from the state registry and another VC from the hospital that holds Alice's health records.  The Yes / No boarding determination itself is a third VC issued to Alice 24 hours before boarding along with or integrated into her traditional boarding pass. This is useful because nobody wants Alice to discover a problem as she's trying to step off the gangplank.
>> 
>> 6. All three of these VCs from three separate issuers are available via VC-HTTP API. Alice hates smartphones and apps but she is willing to use technology to provide consent. For example, when she gets a text message on her feature phone saying: Is it OK for {this}? Reply Yes or No.
>> 
>> 7. With GNAP, the cruise operator (trusted by Alice) fronts a GNAP Authorization Server operated by CCPA (trusted by the cruise operator). The cruise operator is able to send consent text messages to Alice (as in step 6) as appropriate and Alice is fine with that because she has a _voluntary_ relationship with the cruise operator. Everyone is fine with that because the consent questions are being presented to Alice in context of something she more-or-less understands and expects.
>> 
>> So, behind the scenes, we have all sorts of servers and clients and user-agents and maybe a mandate to do it all according to zero-trust architecture. There may be middlemen services and trusted microservice platforms. Alice's health records could be in 5,000 different places and her vaccine credential could be in 50 state registries. Of the 1,000 people on board, some are children, others are demented, and a sizable number are not citizens of the US.
>> 
>> Notice that trust federations are of limited help in this situation. The context definition is entirely up to the cruise operator as verifier. No state or federal regulations are involved except to the extent access to the vaccination registry VC is covered by some public sector law and access to the health record is covered by HIPAA. Postulating that 70% of the 1,000 passengers on the cruise has an Apple or Android phone, with or without some app like Microsoft Authenticator is reasonable but I'm not sure it helps the situation. 
>> 
>> Finally, I'm not saying this use-case can't work with OAuth2 and client credentials and I'm not saying that GNAP alone will fix this. What I'm claiming is that the success of our SSI adventure depends on not tying VC-HTTP API to OAuth2.
>> 
>> - Adrian
>> 
>> 
>> 
>>> On Wed, Jul 7, 2021 at 4:11 PM Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote:
>>> Adrian --
>>> 
>>> This brief message is to say --
>>> 
>>> The longer messages from Manu and Dave did a remarkable
>>> job of covering what I was thinking, and wording it more
>>> clearly than what I was drafting.
>>> 
>>> It would (hopefully) bring me a lot closer to understanding, 
>>> and thus to addressing, your position if you could provide 
>>> some concrete answers and examples as they described and 
>>> requested in their messages.
>>> 
>>> Thanks,
>>> 
>>> Ted