Re: VC HTTP API specification structure

On 5/3/21 1:48 PM, Adrian Gropper wrote:
> On Mon, May 3, 2021 at 8:28 AM Manu Sporny wrote:
> 
> Do I have that right, Adrian?
> 
> *AG: Yes.*

Great, then you're not talking past me. I understand what you're saying and
acknowledge your concerns.

At this point, you've convinced me that we have documented your concerns
correctly. Now, the question becomes, how do we move forward while addressing
your concerns?

One way to do this is to raise issues on the repository, which I've done here:

https://github.com/w3c-ccg/vc-http-api/issues/181
https://github.com/w3c-ccg/vc-http-api/issues/182

That will ensure that these items are tracked on a long-term basis by the Task
Force.

Now, to ensure that I'm not talking past you, can you please articulate the
groups concerns with the structure of the specification and the specific
concrete proposal on the table regarding the specification (and how it might
address your concerns)?

> *AG: I'm sorry, but the parallel process terrifies me. I genuinely don't 
> understand where the group is headed and I have over a decade of experience
> participating in both authorization and identity standards work.

The group is attempting to create two documents so that it can write down
"where it is headed". The first document is a use cases document. The second
document is a specification, and it's first purpose is to write down what the
current set of APIs do (currently).

To put it another way -- we are attempting to write things down, but we need
both documents to do so. We have existing use cases that we're documenting. We
also have an existing API that we're trying to document in a human readable
form for the purposes of addressing the "I genuinely don't understand where
the group is headed" concern you have above.

Ok, you don't understand, can we write down what we have right now so that we
can get everyone more on the same page... and then decide where we're headed?
Won't having all of this written down help us decide on a direction rather
than not writing half of what exists down and instead talking about it?

> * * * *AG: The SVIP "plugfest" approach contributes to my terror. It's 
> built around an assumption that individual people have no market power. 
> It's the sovereigns protecting themselves and their interests and giving 
> their "Subjects" what they say the subjects need. This is not the 
> bitcoin-inspired self sovereign decentralized vision I signed-up for.*

If this was about a sovereign establishing power over their population, why
even fund this technology? Why not just go with a national OpenID provider and
be done with it?

If it's built on the assumption you state, then why are people bringing their
own DIDs to the SVIP ecosystem being considered? Why not just not provide a
choice and require ONE DID to rule them all?

Sovereigns provide credentials -- they have done that since time immemorial.
Why does doing that preclude your bitcoin-inspired self-sovereign
decentralized vision?  We can have both, can't we? Why is that terrifying to you?

> *AG: Delegation and authorization IS the specification structure I'm 
> talking about.

I have no idea what that means. Could you please propose a specification
structure, perhaps as a bulleted outline, that the group could consider?

> The GNAP group is trying to stay compatible with DID and VC and
> capabilities and non-HTTP transports and avoid federation and "trust" 
> assumptions. The SSI community ignores their work at great risk to our own
> goals.

Why do you think the SSI community is ignoring the GNAP work? I haven't seen
any indication of that. I have seen an indication of the opposite. What made
you think that the SSI community is ignoring GNAP?

> AG: So, please, no delay, particularly since this group is only talking
> about HTTP.  *

Would you like us to put this forward to the group during the next call?

PROPOSAL: Consider the series of "GNAP Proposals" put forward by Adrian
immediately and without delay.

> *AG: It's the parallelize thing that paralyzes me. Please don't keep 
> insisting that it's innocuous. I find it terrifying and the insistence
> just makes it more upsetting. * * * *- Adrian*

Could you please point to where I insisted that it isn't innocuous? At this
point every path is innocuous to someone involved in the work.

There are risks with all the paths forward, and we're trying to find a balance
while understanding that no path is perfect and the group will have to iterate
on the journey.

There are a number of people in this community that are dedicating significant
resources to this effort, and we need to (as a community) find a way to make
progress in ways that work for the largest number of people.

Adrian, I hope you see how much effort is being put into addressing your
concerns. Please respond to the questions above to make sure we're narrowing
toward a concrete proposal that is (ideally) going to work for all involved.

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

Received on Monday, 3 May 2021 20:21:17 UTC