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
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）信息的文档格式。它扩展了事件处理工作组（INCH 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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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节中，我们介绍了典型交易欺诈中的参与者。第4节描述了通过IODEF文件进行欺诈报告。我们在第5节中定义了Thraud报告的要素。
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节中，描述了签名Thraud报告的概要。在第8节中，我们为IODEF事件类定义了新的属性值。第9节介绍了安全注意事项。第10节包含有关注册相关媒体子类型和XML命名空间标识符的IANA注意事项。附录包含完整的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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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) |
+-----------+
+--------------------------------------+
| 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.
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.
Thraud报告应为[RFC5070]中定义的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 ]
+-------------+
+-------------+
| 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类模式中的扩展点。实施者应在附加数据中仅包括以下对象之一：欺诈付款、欺诈转账、欺诈实体身份或欺诈其他。这些记录统称为Thraud记录。本规范在下文第5节中定义了相应的类别。
The Thraud profile of the Incident class is defined in Sections 6 and 7, below.
下文第6节和第7节定义了事故类别的Thraud概况。
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节。
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>-----[ FraudEventPayment ]
+------------------+
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>-----[ FraudEventPayment ]
+------------------+
Figure 3. The FraudEventPayment Extension
图3。欺诈支付扩展
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 ]
+------------------+
+------------------+
| 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节。
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>-----[ FraudEventIdentity ]
+------------------+
+------------------+
| 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.
其他Thraud记录的结构如图6所示。另见第5.4节。FraudEventOther类有一个开放的定义，可以作为将来出现的事件类型的占位符。
+------------------+
| AdditionalData |
+------------------+
| ENUM dtype (xml) |<>----[ 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.
FraudeEventPaymentType类用于报告欺诈性支付或欺诈性支付尝试的收款人指令。欺诈者有时使用同一受款人指示（包括金额）进行多次欺诈性支付尝试。通过报告欺诈中使用的支付指令，其他组织可能能够检测到向同一收款人的类似欺诈支付企图。
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 ]
+-------------+
+-------------+
| 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: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:MLString类型的值。格式应如[RFC4519]第2.23节所述，该节将邮政地址定义为由“$”字符分隔的自由格式多行字符串。
Zero or one value of type thraud:AmountType. See Section 5.5.
thraud: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.
FraudeEventTransferType类用于报告欺诈性资金转账或欺诈性资金转账尝试的收款人指令。欺诈者有时使用相同的收款人指示（包括金额）进行多次欺诈性资金转账尝试。通过报告欺诈中使用的资金转账指令，其他组织可能能够检测到向同一受款人的类似欺诈资金转账企图。
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 ]
+--------------+
+--------------+
| 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:BankIDType类型的值。BankIDType类的结构如图9所示。内容应为xs:string类型。名称空间属性应为xs:anyURI类型，并应标识用于标识银行或账户的编号系统。
+-------------------+
| BankIDType |
+-------------------+
| STRING |
| |
| STRING namespace |
+-------------------+
+-------------------+
| 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
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.
由美国银行家协会管理的向持有该账户的金融机构注册的九位数路由号码之一。
http://www.openauthentication.org/thraud/resources/bank-id-
namespace.htm#american_bankers_association
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.
由加拿大支付协会管理的向持有该账户的金融机构注册的三位数机构编号。
http://www.openauthentication.org/thraud/resources/bank-id-
namespace.htm#canadian_payments_association
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.
相应的AccountID代表由全球银行间金融电信协会（SWIFT）管理的分配给账户的“电子形式”（即不含空格）的ISO 13616国际银行账号[ISO13616-1:2007]。对应的BankID xs:string值应设置为空字符串。接收组织应忽略相应的BankID值。
http://www.openauthentication.org/thraud/resources/bank-id-
namespace.htm#iso13616_1_2007
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.
由SWIFT管理的向持有账户的金融组织注册的八字符银行识别码[ISO9362:1994]。
http://www.openauthentication.org/thraud/resources/bank-id-
namespace.htm#iso9362_1994
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
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:string类型的零或一个值。目标主帐号，由BankID元素中标识的财务组织管理。如果BankID名称空间属性值为“iso13616_1_2007”，则该元素应包含分配给该账户的“电子形式”（即不包含空格）的国际银行账号。在所有其他情况下，要素应仅包含由持有该账户的财务组织管理的账号。报告组织应删除识别国家、银行或分行的所有前缀。
Zero or one value of type thraud:AccountTypeType. See Section 5.6.
零或一个thraud:AccountTypeType类型的值。见第5.6节。
Zero or one value of type thraud:AmountType. See Section 5.5.
thraud: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.
FraudeEntityType类用于报告欺诈性模拟或欺诈性模拟尝试。通过报告模拟事件，其他潜在受害者可能能够检测到类似的欺诈性模拟企图。
The structure of the FraudEventIdentityType class SHALL be as shown in Figure 10.
FraudeEntityType类的结构如图10所示。
+--------------+
| FraudEvent- |
| IdentityType |
+--------------+
| |<>--{1..*}--[ IdentityComponent ]
+--------------+
+--------------+
| FraudEvent- |
| IdentityType |
+--------------+
| |<>--{1..*}--[ IdentityComponent ]
+--------------+
Figure 10. The FraudEventIdentityType Class
图10。FraudeEntityType类
The contents of the FraudEventIdentityType class are described below.
FraudeEntityType类的内容描述如下。
One or more values of type iodef:ExtensionType. This specification defines two extensions: EmailAddress and UserID.
一个或多个iodef:ExtensionType类型的值。该规范定义了两个扩展：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.
在报告身份欺诈事件时，报告机构可能包括受害者的电子邮件地址。这应通过在IdentityComponent对象中放置iodef:Email类型的对象来实现。它应包含预期欺诈受害者的电子邮件地址。
The IdentityComponent.dtype attribute SHALL be set to the value "string".
IdentityComponent.dtype属性应设置为值“string”。
The IdentityComponent.meaning attribute SHALL be set to the value "victim email address".
IdentityComponent.Meansing属性应设置为值“受害者电子邮件地址”。
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对象中放置iodef:ExtensionType类型的对象来实现。扩展内容的数据类型应为xs:string。它应包含预期欺诈受害者的用户标识符。
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.Meansing属性应设置为值“受害者用户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 ]
+-------------+
+-------------+
| 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
FraudEventTotherType类的许多组件也是FraudEventPaymentType或FraudEventTransferType类的组件。它们在FraudEventOtherType类中的使用与
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类特有的组件。
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
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
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: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 |
+------------------+
+------------------+
| 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.
必需的十进制数。支付或转账的金额。
REQUIRED STRING. The three-letter currency code [ISO4217:2008].
必需的字符串。三字母货币代码[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 |
+-----------------+
+-----------------+
| 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.
Thraud报告应符合[RFC5070]中IODEF文件规定的数据模型。该数据模型的以下组件在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.EndTime Incident.EventData.Flow.System Incident.EventData.Flow.ServiceIncident.EventData.Flow.System.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
事件。历史事件。附加数据事件。ext-purpose事件。IncidentID.instance事件。Contact.Description事件。Contact.RegistryHandle事件。Contact.PostalAddress事件。Contact.Fax事件。Contact.TimeZone事件。Contact.AdditionalData事件。Contact.Contact.Description事件。Contact.Contact.RegistryHandle事件Incident.Contact.Contact.PostalAddress Incident.Contact.Contact.Fax Incident.Contact.Contact.Contact.TimeZone Incident.Contact.Contact.Contact.Contact.Contact.Contact.Contact.ext-type Incident.Method.Reference Incident.EventData.Method.Reference.DescriptionIncident.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.RecordEvent.EventData.EventData Event.EventData.Flow.System.OperatingSystem Event.EventData.Flow.System.Counter Event.EventData.Flow.System.Description Event.EventData.Flow.System.AdditionalData Event.EventData.Flow.System.ext-category Event.EventData.Flow.System.Node.Location Event.EventData.Flow.System.Node.DateTimeEvent.EventData.Flow.System.Node.NodeRole Event.EventData.Flow.System.Node.Counter Event.EventData.Flow.System.Node.Address.ext-category Event.EventData.Flow.System.Service.ProtoType Event.EventData.Flow.System.Service.ProtoCode Event.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.
签字报告应符合第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.
o 标准注册树中的媒体子类型名称“thraud+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
子类型名称：thraud+xml
Required parameters: none
所需参数：无
Optional parameters: "charset": same as the charset parameter of application/xml, as specified in [RFC3023].
可选参数：“charset”：与application/xml的charset参数相同，如[RFC3023]中所述。
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>"
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.
使用限制：thraud media仅用于交换欺诈情报数据。
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
Siddharth Bajaj VeriSign，Inc.美国加利福尼亚州米德尔菲尔德路东487号山景城94043电子邮件：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部分：国际银行账号的结构，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媒体类型”，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.，“轻量级目录访问协议（LDAP）：用户应用程序模式”，RFC4519，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 50702007年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">
<?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>
<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>
<?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" 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号电话：94043电话：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 Truste，Inc.加拿大渥太华创新大道1000号K2K 3E7电话：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咨询有限责任公司海洋公园大道247号。加利福尼亚州圣莫尼卡90405美国电话：1-310-399-1747电子邮件：迈克尔。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号电话：94043电话：1-650-426-3458电子邮件：sbajaj@verisign.com