Re: VC HTTP API specification structure

Manu and Steven,

Manu first:

Thank you for your prompt consideration. This thread is primarily to
support my suggestion that we work on three separate documents. It's a
question you raised and I feel it's an important question. The role of
authorization in the group's work is potentially separable from the
structure question. As I tried to say in our initial call, it will be
easier to do a privacy analysis if we deal with Issuer, Verifier, and
Holder APIs separately, with or without authorization.

Steven,

Thank you for your important questions:

> 1. What does a GNAP resource server do that other things don't? Why should
> people care and want one? (please address both developers and users in the
> general public, if the reasons are different).


It may be helpful to glance at the May 1 slides:
https://lists.w3.org/Archives/Public/public-credentials/2021May/att-0002/Verifiable_Credentials_HTTP_API.pdf
then,
with as few acronyms as possible:

   - Issuers and and Verifiers have vastly more power than the Subject of a
   verifiable credential.
   -

   Point-to-point messaging between Issuer and Subject can place excess
   cost and burden on the subject. (e.g spam and CAPCHAs).


   -

   A Subject can mitigate the asymmetry of power by requiring the Issuer or
   Verifier to interact with an agent of their choice. Unions, doctors, and
   defense lawyers are examples of delegates as agents chosen by the subject
   when power or knowledge are asymmetrical.
   - In a digital context, the agent can be a semi-autonomous bot.
   - Lacking the appropriate standards Issuers and Verifiers can prevent
   the Subject from choosing a cost-effective self-sovereign or fiduciary
   agent.
   - GNAP Is a protocol for specifying the Subject's choice of agent to an
   Issuer or Verifier.
   - For ease-of-use and cost effectiveness, the agent should apply to
   multiple domains including education, health, commerce, and finance.
   - Verifiable credential Issuers and Verifiers tend to be domain
   specific. Therefore, the delegation protocol benefits from a separation of
   concerns between authorization and the context of the verifiable credential.

2. Supposing that a GNAP is required, how does this relate to Manu's
> question of what this "has to do with the physical structure of the
> document that the Editors will need to work with"


Separation of concerns benefits the self-sovereign Subject by minimizing
the risk of vendor lock-in. As mentioned above, the group can choose to put
delegation and authorization to later conversations but that still doesn't
mean we should be combining Issuer, Verifier, and Holder into the same
document. The GNAP document structure has dealt with some of this issue by
separating out the request-related concerns at the authorization server
from the context-dependent aspects that dominate the VC itself. In other
words, the VC is of interest to Issuers, Verifiers, and clients in what
GNAP calls Resource Servers and they have a document of their own, separate
from the authorization server. That is the separation of concerns I propose
to our group from the start.

- Adrian




