First steps

[Keyrxng]

Pushing at this point to see if CI will allow for proper testing and because using the up to date safe-sdk needs some node package workarounds.

---

• I'm thinking this UI we create the passkey and safe (deploy as well potentially).

https://w3c.github.io/webauthn/#rp-id

For example, given a Relying Party whose origin is https://login.example.com:1337, then the following RP IDs are valid: login.example.com (default) and example.com, but not m.login.example.com and not com. Another example of a valid origin is http://localhost:8000, due to the origin being localhost.

By this logic registering the credential on safe.ubq.fi will allow it to be used on ubq.fi not pay.ubq.fi. So maybe the domain for this UI needs to be an extension of pay.ubq.fi?

Although looking at effective domains it seems that it would boil down to the domain > hostname so this will need tested.

• Then on pay.ubq.fi we just request the credential and either A) use that credential to interact with the SAFE directly B) Use the credential to create a throwaway signer which, if possible, should be able to claim a permit into the SAFE.

---

Basic QA showing account generation and persistence through localstorage only, no request logic implemented yet

oauth-webauthn-pk.mp4

[github-actions]

Unused dependencies (8)

Filename	dependencies
package.json	@keyrxng/webauthn-evm-signer @octokit/request-error @octokit/rest @safe-global/api-kit @safe-global/protocol-kit @safe-global/safe-core-sdk-types @supabase/supabase-js ethers

[0x4007]

When the CI passes I can test from mobile. The video looks like a pretty solid proof of concept though.

[0x4007]

I just tried a permit claim after reading this pull. I think it could be nice to make a simple typescript module that will self contain a couple of capabilities:

1. Render a "sign in" button
2. Cache the sign in.

"Signing in" would be using the on device biometric. I imagine the user only needs to do this once every so often, and then permit claims can be super seamless.

But if deterministic key generation is shaky then we will definitely need to use SAFE and all that infrastructure.

I hope that we can deterministically and reliably generate a signing key per device as a first checkpoint of this tech as it seems significantly simpler.

As a second checkpoint we can design the system to incentivize rotating keys, and making use of sponsored transactions (these require SAFE)

@Keyrxng rfc

[Keyrxng]

I hope that we can deterministically and reliably generate a signing key per device as a first checkpoint of this tech as it seems significantly simpler.

I'm confident we can and that we're a few strokes away from it.

If the package bundles signing in and caching then it'd be just the webauthn create/request/verify logic, GitHub sign in, an exported button and some localStorage calls.

Credentials are scoped to the domain they are being registered at so should it be generic in that sense and tie the credential only to the invoking domain or should I aim to create a credential from this package which is discoverable across other ubq.fi domains?

"Signing in" would be using the on device biometric. I imagine the user only needs to do this once every so often, and then permit claims can be super seamless.

The re-auth in the video I'm sure was only because I had been spamming login/logout for the last few minutes, if that's what this comment is based on. But yeah it is possible with both OAuth and WebAuthn to not have to re-auth every time.

following the premise in the first comment, they'd auth once via GitHub on safe.pay.ubq.fi and with the right setup the credential should be discoverable without user interaction on pay.ubq.fi (after an initial connect). I need to test to be sure but from what I've read it's doable across domains (I've only tried it on the same domain it was created but it works without re-prompting)

As a second checkpoint we can design the system to incentivize rotating keys, and making use of sponsored transactions

So right now the system should be aiming to make no use of SAFE? The first impl should create an EOA using our key derivation process and that is the 'user account', am I understanding you right there? If I am then are you suggesting too that the new module not contain any GitHub sign in logic and be just webauthn/keygen/caching?

[0x4007]

I think the first checkpoint is necessary to achieve for the second checkpoint. So for now perhaps it makes sense to get the standalone on-device signer part working before worrying about adding them to a SAFE (and associating the SAFE with a GitHub login.)

[Keyrxng]

Updated the video in the first comment, No creation just sign in with github > select passkey which will be the standard claim portal flow (there is a large pause here as it awaits the funding call but this is only for testing). Ofc they'll have to create a passkey on first visit as in the previous video.

