0063 XLS-63d: SignIn Transaction

[dangell7]

Title: SignIn Transaction
Type: Draft
Author:
[Denis Angell, XRPL-Labs (dangell7)
Affiliation: XRPL-Labs

Problem Statement

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.

Proposal

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.

Importantly, SignIn transactions are not intended to be submitted to the ledger.

New Transaction Type: SignIn

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.

The transaction has the following fields:

Field	Type	Required	Description
sfTransactionType	String	✔️	The type of transaction, which is "SignIn" for this proposal.
sfAccount	AccountID	✔️	The account of the user signing in.
sfData	VariableLength	✔️	The arbitrary data to be signed by the user, represented as a hex string.

Example SignIn transaction:

{
   "Account": "rExampleAccountAddress",
   "TransactionType": "SignIn",
   "Data": "48656C6C6F205852504C2041757468656E7469636174696F6E"
}

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.

[desimmons]

Is it possible that the arbitrary piece of data the user is being asked to sign is itself a transaction object?

[dangell7]

Good point, I could block anything starting with 1200 however submitting the tx_blob with this signature would result in a failure because the signature would not match the payload.

[desimmons]

I think a key feature of this transaction type should be that when creating it, the signer is guaranteed that no ledger modifications can be made. Not sure what the best way to achieve that is though

[ximinez]

A signature for a wrapper even around a fully valid transaction can't be a valid signature for that transaction. As long as there is any modification to the transaction, you'll get a completely different signature.

[shortthefomo]

This seems to be a common theme some of the more advanced wallets love to use, limiting what can be signed. eg Xaman if not mistaken also won't sign arbitrary random data as well.

Allowing this does then ask the question as to what's next?

But see the utility.

[brettmollin]

I see apps using an empty account_set transaction for this purpose.