3box/3id-connect

3ID account management application run in an iFrame

Welcome to 3Box Labs!

3Box Labs is a Web3 product studio that creates software to advance a more open, safe, and collaborative web. We are the inventors and a core maintainer of Ceramic, a decentralized network for composable data. Permissionless data composability will inevitably network all of the information on the web, transform the way we build applications, and connect users to their data, and each other, in new and exciting ways. To learn more about 3Box Labs, visit https://3boxlabs.com/.

Getting Started

👤 Visit Ceramic Network to build applications with composable data.

💬 Join Ceramic Community Discord to chat with the core team and developer community

👩‍💻 Explore our blog to learn more about Ceramic, comopsable data and Web3 - and sign up for our newsletter.

3id-connect's Issues

3id-connect module, external provider

These are changes for part of 3id-connect module consumed by libraries (3boxjs) to use 3id-connect and its provider.

• consume an eth or authprovider now (can pull most of the idea of an authprovider here)
• consumes rpc calls from iframe for authenticate, createLink, migrate
  - migrate, returns seeds for main and spaces
  - authenticate returns auth secret

Reconcile migration and existing keychain with new idw/ceramic

Ideal upgrade path still means supporting what is currently in 3boxjs (no upgrade needed to migrate)

some work on this earlier, likely best path is developing legacy and new idw/connect separately, and then they run as two logical services in iframe consuming their rpc calls, legacy calls continue to work, migration takes place there, migration will run and take current serialized state and add to cereamic, if migration has taken place, will map legacy rpc calls to new 'service'

Migration notification

likely want some screen to indicate why signing a 3box message for migration

Argent support not working

Argent should support EIP1271 so it should work with 3id-connect. However right now it's failing with the error message below.
Provider returned signature from different account than requested.

Refactor out migrations as modules

Not exactly clear how this will look, but only way maintain 3id-connect/idw as we go forwards and easily support the migration. There is a full a migration implemented later, this will be pulling out the partial migration and being able to flag it. may run one after another as well

Visual consent flow, design v1

This will be rough design implementation, structure, build, etc

Iframe deploy and pipeline

domain
build / ci pipeline
maybe not needed at first, but consider versioning iframe, may simplify upgrade in future

Review documentation to 3Box SDK and 3ID Connect

On Github and on docs site

Design screens for self.id + 3ID Connect

This includes screens for
[ ] 3ID Connect window
[ ] Self.ID application

Store state by did and linked accounts

allows lookup to see if seed/authsecret already exist for did and dont need to request user for it

Upgrade to 3box-js with updated did libraries

Support keychain

Additional calls to the iframe for adding / removing auth methods. Public caip-10 links needs to be signed locally.

Warning on compilation - production build fails

HI, I get this error

Using "3id-connect": "1.0.0-alpha.3"

How can it be solved so I can create a production build?

Error in Netlify

Thanks

Design remaining screens for full migration

Visual consent flow, design final

This will be to support full requirements (like mobile, screensize, remaining design requirements, etc)

Will need to coordinate to fine exact line between v1 and design final. As well as align on tooling and make sure v1 does serve this.

Error on running the example application in branch develop-ceramic

Error: Validation Error: data['ceramic://bagcqcerab3lf5regasdioanst6buv7qlbxtj3kfnq2uzajaaynxsxjdeoedq'] should be string
at Object.eval (utils.js:28)
at Generator.next ()
at fulfilled (utils.js:5)

Implement proper key derivation for account spaces

• Derive keys according to the 3IP spec for each space that is being requested.
• Allow user to see which spaces are being requested.
• Save consents to spaces along with the origin of the app.
• Send derived space seeds in the response.

Create Account Modal

no existing known dids
actions -> create account (in 3id) or link to other account (selfid)

3id-connect ceramic

move repos or split
clean up branches
split pipeline
move to app.3idconnect.org

Use internal Ceramic node

Remove branding, and other indications of 3box such as color

Polish consent module design

Full Migration Support from 3boxjs

Map our current auth/link support to the general authProvide interface. Need to be able to consume something like web3modal through multiple authproviders, or that needs to map to interface in some way. Persist seed in iframe.

Update default ceramic url to point to new environment in 3id-connect

Should point to our new deployment https://ceramic-clay.3boxlabs.com for the internal node.

Setup testing framework for wallets