• This UI is linked locally with the current salts branch of webauth-signing-key and is responsible for feeding OAuth details and the orgSalt to the module. The module handles passkey and private key generation.
• The module could be made to handle OAuth sign in too but I think it is unnecessary and that should be handled by the server of the UI and just the needed entropy points passed in.

I've had the faucet setup on Amoy and I'm sure the testnet is having a bad day today, I managed to get a few funding txs through but haven't managed more than one in the last hour of trying.

---

As it stands, we have a deterministic EOA generated using a 12 word seed phrase made up of 12 different data points. 3 of which come from the org salt, two of them are the same value but a different representation of it.

We are able to fund the newly created EOA with the faucet immediately upon creation (although this obviously is not the way it should be), we'll store the address in the DB and the user is able to use the /start command then it should fund them via a specific plugin or call to the worker in the permit plugin.

---

With this the basics are covered. Now it's a case of migrating this UI to a NextJS build and running everything on the server that we can. Then it's a matter of ensuring that things are as secure as I think that they are. Beyond that is minor sorts of things such as;

• Do we allow a user to enter custom name, displayName and id likely increasing security of the EOA but with a less streamlined registration flow or do we stick with public GH info and we determine the ID?
• Do we bypass some best practices and store sensitive things in the browser if it makes UX more streamlined?

While it's not out-of-the-question, it's likely preferable to avoid having to draw up smart contracts to facilitate things or to increase the security of ops isn't it?

---

[0x4007]

Updated the video in the first comment, No creation just sign in with github > select passkey which will be the standard claim portal flow (there is a large pause here as it awaits the funding call but this is only for testing). Ofc they'll have to create a passkey on first visit as in the previous video.

Exciting research and to see this!

You shouldn't need the sign in with GitHub button. This is out of scope until we start working with SAFEs (see my previous comment)

Instead just focus on creating the identity exclusively with webauthn. Each device should have separate signing keys so there no need to link any of them together using the GitHub user as the common link.

• This UI is linked locally with the current salts branch of webauth-signing-key and is responsible for feeding OAuth details and the orgSalt to the module. The module handles passkey and private key generation.

Why do we need org salt etc? Doesn't seem like the most lean approach.

• The module could be made to handle OAuth sign in too but I think it is unnecessary and that should be handled by the server of the UI and just the needed entropy points passed in.

I've had the faucet setup on Amoy and I'm sure the testnet is having a bad day today, I managed to get a few funding txs through but haven't managed more than one in the last hour of trying.

---

As it stands, we have a deterministic EOA generated using a 12 word seed phrase made up of 12 different data points. 3 of which come from the org salt, two of them are the same value but a different representation of it.

Let's generate individual private keys instead of mnemonics. Individual keys are easier to work with. I only think that mnemonics are a useful concept in the context of onboarding to one's first wallet (like metamask)

After that I always generate private keys instead. It's less overhead when writing scripts and such.

We are able to fund the newly created EOA with the faucet immediately upon creation (although this obviously is not the way it should be), we'll store the address in the DB and the user is able to use the /start command then it should fund them via a specific plugin or call to the worker in the permit plugin.

Cool and interesting. However with sponsored transactions we might not need to implement this But seems that the hard work is done already? If so then perhaps we can skip on the sponsored transactions idea?

---

With this the basics are covered. Now it's a case of migrating this UI to a NextJS build and running everything on the server that we can. Then it's a matter of ensuring that things are as secure as I think that they are. Beyond that is minor sorts of things such as;

• Do we allow a user to enter custom name, displayName and id likely increasing security of the EOA but with a less streamlined registration flow or do we stick with public GH info and we determine the ID?

Always focus on streamlining. It makes this feel a ton more futuristic for demos and presentations.

• Do we bypass some best practices and store sensitive things in the browser if it makes UX more streamlined?

Focus on streamlining. Security considerations should be minimal. Especially for permit claims there's really no stakes.

