You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current implementation we assume that ucan/attest is issued by the principal doing validation. And because ucan/attest is tied to specific delegation it introduces unnecessary loops where agent that did:mailto delegated capabilities needs ask re-request service to attest delegations every time did:mailto gets delegation even if it is covered by first attestation.
We can avoid this complication if such agent could arrange delegations on it's own as long as it has been delegated ucan/attest capability by the did:mailto principal.
The text was updated successfully, but these errors were encountered:
It is worth calling out that direction new UCAN spec is headed would make this non issue because they remove proofs from the delegation and consequently it if you had did:mailto:web.mail:alice → did:key:zAgent and later there was did:key:zSpace → did:mailto:web.mail:alice invoking agent would be able to just provide those proofs at the invocation time.
In the current implementation we assume that
ucan/attest
is issued by the principal doing validation. And becauseucan/attest
is tied to specific delegation it introduces unnecessary loops where agent that did:mailto delegated capabilities needs ask re-request service to attest delegations every timedid:mailto
gets delegation even if it is covered by first attestation.We can avoid this complication if such agent could arrange delegations on it's own as long as it has been delegated
ucan/attest
capability by thedid:mailto
principal.The text was updated successfully, but these errors were encountered: