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

Yes, Steve. Your framing is pretty much the difference between UMA1 and
UMA2. UMA2 was nicknamed as the Wide Ecosystem upgrade to UMA1. Justin and
I worked on UMA2 as well as subsequent profiles of UMA2 such as OpenID
HEART in healthcare. That was about 5 years ago. Adoption of UMA 1 or 2 is
miniscule. The healthcare vertical ignored HEART and came up with
https://www.udap.org on top of OAuth. It's just another delaying tactic to
keep the incumbents in control a few more years.

I understand the desire in our SSI workgroups to push the cross-domain
trust / client credentials issue elsewhere. It's probably related to the
discussions of whether to distance our work from the term "self-sovereign"
lest we upset the real sovereigns. The sense I get, so far, is that VC-HTTP
API would rather I take this struggle elsewhere or at least put it into a
later version so that we can all make "progress" serving the sovereign
customers waiting for a standard.

My objection is based on principle and implementation experience. I'm happy
to share what I can about OAuth in the context of SSI. I'm not being paid
for this and if the group wants me to take this issue elsewhere, then you
can vote me off the island at any time.

Or, VC-HTTP API can scope to A2 and we all move ahead together to figure
out the real issues around authorization in the context of digital
credentials.

Adrian

On Wed, Jul 7, 2021 at 10:57 PM Steve Capell <steve.capell@gmail.com> wrote:

> 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
>>
>>