Fix test delegation approval

[2byrds]

Delegation Approval enpoint added.
The formatting for test_aiding was updated but the only significant change is the test_identifier_delegation_end test.

[2byrds]

Depends on https://github.com/WebOfTrust/keripy/pull/789/files

[2byrds]

Per the discussion on #247 I'm going to adjust the endpoint for the approval on this PR.

[2byrds]

Updated per @lenkan suggestion to use a separate endpoint and a PUT instead of POST

[codecov]

Codecov Report

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

Project coverage is 92.71%. Comparing base (caad67b) to head (fcaea50).
Report is 11 commits behind head on main.

Files	Patch %	Lines
src/keria/app/aiding.py	76.59%	11 Missing ⚠️
tests/app/test_aiding.py	98.13%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #248      +/-   ##
==========================================
- Coverage   92.82%   92.71%   -0.12%     
==========================================
  Files          37       36       -1     
  Lines        6982     7093     +111     
==========================================
+ Hits         6481     6576      +95     
- Misses        501      517      +16     

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

[lenkan]

Cross posting my comment on #247 for visibility

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.

I think from the dev meeting today it is clear that the desired approach is to not have to do step 4 as a separate API call, but rather as a part of the call that posts the interaction event.

[2byrds]

Cross posting my comment on #247 for visibility

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.

I think from the dev meeting today it is clear that the desired approach is to not have to do step 4 as a separate API call, but rather as a part of the call that posts the interaction event.

I agree, let's hear from @pfeairheller and I'll adjust the PR accordingly

[pfeairheller]

A few concerns here...

First, the history on this PR seems odd as it is bringing in some of my commits from 9 days ago.

Second, I don't think REST likes a PUT on a plural endpoint, PUTs require a resource afaik.

Third, I'm not sure why there is the waterfall of excepts at the bottom of the on_put, none of those exceptions can happen in that try block.

Fourth, we have a "delegating.py" file where this code should belong and the endpoint should be "delegation" specific, not "approvals"

Finally (and most importantly) I don't think this is the right approach. If you look at credentialing.py, there are endpoints that do credential specific things that ALSO require an anchoring event. That is the pattern that should be followed for this. A delegation endpoint that accepts either an IXN or ROT that is processed by the IdentifierResource, then a long running operation is returned. A new cue can be submitted to a Doer that then checks the delegables escrow, creates the anchor seal attachment and parses the event and when it is actually committed then declares the operation "done". So you'll need a new long running operation type with code in the Monitor to check for this to be "done" by looking for the successful completion of the delegated event.

My suggestion is to close this PR and open a new one that takes another approach.

[2byrds]

Closing now that review comments addressed in new PR #250