You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Passkeys do not allow credential reuse across relying parties (i.e. Dapps). If a Safe user wants to represent as single device as a Safe owner using passkeys in a way that they can control their Safe from multiple interfaces, this would require either:
Adding multiple owners to a Safe. In the context of n of m Safes where n > 1 this has negative security implications as a single device could technically produce more than one signature and cause the ownership policy to not work as intended
Use nested Safes, where the child Safe would have multiple WebAuthn signer owners, one for each passkey credential from each relying party. This has compatibility implications with 4337 which does not allow nested Safe structures.
As a work-around, a "passkey registry" Safe owner could be implemented including a mapping(bytes => mapping(address => PublicKey)) where the keys are the credential ID and the Safe account address (which is needed to make this an associated storage access in the context of 4337).
This would allow the following ownership structure:
flowchart TD
A{Safe} --> B(Web3Auth Owner)
A --> C{Passkey Registry}
C -->|app.safe.global| D(Webauthn Owner)
C -->|cow.swap| E(Webauthn Owner)
C -->|...| F(Webauthn Owner)
Loading
The expected outcome of this issue is a passkey registry PoC along with test(s) to demonstrate its functionality.
The text was updated successfully, but these errors were encountered:
Passkeys do not allow credential reuse across relying parties (i.e. Dapps). If a Safe user wants to represent as single device as a Safe owner using passkeys in a way that they can control their Safe from multiple interfaces, this would require either:
n
ofm
Safes wheren > 1
this has negative security implications as a single device could technically produce more than one signature and cause the ownership policy to not work as intendedWebAuthn
signer owners, one for each passkey credential from each relying party. This has compatibility implications with 4337 which does not allow nested Safe structures.As a work-around, a "passkey registry" Safe owner could be implemented including a
mapping(bytes => mapping(address => PublicKey))
where the keys are the credential ID and the Safe account address (which is needed to make this an associated storage access in the context of 4337).This would allow the following ownership structure:
The expected outcome of this issue is a passkey registry PoC along with test(s) to demonstrate its functionality.
The text was updated successfully, but these errors were encountered: