ucanto icon indicating copy to clipboard operation
ucanto copied to clipboard

Support ucan/attest issued by did:mailto principal

Open Gozala opened this issue 2 years ago • 2 comments

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.

Gozala avatar Oct 28 '23 13:10 Gozala

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.

Gozala avatar Oct 28 '23 13:10 Gozala

This is the code that currently assesses whether delegation issued by did:mailto is valid

https://github.com/web3-storage/ucanto/blob/43ea497ca2200f9e1e15dbbdd033ec24895edb7d/packages/validator/src/lib.js#L544-L560

I think we could extend that function to also check this claim

const attestation = capability({
  with: Schema.literal(delegation.issuer.did()),
  can: 'ucan/attest',
  nb: Schema.struct({
    proof: Schema.link(delegation.cid),
  }),
})

We will need to be extra careful so that we only allow ucan/attest with given did:mailto if:

  1. Issuer has been delegated such ability.
  2. Delegation is attested by the verifying authority (and not by itself)

Gozala avatar Oct 28 '23 13:10 Gozala