Re: VC HTTP API specification structure

On 5/4/21 7:35 PM, Adrian Gropper wrote:
> I don't understand why "document and iterate on the current 
> client-server" is in there.

"document" is there because this has been an active CCG work item for
15+ months, but largely existed in Open API Specification (OAS) form
(not necessarily easily human readable form). Here is what has been
there for over a year now:

https://w3c-ccg.github.io/vc-http-api/

We are saying "document" because we are trying to write better human
readable documentation around the OAS document published above.

"iterate" because we don't expect that we are anywhere near done. We
will need to iterate given that there are use cases people in this
community want to address, like authorization, that the current APIs
don't address.

"current" because something exists right now (and has for more than a
year), and there was a CCG request to document more of what we currently
have in order to make it more accessible to the community. We might as
well start by documenting what we know to work from an interoperability
perspective.

"client-server" is in there because that's the way IETF and W3C
specifications talk about protocols; especially HTTP-based protocols...
these terms are clearly defined in the HTTP specification:

https://tools.ietf.org/html/rfc7230#section-2.1

> Keep in mind, that I am fundamentally skeptical of how we got to the
> "current client-server" situation because the SVIP goals are so
> extreme in asymmetry.

We got to the whole "client-server" situation because that's how HTTP
works. It is a protocol between clients and servers, as defined in the
HTTP specification:

https://tools.ietf.org/html/rfc7230#section-2.1

It has nothing to do with SVIP goals, power dynamics, sovereignty, or
anything else at the political layer.

> Does HTTP require us to adopt a client-server model?

Yes, it does... and I expect your definition of "client" and "server"
deviates from the definition in the HTTP specification. It is the
definition in the HTTP specification that I'm using... to paraphrase:

System A (client) sends a message to System B (server).

That's it.

System A (client) could be my phone and System B (server) could be your
phone. Note that in this case, we're talking about a peer-to-peer
network, where we're operating as equals, and both of us have
sovereignty (to the degree that we find acceptable) over our software
and devices.

> Even the wording is problematic. We can probably agree that the
> Subject is not sovereign relative to the Issuer.

Why not? I can self-issue VCs using the VC HTTP API. In that scenario, I
am sovereign in relation to the issuer. This may be the concept that
hasn't landed with you yet -- this is just an API, you can have full
sovereign control over it if you run the software yourself (and I expect
many will).

> But is the Subject to be the client or the server in the spec?

The subject could be in control of both the client and the server, or
just the client, or just the server, or neither. All variations are
possible with the VC HTTP API, just as all roles are available to all
parties in the Verifiable Credential Ecosystem.

> I kept GNAP out of my recent proposal in order to reach for consensus
> while still allowing GNAP language and maybe some aspects of the
> protocol to be introduced without delay. In GNAP the Subject controls
> an Authorization Server. What does that make the Issuer? It's hard to
> say. The Issuer could be a Resource Server in the sense that any 
> processor that has personal data about the Subject in the clear is a
>  Resource Server. A Client might also have access to the VC data but,
> in some cases the data could be encrypted when it hits a client in
> the protocol.

Every one of the sentences above has some sort of invalid assumption in
it, so it's good that you kept GNAP out of your most recent proposal...
because all of that is going to take A LOT of work to unpack and will
slow the discussion down.

What we can be fairly certain of is that the specification will have a
section on Authorization and I expect we'll speak to OAuth2 and GNAP in
some capacity in that section.

> The point I'm trying to make as we work on use-cases and other things
> in parallel, is that the Authorization Server is a separation of
> concerns between controller (AS) and processor (RS). The AS does not
> need and may not ever have access to the contents of the VC,
> particularly if the VC is encrypted and the AS operator does not have
> the key. (The choice of whether the Subject has the key to their own
> VC is up to the Issuer, of course).

I can't easily make sense of the statements above... there seems to be a
decent amount of conflation between VCs, GNAP, and the VC HTTP API. I'm
sure we'll get to discussing it in time, when we pick up the
Authorization discussion.

... rolling back around to your proposal, with a few revisions. Do you
understand why "document and iterate on the current client-server" is in
there now?

PROPOSAL: Create a VC HTTP API specification in ReSpec format so that we
can document and iterate on the current client-server HTTP protocol for
the purposes of issuing a Verifiable Credential.

More specifically, would you object to the proposal above?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Received on Wednesday, 5 May 2021 03:40:46 UTC