added approval endpoint for delegator after they anchor seal in their KEL

[2byrds]

Additions based on Phil's guidance and using his current PR

[codecov]

Codecov Report

Attention: Patch coverage is 12.50000% with 21 lines in your changes are missing coverage. Please review.

Please upload report for BASE (feat-fix-delegation@55cb7c6). Learn more about missing BASE report.

Files	Patch %	Lines
src/keria/app/aiding.py	12.50%	21 Missing ⚠️

Additional details and impacted files

@@                  Coverage Diff                   @@
##             feat-fix-delegation     #247   +/-   ##
======================================================
  Coverage                       ?   92.74%           
======================================================
  Files                          ?       36           
  Lines                          ?     7016           
  Branches                       ?        0           
======================================================
  Hits                           ?     6507           
  Misses                         ?      509           
  Partials                       ?        0           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lenkan]

Do I understand this correctly that the follow is the flow for the delegator?

=> POST /identifiers/name/events
{
  ixn: { anchoring event }
}
<= HTTP 200 OK


=> POST /identifiers/name/events
{
  approveDelegation: { anchoring event }
}
<= HTTP 200 OK

I.e. you first post the event, then explicitly approve the delegation as a separate API call. In that case, I have two questions.

• How does it work when the delegator is a multisig? Do all participants have to do the same thing?
• Does the second POST with the approveDelegation field actually append an event? If not, I think this should move to a separate endpoint to avoid confusion. To me POST /identifiers/name/events says that you will append an event to the KEL.

[2byrds]

• How does it work when the delegator is a multisig? Do all participants have to do the same thing?

Great questions @lenkan i'll need to add tests for the multi-sig case to be sure. The delegatee 'dip' event and the 'ixn' events will be thresholded, the multi-sig AID won't complete until enough signatures are provided.

• Does the second POST with the approveDelegation field actually append an event? If not, I think this should move to a separate endpoint to avoid confusion. To me POST /identifiers/name/events says that you will append an event to the KEL.

Without the approval, the delegator AID won't process the 'dip' of the delegatee. It will sit in escrow until the approval is given. It is meant to be similar to the 'ixn' anchor being needed, but this is an additional check in order to protect the delegator AID from accidentally anchoring a seal that triggers an approval. So the delegation isn't complete until the 'dip' is finally processed by the delegator when the approval is sent, but that still depends on all the signature thresholds being met. Since it is a two step-process the correct functionality is that a threshold of approvals is met, I believe. I'll verify with tests if a threshold of approvals is needed for the multi-sig case. Thoughts?

[lenkan]

What is the process?

1. Delegatee create delegated inception event dip
2. Delegator receives the inception event details out of band
3. Delegator create interaction event with delegation information in anchor data.
4. Delegator approves delegation by posting the same interaction event again?

What is the risk with having step 4 processed automatically?

If it is not possible to do automatically, can we add a flag to step 3 so it becomes

POST /identifiers/name/events
{ 
   ixn: [ anchor data ], 
   approveDelegation: true 
}

Another option if we absolutely need to do do another call to the server, we can move it to another endpoint? What is it that is being created or modified here? Is it a "pending delegation request"?

Note: I am not saying any of my suggestion are objectively better, just trying to trigger discussion about how we design the HTTP API of KERIA so that we can improve it as we move forward.

[2byrds]

Shifting over to a new PR, but will recap the needed changes based on @lenkan suggestions #248