While it's not out-of-the-question, it's likely preferable to avoid having to draw up smart contracts to facilitate things or to increase the security of ops isn't it?

We can worry about this later but I don't have a vision for this currently.

---

If you require more entropy (I don't think this is necessary but I'll write this down here anyways) you can consider making an optional password as a salt. Although it would be much nicer to login to a wallet only after a face id biometric from my phone instead of dealing with passwords etc.

[Keyrxng]

You shouldn't need the sign in with GitHub button. This is out of scope until we start working with SAFEs

Removing GitHub auth strips us of entropy, side-steps an advised best practice and weakens the security of the derived EOA. @rndquu's comment highlights points of failure when using just the credential information to derive the EOA.

Why do we need org salt etc? Doesn't seem like the most lean approach.

const authEntropies = [
        `${displayName}-${id.toString()}-${name}`,
        `${userOauth.id}-${userOauth.ca}-${userOauth.iid}`,
        `${cred.id}-${cred.type}-${cred.rawId}`,
        `${wordlist.getWord(orgSaltIndexes[0])}-${wordlist.getWord(orgSaltIndexes[1])}-${wordlist.getWord(orgSaltIndexes[2])}`
    ]

It adds a third layer of entropy that a bad actor would need to hack to break the algorithm.

• Row 1 and 3 come from the credential:
  • Row 1: Decided when the credential is created by us or them.
  • Row 3: Comes from after the credential is created. id and rawId are the same value but one is a base64 string and the other a buffer/uint8array.

If we remove GitHub, the user needs to decide Row 1, as we can't identify them. This makes adding a password easier if we decide to go that route, but it makes things less streamlined and less secure because we'd need this input every time and we probably should not store it in the browser.

• Row 2: Our ultra-high entropy UUIDs (and a lesser effective date string) fill our word count quota and require a separate entity hack.

• Row 4: Our orgSalt, three words from a mnemonic-like salt derived using the UUIDs. This gives us 12 "words" for a single seed to derive the EOA pk from.

Let's generate individual private keys instead of mnemonics. Individual keys are easier to work with.

The EOA mnemonic will never be exported or exposed; we'll work only with PKs but treat our seed entropy as a 12 "word" mnemonic. This can be simplified by buffering all data points and hashing them instead of turning each into a word. I felt following the mnemonic standard is generally a good idea as it's the Web3 wallet standard, but it might be extra steps without added benefit.

---

If so then perhaps we can skip on the sponsored transactions idea?

For the first iteration, we should use the faucet. We don't have the infrastructure for sponsored transactions, nor are AA solutions mature enough yet, this way we can get a decent beta test going with V1. This approach also allows supporting funding on many chains easily, even after having a dedicated Safe sponsored transactions flow. Cloning the relayer onto other chains is straightforward; the only issue is testnet gas to test them but if it works on one chain, it'll work on any OpenZeppelin Defender supported chain. Keeping them all topped up could be automated with Defender as well.

Once SafeSDK releases passkey integration, we can have the EOA deploy a safe, bind the passkey to the safe, and stop using the EOA, depending on the SafeSDK passkey feature details, making moving into V2 seamless.

---

Focus on streamlining. Security considerations should be minimal.

The most streamlined approach is also the most secure in my eyes considering rows 1 and 3 of the auth entropy.

With OAuth:

• 5-click process spanning < 5 seconds:
  1. Click "Sign in with GitHub" (Supabase sessions live indefinitely and across multiple instances so once we have NextJs auth middleware set up I think this may be required very rarely depending on how we treat re-auth)
  2. Maybe click authorize Ubiquity (if first time or after a set period)
  3. Click webauthn method
  4. Click which passkey to use
  5. Enter pin/smile at your phone

Without OAuth:

• Ask for name, displayName, and password at registration.
• We could use conditionalMediation to discover user credentials.
• But we may need to re-enter all three if they aren't obtainable by the RP (us), or store them in the browser
• Our 12 point EOA seed becomes a 9 point seed, making the org salts 50% of the entropy if we make up the rest, and they seem to be a point of contention already so that doesn't seem right and given poor account security habits, brute-forcing user input isn't hard. A hacker would only need to discover our orgSalts to break the algorithm if they've socially engineered the rest.

[0x4007]

If we only need to login once with GitHub then maybe it is the best approach. Anyways I wasn't too concerned about security because each device should have its own fingerprint and that's pretty impossible to guess, I assume.

[Keyrxng]

each device should have its own fingerprint and that's pretty impossible to guess

You are right they couldn't outright guess and are very unlikely to brute force it, if you mean the credential ID etc. But the ID is not bulletproof as it can be MITD'ed and is potentially hackable through the user keychain storage through simswap, account hacked etc we are relying on the user adhering to good security practices like only using trusted networks, good account security and hygiene habits which is too fragile imo.

If we only need to login once with GitHub then maybe it is the best approach

The last project I built with Supabase auth/Nextjs I had indefinite sessions logged in until you physically logged out which we should advise I think but allow them the choice I guess

[0x4007]

each device should have its own fingerprint and that's pretty impossible to guess

You are right they couldn't outright guess and are very unlikely to brute force it, if you mean the credential ID etc. But the ID is not bulletproof as it can be MITD'ed

Couldn't we handle everything client side without GitHub? If it's all generated on device etc then no man in the middle is possible. Fully on device is my vision.

and is potentially hackable through the user keychain storage through simswap, account hacked etc we are relying on the user adhering to good security practices like only using trusted networks, good account security and hygiene habits which is too fragile imo.

Again if handled on device and no key exports allowed none of this is possible.

If we only need to login once with GitHub then maybe it is the best approach

The last project I built with Supabase auth/Nextjs I had indefinite sessions logged in until you physically logged out which we should advise I think but allow them the choice I guess

I wouldn't allow logging out. There's no benefit to it. One device should have one signing key.

[Keyrxng]

All-in-all, yes it's possible but then we need to get creative and use methods like fingerprinting which was shown to be less accurate than what we need it to be. Or other methods but each one is going to have it's list of cons and why not build with security in mind considering if one single account is hacked the reliability of the DAO and it's services sinks

At the bottom are some comments taken from the docs, obviously there are hundreds of other things to consider as well. The docs are extensive and the configurability produces lots of possibilities and ways to get things done so I've linked just what I felt was immediately relevant without overdoing it.

Things are geared towards preventing the credential from being accessed or used be another RP as well as the credential being resistant to doxxing someone. This is of no consequence to us, what matters is what data is potentially obtainable by any bad actor that makes up the seed for an EOA. If this is weak then everything else sort of falls flat so the more redundancy we add to this the better.

Alternatively, implement WebAuthn to-spec with a username/password flow and produce a truly random wallet seed then store that private key/seed in the database exposed only after being fully webauthn'd. Which is more akin to a traditional user system and we only need to protect the database entry for this user. But it also centralizes things significantly which is has it's own downsides

---

Couldn't we handle everything client side without GitHub? If it's all generated on device etc then no man in the middle is possible. Fully on device is my vision.

Again if handled on device and no key exports allowed none of this is possible.

MITM is still possible most notably during registration ceremonies but it's more than that. A lot of information is still potentially leakable so finding secure entropy becomes a problem if only using info obtainable from what the users authenticator returns

On-device uses the secure credential (privateKey) keypair to sign data sent by the client in order to return a credential with attestationData that we should be verifying against a database of user:publicKey:attestationMeta to verify that the object returned to us is verifiably our user based on the data we should be storing at registration and by verifying the signed data.

This is the intended flow of the WebAuthn API and apparently so long as the registration ceremony is handled securely then future auth ceremonies are MITM-resistant. But keep in mind, that may not be true for our use-case depending on what we use for entropy from the credential.

Because we are not storing these types of info and are relying on a derivation alg to generate our user system we need entropy from multiple locations that is independently verifiable to be our user, preferably that is itself an auth ceremony of some kind i.e username, password or OAuth which we can correlate to a user so we can identify them in order to create the credential and to derive their EOA.

---

The docs mention improved UX via local storage of the credential ID but that's only beneficial if you have a backend to query that publicKey against and have a traditional user system. We want to limit exposing that ID as much as possible.

• Because either we decide the user's name, displayName etc or they do. If they do it's likely easily brute-forced or socially engineered. (Yes we will use their github username etc but we have the entropy of multiple secure UUIDs because of it)

• Without these OAuth UUIDs and the already established user-identity we cannot create or derive a user account without seriously harming it's security and "futurism" of UX

• Our user system is far from traditional, all of these "accounts" are on-chain and can be accessed anywhere by anyone with the PK so do not benefit from passkeys after the fact.

The security concern for us is how easy is it to break the pk algorithm? Passkeys are inherently secure if done right i.e for a hacker to log into a traditional account they need to perform great feats to bypass biometrics etc and those traditional accounts are bound to their domain i.e X, or whatever and if used on a 3rd party site they go through OAuth and run the WebAuthn flow.

Our concern really is how easy is it to obtain the data used as entropy? Using easily and commonly exposed passkey IDs, name, displayName, or anything returned really from the authenticator alone is far too brittle. If it's user input it's likely easy to socially engineer or brute force. A hacker bypasses the inherent passkey protections if they are able to intercept an ID because it's a data point and it's not many steps from here to having EOA access (if they can breach our salt security)

---

https://www.w3.org/TR/webauthn/#sctn-sample-registration

The authenticator returns a response to the client, which in turn returns a response to the Relying Party script. If the user declined to select an authenticator or provide authorization, an appropriate error is returned.

If a new credential was created,

The Relying Party script sends the newly generated credential public key to the server, along with additional information such as attestation regarding the provenance and characteristics of the authenticator.

The server stores the credential public key in its database and associates it with the user as well as with the characteristics of authentication indicated by attestation, also storing a friendly name for later use.

The script may store data such as the credential ID in local storage, to improve future UX by narrowing the choice of credential for the user.

---

https://www.w3.org/TR/webauthn/#sctn-sample-authentication

... If an assertion was successfully generated and returned,

The script sends the assertion to the server.

The server examines the assertion, extracts the credential ID, looks up the registered credential public key in its database, and verifies the assertion signature. If valid, it looks up the identity associated with the assertion’s credential ID; that identity is now authenticated. If the credential ID is not recognized by the server (e.g., it has been deregistered due to inactivity) then the authentication has failed; each Relying Party will handle this in its own way.

The server now does whatever it would otherwise do upon successful authentication -- return a success page, set authentication cookies, etc.

---

https://www.w3.org/TR/webauthn/#sctn-security-considerations

Under the assumption that a registration ceremony is completed securely, and that the authenticator maintains confidentiality of the credential private key, subsequent authentication ceremonies using that public key credential are resistant to man-in-the-middle attacks.

---

https://www.w3.org/TR/webauthn/#sctn-privacy-attacks

Many aspects of the design of the Web Authentication API are motivated by privacy concerns. The main concern considered in this specification is the protection of the user’s personal identity, i.e., the identification of a human being or a correlation of separate identities as belonging to the same human being. Although the Web Authentication API does not use or provide any form of global identity, the following kinds of potentially correlatable identifiers are used:

• The user’s credential IDs and credential public keys.

These are registered by the WebAuthn Relying Party and subsequently used by the user to prove possession of the corresponding credential private key. They are also visible to the client in the communication with the authenticator.

• The user’s identities specific to each Relying Party, e.g., usernames and user handles.

These identities are obviously used by each Relying Party to identify a user in their system. They are also visible to the client in the communication with the authenticator.

• The user’s biometric characteristic(s), e.g., fingerprints or facial recognition data [ISOBiometricVocabulary].

This is optionally used by the authenticator to perform user verification. It is not revealed to the Relying Party, but in the case of platform authenticators, it might be visible to the client depending on the implementation.

• The models of the user’s authenticators, e.g., product names.

This is exposed in the attestation statement provided to the Relying Party during registration. It is also visible to the client in the communication with the authenticator.

• The identities of the user’s authenticators, e.g., serial numbers.

This is possibly used by the client to enable communication with the authenticator, but is not exposed to the Relying Party.

[0x4007]

One solution:

• Device fingerprinting + GitHub login.
• GitHub login has a SAFE associated.
• disposable signing keys generated from fingerprinting.
• we automatically add the rotated signer to the safe in the background on behalf of the user. Excluding the gas fee problem, we should be able to invoke transactions without prompting the user.

We can consider sponsoring these key rotations, but we might need to have a "master key" added to everybody's SAFEs to reset the signers. It can pay for the key rotation transactions.

It might seem a little convoluted but the end result is that signing transactions will be totally seamless for the user. No prompts/confirmations/modals for permit claims.

[Keyrxng]

If we don't want the user having to confirm anything, delegate proposals are out of the question unless we do have that master key to auth incoming proposals or have the infrastructure to build their EOA tied to their credentials and confirm incoming txs with their owner key (we'd need to listen to all our users Safes, unless they confirm via a Safe UI (afaik))

I was thinking something along these lines:

1. A HDNodeWallet has the ability to derive child nodes. These can be known when we create the EOA, we create the safe adding these child nodes as owners. No others are added beyond those and these nodes become the keys that we use on rotation and a random one out of 10 for example is returned via the alg. Threshold === 1 would be ideal here and probably just as safe as having > 1 and using one of the other nodes to confirm but safer with > 1. (not fully fleshed out as would still require full entropy)

2. We follow the WebAuthn spec closer and we have a database we can store and verify their credentials.

• Registering/Adding a new passkey is via GitHub (can happen on any device without a passkey). We could create a truly random wallet here too.
• Logging in is a simple passkey request we verify and create a truly random disposable wallet once authed
• We have a backend/API that adds the random wallet as a delegate then proposes and we are able to confirm it with their original ownerKey

3. We implement on-chain passkey verification via custom smart contracts (not smart accounts yet as that's out of scope for version 1 according to @rndquu) example

Two is the only route where we avoid having to deal with entropy all together but the security concern then shifts onto securing the db and acc data.

It might seem a little convoluted but the end result is that signing transactions will be totally seamless for the user. No prompts/confirmations/modals for permit claims.

I understand the vision clearly. Frictionless, streamlined UI with complete blockchain abstraction meaning no prompts, confirmations, or dealing with gas or funds.

One is more attractive to me personally than two but it makes adding multiple passkeys for the same EOA difficult because we don't have a point of reference for the original. You'd want to be able to login with GitHub on your mac then on your blackberry and be able to access the same Safe. Unless you can share your passkey between devices like icloud this becomes a problem.

Unless we store the user's credential in Supabase.auth.user.meta (if possible) I struggle to see how we'd solve this problem with the path we are on. Although I am focusing on this today so I'll see where I get with it.

P.S I think Gnosis-sponsored 5x-per-day or whatever it was is only via official Safe UIs. In our case we'll likely need to be the sponsor, may be wrong here.

---

https://help.safe.global/en/collections/9830-safe-mobile

https://help.safe.global/en/articles/40799-what-is-a-delegate-key

Safe owners can propose new transactions displayed in official Safe interfaces on web and mobile. An owner should sign the transaction to do so. Some teams need to enable non-owners to propose a transaction. Safe's "delegate key" feature allows to do that.

https://help.safe.global/en/articles/40829-how-signer-keys-are-stored

It is possible to confirm and reject Safe transactions with the Safe Mobile apps. As a prerequisite, you need to import an owner key by importing a seed phrase or directly a raw private key.

https://safe-transaction-mainnet.safe.global/ (API)

• /v2/delegates/
  Create a delegate for a Safe address with a custom label. Calls with same delegate but different label or
  signer will update the label or delegator if different.
  An EOA is required to sign the following EIP712 data:

• /v1/multisig-transactions/{safe_tx_hash}/confirmations/
  Add a confirmation for a transaction. More than one signature can be used. This endpoint does not support
  the use of delegates to make a transaction trusted.

---

As far as I can tell given the current state of Safe, a signing key is a "delegate key" and is supposed to be used for proposing transactions that are then confirmed by the owner key via an official Safe UI or via a non-delegate confirmation. Additionally, the signature threshold must be > 1 otherwise I assume that delegate key is going to actually propose and execute the tx, which is the same as just using the owner key.

https://docs.safe.global/sdk/protocol-kit
https://help.safe.global/en/articles/40791-how-to-add-an-owner-key-to-the-safe-such-that-you-can-transact-on-mobile-to-enable-transactions-on-mobile-ios-only

Adding an owner key seems to be more inline with what we need so it can actually confirm proposals but I think this may only be possible for iOS.

If that master key is used in all accounts doesn't that create another huge security issue and to overcome this we'd need another keypair algorithm? I don't think that's the way to go either.

---

Device fingerprinting + GitHub login.
disposable signing keys generated from fingerprinting.

Because fingerprinting, at least the package we looked at, was 40-60% accurate I don't think it's accurate enough to produce reliable results and it's a lesser passkey as they are always going to be device-bound, more reliable and more secure. So any fingerprinting other than passkeys should not be used in my opinion.

GitHub login has a SAFE associated.

That implies the EOA that deploys the Safe is derived purely from the GitHub login data. Subsequent attempts to derive this EOA would always require logging in or having that immediately available (so no localStorage allowed). And without WebAuthn to-spec it makes using it pretty useless if it's not used for entropy for the EOA because why even request it if we are not verifying or using it?

[Keyrxng]

I feel the length of my comments are beyond a joke and must be starting to annoy people. Is that the case, should I stop writing as much info or is it a good thing to have a lot of context?

I'm trying to get the relevant context across I have and it's hard to do considering the depth of what's involved but tell me to stfu if I'm over doing it and I'll reign it in

[ubiquity-os-deployer]

0fd5a17

2cd989a

[Keyrxng]

@0x4007 CI needs fixed in regards to OAuth because the allowed urls or redirect urls do not include a wildcard so that it allows auth on PR previews. Right now it redirects only to the official work.ubq.fi so you'll only be able to demo this if you checkout the branch locally.

I'm mistaken I'm thinking of Auth0, GitHub only allow one redirect url and I don't think you can use wildcards.

I could also point things to my supabase instance and setup my github app for OAuth and merge this so I have a fixed url to redirect to

[0x4007]

P.S I think Gnosis-sponsored 5x-per-day or whatever it was is only via official Safe UIs. In our case we'll likely need to be the sponsor, may be wrong here.

It might be easy to reverse engineer how they do it by looking at how the transaction is crafted on chain.

I feel the length of my comments are beyond a joke and must be starting to annoy people. Is that the case, should I stop writing as much info or is it a good thing to have a lot of context?

Writing is an art. Maximize signal to noise for any ubiquity communications. Share a ton of relevant context with your counterparties.

I didn't do the deep research on authentication technologies so it's optimal to share only the absolute essentials. I wouldn't be able to add value to anything beyond essentials. I don't need to know implementation details of all that you researched. I only need to know tradeoffs.

[0x4007]

Some potentially useful technologies:

• https://github.com/paulmillr/micro-eth-signer
• https://github.com/passwordless-id/webauthn

[Keyrxng]

Some potentially useful technologies:

• https://github.com/paulmillr/micro-eth-signer
• https://github.com/passwordless-id/webauthn

To summarize webauthn and EOA creation is fully implemented. We have server-side transactions fully abstracted away from the user. The faucet was a performance issue but with the new plugin that's resolved and will be removed

micro-eth-signer might be useful for where things are at in #2 I will check it out more later but the readme appears solid