Skip to content

Commit 1ea4774

Browse files
mvadariTapanito
andauthored
Add XLS-63d: 0063 XLS-63d: SignIn Transaction (#351)
Co-authored-by: Vito Tumas <5780819+Tapanito@users.noreply.github.com>
1 parent b77fd00 commit 1ea4774

File tree

1 file changed

+43
-0
lines changed

1 file changed

+43
-0
lines changed

XLS-0063-signin/README.md

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
<pre>
2+
xls: 63
3+
title: SignIn Transaction
4+
description: A dedicated transaction type for off-chain signing in with wallets
5+
author: Denis Angell (@dangell7)
6+
created: 2024-03-26
7+
status: Stagnant
8+
category: Community
9+
</pre>
10+
11+
# Problem Statement
12+
13+
In the XRPL ecosystem, certain wallets (Ledger) restrict users from signing arbitrary hex messages as a security measure to protect against malicious activities. This limitation poses a challenge for applications that require user authentication through signature verification. As a result, some applications resort to using low drop Payment transactions as a workaround for authentication, which is not an ideal solution and can lead to unnecessary ledger bloat. To provide a more secure and efficient method for user authentication, a dedicated transaction type for signing in is necessary.
14+
15+
# Proposal
16+
17+
We propose the introduction of a new transaction type called "SignIn" that includes only the common transaction fields along with an additional field, `sfData`, which is an arbitrary data hex field. This transaction type will be specifically designed for applications to authenticate users by allowing them to sign a piece of data that can be verified by the application.
18+
19+
> Importantly, `SignIn` transactions are not intended to be submitted to the ledger.
20+
21+
## New Transaction Type: `SignIn`
22+
23+
The `SignIn` transaction is a new transaction type that allows users to sign an arbitrary piece of data for the purpose of authentication. This transaction type is not intended to transfer any funds or alter the ledger state in any way, but rather to provide a verifiable signature that applications can use to authenticate users.
24+
25+
The transaction has the following fields:
26+
27+
| Field | Type | Required | Description |
28+
| ----------------- | -------------- | -------- | ------------------------------------------------------------------------- |
29+
| sfTransactionType | String | ✔️ | The type of transaction, which is "SignIn" for this proposal. |
30+
| sfAccount | AccountID | ✔️ | The account of the user signing in. |
31+
| sfData | VariableLength | ✔️ | The arbitrary data to be signed by the user, represented as a hex string. |
32+
33+
Example `SignIn` transaction:
34+
35+
```json
36+
{
37+
"Account": "rExampleAccountAddress",
38+
"TransactionType": "SignIn",
39+
"Data": "48656C6C6F205852504C2041757468656E7469636174696F6E"
40+
}
41+
```
42+
43+
In this example, the `Data` field contains a hex-encoded string that the user's wallet will sign. The application can then verify the signature against the user's public key to authenticate the user.

0 commit comments

Comments
 (0)