Re: VC HTTP API specification structure

Hi Steven,

First, your initial tool vs. use of the tool perspective did not resonate
with me. The VC contents are important to both the Issuer and the Verifier
as is the trust federation they share. None of that has anything to do with
self-sovereign identity or DIDs or the opportunity for the Subject to
introduce an agent as their delegate. A VC issued to the Subjects iris scan
or passport number would be just as useful to a Verifier with an iris
scanner or a passport presentation. Neither the iris scan nor the passport
check requires a network connection to call home or central database
per-se.

The privacy benefit of using a non-correaltable (same-domain) DIDs for
separate Subject relationships with the Issuer and the Verifier is valuable
and should definitely be supported but it is orthogonal to both the
delegation issues and self-sovereign identity.

Second, I think you did a good job of restating my concern for building on
a foundation of authorization and delegation if we're to preserve our
self-sovereign vision.

Third:
A. GNAP is not the only way but the people working on GNAP are much the
same as the ones that worked on OAuth and UMA before GNAP and we've moved
on to GNAP for various good reasons.

B. and C. can best be understood in terms a typical use-cases document:

   - As an Issuer, my principal role is to *process requests* for VCs from
   a Subject or on behalf of a Subject.
   - As a Verifier, my principal role is to *make requests* for VCs as
   authorized by a Subject or on behalf of a Subject.
   - As a Subject, my roles are:
      - make requests to Issuers
      - process requests from Verifiers
      - directly or by authorizing agents to act on my behalf.
   - As an API standards workgroup, VC-HTTP is *not concerned at all* with
   persistence of any VCs.
      - the Issuers can always (re) create a VC on request.
      - the Verifiers can discard the VC after processing or, with ZKPs,
      can avoid ever processing the VC itself.
      - the self-sovereign Subject can choose a many different ways to
      process requests from Verifiers, with or without VC storage (locally or
      custodial), with or without an agent,

C: I have 20+ years of evidence from health care on how powerful interests
manipulate standards in order to limit the ability of regulators to advance
the public interest. So yes, I'm happy to share details and examples of how
an industry manages to waste $1T / year of Subjects' money (compared to
other rich economies) and also contribute to over 570,000 people dying in a
pandemic while convincing them of the industry's heroic deeds.

- Adrian

On Mon, May 3, 2021 at 4:42 PM sn0281 <sn0281@uniserve.com> wrote:

> Hi Adrian, Manu, and all,
>
> [Aside to Adrian/Manu: I'm working through ISP/mail problems and must send
> this from a different address than usual; I'm uncertain if it will appear
> on the CCG list directly; perhaps if it doesn't one of you can quote or
> repost it, so it shows up there].
>
> Responses inline.
>
> On 2021-05-02 1:19 pm, Adrian Gropper wrote:
>
> ...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.
>
> Agreed that the asymmetry of power and the possibility of large
> institutions placing "excess cost and burden on the subject" is
> important.
>
> In trying to understand this better, I found myself recasting the issue as
> follows:
>
> In general, credentials (VCs), and authorization will be
> separate-yet-interdependent in the same way as a tool and the use of that
> tool. So, a simple case:
>
> 1. Bob gets a PhD in Mathematics, which is encoded in a VC. (Creation of
> the tool by Issuer).
>
> 2. Bob presents the PhD to Blog X, where only those with PhDs in
> Mathematics are allowed to post.  (Assessment by Verifier at Blog X that
> the right tool is being presented, and is being applied in the right
> context.)
>
> For this system to function both steps 1 and 2 must understand VCs,
> probably based on DIDs (and probably the same DID methods). In other words
> there must be close development of the interoperability across both the
> creation of the VC and the authorization -- everyone must be able to read
> everyone else's protocols. The tool and its use must be harmonized. The
> hammer must be the correct size and shape for a given nail and board
> combination.
>
> Agreed so far?
>
> Now, what you're introducing, Adrian, if I get this right, is that
> large-scale Verifiers in step 2 (and possibly large-scale Issuers in step
> 1?) have so much more power that they can create vendor lock-in, and block,
> impede, and generally bully individual Subjects, and so it's necessary to
> have large-scale Agents for the subjects (like GNAP) to balance the power.
>
> And you're saying that since it's all one system, building-in large Agents
> for the Subject needs to be done at all stages, including early stages
> (like now), not after-the-fact.
>
> If so: this seems to me like an important possibility and like something
> that needs to be studied in depth now if standards are being considered
> that would exclude the Agent/GNAP possibility in future. But, see next
> question.
>
>
> 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.
>
> I found your response here confusing, in term of the overall problem of
> whether to proceed to standards that have three documents or one document.
> So I'm going to try to break it down with some further questions:
>
> A. If having a large-scale Agent to represent the Subject is important, is
> GNAP the only way to do it? Could others be considered? Have they been?
>
> B. What evidence is there that 1-document versus 3-documents will make it
> easier to incorporate any Subject Agent protective structure (GNAP or
> other)?
>
> C. (Perhaps most critical): What evidence is there that the parallel
> developments on-going (the Vaccine, DHS plug-fests) are excluding standards
> for an Agent for the Subject in future? In other words, are they
> freezing-in a closed system in which Agents for the Subject will be unable
> to participate?
>
>
>
> Steven Rowat
>
>
>
> - 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
>>
>>
>>