Re: VC HTTP API specification structure

On 2021-05-02 8:25 am, Adrian Gropper wrote:
> inline...
> On Sat, May 1, 2021 at 10:55 PM Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>> wrote:
>
>     <snip>
>
>     Can you please explain to the group how any of what you have shared has to do
>     with the physical structure of the document that the Editors will need to work
>     with? Please put these in the form of concrete counter-proposals to the
>     proposal above. 
>
>     <snip>
>

Adrian,

These proposals are admirably concise. But.

As a list member who relies on standard English to understand the concepts being considered, even after looking at [1] [2] and the diagrams, I'm still at a loss. So I'd like it if you could please explain, in similarly concise but standard English terms (with as few acronyms as possible):

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

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


Steven Rowat

>
> Please refer to slide 4 https://lists.w3.org/Archives/Public/public-credentials/2021Apr/att-0120/2021-VC-HTTP-API.pdf <https://lists.w3.org/Archives/Public/public-credentials/2021Apr/att-0120/2021-VC-HTTP-API.pdf> for a helpful diagram.
>
> With respect to the *VC **Issuer**HTTP API*specification:
>
> PROPOSAL A: The VC Issuer is a GNAP Resource Server (RS) as defined in [1] .
>
> PROPOSAL B: The VC Issuer SHOULD allow the VC Subject to use a GNAP Authorization Server (AS) as defined in [2] as their agent.
>
> PROPOSAL C: The VC Issuer MUST allow the VC Subject or their agent to designate a GNAP RS as the VC Holder.
>
> PROPOSAL D: The VC Issuer MAY restrict the VC Subject's choice of Holder RS based on certification requirements including federation.
>
> PROPOSAL E: The interaction between Subject AS and VC Holder is out of scope for the VC Issuer HTTP API specification.
>
> With respect to the *VC **Verifier**HTTP API* specification:
>
> PROPOSAL F: The VC Verifier is a GNAP client as defined in [1] and [2]
>
> PROPOSAL G: The VC Verifier MAY restrict the VC Subject's choice of Holder RS based on certification requirements including federation.
>
> PROPOSAL H: The interaction between Subject AS and VC Holder is out of scope for the VC Verifier HTTP API specification.
>
> 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.
>
> 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.
>
> - Adrian
>
> [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>
> [2] https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-05.html <https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-05.html>