We need a testing framework that makes sure that all of the wallets we currently support actually work.

@zachferland Seems like this is out of scope for now, but if you have some free time to plan out the work needed and scope for this that would set us up for a more stable system in the future.

Auth to parent window

external auth will make rpc call to parent window now
probably create link at same time

Spec & prio contract wallet flows in 3ID connecg

Link Account Modal

existing dids in 3id-connect
actions -> Link to current (if one, if multiple, latest or default to second action) or link to other (selfid)

Set up deployment

We need to figure out how to best deploy this. My initial take is just to deploy;

• master -> s3 bucket which account.3box.io points to
• develop -> s3 bucket which account-dev.3box.io points to

Hardening v1 release

Track issues and bugs here, in prep for default roll out, where it must work most everywhere for everyone. Expect to see some requirements not anticipated.

Issues:
cant inject iframe on page load with cdn dist and server side rendering

Migrate Profile data to IDX

Decide where to do the migration

UI (external provider)

Remove provider selection
Have good flow for signing outside iframe while still conveying info to user about what is happening

• can background still while signing, but may want to allow app to set z-index, so that other modal/iframe providers can overlay it, or this can become a small notification style overlay

Bug: Not working in safari

May also be issue in 3boxjs prior, tracking here, prior details in discord.

iframe service, external provider

Changes needed to module running in iframe

• rpc calls to parent window for migrate, authMethod/authenticate, createLink, return cached results if available, instead of making calls
• remove 3id from external auth, just consume seeds and cache

branding/design refactor

already changed, but needs review, and another round

IDW external provider flow and logic

First poc just used metamask, but needs to allow provider selection and maybe take some signal from develop through 3boxjs

3id-connect 3idv0 to 3idv1 migration

detect if existing 3idv0 and no ceramic
if migrate - sign additional 3box message, 3id-did-provider 3idv0 then add authSecret.
if not - continue as usual

most of the migration logic in 3id-did-provider, making this no more difficult than described above

Improve user experience flows

Less any design stuff, just getting clearer idea on flows need to first release and then full migration (control hooks in 3boxjs and iframe (extra rpc calls)). For example, once full migration, likely makes sense to have provider selection, signing within own page (then redirect back), since very infrequent action, needs more space/control and would make clear that keys manage in this account webpage/iframe. Then all the consent flows could be small less obtrusive module overlays. Best to think through now so that all control handlers are available in 3boxjs. (don't want to require 3boxjs update for full migration, just idw iframe)

Finalize 3ID Connect consent module design

UI Cleanups

Sena will make a list.

Design flows for linking accounts

Upgrade and test 3id-connect with the newest versions of ceramic, cids, etc.

Wasn't sure who made sense to take this on so I assigned it to both @PaulLeCam and @zachferland for now, although probably only one of them needs to pick this up. But now that release candidates of the ceramic core packages are out with upgraded ipfs, cids, and multiformats, it would be good to make sure that 3id connect works with them so we can start telling people who are having version incompatibility errors that they can upgrade to the release candidate and use it.

Simple Ceramic auth flow

Use beta version of IDW 2.0
Create a ceramic-http-client and connect to a clientside ceramic node
A signle auth message. Something like give this app access to your 3ID

UI (external auth & full migration)

• Migration screen for legacy 3Box accounts
• Remove branding
• Link a second account to a 3ID

Decouple Account auth logic from UI

Currently index.js and account.js is a bit to interlinked. The Account class can be refeactored in such a way where it takes functions that affects the UI when needed. Also I think that the postmsg-rpc functions should be specified fro within the Account class.

Maybe we should also rename the Account class to something like AccountProvider.

Support multiple accounts

most user handling is out of 3id-connect, but this just needs a bit of refactor for internal state to support requests for any
this doesnt include selecting, just handling diff dids depending on account link

TypeScript declarations

Would be nice to have TS declarations exposed.

Flows/Modal Full Migration from 3boxjs Support

Will likely need some additional ui hooks/events available from the connect service provider. May want an additional migration request/view to communicate why they need to sign every space.

Simplify assumption for now will any auth method you add, you will also create a link. This will likely need some more error handling for unhappy paths.

Also simplifying, wont have ui for adding other arbitrary links yet.

So ui/flows for now will mostly look the same for now.

build: when ci build fails do not run deploy step

Feature check for localstorage