Re: VC HTTP API specification structure

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 <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 melike 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 <mailto: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 <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 <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/ <https://www.linkedin.com/in/manusporny/>
>     Founder/CEO - Digital Bazaar, Inc.
>     blog: Veres One Decentralized Identifier Blockchain Launches
>     https://tinyurl.com/veres-one-launches <https://tinyurl.com/veres-one-launches>
>
>