Re: VC HTTP API specification structure

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

Received on Sunday, 2 May 2021 18:39:44 UTC