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

feat!: allow attestations from did:mailto #326

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Gozala
Copy link
Collaborator

@Gozala Gozala commented Oct 30, 2023

Fixes #325

@Gozala Gozala requested review from travis and gobengo October 30, 2023 20:14
Gozala added a commit to storacha-network/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 web3-storage/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 <[email protected]>
})

// and creates an attestation using an authorization from
// the account account
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// the account account
// the account

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

Successfully merging this pull request may close these issues.

Support ucan/attest issued by did:mailto principal
3 participants