Re: VC HTTP API specification structure

Not to take away from genuine concerns here, but what does any of this have
to do with
1) using separate open api specification files for each concern in the
vc-http-api?
2) using a single respec file to document an actual specification for the
vc-http-api?

The two proposals that are blocked have to do with picking a path forward
so that we can actually make some progress and test things out, and do not
have to be the final end all state.  All that is being asked, is can the
group agree to a format to move forward with in order to begin
specifications work beyond just a single open api spec?

This is not to detract from the valid concerns raised, just pointing out
that if we can agree on format, then we actually have something we can
issue pull requests against to discuss these issues with practical
implementations and specs.

Michael Prorock
CTO, Founder
mesur.io

On Mon, May 3, 2021, 18:11 Alan Karp <alanhkarp@gmail.com> wrote:

> Adrian has been doing such a good job expressing his concerns, that I have
> been able to lurk.  Time for me to pipe up.
>
> I think Steven's note explains Adrian's (and my) concern.  It gives the
> example of Bob earning a Ph.D., getting a VC to that effect, and using that
> VC to join an exclusive group.  That's all well and good, but consider a
> different example.  Bob gets sick and wants to delegate to his neighbor
> permission to act on his behalf for a small set of medical decisions, among
> them picking up his prescriptions.  At some point that neighbor needs to
> leave town and wishes to delegate just the pharmacy permission to her son.
>
> I believe that Adrian's concern is that those delegations will need to be
> done through a provider not of Bob's choosing, perhaps his health insurance
> company or the hospital Bob's doctor specifies.  The result would be a
> serious lack of control, e.g., the provider might deny the delegation, and
> privacy, e.g., the provider would know the relationship between Bob and his
> neighbor.  We see such examples today, such as when you must have an
> account to work on a Google doc.  I would like people to have in mind such
> attenuated delegation examples while keeping in mind more general patterns
> as well.
>
> There are a few similarities and a lot of differences between a claims VC,
> such as Bob's Ph.D., and an authorization VC, as in the pharmacy example.
> For example, revocation is done completely differently.  If you aren't
> careful, such things can be jumbled up, leading to a complicated standard
> that serves neither community well.  Adrian and I would like to help keep
> that from happening.
>
> --------------
> Alan Karp
>
>
> On Mon, May 3, 2021 at 1:40 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
>>>
>>>
>>>