Open Gozala opened 11 months ago
Also I'm not sure if we capture space names anywhere, but it might be a good idea to do so in the delegation itself
so this does work in the simplest cases:
# create a space with agent 1
➜ W3_STORE_NAME=agent1 w3 space ls
➜ W3_STORE_NAME=agent1 w3 authorize travis.vachon@protocol.ai
⁂ agent authorized to use capabilities delegated to travis.vachon@protocol.ai
➜ W3_STORE_NAME=agent1 w3 space ls
did:key:z6Mkfy8k2JJUdNWCJtvzYrko5QRc7GXP6pksKDG19gxYzyi4
# now try to get the space with agent 2
➜ W3_STORE_NAME=agent2 w3 space ls
➜ W3_STORE_NAME=agent2 w3 authorize travis.vachon@protocol.ai
⁂ agent authorized to use capabilities delegated to travis.vachon@protocol.ai
➜ W3_STORE_NAME=agent2 w3 space ls
did:key:z6Mkfy8k2JJUdNWCJtvzYrko5QRc7GXP6pksKDG19gxYzyi4
# it worked!
but there does seem to be a bug where spaces created by agent 1 after agent 2 has authorized won't be accessible:
# create and provision _another_ space with agent 1
➜ W3_STORE_NAME=agent1 w3 space create
did:key:z6Mkm3DPFdNDqw3fGPDxyASZzHw9ndJoaFin4AFos5JNN1Nn
➜ W3_STORE_NAME=agent1 w3 space ls
did:key:z6Mkfy8k2JJUdNWCJtvzYrko5QRc7GXP6pksKDG19gxYzyi4
* did:key:z6Mkm3DPFdNDqw3fGPDxyASZzHw9ndJoaFin4AFos5JNN1Nn
➜ W3_STORE_NAME=agent1 w3 space register --email travis.vachon@protocol.ai
⁂ space registered to travis.vachon@protocol.ai
# now claim delegations with agent 2, hoping to get access to the new space
➜ W3_STORE_NAME=agent2 w3 space ls
did:key:z6Mkfy8k2JJUdNWCJtvzYrko5QRc7GXP6pksKDG19gxYzyi4
➜ W3_STORE_NAME=agent2 w3 can access claim
➜ W3_STORE_NAME=agent2 w3 space ls
did:key:z6Mkfy8k2JJUdNWCJtvzYrko5QRc7GXP6pksKDG19gxYzyi4
# it didn't work!
but! agents who authorize after that get both:
➜ W3_STORE_NAME=agent3 w3 authorize travis.vachon@protocol.ai
⁂ agent authorized to use capabilities delegated to travis.vachon@protocol.ai
➜ W3_STORE_NAME=agent3 w3 space ls
did:key:z6Mkm3DPFdNDqw3fGPDxyASZzHw9ndJoaFin4AFos5JNN1Nn
did:key:z6Mkfy8k2JJUdNWCJtvzYrko5QRc7GXP6pksKDG19gxYzyi4
and if I re-authorize (and work around a known issue where we don't wait for proofs when authorizing a second time), I do get the spaces I'm expecting:
➜ W3_STORE_NAME=agent2 w3 authorize travis.vachon@protocol.ai
⁂ agent authorized to use capabilities delegated to travis.vachon@protocol.ai
➜ W3_STORE_NAME=agent2 w3 space ls
did:key:z6Mkfy8k2JJUdNWCJtvzYrko5QRc7GXP6pksKDG19gxYzyi4
➜ W3_STORE_NAME=agent2 w3 can access claim
➜ W3_STORE_NAME=agent2 w3 space ls
did:key:z6Mkfy8k2JJUdNWCJtvzYrko5QRc7GXP6pksKDG19gxYzyi4
did:key:z6Mkm3DPFdNDqw3fGPDxyASZzHw9ndJoaFin4AFos5JNN1Nn
Me and @travis chatted about and looked into a fix which would require non-trivial changes. So we have decided that instead we can do following:
w3 access claim
top level command to pull delegations.Separately I have also created https://github.com/web3-storage/ucanto/issues/325 which if fixed is going to allow to allow our to gain access to new spaces without having to go additional authorization loops.
Here is how I think we could solve this problem:
w3 access claim
program should invoke access/claim
for own agent and all active account
s.We could do 1 and 2 but 3 is a tricky bit. Delegation from an account to the agent requires an attestation. Right now we create attestation only on authorization and perform interactive confirmation with a user over email.
So to accomplish no 3 I can think of the following options:
We revive https://github.com/web3-storage/ucanto/issues/325 so that existing account authorization (login) could be used to attest delegation from an account without having to go through a service backend and another email authorization flow.
We could update UCAN validator so that on invocation you construct this kind of invocation and consider it valid:
{
iss: "did:key:zAlice"
aud: "did:web:web3.storage"
att: [{ can: "store/list", with: "did:key:zSpace" }]
prf: [
{ iss: "did:mailto:web.mail:alice", aud: "did:key:zAlice", att: [{ can: "*", with: "ucan:*" }] },
// This proof is misaligned by principal, according to spec it should be proof of ☝️, however new
// spec does not need proofs in delegations it needs a proof path in invocations and this is
// invocation so seems fine
{ iss: "did:key:zSpace", aud: "did:mailto:web.mail:alice", att: [{can: "*", with: "did:key:zSpace" }] },
]
}
We could implement API for creating attestations without the login flow. Specifically we could say if you send access/request
or access/authorize
invocation where audience is did:mailto
, we simply trigger email authorization flow where user is send an email if they click it in time we'll issue a delegation and corresponding attestation.
access/authorize
and access/confirm
. Had a chat with @travis and we came up with a hybrid option which I think we should go with, specifically:
Extend access/confirm
capability handler so that with
field could be did:mailto
matching an account
here. So basically change following lines
To these
const { account, agent } = parse(capability)
// Confirmation MUST be authorized either by an account or a service
if (capability.with !== ctx.signer.did() && capability.with !== account.did()) {
throw new Error(`Not a valid access/confirm delegation`)
}
For accounts new spaces agent could issue access/confirm
invocation using an account with
and store that delegation into proof store.
We should make access sync really smooth across agents, it should be as simple as
git pull
I suggestw3 access claim
command (as opposed tow3 can access claim
).That sort of works today, but I don't believe it works quite like what I'd expect. Here is the scenario:
A
andB
.A
user created a space "Repo".w3 access claim
on deviceB
they should have access to space "Repo" and it must show when runningw3 space ls
.I might be mistaken but I do not believe it currently works like that, because access claim will just pull down delegations for the agent. To make above work we also need to pull down delegations for the account and then locally: