-
Notifications
You must be signed in to change notification settings - Fork 84
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
Sign-in with stacks #70
Open
friedger
wants to merge
4
commits into
stacksgov:main
Choose a base branch
from
friedger:sign-in-with-stacks
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
93 changes: 93 additions & 0 deletions
93
sips/sip-x sign-in-with-stacks/sip-x-sign-in-with-stacks.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,93 @@ | ||
# Preamble | ||
|
||
SIP Number: X | ||
|
||
Title: Sign In With Stacks | ||
|
||
Author: Friedger Müffke ([email protected]), Leo Pradel | ||
|
||
Consideration: Technical | ||
|
||
Type: Standard | ||
|
||
Status: Draft | ||
|
||
Created: 18 May 2022 | ||
|
||
License: CC0-1.0 | ||
|
||
Sign-off: | ||
|
||
Layer: Applications | ||
|
||
Discussions-To: https://github.com/stacksgov/sips | ||
|
||
# Abstract | ||
|
||
Web applications often provide their services only to authenticated users. In | ||
Web2, this was done through username and password or federated logins. In Web3, | ||
users can prove their digital identity by cryptographically signing that the | ||
user ownes the private key associated with that digital identity. | ||
|
||
SIP-018 defines the structure of signatures in general. This SIP defines the | ||
message format that web applications and similar off-chain services should use for their users to sign. | ||
|
||
# License and Copyright | ||
|
||
This SIP is made available under the terms of the Creative Commons CC0 1.0 Universal license, available at https://creativecommons.org/publicdomain/zero/1.0/ | ||
This SIP’s copyright is held by the Stacks Open Internet Foundation. | ||
|
||
# Introduction | ||
|
||
# Specification | ||
|
||
Sign-In with Stacks works as follows: | ||
|
||
1. The wallet presents the user with a structured message as defined in SIP-018. The message is a clarity value of type `tuple` with the properties described below. | ||
2. The signature is then presented to the server, which checks the signature’s validity and message content. | ||
3. Additional fields, including expiration-time, not-before, request-id, chain-id, and resources may be incorporated as part of authentication for the session. | ||
4. The server may further fetch data associated with the public key, the stacks address, or other data sources that may or may not be permissioned. | ||
|
||
## Properties | ||
|
||
| name | type | description | | ||
| --------------- | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| domain | (string-ascii 126) | Must be the application's domain name (max 80) followed by ` wants you to sign in with your Stacks account` | | ||
| address | string-ascii | The address of the signer in CAPI-10 format, including the chain id. | | ||
| statement | (string-ascii 80) | (optional) Describes the terms and conditions the user agrees to by using the application. | | ||
| uri | (string-ascii 80) | An RFC 3986 URI referring to the resource that is the subject of the signing (as in the subject of a claim). | | ||
| version | string | is the current version of the message, which MUST be X for this specification. | | ||
| nonce | (string-ascii 64) | randomized token used to prevent replay attacks, at least 8 alphanumeric characters. | | ||
| issued-at | (string-ascii 27) | The ISO 8601 datetime string of the current time. | | ||
| expiration-time | (string-ascii 27) | (optional) The ISO 8601 datetime string that, if present, indicates when the signed authentication message is no longer valid. | | ||
| not-before | (string-ascii 27) | (optional) The ISO 8601 datetime string that, if present, indicates when the signed authentication message will become valid. | | ||
| request-id | (string-ascii 64) | an system-specific identifier that may be used to uniquely refer to the sign-in request. | | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. request-id should be optional too @friedger |
||
| resources | (list 10 (string-ascii 80)) | (optional) A list of information or references to information the user wishes to have resolved as part of authentication by the relying party. They are expressed as RFC 3986 URIs | | ||
|
||
## Presentation and Localization | ||
|
||
TODO | ||
|
||
# Related work | ||
friedger marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Stacks Auth | ||
The Stacks authentication protocol uses a signed JWT with data similar to this SIP to authenticate the user to the app. However, this signed token contains data that should not be shared outside the app without the users' consent. | ||
|
||
## Ethereum EIP4361 | ||
|
||
[Ethereum EIP4361 standard](https://eips.ethereum.org/EIPS/eip-4361) | ||
|
||
## DID Auth | ||
|
||
[DID Auth Working | ||
group](https://identity.foundation/working-groups/authentication.html) | ||
|
||
[OpenID Connect for Verifiable Presentations](https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0.html) | ||
|
||
# Backwards Compatibility | ||
|
||
Not applicable | ||
|
||
# Activation | ||
|
||
TODO |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
One of the tricky things with authentication tokens like this is making sure they can't be replayed by someone who captures them. Is there a way we can mandate
expiration-time
or perhaps use atimeout
? Maybe we could use the Stacks blockchain height to determine how long a login token is good for (e.g. "This token expires at Stacks block height 12345").