Switch invoker to authorizedParty

[cwebber]

invoker is a bit confusing because it makes the capability document look like an invocation when you're reading it. @dmitrizagidulin suggests authorizedParty which is closer to the oauth group does

[danfinlay]

I think “recipient” also works pretty well.

[dlongley]

We want to be able to distinguish invoker from delegator, so if we change the name, we should change both, perhaps to: authorizedInvoker and authorizedDelegator. I'm also not sure how confusing it is ... and whether or not a change is really necessary must now be weighed against the cost of changing what is already being deployed today.

[danfinlay]

I agree with not breaking existing things, just riffing on the wording because having just written up the type, invoker stood out as a bit awkward :)

[dlongley]

We are likely going to change invoker to authorizedInvoker and delegator to authorizedDelegator to avoid confusion. The reason for moving forward with the change is that specifying who delegated a capability via the delegator property is useful -- and this would be in conflict with using it to mean who is authorized to further delegate. Since we'd be changing to use authorizedDelegator it would make sense to align invoker by changing it to authorizedInvoker even though we don't have a use case for invoker at this time. We will likely make this change in our ocapld.js implementation very shortly.

cc: @cwebber

[dlongley]

We're going to experiment a bit more with our implementation per the last comment -- it may turn out to be more confusing in some ways to use authorizedDelegator than just delegator -- based on the fact that you need to check parentCapability.authorizedDelegator when verifying, not capability.authorizedDelegator.