[要約] RFC 8905は、「payto」URIスキームに関する技術文書で、支払い情報を表現するための統一的な方法を定義しています。このスキームの目的は、さまざまな支払い方法やサービス間での互換性を高めることにあります。利用場面としては、電子メール、ウェブサイト、請求書などで支払い情報を簡単に共有し、ユーザーが支払いをスムーズに行えるようにすることが挙げられます。関連するRFCには、URIの一般的な構造を定義するRFC 3986などがあります。
Independent Submission F. Dold
Request for Comments: 8905 Taler Systems SA
Category: Informational C. Grothoff
ISSN: 2070-1721 Bern University of Applied Sciences
October 2020
The 'payto' URI Scheme for Payments
支払いのための「Payto」URIスキーム
Abstract
概要
This document defines the 'payto' Uniform Resource Identifier (URI) scheme for designating targets for payments.
このドキュメントは、支払いのターゲットを指定するための 'PayTo' Uniform Resource Identifier（URI）方式を定義しています。
A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications.
すべての支払いターゲットタイプのUnified URIスキームを使用すると、アプリケーションは支払い対象を表すURIとのユーザーインタラクションを提供し、新しい支払いシステムとアプリケーションの導入を簡素化します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係にRFCシリーズへの貢献です。RFCエディタは、この文書を裁量で公開することを選択し、実装または展開のためのその値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8905.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8905で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。
Table of Contents
目次
1. Introduction
1.1. Objective
1.2. Requirements Language
2. Syntax of a 'payto' URI
3. Semantics
4. Examples
5. Generic Options
6. Internationalization and Character Encoding
7. Tracking Payment Target Types
7.1. ACH Bank Account
7.2. Business Identifier Code
7.3. International Bank Account Number
7.4. Unified Payments Interface
7.5. Bitcoin Address
7.6. Interledger Protocol Address
7.7. Void Payment Target
8. Security Considerations
9. IANA Considerations
10. Payto Payment Target Types
11. References
11.1. Normative References
11.2. Informative References
Authors' Addresses
This document defines the 'payto' Uniform Resource Identifier (URI) [RFC3986] scheme for designating transfer form data for payments.
この文書は、支払いのための転送フォームデータを指定するための「PayTo」統一リソース識別子（URI）[RFC3986]を定義しています。
A 'payto' URI always identifies the target of a payment. A 'payto' URI consists of a payment target type, a target identifier, and optional parameters such as an amount or a payment reference.
'PayTo' URIは常に支払いのターゲットを識別します。「PayTo」URIは、支払いターゲットタイプ、ターゲット識別子、および金額または支払い基準などのオプションのパラメータで構成されています。
The interpretation of the target identifier is defined by the payment target type and typically represents either a bank account or an (unsettled) transaction.
ターゲット識別子の解釈は、支払いターゲットタイプによって定義され、通常は銀行口座または（未購入）トランザクションを表します。
A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications.
すべての支払いターゲットタイプのUnified URIスキームを使用すると、アプリケーションは支払い対象を表すURIとのユーザーインタラクションを提供し、新しい支払いシステムとアプリケーションの導入を簡素化します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the Augmented Backus-Naur Form (ABNF) of [RFC5234].
この文書では、[RFC5234]の拡張された背景 - Naur形式（ABNF）を使用しています。
payto-URI = "payto://" authority path-abempty [ "?" opts ]
opts = opt *( "&" opt )
opt-name = generic-opt / authority-specific-opt
opt-value = *pchar
opt = opt-name "=" opt-value
generic-opt = "amount" / "receiver-name" / "sender-name" /
"message" / "instruction"
authority-specific-opt = ALPHA *( ALPHA / DIGIT / "-" / "." )
authority = ALPHA *( ALPHA / DIGIT / "-" / "." )
'path-abempty' is defined in Section 3.3 of [RFC3986]. 'pchar' is defined in Appendix A of [RFC3986].
[PATH-ABEMPTY]は[RFC3986]のセクション3.3で定義されています。'Pchar'は[RFC3986]の付録Aで定義されています。
The authority component of a payment URI identifies the payment target type. The payment target types are defined in the "Payto Payment Target Types" registry (see Section 10). The path component of the URI identifies the target for a payment as interpreted by the respective payment target type. The query component of the URI can provide additional parameters for a payment. Every payment target type SHOULD accept the options defined in generic-opt. The default operation of applications that invoke a URI with the 'payto' scheme MUST be to launch an application (if available) associated with the payment target type that can initiate a payment. If multiple handlers are registered for the same payment target type, the user SHOULD be able to choose which application to launch. This allows users with multiple bank accounts (each accessed via the respective bank's banking application) to choose which account to pay with. An application SHOULD allow dereferencing a 'payto' URI even if the payment target type of that URI is not registered in the "Payto Payment Target Types" registry. Details of the payment MUST be taken from the path and options given in the URI. The user SHOULD be allowed to modify these details before confirming a payment.
支払いURIの権限コンポーネントは、支払い対象の種類を識別します。支払いターゲットの種類は、「PayTo Payte Target Types」レジストリに定義されています（セクション10を参照）。 URIのパスコンポーネントは、それぞれの支払いターゲットタイプによって解釈されるような支払いのターゲットを識別します。 URIのクエリコンポーネントは、支払いに追加のパラメータを提供できます。すべての支払いターゲットタイプは、Generic-optで定義されているオプションを受け入れる必要があります。 'PayTo'スキームでURIを呼び出すアプリケーションのデフォルト操作は、支払いを開始できる支払いターゲットタイプに関連付けられているアプリケーション（利用可能な場合）を起動する必要があります。同じ支払いターゲットタイプに対して複数のハンドラが登録されている場合、ユーザーはどのアプリケーションを起動するかを選択できます。これにより、複数の銀行口座（それぞれそれぞれの銀行の銀行業務アプリケーションを介してアクセス）を使用して、どのアカウントを支払うかを選択できます。アプリケーションは、そのURIの支払い対象のタイプが「PayTo Payment Tarait Types」レジストリに登録されていなくても、「PayTo」URIを参照できるようにする必要があります。支払いの詳細は、URIに記載されているパスとオプションから取得する必要があります。支払いを確認する前に、ユーザーはこれらの詳細を変更することを許可されている必要があります。
Valid Example:
有効な例：
payto://iban/DE75512108001245126199?amount=EUR:200.0&message=hello
Invalid Example (authority missing):
無効な例（権限がありません）：
payto:iban/12345
PayTo：IBAN / 12345.
Applications MUST accept URIs with options in any order. The "amount" option MUST NOT occur more than once. Other options MAY be allowed multiple times, with further restrictions depending on the payment target type. The following options SHOULD be understood by every payment target type.
アプリケーションは任意の順序でオプションを使用してURIを受け入れる必要があります。「金額」オプションは複数回発生してはいけません。他のオプションは複数回許可され、支払い対象の種類によってはさらに制限があります。以下のオプションは、すべての支払い対象の種類によって理解されるべきです。
amount: The amount to transfer. The format MUST be:
金額：転送する量。フォーマットは次のとおりです。
amount = currency ":" unit [ "." fraction ]
currency = 1*ALPHA
unit = 1*(DIGIT / ",")
fraction = 1*(DIGIT / ",")
If a 3-letter 'currency' is used, it MUST be an [ISO4217] alphabetic code. A payment target type MAY define semantics beyond ISO 4217 for currency codes that are not 3 characters. The 'unit' value MUST be smaller than 2^53. If present, the 'fraction' MUST consist of no more than 8 decimal digits. The use of commas is optional for readability, and they MUST be ignored.
3文字の「通貨」が使用されている場合は、[ISO4217]のアルファベットコードでなければなりません。支払いターゲットタイプは、3文字ではない通貨コードのためにISO 4217を超えてセマンティクスを定義することができます。'単位'値は2 ^ 53より小さくなければなりません。存在する場合、 'fraction'は8桁以下の10進数で構成されていなければなりません。コンマの使用は読みやすさのためのオプションであり、無視する必要があります。
receiver-name: Name of the entity that receives the payment (creditor). The value of this option MAY be subject to lossy conversion, modification, and truncation (for example, due to line wrapping or character set conversion).
受信者名：支払いを受け取るエンティティの名前（債権者）。このオプションの値は、損失の多い変換、修正、切り捨ての対象となる可能性があります（たとえば、ラインラッピングや文字セット変換により）。
sender-name: Name of the entity that makes the payment (debtor). The value of this option MAY be subject to lossy conversion, modification, and truncation (for example, due to line wrapping or character set conversion).
sender-name：支払いをするエンティティの名前（債務者）。このオプションの値は、損失の多い変換、修正、切り捨ての対象となる可能性があります（たとえば、ラインラッピングや文字セット変換により）。
message: A short message to identify the purpose of the payment. The value of this option MAY be subject to lossy conversion, modification, and truncation (for example, due to line wrapping or character set conversion).
メッセージ：支払いの目的を特定するための短いメッセージ。このオプションの値は、損失の多い変換、修正、切り捨ての対象となる可能性があります（たとえば、ラインラッピングや文字セット変換により）。
instruction: A short message giving payment reconciliation instructions to the recipient. An instruction that follows the character set and length limitation defined by the respective payment target type SHOULD NOT be subject to lossy conversion.
命令：受信者に支払い調整指示を与える短いメッセージ。それぞれの支払い対象タイプによって定義された文字セットおよび長さ制限に従う命令は、非可逆的な変換の対象とはならない。
Various payment systems use restricted character sets. An application that processes 'payto' URIs MUST convert characters that are not allowed by the respective payment systems into allowable characters using either an encoding or a replacement table. This conversion process MAY be lossy, except for the instruction field. If the value of the instruction field would be subject to lossy conversion, modification, or truncation, the application SHOULD refuse further processing of the payment until a different value for the instruction is provided.
さまざまな支払いシステムは、制限付き文字セットを使用しています。「PayTo」URIを処理するアプリケーションは、それぞれの支払いシステムによって許可されていない文字を符号化または交換テーブルを使用して許容文字に変換する必要があります。この変換プロセスは、命令フィールドを除いて損失がある場合があります。命令フィールドの値が可逆変換、修正、または切り捨ての対象となる場合、アプリケーションは命令の異なる値が提供されるまで支払いのさらなる処理を拒否する必要があります。
To avoid special encoding rules for the payment target identifier, the userinfo component [RFC3986] is disallowed in 'payto' URIs. Instead, the payment target identifier is given as an option, where encoding rules are uniform for all options.
支払い対象識別子の特別な符号化規則を回避するために、UserInfoコンポーネント[RFC3986]は「PayTo」URIで許可されていません。代わりに、支払いターゲット識別子はオプションとして与えられます。ここでは、エンコード規則はすべてのオプションに対して一様になっています。
Defining a generic way of tagging the language of option fields containing natural language text (such as "receiver-name", "sender-name", and "message) is out of the scope of this document, as internationalization must accommodate the restrictions and requirements of the underlying banking system of the payment target type. The internationalization concerns SHOULD be individually defined by each payment target type.
自然言語テキストを含むオプションフィールドの言語をタグ付けする一般的な方法を定義する（ "Receiver-Name"、 "Sender-Name"、および "Messageなど）国際化は制限に対応しなければならないため、この文書の範囲外です。支払い対象の種類の基礎となる銀行システムの要件。国際化の懸念は、各支払い対象の種類によって個別に定義されるべきです。
A registry of "Payto Payment Target Types" is described in Section 10. The registration policy for this registry is "First Come First Served", as described in [RFC8126]. When requesting new entries, careful consideration of the following criteria is strongly advised:
[RFC8126]で説明されているように、このレジストリの登録ポリシーは「最初に提供される」と同様に、このレジストリの登録ポリシーを「最初に提供」されています。新しいエントリを要求するときは、以下の基準を慎重に検討しています。
1. The description clearly defines the syntax and semantics of the payment target and optional parameters if applicable.
1. この説明では、該当する場合は、支払いターゲットとオプションのパラメータの構文とセマンティクスを明確に定義します。
2. Relevant references are provided if they are available.
2. 利用可能な場合には、関連する参照が提供されています。
3. The chosen name is appropriate for the payment target type, does not conflict with well-known payment systems, and avoids potential to confuse users.
3. 選択された名前は支払いターゲットの種類に適しており、周知の支払いシステムと矛盾しないため、ユーザーを混同する可能性が回避されます。
4. The payment system underlying the payment target type is not fundamentally incompatible with the general options (such as positive decimal amounts) in this specification.
4. 支払いターゲットタイプの基礎となる支払いシステムは、この仕様の一般的なオプション（正の小数など）と根本的に互換性がありません。
5. The payment target type is not a vendor-specific version of a payment target type that could be described more generally by a vendor-neutral payment target type.
5. 支払いターゲットタイプは、ベンダーニュートラル支払いターゲットタイプによってより一般的に説明され得る支払いターゲットタイプのベンダー固有のバージョンではありません。
6. The specification of the new payment target type remains within the scope of payment transfer form data. In particular, specifying complete invoices is not in scope. Neither are processing instructions to the payment processor or bank beyond a simple payment.
6. 新しい支払いターゲットタイプの指定は、支払い転送フォームデータの範囲内にあります。特に、完全な請求書を指定することは範囲内ではありません。単純な支払いを超えた支払いプロセッサまたは銀行に命令を処理していません。
7. The payment target and the options do not contain the payment sender's account details.
7. 支払いターゲットとオプションには、支払い送信者のアカウントの詳細が含まれていません。
Documents that support requests for new registry entries should provide the following information for each entry:
新しいレジストリエントリの要求をサポートする文書は、各エントリに次の情報を提供する必要があります。
Name: The name of the payment target type (case-insensitive ASCII string, restricted to alphanumeric characters, dots, and dashes).
名前：支払いターゲットタイプの名前（大文字と小文字を区別しないASCII文字列、英数字、ドット、ダッシュ）。
Description: A description of the payment target type, including the semantics of the path in the URI if applicable.
説明：該当する場合、URI内のパスのセマンティクスを含む、支払い先の種類の説明。
Example: At least one example URI to illustrate the payment target type.
例：支払いターゲットタイプを説明するための少なくとも1つの例のURI。
Contact: The contact information of a person to contact for further information.
連絡先：関連情報について連絡を取ります。
References: Optionally, references describing the payment target type (such as an RFC) and target-specific options or references describing the payment system underlying the payment target type.
参照：オプションで、支払いターゲットの種類（RFCなど）とターゲット固有のオプションまたは支払い対象の種類の基礎となる支払いシステムを記述する参照。
This document populates the registry with seven entries as follows (see also Section 10).
このドキュメントでは、次のように7つのエントリを使用してレジストリを入力します（セクション10も参照）。
Name: ach
名前：Ach.
Description: Automated Clearing House (ACH). The path consists of two components: the routing number and the account number. Limitations on the length and character set of option values are defined by the implementation of the handler. Language tagging and internationalization of options are not supported.
説明：自動クリアハウス（ACH）。パスは、ルーティング番号とアカウント番号の2つのコンポーネントで構成されています。オプション値の長さと文字セットの制限は、ハンドラの実装によって定義されます。言語のタグ付けとオプションの国際化はサポートされていません。
Example:
payto://ach/122000661/1234
Contact: N/A
連絡先：N / A
References: [NACHA], RFC 8905
参照：[Nacha]、RFC 8905
Name: bic
名前：BIC.
Description: Business Identifier Code (BIC). The path consists of just a BIC. This is used for wire transfers between banks. The registry for BICs is provided by the Society for Worldwide Interbank Financial Telecommunication (SWIFT). The path does not allow specifying a bank account number. Limitations on the length and character set of option values are defined by the implementation of the handler. Language tagging and internationalization of options are not supported.
説明：ビジネス識別子コード（BIC）。道はほんのBICで構成されています。これはバンク間のワイヤ転送に使用されます。BICSのレジストリは、世界中のInterbank Financial通信（SWIFT）の社会によって提供されています。パスは銀行口座番号を指定することを許可しません。オプション値の長さと文字セットの制限は、ハンドラの実装によって定義されます。言語のタグ付けとオプションの国際化はサポートされていません。
Example:
payto://bic/SOGEDEFFXXX
Contact: N/A
連絡先：N / A
References: [BIC], RFC 8905
参照：[BIC]、RFC 8905
Name: iban
名前：IBAN.
Description: International Bank Account Number (IBAN). Generally, the IBAN allows to unambiguously derive the associated Business Identifier Code (BIC) using a lookup in the respective proprietary translation table. However, some legacy applications process payments to the same IBAN differently based on the specified BIC. Thus, the path can consist of either a single component (the IBAN) or two components (BIC followed by IBAN). The "message" option of the 'payto' URI corresponds to the "unstructured remittance information" of Single Euro Payments Area (SEPA) credit transfers and is thus limited to 140 characters with character set limitations that differ according to the countries of the banks and payment processors involved in the payment. The "instruction" option of the 'payto' URI corresponds to the "end-to-end identifier" of SEPA credit transfers and is thus limited to, at most, 35 characters, which can be alphanumeric or from the allowed set of special characters, i.e., "+?/-:().,'". Language tagging and internationalization of options are not supported.
説明：国際銀行口座番号（IBAN）。一般に、IBANは、それぞれの独自の変換テーブルのルックアップを使用して関連するビジネス識別コード（BIC）を明確に導出することを可能にします。ただし、特定のBICに基づいて同じIBANに異なるIBANに支払いを処理します。したがって、経路は単一成分（IBAN）または2つの構成要素（BICに続くIBAN）のいずれかからなることができる。 「PayTo」URIの「メッセージ」オプションは、単一のユーロ支払い地域（SEPA）クレジット転送の「非構造化送金情報」に対応し、したがって、銀行の国々によって異なる文字セットの制限を有する140文字に制限される。支払いに関わる支払いプロセッサ。 「PayTo」URIの「命令」オプションは、SEPAクレジット転送の「エンドツーエンド識別子」に対応し、したがって、最大35文字、英数字または許容された特殊文字のセットから限定される。 、すなわち「？/ - :(）。、 '"。言語のタグ付けとオプションの国際化はサポートされていません。
Examples:
payto://iban/DE75512108001245126199
payto://iban/SOGEDEFFXXX/DE75512108001245126199
Contact: N/A
連絡先：N / A
References: [ISO20022], RFC 8905
参照：[ISO20022]、RFC 8905
Name: upi
名前：upi
Description: Unified Payment Interface (UPI). The path is an account alias. The amount and receiver-name options are mandatory for this payment target. Limitations on the length and character set of option values are defined by the implementation of the handler. Language tags and internationalization of options are not supported.
説明：Unified Payment Interface（UPI）。パスはアカウントエイリアスです。この支払い対象には、金額と受信者名のオプションが必須です。オプション値の長さと文字セットの制限は、ハンドラの実装によって定義されます。言語タグとオプションの国際化はサポートされていません。
Example:
payto://upi/alice@example.com?receiver-name=Alice&amount=INR:200
Contact: N/A
連絡先：N / A
References: [UPILinking], RFC 8905
参照：[upilinking]、RFC 8905.
Name: bitcoin
名前：Bitcoin.
Description: Bitcoin protocol. The path is a "bitcoinaddress", as per [BIP0021]. Limitations on the length and character set of option values are defined by the implementation of the handler. Language tags and internationalization of options are not supported.
説明：Bitcoinプロトコル。PATHは[BIP0021]のように、「BitcoinAddress」です。オプション値の長さと文字セットの制限は、ハンドラの実装によって定義されます。言語タグとオプションの国際化はサポートされていません。
Example:
payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu
Contact: N/A
連絡先：N / A
References: [BIP0021], RFC 8905
参照：[BIP0021]、RFC 8905
Name: ilp
名前：ilp.
Description: Interledger protocol (ILP). The path is an ILP address, as per [ILP-ADDR]. Limitations on the length and character set of option values are defined by the implementation of the handler. Language tagging and internationalization of options are not supported.
説明：Interledgerプロトコル（ILP）。PATHは、[ILP-ADDR]のようにILPアドレスです。オプション値の長さと文字セットの制限は、ハンドラの実装によって定義されます。言語のタグ付けとオプションの国際化はサポートされていません。
Example:
payto://ilp/g.acme.bob
Contact: N/A
連絡先：N / A
References: [ILP-ADDR], RFC 8905
参照：[ILP-ADDR]、RFC 8905
Name: void
名前：void.
Description: The "void" payment target type allows specifying the parameters of an out-of-band payment (such as cash or other types of in-person transactions). The path is optional and interpreted as a comment. Limitations on the length and character set of option values are defined by the implementation of the handler. Language tags and internationalization of options are not supported.
説明：「void」決算ターゲットタイプにより、帯域外払いのパラメータ（現金やその他の種類の取引など）を指定できます。パスはオプションであり、コメントとして解釈されます。オプション値の長さと文字セットの制限は、ハンドラの実装によって定義されます。言語タグとオプションの国際化はサポートされていません。
Example:
payto://void/?amount=EUR:10.5
Contact: N/A
連絡先：N / A
References: RFC 8905
参照：RFC 8905
Interactive applications handling the 'payto' URI scheme MUST NOT initiate any financial transactions without prior review and confirmation from the user and MUST take measures to prevent clickjacking [HMW12].
「PayTo」URIスキームを処理する対話型アプリケーションは、ユーザからの事前にレビューと確認なしに、財務トランザクションを開始してはならず、[HMW12]をクリックするのを防ぐための対策を講じてください。
Unless a 'payto' URI is received over a trusted, authenticated channel, a user might not be able to identify the target of a payment. In particular, due to homographs [unicode-tr36], a payment target type SHOULD NOT use human-readable names in combination with unicode in the target account specification, as it could give the user the illusion of being able to identify the target account from the URI.
「PayTo」URIが信頼できる認証されたチャネルを介して受信されない限り、ユーザーは支払いのターゲットを識別できない可能性があります。特に、ホモグラフのために、支払いターゲットタイプは、ターゲットアカウント仕様でUnicodeと組み合わせて人間が読める名前を使用しないでください。URI。
The authentication/authorization mechanisms and transport security services used to process a payment encoded in a 'payto' URI are handled by the application and are not in scope of this document.
「PayTo」URIでエンコードされた支払いを処理するために使用される認証/承認メカニズムおよびトランスポートセキュリティサービスは、アプリケーションによって処理され、この文書の範囲内ではありません。
To avoid unnecessary data collection, payment target types SHOULD NOT include personally identifying information about the sender of a payment that is not essential for an application to conduct a payment.
不要なデータ収集を避けるために、支払いターゲットタイプには、申請書が支払いを行うことが不可欠ではない支払いの送信者に関する情報を個人的に識別することを含みません。
IANA maintains the "Uniform Resource Identifier (URI) Schemes" registry, which contains an entry for the 'payto' URI scheme as follows. IANA has updated that entry to reference this document.
IANAは、次のように「PayTo」URIスキームのエントリを含む「Uniform Resource Identifier（URI）スキーム」レジストリを管理しています。IANAはこの文書を参照するためのそのエントリを更新しました。
Scheme name: payto
スキーム名：PayTo.
Status: provisional
ステータス：暫定
URI scheme syntax: See Section 2 of RFC 8905.
URIスキーム構文：RFC 8905のセクション2を参照してください。
URI scheme semantics: See Section 3 of RFC 8905.
URIスキームセマンティクス：RFC 8905のセクション3を参照してください。
Applications/protocols that use this scheme name: payto URIs are mainly used by financial software.
このスキーム名を使用するアプリケーション/プロトコル：PayTo URIは主に金融ソフトウェアによって使用されます。
Contact: Christian Grothoff <grothoff@gnu.org>
Change controller: Christian Grothoff <grothoff@gnu.org>
References: See Section 11 of RFC 8905.
参照：RFC 8905のセクション11を参照してください。
This document specifies a list of payment target types. It is possible that future work will need to specify additional payment target types. The GNUnet Assigned Numbers Authority (GANA) [GANA] operates the "Payto Payment Target Types" registry to track the following information for each payment target type:
このドキュメントは支払い対象の種類のリストを指定します。将来の作業では、追加の支払い対象タイプを指定する必要がある可能性があります。GNUNET割り当てられた番号局（GANA）[GANA]は、各支払い対象の種類について次の情報を追跡するために「PayTo Payte Target Types」レジストリを操作します。
Name: The name of the payment target type (case-insensitive ASCII string, restricted to alphanumeric characters, dots, and dashes)
名前：支払いターゲットタイプの名前（大文字と小文字を区別しないASCII文字列、英数字、ドット、ダッシュ）
Contact: The contact information of a person to contact for further information
お問い合わせ：詳細については、連絡先の連絡先情報
References: Optionally, references describing the payment target type (such as an RFC) and target-specific options or references describing the payment system underlying the payment target type
参照：オプションで、支払いターゲットタイプ（RFCなど）とターゲット固有のオプションまたは支払い対象の種類の基礎となる支払いシステムを記述する参照
The entries in the "Payto Payment Target Types" registry defined in this document are as follows:
このドキュメントで定義されている「PayTo Paynal Target Types」レジストリのエントリは次のとおりです。
+=========+=========+===========+
| Name | Contact | Reference |
+=========+=========+===========+
| ach | N/A | RFC 8905 |
+---------+---------+-----------+
| bic | N/A | RFC 8905 |
+---------+---------+-----------+
| iban | N/A | RFC 8905 |
+---------+---------+-----------+
| upi | N/A | RFC 8905 |
+---------+---------+-----------+
| bitcoin | N/A | RFC 8905 |
+---------+---------+-----------+
| ilp | N/A | RFC 8905 |
+---------+---------+-----------+
| void | N/A | RFC 8905 |
+---------+---------+-----------+
Table 1
表1
[ISO20022] International Organization for Standardization, "Financial Services - Universal financial industry message scheme", ISO 20022, May 2013, <https://www.iso.org>.
[ISO20022]国際標準化、「金融サービス - ユニバーサル金融業界メッセージスキーム」、ISO 20022、2013年5月、<https：//www.iso.org>。
[ISO4217] International Organization for Standardization, "Codes for the representation of currencies", ISO 4217, August 2015, <https://www.iso.org>.
[ISO4217]国際標準化機関、「通貨表現のためのコード」、ISO 4217、2015年8月、<https：//www.iso.org>。
[NACHA] Nacha, "2020 Nacha Operating Rules & Guidelines", 2019.
[Nacha] Nacha、「2020年ナッカー営業ルール＆ガイドライン」、2019年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、「Uniform Resource Identifier（URI）：汎用構文」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[unicode-tr36] Davis, M., Ed. and M. Suignard, Ed., "Unicode Technical Report #36: Unicode Security Considerations", September 2014.
[Unicode-Tr36] Davis、M.、ED。2014年9月、「Unicode Technical Report＃36：Unicode Technical Report＃36：Unicode Security Inchanations」。
[BIC] International Organization for Standardization, "Banking -- Banking telecommunication messages -- Business identifier code (BIC)", ISO 9362, December 2014, <https://www.iso.org>.
[BIC]国際標準化、「銀行業務用電気通信メッセージ - ビジネス識別コード（BIC）」、ISO 9362、2014年12月、<https://www.iso.org>。
[BIP0021] Schneider, N. and M. Corallo, "Bitcoin Improvement Proposal 21", September 2019, <https://en.bitcoin.it/w/ index.php?title=BIP_0021&oldid=66778>.
[BIP0021] Schneider、N.およびM. Corallo、2019年9月、2019年9月、<https：//en.bitcoin.it/w/ index.php？title = bip_0021＆oldid = 66778>。
[GANA] GNUnet e.V., "GNUnet Assigned Numbers Authority (GANA)", April 2020, <https://gana.gnunet.org/>.
[Gana] Gnunet E.V.「Gnunet Assigned Gurvers Authority（Gana）」、2020年4月、<https：//gana.gnunet.org/>。
[HMW12] Huang, L., Moshchuk, A., Wang, H., Schecter, S., and C. Jackson, "Clickjacking: Attacks and Defenses", 2012, <https://www.usenix.org/system/files/conference/ usenixsecurity12/sec12-final39.pdf>.
[HMW12] Huang、L.、Moshchuk、A.、Wang、H.、Schecter、S.、Clickjacking、「ClickJacking：攻撃：攻撃：/ defenses」、2012、<https：//ww.usenix.org/system/ files / conference / usenixsecurity12 / sec12-final39.pdf>。
[ILP-ADDR] Interledger, "ILP Addresses - v2.0.0", <https://interledger.org/rfcs/0015-ilp-addresses/>.
[ILP-ADDR] Interledger、 "ILPアドレス - v2.0.0"、<https://interledger.org/rfcs/0015-ilp-addresses/>。
[UPILinking] National Payments Corporation of India, "Unified Payment Interface - Common URL Specifications For Deep Linking And Proximity Integration", November 2017, <https://www.npci.org.in/sites/default/files/ UPI%20Linking%20Specs_ver%201.6.pdf>.
[Upilinkink]インドの国内支払株式会社、「統一された支払いインタフェース - 深連合と近接統合のための一般的なURL仕様」、2017年11月、<https://www.npci.org.in/sits/default/files/ upi％20階層％20SPECS_VER％201.6.pdf>。
Authors' Addresses
著者の住所
Florian Dold Taler Systems SA 7, rue de Mondorf L-5421 Erpeldange Luxembourg
Florian Dold Toler Systems SA 7、Rue de Mondorf L-5421 Erpeldangeルクセンブルク
Email: dold@taler.net
Christian Grothoff Bern University of Applied Sciences Quellgasse 21 CH-2501 Biel/Bienne Switzerland
クリスチャン・グローソフベルン応用科学大学クエルガス21 CH-2501 BIEL / BIENNE Switzerland
Email: christian.grothoff@bfh.ch