-
Notifications
You must be signed in to change notification settings - Fork 147
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
caip-122: Sign in With X (SIWx) #122
Conversation
We (Web3Auth) support this and have extended CAIP-74 in the same way in our implementation of Sign in With Web3 |
Co-authored-by: Bumblefudge <jcaballero@centre.io>
Co-authored-by: Bumblefudge <jcaballero@centre.io>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🏇
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in general LGTM - just one nit - we sometimes do MUST and sometimes must - I think we should always do MUST
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, @ligi -- squash my MUST commits and we're GTG
Co-authored-by: Bumblefudge <jcaballero@centre.io>
Co-authored-by: Bumblefudge <jcaballero@centre.io>
Co-authored-by: Bumblefudge <jcaballero@centre.io>
Co-authored-by: Bumblefudge <jcaballero@centre.io>
I implemented this a few days back - https://github.com/sk1122/sign-in-with-any-chain In the process of making it in compliance with CAIP-122 |
This may be relevant/helpful to you: |
This is very cool! In the current project I'm working on we are using a lot of sign/verify schemes with EVM but we want to be able to support any blockchain. @sk1122 @haardikk21 are you still working on your respective SDKs? |
SIWx (the library) is somewhat active still. We recently added starknet support to it. If you'd like to support new blockchains on it - feel free to make a PR. In the short term there's no plans for adding anything specifically on my side. |
@1swaraj I'm also interested in an update on your project |
caip: 122
title: Sign in With X (SIWx)
author: Haardik (@haardikk21), Sergey Ukustov (@ukstv)
discussions-to: #122
status: Draft
type: Standard
created: 2022-06-23
updated: 2022-07-06
Abstract
Sign in With X describes how blockchain accounts should authenticate and authorize with off-chain services by signing a chain-agnostic message parameterized by scope, session details, and security mechanisms (e.g. a nonce).
The goal of this specification is to define a chain-agnostic data model. When accompanied with chain-specific message forms and signing algorithms, along with chain-agnostic serialization format, this would allow for a self-custodied alternative to centralized identity providers, and improve interoperability across off-chain services for blockchain based authentication.
Motivation
With EIP-4361, we got introduced to Sign in With Ethereum - which standardized an Ethereum-focused workflow to authenticate Ethereum accounts on non-blockchain services. This work is meant to generalize and abstract the Sign in With Ethereum specification, thereby making EIP-4361 a specific implementation of this specification, to work with all blockchains.
Additionally, with CAIP-74 we got a way to represent a chain-agnostic capability object (OCAP) by placing EIP-4361 message into CACAO container.
With this specification, we hope to extend CAIP-74 to support blockchains other than Ethereum and allow for the creation of OCAPs in a chain-agnostic way.
Specification
Abstract Data Model
We start with declaring an abstract data model, which contains all the requisite information, metadata, and security mechanisms to authenticate and authorize with a blockchain account securely. We call this data model SIWX.
The data model MUST contain the following fields:
domain
dnsauthority
that is requesting the signing.address
uri
version
statement
\n
.nonce
issued-at
expiration-time
not-before
request-id
resources
\n
.signature
type
Namespace Specification
A namespace specification must provide:
type
strings that designate each signing algorithm,The signing algorithm must cover:
Examples
As a general suggestion for authors and implementers, the signing input should be based on string. The string should be human-readable, so that the signing represents a fully informed consent of a user.
The proposed string representation format, inspired from EIP-4361, should be as such:
As an example, EIP-4361 directly conforms to this data model. Since EIP-155 chains can request personal signatures (EIP-191) or contract signatures (EIP-1271) in plaintext, an example message to be signed could be
Other chains, however, for example Solana, cannot do plaintext signatures and require signing over raw bytes. As such, signing input for the data model could be created as a string, similar to EIP-4361 example above, that is represented as raw bytes. The signing input is then passed to Solana-specific signing algorithm. This should be defined in the Solana namespace for this CAIP specification.
Below is an example of the data model represented as a plain text similar Ethereum, and then converted to raw bytes.
Plain text representation:
Raw bytes (encoded as base64url for brevity).
Rationale
Backwards Compatibility
Not applicable.
References
Copyright
Copyright and related rights waived via CC0.
cc @oed @ukstv