Re: Attempting to block work (was: Re: VC HTTP Authorization Conversation)

I know but there are implementations out in the real world so I am asking
those implementers directly. I agree we should address the endpoints first
and we wouldn't have got here if we talked about authz until the end of the
year. Everybody should feel free to ask Ivan, Veronica and Hagrid why their
endpoints exist or even ask them to create new ones.

To address David's questions about the endpoints.
*Issuer*

   - It appears you are going for a short lived credential and the API is
   currently setup for long lived credentials (I forgot to mention the update
   endpoint only updates status)

*Holder*

   - Yes* /presentations/prove *takes in a presentation and this prove a
   presentation returns the presentation along with a proof



Here are the answers my agents gave me:

Ivan:

   - /credentials/issue
      - I am an endpoint internal to my organization so the authz shouldn't
      matter to you
   - /credentials/update
      - I use the internal org authz as well

Veronica

   - To be honest.. I verify anything you throw at me. I get upset when I
   can't verify something. Do I really need to authz?

Holder

   - /credentials/derive
      - All I do is remove information. Do I need authz?
   - /presentations/prove
      - I'm pretty proud of my credentials, I will prove anything you want
      me to. Do I need authz?
   - /presentations/available
      - I don't need authz since I'm just a notify me button to poke.
   - /presentation/submissions
      - I only take in credentials from you. I can find other ways to throw
      away garbage. Do I need authz?

I presume the answer to some of those do i needs is yes... Interested in
hearing others thoughts

brian

On Sat, Jun 12, 2021 at 1:57 AM David Chadwick <
d.w.chadwick@verifiablecredentials.info> wrote:

> Hi Brian
>
> before addressing authz issues we should address the endpoints to see if
> they are sufficient for what wallet providers need.
> On 12/06/2021 09:21, Brian Richter wrote:
>
> There aren't that many endpoints in the current spec, let's enumerate them.
>
> Hi, I am Ivan the Issuer, I have 2 endpoints:
>
> I need 3 endpoints
>
> Register for a VC
>
> Issue a VC
>
> Refresh a VC
>
>
>    - I will issue a VC
>    - I will update a VC
>
> What authorization mechanism do I use?
>
> Hi, I am Veronica the Verifier, I have 2 endpoints:
>
>    - I will verify a VC
>    - I will verify a VP
>
> What authorization mechanism do I use?
>
> Hi, I am Hagrid the Holder, I have 4 endpoints:
>
>
>    - I will derive you a credential
>    - I will prove a presentation
>
> Is this the same as "return a presentation that matches this policy" since
> this is the functionality that most wallets will need when responding to a
> request from a RP/SP
>
> Kind regards
>
> David
>
>
>    - Tell me a presentation is ready for me
>    - Provide me a presentation to store
>
> What authorization mechanism do I use?
>
>
> I would be interested in implementers answers to the above questions.
>
> - Brian
>
> On Sat, Jun 12, 2021 at 1:05 AM David Chadwick <
> d.w.chadwick@verifiablecredentials.info> wrote:
>
>>
>> On 11/06/2021 21:54, Orie Steele wrote:
>>
>> The process certainly does not appear to be going super well on this work
>> item, but I think a more rigid issue / PR review on calls and more
>> debate on email can help with that.
>>
>> Perhaps that is because issuer, holder and verifier APIs are all rolled
>> into one  HTTP API. If we clearly separate the API services (and
>> discussion) into those appertaining to the issuer, holder and verifer APIs,
>> then I believe the discussions will be easier to handle.
>>
>> Kind regards
>>
>> David
>>
>