[要約] RFC 5941は、トランザクション詐欺データの共有に関する標準化されたプロトコルを提案しています。その目的は、金融機関や関連組織間での詐欺情報の共有を容易にし、詐欺行為の早期検出と防止を支援することです。
Internet Engineering Task Force (IETF) D. M'Raihi
Request for Comments: 5941 VeriSign
Category: Informational S. Boeyen
ISSN: 2070-1721 Entrust
M. Grandcolas
Grandcolas Consulting, LLC
S. Bajaj
VeriSign
August 2010
Sharing Transaction Fraud Data
トランザクション詐欺データの共有
Abstract
概要
This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling Working Group (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format.
このドキュメントでは、トランザクション詐欺（Throad）情報を交換するためのドキュメント形式について説明します。インシデントハンドリングワーキンググループ（インチWG）インシデントオブジェクト説明交換形式（IODEF）インシデントレポートドキュメント形式を拡張します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5941.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5941で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
2. Requirements Terminology ........................................5
3. Anatomy of a Transaction Fraud ..................................6
4. IODEF-Document Incident Class ...................................7
5. Thraud Record Class Definitions .................................8
5.1. FraudEventPaymentType Class ................................9
5.1.1. PayeeName ..........................................10
5.1.2. PostalAddress ......................................10
5.1.3. PayeeAmount ........................................10
5.2. FraudEventTransferType Class ..............................10
5.2.1. BankID .............................................11
5.2.2. AccountID ..........................................12
5.2.3. AccountType ........................................13
5.2.4. TransferAmount .....................................13
5.3. FraudEventIdentityType Class ..............................13
5.3.1. IdentityComponent ..................................13
5.4. FraudEventOtherType Class .................................14
5.4.1. OtherEventType .....................................15
5.4.2. OtherEventDescription ..............................15
5.5. AmountType Class ..........................................15
5.5.1. Class Contents .....................................15
5.5.2. Currency ...........................................15
5.6. AccountTypeType Class .....................................16
6. IODEF Profile for an Activity Thraud Report ....................16
6.1. Mandatory Components ......................................16
6.2. Recommended Components ....................................17
6.3. Deprecated Components .....................................17
7. IODEF Profile for a Signature Thraud Report ....................19
8. IODEF Additional Attribute Values ..............................19
8.1. Purpose Attribute .........................................19
9. Security Considerations ........................................19
10. IANA Considerations ...........................................21
10.1. Media Sub-Type ...........................................21
10.2. XML Namespace ............................................22
11. Conclusion ....................................................22
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................23
Appendix A. Thraud Record XML Schema...............................24
Appendix B. Example of a Thraud Report.............................26
Financial organizations and merchants that offer online access to their services frequently encounter fraud perpetrated against their customers' accounts. In their attempts to combat these frauds, the organizations and their law enforcement agencies could benefit greatly by sharing intelligence about fraud incidents and patterns with similar organizations and agencies. This specification standardizes a document format by which they can share such information. It is intended to facilitate multi-vendor interoperability between conformant components of an open fraud reporting framework.
サービスへのオンラインアクセスを提供する金融組織や商人は、顧客のアカウントに対して行われる詐欺に頻繁に遭遇します。これらの詐欺と戦う試みにおいて、組織とその法執行機関は、詐欺事件やパターンについて同様の組織や機関とのインテリジェンスを共有することで大きな利益を得ることができます。この仕様は、そのような情報を共有できるドキュメント形式を標準化します。これは、オープン詐欺報告フレームワークのコンフォーマントコンポーネント間のマルチベンダーの相互運用性を促進することを目的としています。
Information sharing can take place directly between financial organizations and merchants. However, the power of shared intelligence is multiplied many times if the information is gathered from multiple sources by a shared network, consolidated, and redistributed to participants.
情報共有は、金融組織と商人の間で直接行うことができます。ただし、共有ネットワークから情報が収集され、参加者に再配布された共有ネットワークによって情報が収集された場合、共有インテリジェンスの力は何度も増加します。
In this arrangement, incident reports submitted to the network are called "inbound reports", and reports issued by the network are called "outbound reports".
この取り決めでは、ネットワークに提出されたインシデントレポートは「インバウンドレポート」と呼ばれ、ネットワークによって発行されたレポートは「アウトバウンドレポート」と呼ばれます。
Inbound reports will be submitted using a push-style protocol (such as email or the Simple Object Access Protocol (SOAP)). Outbound reports will be distributed using either a push-style protocol or a request/response protocol (such as HTTP).
インバウンドレポートは、プッシュスタイルのプロトコル（電子メールまたはSimple Object Access Protocol（SOAP）など）を使用して送信されます。アウトバウンドレポートは、プッシュスタイルのプロトコルまたはリクエスト/応答プロトコル（HTTPなど）のいずれかを使用して配布されます。
Inbound reports identify the contributor of the report, as this information is essential in evaluating the quality of the information it contains and in contacting the source for the purpose of clarification. However, outbound reports commonly do not identify the original sources, as those sources may not wish to be identified to other subscribers. Such reports should, instead, identify the consolidator as the source.
インバウンドレポートは、この情報が含まれる情報の品質を評価し、明確化を目的としてソースに連絡するために不可欠であるため、レポートの貢献者を特定します。ただし、これらのソースは他の加入者に特定されることを望んでいない可能性があるため、アウトバウンドレポートは一般に元のソースを特定しません。そのようなレポートは、代わりに、コンソリダーターをソースとして特定する必要があります。
A report may describe a particular transaction that is known to be, or believed to be, fraudulent, or it may describe a pattern of behavior that is believed to be indicative of fraud. The former type of report is called an "activity report" and the latter a "signature report".
報告書は、不正であると考えられている、または考えられている特定の取引を説明する場合があります。または、詐欺を示すと考えられている行動のパターンを説明する場合があります。以前のタイプのレポートは「アクティビティレポート」と呼ばれ、後者は「署名レポート」と呼ばれます。
The schema defined herein extends the IODEF XML incident reporting schema [RFC5070].
本明細書で定義されているスキーマは、IODEF XMLインシデント報告スキーマ[RFC5070]を拡張します。
In Section 3, we introduce the actors in a typical transaction fraud. Fraud reporting by means of an IODEF-Document is described in Section 4. We define the elements of a Thraud Report in Section 5.
セクション3では、典型的な取引詐欺でアクターを紹介します。IODEF-Documentによる詐欺報告については、セクション4で説明します。セクション5のThroadレポートの要素を定義します。
In Section 6, we describe the Activity Thraud Report profile of the IODEF specification. In Section 7, the profile for a Signature Thraud Report is described. In Section 8, we define new attribute values for the IODEF Incident class. Security considerations are described in Section 9. Section 10 contains IANA considerations regarding the registration of the associated media sub-type and XML namespace identifier. The Appendices contain the complete XML schema and a sample Thraud Report.
セクション6では、IODEF仕様のアクティビティスローレポートプロファイルについて説明します。セクション7では、署名Throadレポートのプロファイルについて説明します。セクション8では、IODEFインシデントクラスの新しい属性値を定義します。セキュリティ上の考慮事項については、セクション9で説明します。セクション10には、関連するメディアサブタイプおよびXMLネームスペース識別子の登録に関するIANAの考慮事項が含まれています。付録には、完全なXMLスキーマとサンプルThroadレポートが含まれています。
Data elements in this document are expressed in Unified Modeling Language (UML) syntax [UML].
このドキュメントのデータ要素は、統一されたモデリング言語（UML）構文[UML]で表されます。
XML namespace prefixes are used throughout this document to stand for their respective XML namespaces, as follows.
XMLネームスペースプレフィックスは、次のように、このドキュメント全体でそれぞれのXML名空間を表すために使用されます。
iodef: urn:ietf:params:xml:ns:iodef-1.0
thraud: urn:ietf:params:xml:ns:thraud-1.0
xs: http://www.w3.org/2001/XMLSchema
xsi: http://www.w3.org/2001/XMLSchema-instance
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The actors in a typical transaction fraud are shown in Figure 1.
典型的な取引詐欺の関係者を図1に示します。
+--------------------------------------+
| Fraudsters |
| (collect & verify victim credentials |
| via phishing, malware, etc.) |
+--------------------------------------+
|
|recruit
|
| ----------------disburse profits-----------------
| | |
v v |
+-----------+ +--------------+ +-------+
| | | | | Fraud |
| |--Open Dest Acct-->| Financial |---->| Dest. |
| | | Organization | |Account|
| Fraud | +--------------+ +-------+
| Executors | ^ funds
| | | transfer
| | +--------------+ +-------+
| | | Victim's | | |
| |---Init Transfer-->| Financial |<-o--|Victim |
| | | Organization | | |Account|
+-----------+ +--------------+ | +-------+
v
+-----------+
| Fraud |
| Detection |
| Sensors |
|(realtime/ |
| offline) |
+-----------+
Figure 1. Transaction Fraud Elements
図1.トランザクション詐欺要素
Transaction fraud activities normally involve the following actors:
取引詐欺活動には通常、次のアクターが含まれます。
1. Fraudsters: individuals or organizations that collect victims' login credentials using a variety of means, including phishing and malware, and verify them (usually by attempting to log in to the victim's account). Then, the Fraudsters may either recruit Fraud Executors themselves or wholesale the victims' credentials to other Fraudsters, who will, in turn, recruit Fraud Executors.
1. 詐欺師：フィッシングやマルウェアを含むさまざまな手段を使用して、被害者のログイン資格情報を収集する個人または組織は、それらを検証します（通常、被害者のアカウントにログインしようとします）。その後、詐欺師は、詐欺執行者自身を募集するか、被害者の資格を他の詐欺師に卸売りします。
2. Fraud Executors: individuals who attempt the fraudulent funds transfer or payment. In the case of fraudulent funds transfers, an account at either the same financial organization as that of the victim or a different one is opened as the destination account for the fraudulent transfer. Alternatively, a fraudulent payment is made using a check or electronic transfer.
2. 詐欺執行者：詐欺的な資金の譲渡または支払いを試みる個人。不正な資金の転送の場合、被害者と同じ金融組織と同じ金融組織のアカウントまたは不正な譲渡の目的地アカウントとして開かれます。あるいは、小切手または電子転送を使用して、不正な支払いが行われます。
3. Victims of both credential theft and transaction fraud.
3. 資格盗難と取引詐欺の両方の犠牲者。
4. Financial organizations that hold the victim's and the Fraud Executor's accounts.
4. 被害者および詐欺執行者のアカウントを保有する金融組織。
5. Sensors at the financial organization that detect fraudulent transaction attempts, either in real-time or after the fact.
5. 詐欺的なトランザクションの試みをリアルタイムまたは事実のいずれかで検出する金融組織のセンサー。
The intention of Thraud reporting is to enable any organization that has detected fraud to share this information, either internally or with other potential victim organizations. The receiving organization can use this information, for example, to institute manual review of transactions initiated from suspicious IP addresses.
Throadの報告の意図は、詐欺を検出した組織が、内部的または他の潜在的な被害者組織とこの情報を共有できるようにすることです。受信組織は、この情報を使用して、疑わしいIPアドレスから開始されたトランザクションの手動レビューを実施することができます。
A Thraud Report SHALL be an instance of the IODEF-Document class, as defined in [RFC5070]. The report SHALL contain at least one Incident object, as defined in [RFC5070]. Each Incident object SHOULD contain information about a single fraud strategy. One Incident object MAY contain information about multiple fraudulent transactions that are consistent with the same fraud strategy. Each fraudulent transaction SHALL be described in a separate EventData object. The data model for the Incident class is defined in [RFC5070] and is repeated here, as Figure 2, for the reader's convenience.
[RFC5070]で定義されているように、ThroadレポートはIODEF-Documentクラスのインスタンスでなければなりません。このレポートには、[RFC5070]で定義されているように、少なくとも1つのインシデントオブジェクトが含まれているものとします。各インシデントオブジェクトには、単一の詐欺戦略に関する情報を含める必要があります。1つのインシデントオブジェクトには、同じ詐欺戦略と一致する複数の詐欺トランザクションに関する情報が含まれている場合があります。各詐欺トランザクションは、別のEventDataオブジェクトに記載されるものとします。インシデントクラスのデータモデルは[RFC5070]で定義されており、読者の便利さのために、図2のようにここで繰り返されます。
+-------------+
| Incident |
+-------------+
|ENUM |<>----------[ IncidentID ]
| purpose |<>--{0..1}--[ AlternativeID ]
|STRING |<>--{0..1}--[ RelatedActivity ]
| ext-purpose |<>--{0..1}--[ DetectTime ]
|ENUM |<>--{0..1}--[ StartTime ]
| lang |<>--{0..1}--[ EndTime ]
|ENUM |<>----------[ ReportTime ]
| restriction |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{1..*}--[ Contact ]
| |<>--{1..*}--[ EventData ]<>--[ AdditionalData ]
| |<>--{0..1}--[ History ]
| |<>--{1..*}--[ AdditionalData ]
+-------------+
Figure 2. Data Model of the Incident Class
図2.インシデントクラスのデータモデル
The AdditionalData abstract class is an extension point in the schema of the EventData class. Implementers SHALL include exactly one of the following objects in AdditionalData: FraudEventPayment, FraudEventTransfer, FraudEventIdentity, or FraudEventOther. Collectively, these are known as Thraud Records. The corresponding classes are defined by this specification in Section 5, below.
追加のData Abstractクラスは、EventDataクラスのスキーマの拡張ポイントです。実装者には、追加のDATAに次の1つのオブジェクトの1つを含めるものとします：詐欺師、詐欺師、詐欺師、または詐欺師。まとめて、これらはThroad Recordsとして知られています。対応するクラスは、以下のセクション5のこの仕様で定義されています。
The Thraud profile of the Incident class is defined in Sections 6 and 7, below.
インシデントクラスのスロープロファイルは、以下のセクション6および7で定義されています。
Thraud Records are expressed in XML. Therefore, the dtype attribute of the AdditionalData element SHALL be assigned the value "xml".
ThroadレコードはXMLで表されます。したがって、追加のDATA要素のDTYPE属性には、値「XML」が割り当てられます。
A payment Thraud Record SHALL be structured as shown in Figure 3. See also Section 5.1.
図3に示すように、支払いスローレコードは構造化されなければならない。セクション5.1も参照。
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>-----[ FraudEventPayment ]
+------------------+
Figure 3. The FraudEventPayment Extension
図3. FraudeventPayment拡張機能
A funds-transfer Thraud Record SHALL be structured as shown in Figure 4. See also Section 5.2.
図4に示すように、ファンド転送スローレコードは構造化されなければならない。セクション5.2も参照。
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>-----[ FraudEventTransfer ]
+------------------+
Figure 4. The FraudEventTransfer Extension
図4.詐欺的なトランスファー拡張
An identity Thraud Record SHALL be structured as shown in Figure 5. See also Section 5.3.
アイデンティティスローレコードは、図5に示すように構成されなければなりません。セクション5.3も参照してください。
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>-----[ FraudEventIdentity ]
+------------------+
Figure 5. The FraudEventIdentity Extension
図5.詐欺念の拡張機能
Other Thraud Records SHALL be structured as shown in Figure 6. See also Section 5.4. The FraudEventOther class has an open definition to act as a placeholder for event types that emerge in the future.
その他のThroadレコードは、図6に示すように構成されているものとします。セクション5.4も参照してください。詐欺師クラスには、将来出現するイベントタイプのプレースホルダーとして機能するオープンな定義があります。
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>----[ FraudEventOther ]
+------------------+
Figure 6. The FraudEventOther Extension
図6.詐欺師の拡張機能
The FraudEventPaymentType class is used to report payee instructions for a fraudulent payment or fraudulent payment attempt. Fraudsters sometimes use the same payee instructions (including the amount) for multiple fraudulent payment attempts. By reporting the payment instructions used in the fraud, other organizations may be able to detect similar fraudulent payment attempts to the same payee.
duraudeventPaymentTypeクラスは、不正な支払いまたは不正な支払いの試みについて、受取人の指示を報告するために使用されます。詐欺師は、複数の不正な支払いの試みに同じ受取人の指示（金額を含む）を使用することがあります。詐欺で使用される支払い指示を報告することにより、他の組織は、同じ受取人に同様の不正な支払いの試みを検出できる場合があります。
The structure of the FraudEventPaymentType class SHALL be as shown in Figure 7.
duraudeventPaymentTypeクラスの構造は、図7に示すように示すものとします。
+-------------+
| FraudEvent- |
| PaymentType |
+-------------+
| |<>--{0..1}--[ PayeeName ]
| |<>--{0..1}--[ PostalAddress ]
| |<>--{0..1}--[ PayeeAmount ]
+-------------+
Figure 7. The FraudEventPaymentType Class
図7. duraudeventPaymentTypeクラス
The contents of the FraudEventPaymentType class are described below. At least one component MUST be present.
duraudeventPaymentTypeクラスの内容については、以下に説明します。少なくとも1つのコンポーネントが存在する必要があります。
Zero or one value of type iodef:MLString. The name of the payee.
タイプIODEFのゼロまたは1つの値：mlString。受取人の名前。
Zero or one value of type iodef:MLString. The format SHALL be as documented in Section 2.23 of [RFC4519], which defines a postal address as a free-form multi-line string separated by the "$" character.
タイプIODEFのゼロまたは1つの値：mlString。この形式は、[RFC4519]のセクション2.23で文書化されているとおりであり、郵便アドレスを「$」文字で区切られた自由形式のマルチライン文字列として定義します。
Zero or one value of type thraud:AmountType. See Section 5.5.
ゼロまたはタイプのthroadの1つの値：lumenttype。セクション5.5を参照してください。
The FraudEventTransferType class is used to report the payee instructions for a fraudulent funds transfer or fraudulent funds transfer attempt. Fraudsters sometimes use the same payee instructions (including the amount) for multiple fraudulent funds transfer attempts. By reporting the funds transfer instructions used in the fraud, other organizations may be able to detect similar fraudulent funds transfer attempts to the same payee.
詐欺的なトランスファータイプクラスは、不正な資金譲渡または不正な資金転送の試みのための受取人の指示を報告するために使用されます。詐欺師は、複数の詐欺的な資金転送の試みに対して同じ受取人の指示（金額を含む）を使用することがあります。詐欺で使用される資金譲渡の指示を報告することにより、他の組織は、同じ受取人への同様の不正な資金転送の試みを検出できる可能性があります。
The structure of the FraudEventTransferType class SHALL be as shown in Figure 8.
詐欺的なトランスフェルタイプクラスの構造は、図8に示すとおりです。
+--------------+
| FraudEvent- |
| TransferType |
+--------------+
| |<>--{0..1}--[ BankID ]
| |<>--{0..1}--[ AccountID ]
| |<>--{0..1}--[ AccountType ]
| |<>--{0..1}--[ TransferAmount ]
+--------------+
Figure 8. The FraudEventTransferType Class
図8. FraudeventRansferTypeクラス
The contents of the FraudEventTransferType class are described below. At least one component MUST be present.
詐欺的なトランスフェルタイプクラスの内容については、以下に説明します。少なくとも1つのコンポーネントが存在する必要があります。
Zero or one value of type thraud:BankIDType. The structure of the BankIDType class SHALL be as shown in Figure 9. The contents SHALL be of type xs:string. The namespace attribute SHALL be of type xs:anyURI and SHALL identify the numbering system used to identify the bank or account.
ゼロまたはタイプのthroad：bankidtypeの1つの値。BankIdTypeクラスの構造は、図9に示すように、内容はXS：文字列のタイプでなければなりません。名前空間属性はタイプXS：Anyuriであり、銀行または口座を識別するために使用される番号付けシステムを特定するものとします。
+-------------------+
| BankIDType |
+-------------------+
| STRING |
| |
| STRING namespace |
+-------------------+
Figure 9. The BankIDType Class
図9. BankIdTypeクラス
A list of registered namespace identifiers is maintained at:
登録された名前空間識別子のリストは、次のように維持されます。
http://www.openauthentication.org/thraud/resources/bank-id-namespace.htm
The following namespace attribute values and their semantics are registered.
次の名前空間属性値とそのセマンティクスが登録されています。
One of the nine-digit Routing Numbers registered to the financial organization that holds the account, as administered by The American Bankers Association.
American Bankers Associationが管理するように、アカウントを保有する金融組織に登録された9桁のルーティング番号の1つ。
http://www.openauthentication.org/thraud/resources/bank-id-namespace.htm#american_bankers_association
The three-digit Institution Number registered to the financial organization that holds the account, as administered by The Canadian Payments Association.
カナダの支払い協会が管理するように、アカウントを保有する金融組織に登録された3桁の機関番号。
http://www.openauthentication.org/thraud/resources/bank-id-namespace.htm#canadian_payments_association
The corresponding AccountID represents the ISO 13616 International Bank Account Number [ISO13616-1:2007] in the "electronic form" (i.e., containing no spaces) that is assigned to the account, as administered by the Society for Worldwide Interbank Financial Telecommunication (SWIFT). The corresponding BankID xs:string value SHOULD be set to the null string. Receiving organizations SHOULD ignore the corresponding BankID value.
対応するアカウントIDは、「電子形式」（つまり、スペースが含まれていない）のISO 13616国際銀行口座番号[ISO13616-1：2007]を表します。）。対応するBankID XS：文字列値はnull文字列に設定する必要があります。受信組織は、対応するBankID値を無視する必要があります。
http://www.openauthentication.org/thraud/resources/bank-id-namespace.htm#iso13616_1_2007
The eight-character Bank Identifier Code [ISO9362:1994] registered to the financial organization that holds the account, as administered by SWIFT.
8文字の銀行識別子コード[ISO9362：1994]は、Swiftが管理するように、アカウントを保持する金融組織に登録しました。
http://www.openauthentication.org/thraud/resources/bank-id-namespace.htm#iso9362_1994
Other namespace values MUST be agreed upon among participants. Requests to register new values SHOULD be made at:
他の名前空間値は、参加者の間で合意する必要があります。新しい値を登録するリクエストは、次のように行う必要があります。
http://www.openauthentication.org/thraud/form/bank-id-namespace
Note that a single organization may be identified by more than one value for any one or more of these namespaces. Therefore, receiving organizations SHOULD take this into account in their matching procedure.
これらの名前空間の1つ以上に対して、単一の組織が複数の値によって識別される場合があることに注意してください。したがって、受信組織は、一致する手順でこれを考慮に入れる必要があります。
Zero or one value of type xs:string. The destination primary account number, as administered by the financial organization identified in the BankID element. In the case where the BankID namespace attribute value is "iso13616_1_2007", this element SHALL contain the International Bank Account Number in the "electronic form" (i.e., containing no spaces) that is assigned to the account. In all other cases, the element SHALL contain only the account number, as administered by the financial organization that holds the account. The reporting organization SHALL remove all prefixes that identify the country, bank, or branch.
タイプxsのゼロまたは1つの値：文字列。BankID要素で特定された金融組織によって管理されている宛先プライマリアカウント番号。BankID Namespace属性値が「ISO13616_1_2007」である場合、この要素には、アカウントに割り当てられた「電子形式」（つまり、スペースが含まれていない）に国際銀行口座番号が含まれます。他のすべてのケースでは、要素には、アカウントを保有する金融組織が管理するアカウント番号のみを含めるものとします。報告機関は、国、銀行、または支店を識別するすべてのプレフィックスを削除するものとします。
Zero or one value of type thraud:AccountTypeType. See Section 5.6.
ゼロまたはタイプのthroadの1つの値：counttypetype。セクション5.6を参照してください。
Zero or one value of type thraud:AmountType. See Section 5.5.
ゼロまたはタイプのthroadの1つの値：lumenttype。セクション5.5を参照してください。
The FraudEventIdentityType class is used to report a fraudulent impersonation or fraudulent impersonation attempt. By reporting the impersonation event, other potential victims may be able to detect similar fraudulent impersonation attempts.
詐欺的なIdentityTypeクラスは、不正ななりすましまたは不正ななりすましの試みを報告するために使用されます。なりすましイベントを報告することにより、他の潜在的な犠牲者が同様の不正ななりすましの試みを検出できる可能性があります。
The structure of the FraudEventIdentityType class SHALL be as shown in Figure 10.
FraudeventidentityTypeクラスの構造は、図10に示すように示すものとします。
+--------------+
| FraudEvent- |
| IdentityType |
+--------------+
| |<>--{1..*}--[ IdentityComponent ]
+--------------+
Figure 10. The FraudEventIdentityType Class
図10. duraudeventidentityTypeクラス
The contents of the FraudEventIdentityType class are described below.
duraudeventidentityTypeクラスの内容については、以下に説明します。
One or more values of type iodef:ExtensionType. This specification defines two extensions: EmailAddress and UserID.
タイプIODEFの1つ以上の値：ExtensionType。この仕様では、2つの拡張機能が定義されています：emailAddressとuserID。
In reporting an identity fraud event, the reporting institution MAY include the victim's email address. This SHALL be achieved by placing an object of type iodef:Email in the IdentityComponent object. It SHALL contain the email address of the intended fraud victim.
ID詐欺イベントの報告において、報告機関には被害者のメールアドレスが含まれる場合があります。これは、IDERCONPONENTオブジェクトに電子メールタイプIODEFのオブジェクトを配置することによって達成されるものとします。意図した詐欺被害者のメールアドレスが含まれているものとします。
The IdentityComponent.dtype attribute SHALL be set to the value "string".
IDComponent.dtype属性は、値「文字列」に設定する必要があります。
The IdentityComponent.meaning attribute SHALL be set to the value "victim email address".
IdentyComponent.mening属性は、値「被害者のメールアドレス」に設定されます。
In reporting an identity fraud event, the reporting institution MAY include the victim's user identifier. This SHALL be achieved by placing an object of type iodef:ExtensionType in the IdentityComponent object. The data type of the extension contents SHALL be xs:string. It SHALL contain the user identifier of the intended fraud victim.
ID詐欺イベントの報告において、報告機関には被害者のユーザー識別子が含まれる場合があります。これは、IDComponentオブジェクトにタイプIODEF：ExtensionTypeのオブジェクトを配置することによって達成されるものとします。拡張コンテンツのデータ型はxs：stringでなければなりません。これには、意図した詐欺被害者のユーザー識別子が含まれます。
The IdentityComponent.type attribute SHALL be set to the value "string".
IDComponent.Type属性は、値「文字列」に設定する必要があります。
The IdentityComponent.meaning attribute SHALL be set to the value "victim user id".
IdentyComponent.mening属性は、値「被害者ユーザーID」に設定されます。
The FraudEventOtherType class SHALL be used to report fraudulent events other than those detailed above, such as new event types that may emerge at some time in the future. This class enables such events to be reported, using this specification, even though the specific characteristics of such events have not yet been formally identified. By reporting the details of these unspecified event types, other institutions may be able to detect similar fraudulent activity.
詐欺師クラスは、将来のある時点で出現する可能性のある新しいイベントタイプなど、上記のイベント以外の不正イベントを報告するために使用されるものとします。このクラスは、このような仕様を使用して、そのようなイベントを報告できるようにしますが、そのようなイベントの特定の特性はまだ正式に特定されていません。これらの不特定のイベントタイプの詳細を報告することにより、他の機関が同様の不正行為を検出できる可能性があります。
The structure of the FraudEventOtherType class SHALL be as shown in Figure 11.
FraudeventotherTypeクラスの構造は、図11に示すとおりです。
+-------------+
| FraudEvent- |
| OtherType |
+-------------+
| |<>----------[ OtherEventType ]
| |<>--{0..1}--[ PayeeName ]
| |<>--{0..1}--[ PostalAddress ]
| |<>--{0..1}--[ BankID ]
| |<>--{0..1}--[ AccountID ]
| |<>--{0..1}--[ AccountType ]
| |<>--{0..1}--[ PayeeAmount ]
| |<>--{0..1}--[ OtherEventDescription ]
+-------------+
Figure 11. The FraudEventOtherType Class
図11.詐欺師クラス
Many of the components of the FraudEventOtherType class are also components of the FraudEventPaymentType or FraudEventTransferType classes. Their use in the FraudEventOtherType class is identical to their use in those classes. Therefore, their descriptions are not duplicated here. Only components that are unique to the FraudEventOtherType class are described below.
FraudeventotherTypeクラスのコンポーネントの多くは、詐欺師のコンポーネントまたは詐欺ventTransferTypeクラスのコンポーネントでもあります。FraudeventotherTypeクラスでのそれらの使用は、それらのクラスでの使用と同じです。したがって、それらの説明はここで複製されていません。詐欺剤クラスに固有のコンポーネントのみを以下に説明します。
One value of type xs:anyURI. A name that classifies the event.
タイプXSの1つの値：Anyuri。イベントを分類する名前。
A list of registered "other event type" identifiers is maintained at:
登録された「その他のイベントタイプ」識別子のリストは、次のように維持されます。
http://www.openauthentication.org/thraud/resources/other-event-type.htm
Requests to register new values SHOULD be made at:
新しい値を登録するリクエストは、次のように行う必要があります。
http://www.openauthentication.org/thraud/form/other-event-type
Zero or one value of type iodef:MLString. A free-form textual description of the event.
タイプIODEFのゼロまたは1つの値：mlString。イベントの自由形式のテキスト説明。
The AmountType class SHALL be as shown in Figure 12. It SHALL be used to report the amount of a payment or transfer fraud.
金額クラスは、図12に示すとおりです。支払いまたは譲渡詐欺の金額を報告するために使用されます。
+------------------+
| AmountType |
+------------------+
| DECIMAL |
| |
| STRING currency |
+------------------+
Figure 12. The AmountType Class
図12.量クラス
The contents of the AmountType class are described below.
金額クラスの内容については、以下に説明します。
REQUIRED DECIMAL. The amount of the payment or transfer.
必要な小数。支払いまたは譲渡の金額。
REQUIRED STRING. The three-letter currency code [ISO4217:2008].
必要な文字列。3文字通貨コード[ISO4217：2008]。
The AccountTypeType class SHALL be as shown in Figure 13. It SHALL be used to report the type of the destination account.
AccountTypeTypeクラスは、図13に示すように、宛先アカウントのタイプを報告するために使用するものとします。
+-----------------+
| AccountTypeType |
+-----------------+
| STRING |
| |
| STRING lang |
+-----------------+
Figure 13. The AccountTypeType Class
図13. AccountTypetypeクラス
Receiving organizations MUST be capable of processing contents containing spelling variations.
受信組織は、スペルのバリエーションを含むコンテンツを処理できる必要があります。
This section describes the profile of the IODEF Incident class for a compliant Activity Thraud Report.
このセクションでは、準拠のアクティビティスローレポートのIODEFインシデントクラスのプロファイルについて説明します。
A Thraud Report SHALL conform to the data model specified for an IODEF-Document in [RFC5070]. The following components of that data model, while optional in IODEF, are REQUIRED in a conformant Thraud Report.
Throadレポートは、[RFC5070]のIODEF-Documentに指定されたデータモデルに準拠するものとします。そのデータモデルの次のコンポーネントは、IODEFではオプションですが、コンフォーマントスローレポートでは必要です。
Receiving organizations MAY reject documents that do not contain all of these components. Therefore, reporting organizations MUST populate them all.
受信組織は、これらのすべてのコンポーネントを含まない文書を拒否する場合があります。したがって、報告組織はそれらすべてを埋め込む必要があります。
Except where noted, these components SHALL be interpreted as described in [RFC5070].
記載されている場合を除き、これらのコンポーネントは[RFC5070]に記載されているように解釈されるものとします。
Incident.Contact.ContactName - The name of the reporting organization. In case the reporting organization acts as a consolidator of reports from other organizations, elements of this class SHALL contain the name of the consolidator. Incident.Contact.Email - An email address at which the reporting organization may be contacted. Incident.Contact.Telephone Incident.EventData Incident.EventData.AdditionalData - SHALL contain exactly one Thraud Record.
Incide.Contact.ContactName-レポート組織の名前。報告組織が他の組織からのレポートの統合者として機能する場合、このクラスの要素には統合者の名前が含まれているものとする。Incide.Contact.Email-レポート組織に連絡できるメールアドレス。inscide.contact.telephone Incident.EventData Incide.EventData.AdditionAldata-ちょうど1つのThroadレコードが含まれているものとします。
Receiving organizations SHOULD be capable of processing the following components. However, they MUST NOT reject documents because they are either present or absent.
受信組織は、次のコンポーネントを処理できる必要があります。ただし、文書が存在するか欠席しているため、ドキュメントを拒否してはなりません。
If available, reporting organizations SHOULD include these components in Thraud Reports. Except where noted, these components SHALL be interpreted as described in [RFC5070].
利用可能な場合、レポート組織はこれらのコンポーネントをThroadレポートに含める必要があります。記載されている場合を除き、これらのコンポーネントは[RFC5070]に記載されているように解釈されるものとします。
Incident.Contact.Contact Incident.Contact.Contact.ContactName - The name of the reporting fraud analyst. Incident.Contact.Contact.Email - The email address of the reporting fraud analyst. Incident.Contact.Contact.Telephone - The telephone number of the reporting fraud analyst. Incident.EventData.Method Incident.EventData.Method.Description Incident.Assessment.Confidence Incident.Assessment.Impact Incident.Assessment.MonetaryImpact Incident.EventData.DetectTime Incident.EventData.StartTime Incident.EventData.EndTime Incident.EventData.Flow Incident.EventData.Flow.System Incident.EventData.Flow.System.Service Incident.EventData.Flow.System.Node.NodeName Incident.EventData.Flow.System.Node.Address
Incide.contact.contact Incide.contact.contact.contactname-報告不正アナリストの名前。Incide.contact.contact.email-レポート詐欺アナリストのメールアドレス。Incide.contact.contact.telephone-報告不正アナリストの電話番号。Incident.EventData.Method Incidence.EventData.Method.Description Incides.Assessment.ConfidentIction.Imptact Incides.Assessment.MonetaryImpact Incident.EventData.DatectIme.EventData.StartTime Incidity.EventData.Endata.EventData.Flow.Flow.Flow.Blow.vlow.flow.ventdata.ventdata.ventdata.ventdata..flow.system Incides.eventData.flow.system.Service Incides.eventData.flow.system.node.nodename Incides.eventdata.flow.system.node.address
This profile provides no guidance to receiving organizations on the proper processing of the following components. Therefore, the reporting organization has no assurance that the receiving organization will handle them in an appropriate manner and SHOULD NOT include them in a Thraud Report. However, receiving organizations MUST NOT reject reports that do contain these components.
このプロファイルは、次のコンポーネントの適切な処理に関する組織を受信するためのガイダンスを提供しません。したがって、レポート組織は、受信組織が適切な方法でそれらを処理することを保証しておらず、スローレポートにそれらを含めるべきではありません。ただし、受信組織は、これらのコンポーネントを含むレポートを拒否してはなりません。
Incident.DetectTime Incident.AlternativeID Incident.RelatedActivity Incident.StartTime Incident.EndTime Incident.ReportTime Incident.Description Incident.Method Incident.History Incident.AdditionalData Incident.ext-purpose Incident.IncidentID.instance Incident.Contact.Description Incident.Contact.RegistryHandle Incident.Contact.PostalAddress Incident.Contact.Fax Incident.Contact.TimeZone Incident.Contact.AdditionalData Incident.Contact.Contact.Description Incident.Contact.Contact.RegistryHandle Incident.Contact.Contact.PostalAddress Incident.Contact.Contact.Fax Incident.Contact.Contact.TimeZone Incident.Contact.Contact.AdditionalData Incident.Contact.ext-role Incident.Contact.ext-type Incident.Contact.Contact.ext-role Incident.Contact.Contact.ext-type Incident.EventData.Method.Reference Incident.EventData.Method.Reference.Description Incident.EventData.Method.AdditionalData Incident.EventData.Method.Reference.URL Incident.Assessment.TimeImpact Incident.Assessment.AdditionalData Incident.Assessment.Impact.type Incident.EventData.Description Incident.EventData.Contact Incident.EventData.Assessment Incident.EventData.Expectation Incident.EventData.Record Incident.EventData.EventData Incident.EventData.Flow.System.OperatingSystem Incident.EventData.Flow.System.Counter Incident.EventData.Flow.System.Description Incident.EventData.Flow.System.AdditionalData Incident.EventData.Flow.System.ext-category Incident.EventData.Flow.System.Node.Location Incident.EventData.Flow.System.Node.DateTime Incident.EventData.Flow.System.Node.NodeRole Incident.EventData.Flow.System.Node.Counter Incident.EventData.Flow.System.Node.Address.ext-category Incident.EventData.Flow.System.Service.ProtoType Incident.EventData.Flow.System.Service.ProtoCode Incident.EventData.Flow.System.Service.ProtoField Incident.EventData.Flow.System.Service.Application
Incide.contact.postalAddress Inciss.contact.fax Inciss.contact.timezone Incident.contact.adtitionaldata Incides.contact.contact.contact.description Incides.contact.registryhandle Incides.contact.contact.contact.postalAddress Incide.contact.faxact.faxのインシデント。contact.contact.timezone Incident.contact.contact.adtitionaldata Incides.contact.ext-role Incides.contact.ext-type Incise.contact.contact.ext-role Incides.contact.contact.ext-type Incisity.EventData.METHOD。参照Incission.EventData.Method.Reference.Description Incide.EventData.Method.AdditionAldata Incident.EventData.Method.Reference.url Incides.Assessment.TimeImpact Incides.Assessment.AdditionAldata IncidenT.Assessment.Impact.Type Incident.EventData.Description Incides.EventData.Contact Incident.EventData.Assessment Incide.EventData.Expectation Incides.EventData.EventData.EventData.EventData Incidity.EventData.Flow.system.System.System.systemtentingStemstiontingTiontingStemsTimingTingStingStingStingStingStingStingStingStingStingsIntingStemsTingSystem。flow.system.counter Incide.eventData.flow.system.description Incide.eventData.flow.system.adtionaldata Incides.eventdata.flow.system.ext-category Incidenta.flow.system.node.location Incident.Eventdata.flow.system.node.dateTime Incident.eventData.flow.system.node.noderole Incident.EventData.flow.system.node.counter Incides.eventData.flow.system.node.address.ext-category Incidity.eventdata.flow.system.service.prototype Incide.eventData.flow.system.service.protocode Incise.eventdata.flow.system.service.protofield Incission.EventData.flow.system.service.Application
A Signature Thraud Report SHALL convey information about the behavior associated with fraudulent events, rather than reporting the details of the specific events themselves.
Signature Throadレポートは、特定のイベント自体の詳細を報告するのではなく、不正行為に関連する行動に関する情報を伝えなければなりません。
Sharing Signature Thraud Reports helps receiving organizations to detect suspicious behavior in their own systems.
署名のThroadレポートを共有すると、組織が自分のシステムで疑わしい行動を検出するのに役立ちます。
A Signature Thraud Report SHALL conform to the profile described in Section 6.
署名スローレポートは、セクション6で説明されているプロファイルに準拠するものとします。
Additional IODEF attribute standard values are defined here.
追加のIODEF属性標準値はここで定義されています。
The following additional values are defined for the Incident.purpose attribute.
インシデントに対して次の追加値が定義されています。目的属性。
Add - The enclosed Thraud Record values SHOULD be added to the corpus by the receiving organization.
追加 - 囲まれたThroadレコード値は、受信組織によってコーパスに追加する必要があります。
Delete - The enclosed Thraud Record types SHOULD be deleted from the corpus by the receiving organization.
削除 - 囲まれたThroadレコードタイプは、受信組織によってコーパスから削除する必要があります。
Modify - The enclosed Thraud Record values SHOULD replace the corresponding values in the corpus. Where no corresponding types currently exist in the corpus, the enclosed values SHOULD be added to the corpus by the receiving organization.
変更 - 囲まれたThroadレコード値は、コーパス内の対応する値を置き換える必要があります。現在、対応するタイプがコーパスに存在しない場合、囲まれた値を受信組織によってコーパスに追加する必要があります。
This document describes a document format for exchanging information about successful or attempted transaction and authentication fraud incidents. The information is intended to be used to improve the effectiveness of participants' fraud detection and prevention programs. The effectiveness of such programs depends critically on the accuracy, reliability, confidentiality, and timeliness of both the information and the participants in its exchange. Threats to accuracy, reliability, and confidentiality include (but are not limited to) those described here.
このドキュメントでは、成功したトランザクションおよび認証詐欺事件に関する情報を交換するためのドキュメント形式について説明します。この情報は、参加者の詐欺検出および予防プログラムの有効性を改善するために使用することを目的としています。このようなプログラムの有効性は、情報とその交換の参加者の両方の正確性、信頼性、機密性、および適時性に大きく依存します。正確性、信頼性、および機密性に対する脅威には、ここで説明されているものが含まれます（ただし、これらに限定されません）。
Fraudsters may attempt to introduce reports that delete or modify incident information in the corpus. Therefore, origin authentication MUST be employed. Human review SHOULD be performed prior to implementing modifications to the corpus.
詐欺師は、コーパス内のインシデント情報を削除または変更するレポートを導入しようとする場合があります。したがって、Origin Authenticationを使用する必要があります。コーパスの変更を実装する前に、人間のレビューを実行する必要があります。
Fraudsters may attempt to interrupt or redirect submissions, thereby preventing the sharing of intelligence concerning their fraud strategies. Therefore, authenticated receipts SHOULD be employed.
詐欺師は、提出物を中断またはリダイレクトしようとする可能性があり、それにより、詐欺戦略に関する情報の共有を防止する場合があります。したがって、認証された領収書を採用する必要があります。
Fraudsters may attempt to impersonate legitimate submitters, thereby poisoning their reputations and rendering ineffective their future submissions. Origin authentication MUST be used to ensure that the sources of reports are properly identified.
詐欺師は、合法的な提出者になりすまし、それによって彼らの評判を中毒し、将来の提出を効果的に提供しようとするかもしれません。Origin Authenticationを使用して、レポートのソースが適切に識別されることを確認する必要があります。
Fraudsters that can view incident reports may adapt their fraud strategies to avoid detection. Therefore, reports MUST be protected by confidentiality services including transport encryption and access control.
インシデントレポートを表示できる詐欺師は、検出を避けるために詐欺戦略を適合させる可能性があります。したがって、レポートは、輸送暗号化やアクセス制御を含む機密保持サービスによって保護する必要があります。
In order to prevent inadvertent disclosure of incident data, incident reports SHOULD be encrypted while in storage.
インシデントデータの不注意な開示を防ぐために、保管中にインシデントレポートを暗号化する必要があります。
The submitter of an incident report may incorrectly identify legitimate activity as a fraud incident. This may lead to denial of service by a receiving organization that relies on the report or information derived from the report. Receiving organizations SHOULD operate a reputation service, in which the reliability of the information from particular sources is assessed and tracked and subsequent reports are weighted accordingly. The source of reports MUST be authenticated. Receiving organizations SHOULD use reports to step up authentication assurance, rather than simply denying service.
インシデントレポートの提出者は、正当な活動を詐欺事件として誤って特定する場合があります。これは、レポートから派生したレポートまたは情報に依存する受信組織によるサービスの拒否につながる可能性があります。受信組織は評判サービスを運営する必要があります。このサービスでは、特定のソースからの情報の信頼性が評価および追跡され、それに応じてその後のレポートが重み付けされます。レポートのソースを認証する必要があります。受信組織は、単にサービスを拒否するのではなく、レポートを使用して認証保証を強化する必要があります。
A receiving organization may misuse a Thraud Report to deny service, resulting in a loss for a legitimate user. If such a user were to learn the identity of the source of the information that led to the denial of service, then that source may become implicated in any resulting claim for compensation. This, in turn, may discourage reporting organizations from participating in intelligence sharing. Therefore, original sources SHOULD NOT be identified in consolidated reports.
受信組織は、スローレポートを誤用してサービスを拒否し、合法的なユーザーの損失をもたらす可能性があります。そのようなユーザーがサービスの拒否につながった情報のソースの身元を学習した場合、そのソースは、補償の結果として生じる請求に関係する可能性があります。これにより、報告組織がインテリジェンス共有に参加するのを思いとどまらせる可能性があります。したがって、統合レポートで元のソースを特定しないでください。
Any origin authentication and data integrity mechanism that is acceptable to both parties MAY be used.
両方の当事者に受け入れられる原点認証とデータの整合性メカニズムを使用することができます。
Any transport confidentiality mechanism that is acceptable to both parties MAY be used.
両当事者に受け入れられる輸送機密メカニズムを使用することができます。
This specification does not include a data compression technique. Therefore, it does not introduce any denial of service vulnerabilities related to decompression.
この仕様には、データ圧縮手法は含まれていません。したがって、減圧に関連するサービスの脆弱性を否定するものではありません。
This specification registers two identifiers:
この仕様は2つの識別子を登録します。
o The media sub-type name "thraud+xml" in the standard registration tree.
o 標準登録ツリーのメディアサブタイプの名前「Throad XML」。
o The xml namespace identifier - urn:ietf:params:xml:ns:thraud-1.0.
o XML名前空間識別子-URN：IETF：PARAMS：XML：NS：THRAUD -1.0。
Type name: application
タイプ名：アプリケーション
Subtype name: thraud+xml
サブタイプ名：Throad XML
Required parameters: none
必要なパラメーター：なし
Optional parameters: "charset": same as the charset parameter of application/xml, as specified in [RFC3023].
オプションのパラメーター：「charset」：[rfc3023]で指定されているように、アプリケーション/xmlのcharsetパラメーターと同じ。
Encoding considerations: same as encoding considerations of application/xml, as specified in [RFC3023].
考慮事項のエンコード：[RFC3023]で指定されているように、アプリケーション/XMLの考慮事項のエンコードと同じ。
Security considerations: in addition to the security considerations described in Section 9, this registration has all of the security considerations described in [RFC3023].
セキュリティ上の考慮事項：セクション9で説明されているセキュリティ上の考慮事項に加えて、この登録には[RFC3023]で説明されているすべてのセキュリティに関する考慮事項があります。
Interoperability considerations: None beyond the interoperability considerations described in [RFC3023].
相互運用性の考慮事項：[RFC3023]で説明されている相互運用性の考慮事項を超えていない。
Published specification: the media type data format is defined in RFC 5941.
公開された仕様：メディアタイプのデータ形式は、RFC 5941で定義されています。
Applications that use this media type: transaction and authentication fraud analysis and reporting applications, and risk-based transaction and authentication evaluation applications.
このメディアタイプを使用するアプリケーション：トランザクションおよび認証詐欺分析とレポートアプリケーション、およびリスクベースのトランザクションおよび認証評価アプリケーション。
Additional information Magic number(s): none File extension: .tfi Macintosh file type codes: none
追加情報マジック番号：なしファイル拡張子：.tfi Macintoshファイルタイプコード：なし
Person and email address to contact for further information:
"D M'Raihi <davidietf@gmail.com>"
Intended usage: LIMITED USE Restrictions on usage: thraud media are intended for no usage other than the exchange of fraud intelligence data.
意図された使用法：使用法の制限制限：Throad Mediaは、詐欺情報の交換以外の使用法を目的としています。
Author: D M'Raihi
著者：D M'Raihi
Change controller: the IESG
Change Controller：IESG
IANA has registered the xml namespace identifier:
IANAはXMLネームスペース識別子を登録しています。
URI: urn:ietf:params:xml:ns:thraud-1.0
Registrant Contact:
登録者の連絡先：
Siddharth Bajaj VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA Email: sbajaj@verisign.com
Siddharth Bajaj Verisign、Inc。487 E. Middlefield Road Mountain View、CA 94043 USAメール：sbajaj@verisign.com
XML: None. Namespace URIs do not represent an XML specification.
XML：なし。名前空間URIはXML仕様を表していません。
This specification introduces a transaction fraud (Thraud) reporting document structure that enables the sharing of fraud data. Based on the IODEF-Document format, the proposed extension facilitates interoperability to increase the security of online applications.
この仕様では、詐欺データの共有を可能にするトランザクション詐欺（Throad）レポートドキュメント構造を導入します。IODEF-Document形式に基づいて、提案された拡張機能は、オンラインアプリケーションのセキュリティを高める相互運用性を促進します。
[ISO13616-1:2007] Financial services - International bank account number (IBAN) -- Part 1: Structure of the IBAN, ISO 13616-1:2007.
[ISO13616-1：2007]金融サービス - 国際銀行口座番号（IBAN） - パート1：IBANの構造、ISO 13616-1：2007。
[ISO4217:2008] Financial services - Codes for the representation of currencies and funds, ISO 4217:2008.
[ISO4217：2008]金融サービス - 通貨と資金の代表のためのコード、ISO 4217：2008。
[ISO9362:1994] Banking -- Banking telecommunication messages -- Bank identifier codes, ISO 9362:1994.
[ISO9362：1994]銀行 - 銀行通信メッセージ - 銀行識別子コード、ISO 9362：1994。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519] Sciberras、A.、ed。、「Lightweight Directory Access Protocol（LDAP）：ユーザーアプリケーションのスキーマ」、RFC 4519、2006年6月。
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.
[RFC5070] Danyliw、R.、Meijer、J。、およびY. Demchenko、「インシデントオブジェクト説明交換形式」、RFC 5070、2007年12月。
[UML] Information technology -- Open Distributed Processing -- Unified Modeling Language (UML) Version 1.4.2, ISO/IEC 19501:2005.
[UML]情報技術 - オープン分散処理 - 統一モデリング言語（UML）バージョン1.4.2、ISO/IEC 19501：2005。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:thraud-1.0"
xmlns:thraud="urn:ietf:params:xml:ns:thraud-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation="
http://www.cert.org/ietf/inch/schema/rfc5070.xsd"/>
<xs:element name="FraudEventPayment"
type="thraud:FraudEventPaymentType"/>
<xs:element name="FraudEventTransfer"
type="thraud:FraudEventTransferType"/>
<xs:element name="FraudEventIdentity"
type="thraud:FraudEventIdentityType"/>
<xs:element name="FraudEventOther"
type="thraud:FraudEventOtherType"/>
<xs:complexType name="FraudEventPaymentType">
<xs:sequence>
<xs:element name="PayeeName" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="PostalAddress" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="PayeeAmount" type="thraud:AmountType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FraudEventTransferType">
<xs:sequence>
<xs:element name="BankID" type="thraud:BankIDType"
minOccurs="0"/>
<xs:element name="AccountID" type="xs:string" minOccurs="0"/>
<xs:element name="AccountType" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="TransferAmount" type="thraud:AmountType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FraudEventIdentityType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="IdentityComponent"
type="iodef:ExtensionType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FraudEventOtherType">
<xs:sequence>
<xs:element name="OtherEventType" type="xs:anyURI"/>
<xs:element name="PayeeName" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="PostalAddress" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="BankID" type="thraud:BankIDType"
minOccurs="0"/>
<xs:element name="AccountID" type="xs:string" minOccurs="0"/>
<xs:element name="AccountType" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="PayeeAmount" type="thraud:AmountType"
minOccurs="0"/>
<xs:element name="OtherEventDescription"
type="iodef:MLStringType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AmountType">
<xs:simpleContent>
<xs:extension base="xs:decimal">
<xs:attribute name="currency" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="BankIDType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="namespace" type="xs:anyURI"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="UserID" type="xs:string"/>
</xs:schema>
Appendix B. Example of a Thraud Report
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-1.0"
lang="en">
<Incident purpose="reporting">
<IncidentID name="fraud.openauthentication.org">908711
</IncidentID>
<ReportTime>2006-10-12T00:00:00-07:00</ReportTime>
<Assessment>
<Impact severity="high" completion="failed"/>
<Confidence rating="high"/>
</Assessment>
<Contact type="organization" role="creator">
<ContactName>Example Corp.</ContactName>
<Email>contact@example.com</Email>
<Telephone>+1.972.555.0150</Telephone>
</Contact>
<EventData>
<DetectTime>2006-10-12T07:42:21-08:00</DetectTime>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.53</Address>
</Node>
<Description>Source of numerous attacks</Description>
</System>
</Flow>
<AdditionalData dtype="xml">
<FraudEventTransfer xmlns="urn:ietf:params:xml:ns:thraud-
1.0" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:thraud-1.0">
<BankID
namespace="http://www.openauthentication.org/thraud/resources/
bank-id-namespace.htm#american_bankers_association">123456789</BankID>
<AccountID>3456789</AccountID>
<AccountType lang="en">saving</AccountType>
<TransferAmount currency="USD">10000</TransferAmount>
</FraudEventTransfer>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
Authors' Addresses
David M'Raihi VeriSign, Inc. 685 E. Middlefield Road Mountain View, CA 94043 USA Phone: 1-650-426-3832 EMail: davidietf@gmail.com
David M'Raihi Verisign、Inc。685 E. Middlefield Road Mountain View、CA 94043 USA電話：1-650-426-3832メール：Davidietf@gmail.com
Sharon Boeyen Entrust, Inc. 1000 Innovation Drive Ottawa, ON, K2K 3E7 Canada Phone: 1-613-270-3181 EMail: sharon.boeyen@entrust.com
Sharon Boeyen Antrust、Inc。1000 Innovation Drive Ottawa、ON、K2K 3E7 Canada電話：1-613-270-3181メール：sharon.boeyen@entrust.com
Michael Grandcolas Grandcolas Consulting, LLC 247 Ocean Park Blvd. Santa Monica, CA 90405 USA Phone: 1-310-399-1747 EMail: michael.grandcolas@hotmail.com
Michael Grandcolas Grandcolas Consulting、LLC 247 Ocean Park Blvd.カリフォルニア州サンタモニカ90405米国電話：1-310-399-1747メール：Michael.GrandColas@hotmail.com
Siddharth Bajaj VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA Phone: 1-650-426-3458 EMail: sbajaj@verisign.com
Siddharth Bajaj Verisign、Inc。487 E. Middlefield Road Mountain View、CA 94043 USA電話：1-650-426-3458メール：sbajaj@verisign.com