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

Adrian --

I knew I should have included more of my own thoughts 
in my previous...


On Jul 7, 2021, at 07:24 PM, Adrian Gropper <agropper@healthurl.com> wrote:
> 
> I will respond to Dave's question below as we wait
> for others to chime in on the numbered issues. 


Your earlier message did not contain numbered *issues*.

It contained numbered *paragraphs*, many of which were 
single sentences, and many of which did not read to me, 
and, I imagine, to others, as issues.

This message to which I am currently responding did at
least *try* to present a sequence of actions, as Dave
requested, but the numbered "steps" in the sequence did 
not appear to me to be uniform in scale, with some being 
comprised of what I think you would agree are multiple 
distinct actions by multiple entities, and others being 
appropriately atomic -- i.e., one action by one entity.


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


I'm pretty sure you meant the lowercase vc/vp there to 
be reversed, so that they corresponded to the initials 
of the instruments of which you wrote, and so vc went 
with VC and vp with VP.

But only *pretty* sure, so I'm going to ask that you 
confirm my interpretation.

I'm also going to ask that, going forward, you take 
some extra time to re-proofread everything you send 
out. (fwiw, I do this myself.) Every typo-driven 
misunderstanding steals time and energy from the work 
we are trying to do, including working to understand 
each other's points.


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

To the best of my understanding, no-one is advocating
for the VC-HTTP-API to be designed such that it can 
only be implemented with OAuth2, which is what I take 
you to mean by "tied to OAuth2", nor do I see anyone 
arguing that future implementations should be blocked 
from using GNAP, *once GNAP is in such a shape as allows 
for such implementations,* which GNAP is not today.

Initial implementations of the VC-HTTP-API are likely
to be made with OAuth2 *because it is standardized
sufficiently* to allow for such implementations. 

The goal, as I see it, is to specify the VC-HTTP-API 
such that GNAP *and other standards not yet even 
begun* could substitute for OAuth2 and, if we're all
good little girls and boys, that all of these would 
be interoperable in the end!

If OAuth2 is half as awful as you've been suggesting,
the marketplace will quickly move from it to GNAP or 
some other, even less awful, alternative, and there
will be much rejoicing, throughout the land.


Ted