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 UCAN-WG group an interesting concern was raised around our session protocol, specifically the way things are designed now is that web3.storage choose the oracle that can attest to the UCAN delegation from the account, which takes the choice from the user.
Conversation got me thinking about the fact that perhaps we could do better and empower user to choose the authority doing attestation instead. So let's consider following flow
sequenceDiagram
participant Issuer as 🔑<br/><br/>did:key:z6Mkk…sxALi
participant Account as 📫 [email protected]
participant Oracle as 🔮<br/><br/>did:web:oracle.link
participant Audience as 🗝️<br/><br/>did:key:z8wc…Alice
participant W3 as 📦 <br/><br/>did:web:web3.storage
Issuer ->> Account: can: store/*
Oracle ->> Audience: can: ucan/attest
Note right of Oracle: Attest delegation below
Account -->> Audience: can: store/add
Audience -) W3: do: store/add
Loading
The problem here is that it's did:web:web3.storage who chooses that did:web:oracle.link MUST provide attestation and not the user. What if we actually allowed did:key:z6Mkk…sxALi to choose oracle instead
sequenceDiagram
participant Issuer as 🔑<br/><br/>did:key:z6Mkk…sxALi
participant Account as 📫 [email protected]
participant Oracle as 🔮<br/><br/>did:web:oracle.link
participant Audience as 🗝️<br/><br/>did:key:z8wc…Alice
participant W3 as 📦 <br/><br/>did:web:web3.storage
Issuer ->> Account: can: store/*
Note right of Issuer: Delegates Oracle ability to attest ☝️
Issuer ->> Oracle: can: ucan/attest
Account -->> Audience: can: store/add
Note right of Oracle: Redelegates to attest to ☝️
Oracle ->> Audience: can: ucan/attest
Audience -) W3: do: store/add
Loading
Now whoever made a initial delegation can choose who can attest the re-delegation. We as a service do not need to care who that is because user chose and then signed over it. Furthermore user is able to delegate bunch of attestations to whoever they choose and we can accept invocations as long as 📫 --> 🗝️ is attested by one of the oracles that issuer 🔑 has delegated ability to attest.
The text was updated successfully, but these errors were encountered:
The way we're going to handle this is that the account is owned by [email protected], and any ucan with a proof-of-control (via oracle or otherwise, e.g. OpenPubkey) of [email protected] has access.
Implicit in this is that a user can choose to use our oracle, or (assuming the existence of some usable mechanism that doesn't yet exist 😅) they can use some other mechanism so long as that mechanism is sufficiently trusted/trustable.
In the UCAN-WG group an interesting concern was raised around our session protocol, specifically the way things are designed now is that web3.storage choose the oracle that can attest to the UCAN delegation from the account, which takes the choice from the user.
Conversation got me thinking about the fact that perhaps we could do better and empower user to choose the authority doing attestation instead. So let's consider following flow
The problem here is that it's
did:web:web3.storage
who chooses thatdid:web:oracle.link
MUST provide attestation and not the user. What if we actually alloweddid:key:z6Mkk…sxALi
to choose oracle insteadNow whoever made a initial delegation can choose who can attest the re-delegation. We as a service do not need to care who that is because user chose and then signed over it. Furthermore user is able to delegate bunch of attestations to whoever they choose and we can accept invocations as long as 📫 --> 🗝️ is attested by one of the oracles that issuer 🔑 has delegated ability to attest.
The text was updated successfully, but these errors were encountered: