Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support ucan/attest issued by did:mailto principal #325

Open
Gozala opened this issue Oct 28, 2023 · 2 comments · May be fixed by #326
Open

Support ucan/attest issued by did:mailto principal #325

Gozala opened this issue Oct 28, 2023 · 2 comments · May be fixed by #326

Comments

@Gozala
Copy link
Collaborator

Gozala commented Oct 28, 2023

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
Copy link
Collaborator Author

Gozala commented Oct 28, 2023

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
Copy link
Collaborator Author

Gozala commented Oct 28, 2023

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

const verifySession = async (delegation, proofs, config) => {
// Create a schema that will match an authorization for this exact delegation
const attestation = capability({
with: Schema.literal(config.authority.did()),
can: 'ucan/attest',
nb: Schema.struct({
proof: Schema.link(delegation.cid),
}),
})
return await claim(
attestation,
// We omit the delegation otherwise we may end up in an infinite loop
proofs.filter(proof => proof != delegation),
config
)
}

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant