Re: VC HTTP API specification structure

Here's a thought on how to introduce some parallelism into our process.

As we work on the use-cases, we start a spec document with the Issuer /
Subject protocol. We can later either add to this document or start a
second one for the Holder or Verifier.

For example:

   - An Issuer publishes an example of a VC they are able to issue at a
   .well-known location. Along with the example VC, there could be:
      - a service endpoint to request the VC
      - a deposit required with the request
      - a list of suggested purposes for the request
   - A Subject creates a data structure that includes:
      - The public identifier of the VC as listed above
      - The Subject identifier that should be in the issued VC
      - A service endpoint to deliver the VC, continue the conversation,
      refund the deposit, or catch the errors
      - Optional information such as payment, purpose, etc...
   - The Issuer
      - evaluates the Subject's preferred identifier and uses various means
      to prove control
      - matches the identifier to records held by the Issuer to decide next
      steps
      - delivers the VC as directed by the subject, or
      - continues the conversation, refunds the deposit, throws an error.

... all of this over HTTP.

- Adrian

On Tue, May 4, 2021 at 2:06 PM Alan Karp <alanhkarp@gmail.com> wrote:

> I am not a "standards guy."  I did serve on the UDDI (Universal
> Description, Discovery, and Integration) committee for a while, so I
> appreciate your efforts.  You have both my thanks and condolences :)
>
> Because of that lack of experience with the standards process, I'm at a
> loss when it comes to helping.  What I do know is:
>
> 1) having a specification in the first place: That's a good thing, but
> you've got to define the scope properly.
> 2) the initial structure of that specification: The outline of the spec
> constrains how the group considers options.
>
> I'll continue to lurk so I can pipe up when I see something that concerns
> me.
>
> --------------
> Alan Karp
>
>
> On Mon, May 3, 2021 at 5:35 PM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> On 5/3/21 6:08 PM, Alan Karp wrote:
>> > 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.
>>
>> Yes, acknowledged -- hearing both of you loud and clear... and I say this
>> as
>> one of the Editors of the Authorization Capabilities (zcap-ld)
>> specification,
>> which deals with many of the same delegation and authorization concerns.
>> Many
>> of us on this list do truly understand the nuances here, and that we
>> should
>> tread carefully and be careful about the choices made. No one is saying
>> that
>> we should be careless here.
>>
>> That said, it has yet to be demonstrated that those concerns have
>> anything to
>> do with 1) having a specification in the first place, and/or 2) the
>> initial
>> structure of that specification.
>>
>> Alan, perhaps you can help Adrian draw a direct line back to the single
>> concrete proposal we're attempting to make progress on... namely, can we
>> pick
>> a starting structure for the VC HTTP API specification so we can get some
>> of
>> these thoughts down?
>>
>> MikeP just asked the question of the hour:
>>
>> Mike Prorock wrote:
>> > 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?
>>
>> Alan, perhaps you can help here -- How is the discussion around
>> Authorization
>> and Delegation, which everyone wants to have (eventually), negatively
>> impacted
>> by items #1 and #2 above?
>>
>> -- 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
>>
>>
>>