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.
この文書は、取引詐欺（Thraud）情報を交換するための文書フォーマットを説明しています。これは、作業部会の取り扱いインシデント（インチ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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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).
インバウンドの報告は、（電子メールまたは簡易オブジェクトアクセスプロトコル（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-文書による詐欺の報告は、我々は第5節でThraudレポートの要素を定義する第4項に記載されています。
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仕様の活動Thraudレポートプロファイルを記述する。セクション7で、署名Thraudレポートのプロファイルが記載されています。第8章では、我々は、IODEFインシデントクラスの新しい属性値を定義します。セキュリティの考慮事項は、セクション10は、関連するメディアサブタイプとXML名前空間識別子の登録に関するIANAの考慮事項が含まれているセクション9に記載されています。付録には、完全なXMLスキーマとサンプルThraudレポートが含まれています。
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
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.詐欺エグゼキュー：不正送金や支払いをしようとした個人。不正送金の場合には、被害者または異なるものと同一の金融機関のいずれかのアカウントが不正転送先口座として開設されます。また、不正支払いは小切手または電子的転送を使用して行われます。
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.
Thraud報告の意図は、内部または他の潜在的な被害者団体と、この情報を共有するために不正行為を検出したあらゆる組織を有効にすることです。受信組織は、不審な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]で定義されるようThraud報告は、IODEF文書クラスのインスタンスでなければなりません。 [RFC5070]で定義されたレポートは、少なくとも一つのインシデントオブジェクトを含まなければなりません。各インシデントオブジェクトは、単一の詐欺戦略についての情報を含むべきです。一つの事件のオブジェクトは、同じ詐欺戦略と一致している複数の不正取引に関する情報を含むことができます。それぞれの不正取引は、個別の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.
AdditionalData抽象クラスは、EventDataのクラスのスキーマ内の拡張ポイントです。 FraudEventPayment、FraudEventTransfer、FraudEventIdentity、またはFraudEventOther：実装者は、正確にAdditionalDataで、次のオブジェクトの1つを含むものとします。まとめると、これらはThraudレコードとして知られています。対応するクラスは、以下のセクション5において、本明細書で定義されています。
The Thraud profile of the Incident class is defined in Sections 6 and 7, below.
インシデントクラスのThraudプロファイルは、以下、セクション6および7に定義されています。
Thraud Records are expressed in XML. Therefore, the dtype attribute of the AdditionalData element SHALL be assigned the value "xml".
ThraudレコードはXMLで表現されています。したがって、AdditionalData素子のDTYPE属性が値「XML」が割り当てられます。
A payment Thraud Record SHALL be structured as shown in Figure 3. See also Section 5.1.
図3を参照してくださいまた、5.1節に示すように、支払Thraud録音は構造化されなければなりません。
+------------------+
| 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節に示されるように資金転送Thraudレコード構造化されなければなりません。
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>-----[ FraudEventTransfer ]
+------------------+
Figure 4. The FraudEventTransfer Extension
図4. FraudEventTransfer拡張
An identity Thraud Record SHALL be structured as shown in Figure 5. See also Section 5.3.
図5も参照セクション5.3に示すように、アイデンティティThraud録音は構造化されなければなりません。
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>-----[ FraudEventIdentity ]
+------------------+
Figure 5. The FraudEventIdentity Extension
図5. FraudEventIdentity拡張
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.
図6を参照してくださいまた、セクション5.4に示すように、他のThraudレコードが構造化されなければなりません。 FraudEventOtherクラスは、将来的に出現するイベントタイプのプレースホルダとして機能するためのオープンな定義があります。
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>----[ FraudEventOther ]
+------------------+
Figure 6. The FraudEventOther Extension
図6. FraudEventOther拡張
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.
FraudEventPaymentTypeクラスは、不正な支払いや不正支払いの試みのための受取人の指示を報告するために使用されます。詐欺師は時々、複数の不正支払いの試みについて（金額含む）同じ受取人の命令を使用します。詐欺で使用される支払命令を報告することによって、他の組織では、同じ受取人に同様の不正支払いの試みを検出することができます。
The structure of the FraudEventPaymentType class SHALL be as shown in Figure 7.
FraudEventPaymentTypeクラスの構造として、図7に示さなければなりません。
+-------------+
| FraudEvent- |
| PaymentType |
+-------------+
| |<>--{0..1}--[ PayeeName ]
| |<>--{0..1}--[ PostalAddress ]
| |<>--{0..1}--[ PayeeAmount ]
+-------------+
Figure 7. The FraudEventPaymentType Class
図7. FraudEventPaymentTypeクラス
The contents of the FraudEventPaymentType class are described below. At least one component MUST be present.
FraudEventPaymentTypeクラスの内容は、以下に記載されています。少なくとも一つの成分が存在しなければなりません。
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.
型thraudのゼロまたは1値：AmountType。 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.
FraudEventTransferTypeクラスは、不正な資金移動や詐欺的な資金移転の試みのための受取人の指示を報告するために使用されます。詐欺師は、時には複数の不正な資金転送の試行のために（量を含む）同一の受取人命令を使用します。詐欺の結果使用した資金転送命令を報告することによって、他の組織では、同じ受取人に類似した不正資金移転の試みを検出することができます。
The structure of the FraudEventTransferType class SHALL be as shown in Figure 8.
FraudEventTransferTypeクラスの構造として、図8に示さなければなりません。
+--------------+
| FraudEvent- |
| TransferType |
+--------------+
| |<>--{0..1}--[ BankID ]
| |<>--{0..1}--[ AccountID ]
| |<>--{0..1}--[ AccountType ]
| |<>--{0..1}--[ TransferAmount ]
+--------------+
Figure 8. The FraudEventTransferType Class
図8. FraudEventTransferTypeクラス
The contents of the FraudEventTransferType class are described below. At least one component MUST be present.
FraudEventTransferTypeクラスの内容は、以下に記載されています。少なくとも一つの成分が存在しなければなりません。
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.
型thraudのゼロまたは1値：BankIDType。ストリング：BankIDTypeクラスの構造として内容がタイプxsのものでなければならない。図9に示さなければなりません。 anyURIの銀行や口座を識別するために使用されるナンバリングシステムを識別しなければならない：namespace属性は、型xsのものでなければなりません。
+-------------------+
| 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.
アメリカ銀行協会によって投与として、アカウントを保持している金融機関に登録された9桁のルーティング番号のいずれか。
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]を表す「電子フォーム」での（すなわち、スペースを含まない）国際銀行間通信協会（SWIFTによって投与として、アカウントに割り当てられていること）。対応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.
単一の組織がこれらの名前空間の任意の一つ以上に複数の値によって識別されてもよいことに留意されたいです。そのため、受信組織は、マッチング手順で、このことを考慮すべきです。
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名前空間の属性値が「iso13616_1_2007」である場合には、この要素は、アカウントに割り当てられている（つまり、何もスペースを含まない）、「電子形式」で国際銀行口座番号を含まなければなりません。アカウントを保持している金融機関によって管理など他のすべての場合では、要素は、唯一の口座番号を含まなければなりません。報告組織は、国、銀行、または支店を識別するすべてのプレフィックスを削除するものとします。
Zero or one value of type thraud:AccountTypeType. See Section 5.6.
型thraudのゼロまたは1値：AccountTypeType。 5.6節を参照してください。
Zero or one value of type thraud:AmountType. See Section 5.5.
型thraudのゼロまたは1値：AmountType。 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.
FraudEventIdentityTypeクラスは詐欺、なりすましや詐欺、なりすましの試みを報告するために使用されます。偽装イベントを報告することによって、他の潜在的な被害者が同様の詐欺、偽装の試みを検出することができます。
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. FraudEventIdentityTypeクラス
The contents of the FraudEventIdentityType class are described below.
FraudEventIdentityTypeクラスの内容は、以下に記載されています。
One or more values of type iodef:ExtensionType. This specification defines two extensions: EmailAddress and UserID.
型IODEFの1つ以上の値：ExtensionType。 EmailAddressとユーザーID：この仕様では、2つの拡張を定義します。
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.
アイデンティティ詐欺イベントをレポートでは、レポート作成機関は、被害者の電子メールアドレスを含んでいてもよいです。 IdentityComponentオブジェクトに電子メール：これはIODEF型のオブジェクトを配置することにより達成されるものとします。これは、意図した詐欺の被害者の電子メールアドレスを含まなければなりません。
The IdentityComponent.dtype attribute SHALL be set to the value "string".
IdentityComponent.dtype属性が値「文字列」に設定されなければなりません。
The IdentityComponent.meaning attribute SHALL be set to the value "victim email address".
IdentityComponent.meaning属性は、「被害者の電子メールアドレス」の値に設定されなければなりません。
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.
アイデンティティ詐欺イベントをレポートでは、レポート作成機関は、被害者のユーザ識別子を含むかもしれません。 IdentityComponentオブジェクト内ExtensionType：これはタイプIODEFのオブジェクトを配置することによって達成されるものとします。文字列：拡張コンテンツのデータ型は、xsされなければなりません。これは、意図した詐欺の被害者のユーザ識別子を含まなければなりません。
The IdentityComponent.type attribute SHALL be set to the value "string".
IdentityComponent.type属性が値「文字列」に設定されなければなりません。
The IdentityComponent.meaning attribute SHALL be set to the value "victim user id".
IdentityComponent.meaning属性は、「被害者のユーザー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.
FraudEventOtherTypeクラスは、このような将来のある時点で出現する可能性のある新しいイベントタイプ、上記のように詳述したもの以外の不正なイベントを報告するために使用しなければなりません。このクラスは、このようなイベントの特定の特性は、まだ正式に確認されていないにもかかわらず、この仕様を使用して、報告するためにこのようなイベントを可能にします。これらの不特定のイベントタイプの詳細を報告することによって、他の機関も同様の不正行為を検出することができます。
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. FraudEventOtherTypeクラス
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クラスのコンポーネントの多くは、FraudEventPaymentTypeまたはFraudEventTransferTypeクラスの構成要素です。 FraudEventOtherTypeクラスでの使用は、これらのクラスでの使用と同じです。そのため、その説明はここでは複製されません。 FraudEventOtherTypeクラスに固有な構成要素のみを以下に記載されています。
One value of type xs:anyURI. A name that classifies the event.
型xsの一つの値：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.
AmountTypeクラスは、図12に示すように、支払いまたは転送詐欺の量を報告するために使用されるものでなければなりません。
+------------------+
| AmountType |
+------------------+
| DECIMAL |
| |
| STRING currency |
+------------------+
Figure 12. The AmountType Class
図12. AmountTypeクラス
The contents of the AmountType class are described below.
AmountTypeクラスの内容は、以下に記載されています。
REQUIRED DECIMAL. The amount of the payment or transfer.
必須DECIMAL。支払いまたは転送量。
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.
このセクションでは、準拠した活動Thraudレポートの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.
ThraudレポートにIODEF、文献[RFC5070]に指定されたデータモデルに適合しなければなりません。そのデータモデルの次のコンポーネントは、IODEFで任意しながら、適合Thraudレポートで必要とされます。
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.
Incident.Contact.ContactName - 報告組織の名称。報告組織が他の組織からの報告のコンソリとして動作する場合には、このクラスの要素は、コンソリの名前を含まなければなりません。 Incident.Contact.Email - 報告組織が接触させてもよいれる電子メールアドレス。 Incident.Contact.Telephone Incident.EventData Incident.EventData.AdditionalDataは - 正確に一つのThraud録音を含まなければなりません。
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].
可能な場合は、報告組織はThraudレポートでは、これらのコンポーネントを含むべきです。 [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
Incident.Contact.Contact Incident.Contact.Contact.ContactName - 報告詐欺のアナリストの名前。 Incident.Contact.Contact.Email - 報告詐欺のアナリストの電子メールアドレス。 Incident.Contact.Contact.Telephone - 報告詐欺のアナリストの電話番号。 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
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.
このプロファイルは、次のコンポーネントの適切な処理に組織を受信することに何のガイダンスを提供していません。したがって、報告組織は、受信組織が適切な方法でそれらを処理するとThraud報告書に含めるべきではないと保証がありません。しかし、受信組織は、これらのコンポーネントが含まれていないレポートを拒否してはなりません。
Incident.DetectTime Incident.AlternativeID Incident.RelatedActivity Incident.StartTime Incident.EndTime Incident.ReportTime Incident.Description Incident.Method
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
Incident.History Incident.AdditionalData Incident.ext-目的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役割Incident.Contact.ext型Incident.Contact.Contact.ext-役割Incident.Contact.Contact.ext型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.EventDat a.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カテゴリIncident.EventData.Flow.System.Node.Location Incident.EventData.Flow.System.Node.DateTime Incident.EventData.Flow.System.Node.NodeRole Incident.EventData.Flow.System.Node.Counter事件.EventData.Flow.System.Node.Address.extカテゴリIncident.EventData.Flow.System.Service.ProtoType Incident.EventData.Flow.System.Service.ProtoCode Incident.EventData.Flow.System.Service.ProtoField Incident.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.
署名Thraud報告書ではなく、特定のイベントそのものの詳細を報告するよりも、詐欺的なイベントに関連付けられた動作に関する情報を伝えるものとします。
Sharing Signature Thraud Reports helps receiving organizations to detect suspicious behavior in their own systems.
署名Thraudレポートを共有することで、独自のシステムで不審な動作を検出するための組織を受け取ることができます。
A Signature Thraud Report SHALL conform to the profile described in Section 6.
署名Thraud報告書は、第6節で説明したプロファイルに適合しなければなりません。
Additional IODEF attribute standard values are defined here.
追加IODEFは標準値がここで定義されている属性。
The following additional values are defined for the Incident.purpose attribute.
以下の追加の値がIncident.purpose属性に定義されています。
Add - The enclosed Thraud Record values SHOULD be added to the corpus by the receiving organization.
追加 - 同封Thraudレコード値は、受信組織によってコーパスに追加する必要があります。
Delete - The enclosed Thraud Record types SHOULD be deleted from the corpus by the receiving organization.
削除 - 同封Thraudレコードタイプは、受信組織によるコーパスから削除する必要があります。
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.
変更 - 同封Thraudレコード値は、コーパスに対応する値を置き換える必要があります。該当するタイプが現在コーパスに存在しない場合、囲まれた値は、受信組織がコーパスに追加する必要があります。
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.
詐欺師は、コーパスにインシデント情報を削除または修正するレポートを導入しようとすることができます。したがって、元の認証を使用しなければなりません。人間のレビューコーパスへの変更を実装する前に行われるべきです。
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.
詐欺師は、それによって彼らの評判を毒殺し、効果のない彼らの将来の提出をレンダリングし、合法的な提出者を偽装しようとすることができます。原産地認証は、レポートのソースが正しく識別されることを保証するために使用しなければなりません。
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.
受信組織は、正当なユーザーのために損失をもたらす、サービスを拒否するThraudレポートを悪用してもよいです。そのようなユーザーがサービス拒否につながった情報源の身元を知るした場合、そのソースは、補償のために、結果として生じるいかなる請求に関与になることがあります。これは、順番に、知性の共有に参加する団体を報告思いとどまらことがあります。そのため、オリジナルのソースは、統合報告書で特定されるべきではありません。
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:
この仕様は、二つの識別子を登録します。
o The media sub-type name "thraud+xml" in the standard registration tree.
標準の登録ツリー内のメディアサブタイプ名「thraud + xmlの」O。
o The xml namespace identifier - urn:ietf:params:xml:ns:thraud-1.0.
IETF：：のparams：XML：NS：thraud-1.0 URN - XML名前空間識別子O。
Type name: application
型名：アプリケーション
Subtype name: thraud+xml
サブタイプ名：thraud + xmlの
Required parameters: none
必須パラメータ：なし
Optional parameters: "charset": same as the charset parameter of application/xml, as specified in [RFC3023].
オプションのパラメータ：「文字セット」：アプリケーション/ XMLのcharsetパラメータと同様、[RFC3023]で指定されるように。
Encoding considerations: same as encoding considerations of application/xml, as specified in [RFC3023].
符号化の考慮事項：アプリケーション/ XMLの符号化の考慮と同様、[RFC3023]で指定されるように。
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
追加情報マジックナンバー（S）：なしファイルの拡張子：.tfi Macintoshのファイルタイプコード：なし
Person and email address to contact for further information: "D M'Raihi <davidietf@gmail.com>"
詳細のために連絡する人とEメールアドレス：「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.
使用に関する制限事項：thraudメディアは、詐欺・インテリジェンス・データの交換以外には使用のために意図されています。
Author: D M'Raihi
著者：D M'Raihi
Change controller: the IESG
変更コントローラ：IESG
IANA has registered the xml namespace identifier:
IANAは、XML名前空間識別子を登録しています：
URI: urn:ietf:params:xml:ns:thraud-1.0
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
シッダールタバジャジベリサイン社487 E.ミドルロード、マウンテンビュー、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.
この仕様は、不正データの共有を可能に取引詐欺（Thraud）の報告文書構造を導入しています。 IODEF・ドキュメント・フォーマットに基づいて、提案されている拡張子は、オンラインアプリケーションのセキュリティを高めるために相互運用性を促進します。
[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519] Sciberras、A.、エド、 "ライトウェイトディレクトリアクセスプロトコル（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.、マイヤー、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。
Appendix A. Thraud Record XML Schema
付録A. ThraudレコードのXMLスキーマ
<?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">
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：thraud-1.0" のxmlns：thraud = "壷：IETF：のparamsを：XML ：NS：thraud-1.0" のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のxmlns：IODEF = "壷：IETF：のparams：XML：NS： "IODEF-1.0" のelementFormDefaultは=" 資格attributeFormDefault = "非修飾"> <XS：インポートの名前空間= "壷：IETF：のparams：XML：NS：IODEF-1.0" のschemaLocation = "http://www.cert.org/ietf/inch/schema/rfc5070.xsd" /> <XS：要素名= "FraudEventPayment" タイプ= "thraud：FraudEventPaymentType" /> <XS：要素名= "FraudEventTransfer" タイプ= "thraud：FraudEventTransferType" /> <XS：要素名= "FraudEventIdentity" タイプ=」 thraud：FraudEventIdentityType "/> <XS：要素名=" FraudEventOther」タイプ= "thraud：FraudEventOtherType" /> <XS：complexTypeの名前= "FraudEventPaymentType"> <XS：シーケンス> <XS：要素名= "PayeeName" タイプ= "IODEF：MLStringType" のminOccurs = "0" /> <XS：要素名= "のPostalAddress" タイプ= "IODEF：MLStringType" のminOccurs = "0" /> <XS：要素名= "PayeeAmount" タイプ= "thraud：AmountType 「美濃ccurs = "0" /> </ XS：配列> </ XS：complexTypeの> <XS：complexTypeの名= "FraudEventTransferType"> <XS：配列> <XS：要素名= "BankID" タイプ= "thraud：BankIDType" minOccurs = "0" /> <XS：要素名= "アカウントID" タイプ= "XS：文字列" のminOccurs = "0" /> <XS：要素名= "AccountType" タイプ= "IODEF：MLStringType" のminOccurs = "0 "/> <XS：要素名=" TransferAmount」タイプ= "thraud：AmountType" のminOccurs = "0" /> </ XS：配列> </ XS：complexTypeの> <XS：complexTypeの名= "FraudEventIdentityType"> <XS ：配列のmaxOccurs = "無制限"> <XS：要素名= "IdentityComponent" タイプ= "IODEF：ExtensionType" /> </ XS：配列> </ XS：complexTypeの> <XS：complexTypeの名= "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>
<XS：配列> <XS：要素名= "OtherEventType" タイプ= "XS：anyURIの" /> <XS：要素名= "PayeeName" タイプ= "IODEF：MLStringType" のminOccurs = "0" /> <XS：要素NAME = "のPostalAddress" タイプ= "IODEF：MLStringType" のminOccurs = "0" /> <XS：要素名= "BankID" タイプ= "thraud：BankIDType" のminOccurs = "0" /> <XS：要素名= "アカウントID "TYPE =" XS：文字列 "のminOccurs = "0"/> <XS：要素名= "AccountType" タイプ= "IODEF：MLStringType" のminOccurs = "0"/> <XS：要素名= "PayeeAmount" タイプ=" thraud：AmountType」のminOccurs = "0" /> <XS：要素名= "OtherEventDescription" タイプ= "IODEF：MLStringType" のminOccurs = "0" /> </ XS：配列> </ XS：complexTypeの> <XS：complexTypeの名前= "AmountType"> <XS：simpleContentを> <XS：増設ベース= "XS：小数点"> <XS：属性名は= "通貨" タイプ= "XS：文字列" /> </ XS：拡張> </ XS ：simpleContentを> </ XS：complexTypeの> <XS：complexTypeの名前= "BankIDType"> <XS：simpleContentを> <XS：拡張ベース= "XS：文字列"> <XS：属性名= "名前空間" タイプ= "XS： anyURIの」使用= "必須" /> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの> <X S：要素名= "ユーザーID" タイプ= "XS：文字列" /> </ XS：スキーマ>
Appendix B. Example of a Thraud Report
Thraud報告書の付録B.例
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <IODEF-ドキュメントのxmlns = "壷：IETF：のparams：XML：NS：IODEF-1.0" のxmlns：XSI = "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス "のxsi：schemaLocationの= "壷：IETF：のparams：XML：NS：IODEF-1.0" LANG = "EN"> <インシデントの目的= "報告"> <IncidentID名=" fraud.openauthentication .ORG "> 908711 </ IncidentID> <ReportTime> 2006-10-12T00：00：00-07：00 </ ReportTime> <評価> <衝撃の重大度=" 高」完了= "" 失敗/> <信頼格付け= "ハイ" /> </アセスメント> <連絡先の種類= "組織" 役割= "生みの親"> <担当者名>例株式会社。</担当者名> <メール> contact@example.com </メール> <電話> 1.972。 555.0150 </電話> </お問い合わせ> <EventDataの> <DetectTime> 2006-10-12T07：42：21から08：00 </ DetectTime> <フロー> <Systemカテゴリ= "ソース"> <ノード> <住所カテゴリ= "IPv4の-addrに" 多数の攻撃> 192.0.2.53 </住所> </ノード> <説明>ソース</説明> </システム> </フロー> <AdditionalData DTYPE = "XML"> <FraudEventTransferののxmlns = "壷：IETF：のparams：XML：NS：thraud-1.0" のxmlns：IODEF = "壷：IETF：のparams：XML：NS： IODEF-1.0" のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance" のxsi：schemaLocationの= "壷：IETF：のparams：XML：NS：thraud-1.0"> <BankID名前空間=」 http://www.openauthentication.org/thraud/resources/銀行-ID-namespace.htm番号のamerican_bankers_association "> 123456789 </ BankID> <アカウントID> 3456789 </アカウントID> <AccountType LANG =" EN "> </ AccountType保存> <TransferAmount通貨= "USD"> 10000 </ TransferAmount> </ FraudEventTransfer> </ AdditionalData> </ EventDataの> </インシデント> </ IODEF-文献>
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
デビッドM'Raihiベリサイン社685 E.ミドルロード、マウンテンビュー、CA 94043 USA電話：1-650-426-3832 Eメール：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
シャロンBoeyenトラスト株式会社1000年イノベーションドライブオタワ、ON、K2K 3E7カナダ電話：1-613-270-3181 Eメール：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
マイケルGrandcolas Grandcolasコンサルティング、LLC 247オーシャンパークブルバードサンタモニカ、CA 90405 USA電話：1-310-399-1747 Eメール：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
シッダールタバジャジベリサイン社487 E.ミドルロード、マウンテンビュー、CA 94043 USA電話：1-650-426-3458 Eメール：sbajaj@verisign.com