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

Allow users to choose oracle as opposed to service choosing one #53

Open
Gozala opened this issue Mar 2, 2023 · 2 comments
Open

Allow users to choose oracle as opposed to service choosing one #53

Gozala opened this issue Mar 2, 2023 · 2 comments

Comments

@Gozala
Copy link
Collaborator

Gozala commented Mar 2, 2023

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.

@gobengo
Copy link
Contributor

gobengo commented Mar 2, 2023

What if we actually allowed did:key:z6Mkk…sxALi to choose oracle instead

👍

@blaine
Copy link

blaine commented Apr 25, 2023

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.

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

No branches or pull requests

3 participants