feat!: allow attestations from did:mailto #326
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
travis
approved these changes
Oct 31, 2023
Gozala
added a commit
to storacha/w3up
that referenced
this pull request
Nov 6, 2023
Implements flows described in #945 ## High level overview ### Accounts This pull request starts differentiating between two kinds of authorizations 1. Space authorization, allowing access to a space. 2. Account authorization, allowing account management and space provisioning. Most core functionality has been added in `Account` module which exposes following functionality - `Account.login(client, email)` - Request account level access though `access/authorize` and awaits until access is granted (through email link) or request expires. It returns an `Account` object which is just a view over UCAN delegations and an agent. That is convenience wrapper allowing us to add e.g. `.provision(space)` method (for provisioning spaces) and `.save()` method that will save account proofs into agent store. - `Account.list()` - Lists all account (sessions) client has in storage. It essentially goes over proofs and wraps ones that are "account authorization"s into `Account` objects. Above functionality should help us answer question whether user has already logged-in or not ? Previously we had no good way to answer such questions. ### Access This fixes issues around authorization flows, where requests would succeed but access was not gained. Issue was caused by imperfect heuristics that tried to match received delegation with a requested authorization. To address this problem `access/authorize` and `access/confirm` capabilities and their handler had been extended to capture request CIDs. This allows client polling for delegations to detect whether received delegation is corresponds to the request more precisely. I have added new `Access` module that attempts to do the client side work without much configurability. - `Access.request` - will send `access/authorize` request and return `PendingAccessRequest` object, which in turn could be used to poll for the response via `.claim()` method. `.claim()` internally uses `.poll()` until it gets the delegation, session expires or request is aborted. - `Access.claim` - sends `access/claim` request and returns `GrantedAccess` object that wraps received delegations. It also (just like `Account`) has `.save()` method which can be used to save delegations into client's store. ### Space I have added new `Space` module that has has `Space.generate()` function to generate new spaces, `Space.fromDelegation`, `Space.fromMnemonic` and more. General idea here also is that `client.createSpace()` will give you `OwnedSpace` object that has bunch of methods like `.toMnemonic`, `.createAuthorization`, `.createRecovery` etc... Notion of not registered spaces had been removed. If you create a space you have an object, you can save it in your client using `client.addSpace(await space. createAuthorization(agent))`. ### Attestation I have moved `ucan/attest` capability definition from `access` to `ucan` as former place was confusing and made no sense. --- The [account.test.js](https://github.com/web3-storage/w3up/pull/1059/files#diff-9a9133d8e343b56d7ef7bd18d01356b8ca7c630143b4687a51f683a5ebe1528f) attempts to capture authorization / provisioning flows from the event diagram. There is one unfortunate problem right now, that is new spaces added will not show in other devices unless you re-authorize. Fixing that requires storacha/ucanto#326 and some more work here. I think it's best to do it as a followup. --- I had to rebase because things upstream have changed, unfortunately I failed to do it cleanly so there is lot of strange changes which I don't exactly know how they happened. I'll try to remove undo them tomorrow --------- Co-authored-by: Alan Shaw <alan.shaw@protocol.ai>
gobengo
reviewed
Nov 7, 2023
| }) | ||
|
|
||
| // and creates an attestation using an authorization from | ||
| // the account account |
Contributor
There was a problem hiding this comment.
Suggested change
| // the account account | |
| // the account |
gobengo
approved these changes
Nov 7, 2023
tx-ravenxbsw3
added a commit
to tx-ravenxbsw3/w3up
that referenced
this pull request
Sep 29, 2025
Implements flows described in #945 ## High level overview ### Accounts This pull request starts differentiating between two kinds of authorizations 1. Space authorization, allowing access to a space. 2. Account authorization, allowing account management and space provisioning. Most core functionality has been added in `Account` module which exposes following functionality - `Account.login(client, email)` - Request account level access though `access/authorize` and awaits until access is granted (through email link) or request expires. It returns an `Account` object which is just a view over UCAN delegations and an agent. That is convenience wrapper allowing us to add e.g. `.provision(space)` method (for provisioning spaces) and `.save()` method that will save account proofs into agent store. - `Account.list()` - Lists all account (sessions) client has in storage. It essentially goes over proofs and wraps ones that are "account authorization"s into `Account` objects. Above functionality should help us answer question whether user has already logged-in or not ? Previously we had no good way to answer such questions. ### Access This fixes issues around authorization flows, where requests would succeed but access was not gained. Issue was caused by imperfect heuristics that tried to match received delegation with a requested authorization. To address this problem `access/authorize` and `access/confirm` capabilities and their handler had been extended to capture request CIDs. This allows client polling for delegations to detect whether received delegation is corresponds to the request more precisely. I have added new `Access` module that attempts to do the client side work without much configurability. - `Access.request` - will send `access/authorize` request and return `PendingAccessRequest` object, which in turn could be used to poll for the response via `.claim()` method. `.claim()` internally uses `.poll()` until it gets the delegation, session expires or request is aborted. - `Access.claim` - sends `access/claim` request and returns `GrantedAccess` object that wraps received delegations. It also (just like `Account`) has `.save()` method which can be used to save delegations into client's store. ### Space I have added new `Space` module that has has `Space.generate()` function to generate new spaces, `Space.fromDelegation`, `Space.fromMnemonic` and more. General idea here also is that `client.createSpace()` will give you `OwnedSpace` object that has bunch of methods like `.toMnemonic`, `.createAuthorization`, `.createRecovery` etc... Notion of not registered spaces had been removed. If you create a space you have an object, you can save it in your client using `client.addSpace(await space. createAuthorization(agent))`. ### Attestation I have moved `ucan/attest` capability definition from `access` to `ucan` as former place was confusing and made no sense. --- The [account.test.js](https://github.com/web3-storage/w3up/pull/1059/files#diff-9a9133d8e343b56d7ef7bd18d01356b8ca7c630143b4687a51f683a5ebe1528f) attempts to capture authorization / provisioning flows from the event diagram. There is one unfortunate problem right now, that is new spaces added will not show in other devices unless you re-authorize. Fixing that requires storacha/ucanto#326 and some more work here. I think it's best to do it as a followup. --- I had to rebase because things upstream have changed, unfortunately I failed to do it cleanly so there is lot of strange changes which I don't exactly know how they happened. I'll try to remove undo them tomorrow --------- Co-authored-by: Alan Shaw <alan.shaw@protocol.ai>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #325