w3-accounts #12

Gozala · 2022-11-25T17:38:03Z

Wrote a specification for explaining accounts and how they correlate with spaces

vasco-santos

LGTM! Good writing @Gozala ❤️

w3-account.md

Co-authored-by: Vasco Santos <santos.vasco10@gmail.com>

gobengo · 2022-11-28T18:08:13Z

w3-account.md

+
+## Account
+
+User account is a [principal][] identified by [`did:mailto`][] (listed in a UCAN's `iss` or `aud` field).


Why have this be did:mailto: and not mailto: ?

The former begs the question of how that did method works, i.e. how to create, read (resolve to did doc), update, and delete dids using that method. The spec for that seems to be a placeholder atm. Understandable, but still I'm struggling to imagine how exactly the read/resolve would work for a did:mailto.

Using just mailto: URIs would sidestep needing to define the did method, and in this spec or ucans, we could define processing rules however we want, all without needing to shoehorn in did semantics.

If we do really want to define/use a did:mailto, how would did resolution work (e.g. here is how did:dns resolution works)

Why have this be did:mailto: and not mailto: ?

Because principals in UCAN spec are DIDs, if they were arbitrary URIs than using just mailto: URI would have made a lot more sense. Perhaps we can work towards allowing UCANs to use arbitrary URIs in principals, but I would pursue that separately and then update to just mailto: as opposed to getting blocked on that.

If we do really want to define/use a did:mailto, how would did resolution work (e.g. here is how did:dns resolution works)

My plan had been do spec that out here https://github.com/ucan-wg/did-mailto, but I don't have bandwidth for that right now.

how to create, read (resolve to did doc), update, and delete dids using that method.

In nutshell, resolution schema is you send them an email asking what's their DID document and they respond you back with did:key corresponding to their document

Gozala · 2022-11-28T19:18:57Z

w3-account.md

+  }],
+  exp: null
+  sig: "..."
+}


Example below illustrates did:dns:web3.storage = did:key:root allowing did:key:zJune to identify as did:dns:web3.storage as long as delegation is valid. This allows did:key:zJune to issue an outer UCAN and sign it with did:key:zJune, however it needs to provide proof of delegation from did:key:root authorizing it do it.

{ iss: "did:dns:web3.storage", aud: "did:key:someone", // Delegates some capability to the did:dns:web3.storage resource. // Capability is not really important, it's just that it CAN delegate capability for `did:dns:web3.storage` att: [{ can: "inbox/add", with: "did:dns:web3.storage" }], sig: "..." // <- signed with did:key:zJune because proof above // 👇 proof that did:key:zJune could issue ucan on behalf of did:dns:web3.storage prf: [{ iss: "did:dns:web3.storage", // <- Maybe this should be did:key:root here aud: "did:dns:web3.storage", // <- delegating to did:dns:web3.storage to align principals // Says that UCAN's issued by `did:dns:web3.storage` may be signed by // did:key:zJune. // This basically says that did:key:zJune is a session key which expires in july att: [{ with: "did:dns:web3.storage", can: "ucan/sign", nb: { as: "did:key:zJune" } }], exp: july, sig: "..." // <- Must be signed by the key did:dns:web3.storage resolves to }], exp: hour }

@expede can you please provide feedback on this

@Gozala wrt send/message, that's new right? I notice that it is of the form verb/noun whereas most of the time our caps name convention is more like noun/verb

Yeah just ignore this, I was sketching this while speaking to @expede over the call so it's pretty sloppy and out of the context here

Hey @expede have you had a chance to consider this ? In our call, I believe you said you were ok with general idea, yet wanted to ponder more about actual representation

Sorry for the post-merge feedback @Gozala !

wrt send/message, that's new right? I notice that it is of the form verb/noun whereas most of the time our caps name convention is more like noun/verb

@gobengo I've been thinking about this in a UCAN "standard library" as msg/send, which cuts across email, text messaging, message passing, etc etc.

iss: "did:dns:web3.storage", // <- Maybe this should be did:key:root here aud: "did:dns:web3.storage",

I continue to find iss == aud deeply strange. I agree with your comment "Maybe this should be did:key:root here".

Rather than granting the ability to sign "as" another DID, I think it's cleaner to make this a "forwarding edge", which follows much more the capabilities worldview. I think that the end result is the same, so it's just naming.

Time 1: carol --[fwd_all]--> dan Time 2: alice --[can: foo]--> bob --[can: foo]--> carol Time 3: dan --[can: foo]--> frank

BECAUSE we can substitute a link:

alice --[can: foo]--> bob --[can: foo]--> carol | [fwd_all] | V dan --[can: foo]--> frank End result: Frank can use Alice's foo

This is kind of like "signing as" Carol, but it's only at the level of authority, not identity. Alice saying "you can sign as Bob" is going to get really confusing unless you want to do DID management, which IMO should be at a DID layer. I think you can manage all of this cleanly at the layer of capabilities.

This is a powerful enough feature that has enough uses that I propose that we add this as a first-class feature to UCAN at some stage. In the meantime, I propose that we call this something other than "signing as".

Here's some delegations in this model:

w3s --[fwd_all]--> didJune w3s --[fwd_all]--> didJuly w3s --[fwd_all]--> didAug ## Super simple case, nothing unusual ## w3s --[fwd_all]--> didJune --[w3s's foo]--> alice ## More complex case with new forwarding concept ## bob --[bob's bar]--> w3s | [fwd_all] | V didJune --[bob's bar]--> carol

Here's that last one concretely:

{ iss: "did:key:june", aud: "did:key:carol", att: [{ can: "thing/doSomthing", with: "resource://example.com" }], sig: "...", prf: [ { iss: "did:key:zBob", aud: "did:dns:web3.storage", att: [{ with: "resource://exmaple.com", can: "thing/doSomething" }], exp: august2022, sig: "..." }, { iss: "did:dns:web3.storage", aud: "did:key:june", att: [{ with: "did:dns:web3.storage", can: "ucan/forward_all" // we can come up with a better label }], exp: november2022, sig: "..." } ] }

w3-account.md

gobengo · 2022-11-28T19:30:17Z

w3-account.md

+ ```ts
+{
+  iss: "did:key:zAgent",
+  aud: "did:dns:web3.storage",


I seem to recall somewhere you were deciding between whether to use did:dns or did:web. Where did that land?

One tradeoff that comes to mind is that updates to did:dns may be more eventually consistent (because ttls), whereas did:web might give us more predictability about how fast we can expect updates to propagate.

Another tradeoff though is did:web requires an ssl cert and tcp socket. So that may be more overhead than we want.

So for my edification: Why did you choose did:dns and not did:web?

General idea is agnostic of choice between did:dns and did:web we could choose one that makes most sense or both. That said I think did:web is probably a going to be a better choice however

gobengo · 2022-11-28T19:47:53Z

I think it would be helpful to have something like a sequence diagram explaining how the capabilities specified here would be used together to accomplish a use case.

Co-authored-by: Benjamin Goering <171782+gobengo@users.noreply.github.com>

Gozala · 2022-11-29T00:36:46Z

Refactored document a bit to align spec with user flow. Added a sequence diagram to illustrate the user flow

gobengo · 2022-11-29T20:17:06Z

Refactored document a bit to align spec with user flow. Added a sequence diagram to illustrate the user flow

@Gozala nice ty. any objection if at some point later I try to rewrite it as a mermaidjs sequence diagram so it's prettier? https://mermaid-js.github.io/mermaid/#/sequenceDiagram

will be post-merge as its a stylistic improvement only

Gozala · 2022-11-30T16:54:51Z

@Gozala nice ty. any objection if at some point later I try to rewrite it as a mermaidjs sequence diagram so it's prettier? https://mermaid-js.github.io/mermaid/#/sequenceDiagram

I'd be delighted if you do

gobengo · 2022-11-30T17:24:41Z

w3-account.md

+  aud: "did:dns:web3.storage",
+  att: [{
+    with: "did:key:zAgent",
+    can: "ucan/issue",


could it be like recovery/authorize-email-resovery? If not rename, am I at least understanding it right?

It's more like user/login

HackMD added 3 commits November 25, 2022 15:52

last changed at Nov 25, 2022 7:50 AM, pushed by Irakli Gozalishvili

a7bae92

last changed at Nov 25, 2022 7:50 AM, pushed by Irakli Gozalishvili

aefa4f4

last changed at Nov 25, 2022 9:36 AM, pushed by Irakli Gozalishvili

12af294

Gozala requested review from alanshaw, hugomrdias, jchris, mikeal, olizilla, vasco-santos and yusefnapora November 25, 2022 17:39

Gozala mentioned this pull request Nov 25, 2022

Way to connect delegation chains ucan-wg/spec#130

Open

vasco-santos approved these changes Nov 28, 2022

View reviewed changes

w3-account.md Outdated Show resolved Hide resolved

w3-account.md Outdated Show resolved Hide resolved

Apply suggestions from code review

533d84e

Co-authored-by: Vasco Santos <santos.vasco10@gmail.com>

gobengo reviewed Nov 28, 2022

View reviewed changes

Gozala commented Nov 28, 2022

View reviewed changes

gobengo reviewed Nov 28, 2022

View reviewed changes

w3-account.md Outdated Show resolved Hide resolved

gobengo reviewed Nov 28, 2022

View reviewed changes

w3-account.md Outdated Show resolved Hide resolved

gobengo reviewed Nov 28, 2022

View reviewed changes

Gozala and others added 3 commits November 28, 2022 12:41

Apply suggestions from code review

b2b99bf

Co-authored-by: Benjamin Goering <171782+gobengo@users.noreply.github.com>

last changed at Nov 28, 2022 4:17 PM, pushed by Irakli Gozalishvili

9e2840a

last changed at Nov 28, 2022 4:17 PM, pushed by Irakli Gozalishvili

7ca4f8b

Gozala mentioned this pull request Nov 29, 2022

Feat: add support for ./update capability web3-storage/ucanto#146

Closed

gobengo reviewed Nov 30, 2022

View reviewed changes

fix typo

94ce498

Gozala merged commit 83916d1 into main Nov 30, 2022

Gozala mentioned this pull request Nov 30, 2022

did snapshots in UCANs #13

Closed

gobengo mentioned this pull request Dec 8, 2022

access service & client should use did:web:web3.storage storacha-network/w3up#237

Closed

5 tasks

Gozala mentioned this pull request Dec 13, 2022

feat: embedded key resolution web3-storage/ucanto#168

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

w3-accounts #12

w3-accounts #12

Gozala commented Nov 25, 2022

vasco-santos left a comment

gobengo Nov 28, 2022 •

edited

Gozala Nov 28, 2022

Gozala Nov 28, 2022

Gozala Nov 28, 2022 •

edited

Gozala Nov 28, 2022

gobengo Nov 28, 2022 •

edited

Gozala Nov 28, 2022 •

edited

Gozala Nov 29, 2022

expede Nov 30, 2022 •

edited

gobengo Nov 28, 2022 •

edited

Gozala Nov 28, 2022

gobengo commented Nov 28, 2022

Gozala commented Nov 29, 2022

gobengo commented Nov 29, 2022

Gozala commented Nov 30, 2022 •

edited

gobengo Nov 30, 2022

Gozala Nov 30, 2022


		## Account

		User account is a [principal][] identified by [`did:mailto`][] (listed in a UCAN's `iss` or `aud` field).

w3-accounts #12

w3-accounts #12

Conversation

Gozala commented Nov 25, 2022

vasco-santos left a comment

Choose a reason for hiding this comment

gobengo Nov 28, 2022 • edited

Choose a reason for hiding this comment

Gozala Nov 28, 2022

Choose a reason for hiding this comment

Gozala Nov 28, 2022

Choose a reason for hiding this comment

Gozala Nov 28, 2022 • edited

Choose a reason for hiding this comment

Gozala Nov 28, 2022

Choose a reason for hiding this comment

gobengo Nov 28, 2022 • edited

Choose a reason for hiding this comment

Gozala Nov 28, 2022 • edited

Choose a reason for hiding this comment

Gozala Nov 29, 2022

Choose a reason for hiding this comment

expede Nov 30, 2022 • edited

Choose a reason for hiding this comment

gobengo Nov 28, 2022 • edited

Choose a reason for hiding this comment

Gozala Nov 28, 2022

Choose a reason for hiding this comment

gobengo commented Nov 28, 2022

Gozala commented Nov 29, 2022

gobengo commented Nov 29, 2022

Gozala commented Nov 30, 2022 • edited

gobengo Nov 30, 2022

Choose a reason for hiding this comment

Gozala Nov 30, 2022

Choose a reason for hiding this comment

gobengo Nov 28, 2022 •

edited

Gozala Nov 28, 2022 •

edited

gobengo Nov 28, 2022 •

edited

Gozala Nov 28, 2022 •

edited

expede Nov 30, 2022 •

edited

gobengo Nov 28, 2022 •

edited

Gozala commented Nov 30, 2022 •

edited