On Sun, May 2, 2021 at 2:42 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 5/2/21 11:25 AM, Adrian Gropper wrote:
> > inline...
>
> Wonderful! Even better, concrete proposals will help the group focus on
> making
> concrete decisions (rather than getting wrapped around the axle on meta
> discussions):
>
> I have written down your proposals here, and they will be raised in the
> group
> in time:
>
> https://github.com/w3c-ccg/vc-http-api/wiki/Task-Force-Proposals
>
> Now that we've gotten to something concrete that we can discuss, I'm going
> to
> attempt to point out that what the group is attempting to do, and the
> discussion you'd like to have, are two almost entirely different things
> (and
> they have an implied order, and we can do both, in time).
>
> Steven also raises some very good questions that, if answered, would help
> you
> make your case to the group. I'd certainly benefit from those answers.
>
> In the absence of those answers, I went and read the links you sent to the
> mailing list (and found them a bit lacking in detail), so I went and read
> the
> most recent specification (which seems to have changed quite a bit since
> the
> last time I read it). I spent around 2 hours skimming the 131 page
> document.
> There's a lot there to absorb, but I do get the problem space and the gist
> of
> what GNAP is promising. As you know, it's still early days in that
> particular
> IETF WG.
>
> So, bringing that to the discussion at hand... I'm responding to all of
> these
> to demonstrate that all were considered and so you have a complete picture
> of
> at least one person's mental model of what you are proposing.
>
> > With respect to the *VC **Issuer* *HTTP API*specification:
> >
> > PROPOSAL A: The VC Issuer is a GNAP Resource Server (RS) as defined in
> [1]
> > <
> https://www.ietf.org/archive/id/draft-ietf-gnap-resource-servers-00.html>.
>
> This
> >
> might be the case, but it's a bit too early to tell and I expect the
> group to be hesitant to accept this proposal because of the instability of
> both the GNAP specification and the VC HTTP API specification.
>
> This also presumes that we have a specification to write this into, which
> we
> don't, and that's what we're trying to establish with the proposal you
> have -1'd.
>
> > PROPOSAL B: The VC Issuer SHOULD allow the VC Subject to use a GNAP
> > Authorization Server (AS) as defined in [2] as their agent.
>
> Normative language assumes the existence of a specification. We don't have
> one
> yet. We would need to pass a proposal establishing a specification and it's
> structure first.
>
> > PROPOSAL C: The VC Issuer MUST allow the VC Subject or their agent to
> > designate a GNAP RS as the VC Holder.
>
> Normative language assumes the existence of a specification. We don't have
> one
> yet. We would need to pass a proposal establishing a specification and it's
> structure first.
>
> > PROPOSAL D: The VC Issuer MAY restrict the VC Subject's choice of Holder
> > RS based on certification requirements including federation.
>
> Normative language assumes the existence of a specification. We don't have
> one
> yet. We would need to pass a proposal establishing a specification and it's
> structure first.
>
> > PROPOSAL E: The interaction between Subject AS and VC Holder is out of
> > scope for the VC Issuer HTTP API specification.
>
> We should discuss this in time, but given that we don't even have
> established
> use cases yet, stating that things are either in scope or out of scope is
> difficult to do.
>
> This would also require the group to learn GNAP, and given size and
> complexity
> of the current specification, the group may not want to put this in front
> of
> other things that could be accomplished without doing a deep dive on GNAP.
>
> > With respect to the *VC **Verifier* *HTTP API* specification:
> >
> > PROPOSAL F: The VC Verifier is a GNAP client as defined in [1] and [2]
>
> This might be the case, but it's a bit too early to tell and I expect the
> group to be hesitant to accept this proposal because of the instability of
> both the GNAP specification and the VC HTTP API specification.
>
> This also presumes that we have a specification to write this into, which
> we
> don't, and that's what we're trying to establish with the proposal you
> have -1'd.
>
> > PROPOSAL G: The VC Verifier MAY restrict the VC Subject's choice of
> Holder
> > RS based on certification requirements including federation.
>
> Normative language assumes the existence of a specification. We don't have
> one
> yet. We would need to pass a proposal establishing a specification and it's
> structure first.
>
> > PROPOSAL H: The interaction between Subject AS and VC Holder is out of
> > scope for the VC Verifier HTTP API specification.
>
> We should discuss this in time, but given that we don't even have
> established
> use cases yet, stating that things are either in scope or out of scope is
> difficult to do.
>
> This would also require the group to learn GNAP, and given size and
> complexity
> of the current specification, the group may not want to put this in front
> of
> other things that could be accomplished without doing a deep dive on GNAP.
>
> > With respect to *VC Holders*:
> >
> > PROPOSAL I: A VC Holder that does not support HTTP is out of scope for
> the
> > VC Issuer HTTP API or VC Verifier HTTP API specifications.
>
> This is a logical tautology; we don't need to run the proposal.
>
> If a client can't speak HTTP, it can't speak to the VC HTTP API.
>
> > PROPOSAL J: A separate informational document can be created that
> > describes the use of GNAP for non-HTTP transports and may be referenced
> in
> > the VC Issuer and VC Verifier specifications.
>
> Someone can always write a separate informational document that describes
> the
> use of GNAP for non-HTTP transports. We may or may not refer to that in
> the VC
> HTTP API specification(s)... but again, that requires us to actually have a
> specification.
>
> At this point, it's fairly clear to me that you'd like to have a discussion
> around Authorization (which is good, we should have that discussion). The
> group is currently trying to decide the structure of the specification so
> they
> have a place to start writing down all of these resolutions. We can't do
> the
> former without doing the latter first.
>
> We will almost certainly get to defining Authorization early on (it's
> missing
> in the current API and is a highly sought after feature). It's at that
> point
> that the discussion you'd like to have would resonate with the group.
>
> Adrian, given all of the above, would you be willing to step aside for the
> time being so the group can create the specification? Do you see that these
> are two different conversations?
>
> -- 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
>
>
>