User Signature

Previous << Provable Authn
Next >> How to develop blockchain game. Day1 - 基礎編Part1

Status

• Last Updated: June 1st 2021
• Stable: Yes
• Risk of Breaking Change: Low
• Compatibility: >= @onflow/fcl@0.0.71

Overview and Introduction

FCL対応ウォレットでデータを個人的に署名する

FCLは現在、signUserMessage()が新たに追加されおり、接続されたウォレットプロバイダーやユーザーのプライベートキーで署名されるサービスに対し、暗号化されていないメッセージデータを送信することができます。

アプリケーションまたはサービスは、Flow Blockchain上のユーザーの公開キーに対して署名を検証し、ユーザーがアカウントのプライベートキーを管理していることを証明することができます。

Use Cases

• Authentication: Cryptographically verify the ownership of a Flow account by signing a piece of data using a private key
• Improved Application Login
  • Increased security: Arguably more secure than proof of ownership by email/password
  • Simplified UX: No application password required
  • Increased privacy: No email or third party authentication service needed
• Message Validation: Assuring that a message sent or received has not been tampered with
• Multisig contracts
• Decentralised exchanges
• Meta transactions

Config and Authentication

前提条件として、FCLはWallet Provider's Authentication Endpointを指すように設定されています。追加の設定は必要ありません。

開発中（およびメインネット上で）は、Wallet Discovery UrlをウォレットプロバイダーのAuthentication Endpointに設定することで、FCLに直接ウォレットを使用するように設定できます。fclを次のように設定します。
config().put("discovery.wallet", "https://my-awesome-wallet-provider.com/fcl/authenticate")

Common Configuration Keysと追加情報は、How to Configure FCLでご覧いただけます。

1. ユーザーがアプリケーションのUIを介してウォレットプロバイダーとの認証を開始する
2. ウォレットがユーザーの識別情報を確認し、アプリケーション内で将来のユーザーの操作のためにFCLに設定するのに使用する情報を返信します
3. 認証レスポンスには、signUserMessage()で使用するuser-signatureサービスを含むプロバイダーのKey Servicesを含める必要があります

User Signature Service

ユーザー署名サービスは標準サービスであり、IFRAME/RPCまたはHTTP/POSTのメソッドを使用します。

user-signatureサービスはFCLから署名可能なメッセージを受け取り、CompositeSignaturesの配列またはnullをデータとして含む標準のPollingResponseを返します。

Approvedのステータスは、複合署名の配列をdataとし持つ要があります。

Declinedのステータスは、その理由を含む必要があります。

Pendingのステータスは、updatesサービスを含める必要があり、localを含めることができます。 IFRAME/RPC メソッドを使用するサービスは、iframe ではpendingが有効ではないため、approvedかdeclinedのレスポンスのみ可能です。

signUserMessage()がアプリケーションによって呼び出されると、FCLはサービスメソッドを使用して、署名可能メッセージをウォレットに送信する方法を決定します。

ウォレットは、正しいUserDomainTagを署名可能メッセージの先頭に追加し、メッセージをハッシュ化し、署名する役割を担います。

Signing Sequence

1. アプリケーションが署名サービスにメッセージを送信します。FCLは16進数文字列を期待しています
2. Wallet/Serviceは、必要なUserDomainTag（下記参照）とハッシュをメッセージにタグ付けし、アカウントキー上で指定されたsignatureAlgorithmを使用して署名します
3. Walletは、addr、keyId、signatureから構成される、利用できる複合署名を16進数文字列として作成します

UserDomainTag

UserDomainTagは、署名されたユーザースペースのペイロードのすべてのプレフィックスです。

メッセージをハッシュ化および署名する前に、ウォレットは指定のDOMAIN TAGを追加しなければなりません。

現在は "FLOW-V0.0-user"

ドメインタグはUTF-8バイトとしてエンコードされ、32バイトの合計長になるよう右にパディングされ、メッセージの先頭に追加されます。

これで署名は、Flowブロックチェーン上で検証することができます。以下は、fcl.verifyUserSignaturesの使用例を示しています。

/**
 * Verify a valid signatures for an account on Flow.
 *
 * @param {string} msg - A message string in hexadecimal format
 * @param {Array} compSigs - An array of Composite Signatures
 * @param {string} compSigs[].addr - The account address
 * @param {number} compSigs[].keyId - The account keyId
 * @param {string} compSigs[].signature - The signature to verify
 * @return {bool}
 *
 * @example
 *
 *  const isValid = await fcl.verifyUserSignatures(
 *    Buffer.from('FOO').toString("hex"),
 *    [{f_type: "CompositeSignature", f_vsn: "1.0.0", addr: "0x123", keyId: 0, signature: "abc123"}]
 *  )
 */

TL;DR Wallet Provider

• FCL に登録し、署名サービスエンドポイントを提供します。それ以上の設定は必要ありません。
• メッセージを受け取ると、ユーザーに承認または拒否を促します
• UserDomainTag をメッセージの先頭に追加し、ユーザーのキー上で指定された signatureAlgorithm を使用してメッセージをハッシュ化および署名します
• dataとして CompositeSignatures の配列と一緒に、もしくは拒否の場合は dataにnullを、そして reasonと一緒に、標準の PollingResponse を返します。

Last updated on Dec 2, 2024 by Brian Doyle

翻訳元

---

Previous << Provable Authn

Flow BlockchainのCadence version1.0ドキュメント (User Signature)

Next >> How to develop blockchain game. Day1 - 基礎編Part1