Re: VC HTTP API specification structure

I don't understand why "document and iterate on the current client-server"
is in there. 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.

Even the wording is problematic. We can probably agree that the Subject is
not sovereign relative to the Issuer. But is the Subject to be the client
or the server in the spec? Does HTTP require us to adopt a client-server
model?

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.

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

- Adrian





On Tue, May 4, 2021 at 6:04 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 5/4/21 3:58 PM, Adrian Gropper wrote:
> > Here's a thought on how to introduce some parallelism into our process.
> >
> > As we work on the use-cases, we start a spec document with the Issuer /
> > Subject protocol. We can later either add to this document or start a
> > second one for the Holder or Verifier.
>
> There it is! Something that has the potential to achieve consensus.
>
> Let me try to translate that into a concrete proposal, Adrian:
>
> 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.
>
> Does that work for you Adrian? Would anyone else object to this as a first
> step on specification structure (noting the context that we always have the
> option of adding or splitting later)?
>
> Remember that this is the first in a series of proposals and we don't have
> to
> do everything that everyone wants simultaneously. I expect that if we pass
> this proposal, we can spend some time alternating between the use cases and
> the specification until we either add more things to the document, or
> decide
> that other documents are necessary.
>
> > For example...
>
> I'm going to avoid discussing your example for now (as it might snatch
> defeat
> from the jaws of victory), and see if we can come to ground on the
> proposal above.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>
>
>