summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5941.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5941.txt')
-rw-r--r--doc/rfc/rfc5941.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc5941.txt b/doc/rfc/rfc5941.txt
new file mode 100644
index 0000000..b8caecb
--- /dev/null
+++ b/doc/rfc/rfc5941.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+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.
+
+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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 1]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 2]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+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
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 3]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+1. Introduction
+
+ 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).
+
+ 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].
+
+ 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.
+
+
+
+M'Raihi, et al. Informational [Page 4]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+ 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.
+
+ Data elements in this document are expressed in Unified Modeling
+ Language (UML) syntax [UML].
+
+ XML namespace prefixes are used throughout this document to stand for
+ their respective XML namespaces, as follows.
+
+ 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
+
+2. Requirements Terminology
+
+ 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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 5]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+3. Anatomy of a Transaction Fraud
+
+ The actors in a typical transaction fraud are shown in Figure 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
+
+ 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.
+
+
+
+
+
+M'Raihi, et al. Informational [Page 6]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+ 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.
+
+ 3. Victims of both credential theft and transaction fraud.
+
+ 4. Financial organizations that hold the victim's and the Fraud
+ Executor's accounts.
+
+ 5. Sensors at the financial organization that detect fraudulent
+ transaction attempts, either in real-time or after the fact.
+
+ 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.
+
+4. IODEF-Document Incident Class
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 7]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+ +-------------+
+ | 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
+
+ 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.
+
+ The Thraud profile of the Incident class is defined in Sections 6 and
+ 7, below.
+
+5. Thraud Record Class Definitions
+
+ Thraud Records are expressed in XML. Therefore, the dtype attribute
+ of the AdditionalData element SHALL be assigned the value "xml".
+
+ A payment Thraud Record SHALL be structured as shown in Figure 3.
+ See also Section 5.1.
+
+ +------------------+
+ | AdditionalData |
+ +------------------+
+ | ENUM dtype (xml) |<>-----[ FraudEventPayment ]
+ +------------------+
+
+ Figure 3. The FraudEventPayment Extension
+
+
+
+
+
+M'Raihi, et al. Informational [Page 8]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+ A funds-transfer Thraud Record SHALL be structured as shown in
+ Figure 4. See also Section 5.2.
+
+ +------------------+
+ | AdditionalData |
+ +------------------+
+ | ENUM dtype (xml) |<>-----[ FraudEventTransfer ]
+ +------------------+
+
+ Figure 4. The FraudEventTransfer Extension
+
+ An identity Thraud Record SHALL be structured as shown in Figure 5.
+ See also Section 5.3.
+
+ +------------------+
+ | AdditionalData |
+ +------------------+
+ | ENUM dtype (xml) |<>-----[ FraudEventIdentity ]
+ +------------------+
+
+ Figure 5. The FraudEventIdentity Extension
+
+ 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.
+
+ +------------------+
+ | AdditionalData |
+ +------------------+
+ | ENUM dtype (xml) |<>----[ FraudEventOther ]
+ +------------------+
+
+ Figure 6. The FraudEventOther Extension
+
+5.1. FraudEventPaymentType Class
+
+ 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.
+
+ The structure of the FraudEventPaymentType class SHALL be as shown in
+ Figure 7.
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 9]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+ +-------------+
+ | FraudEvent- |
+ | PaymentType |
+ +-------------+
+ | |<>--{0..1}--[ PayeeName ]
+ | |<>--{0..1}--[ PostalAddress ]
+ | |<>--{0..1}--[ PayeeAmount ]
+ +-------------+
+
+ Figure 7. The FraudEventPaymentType Class
+
+ The contents of the FraudEventPaymentType class are described below.
+ At least one component MUST be present.
+
+5.1.1. PayeeName
+
+ Zero or one value of type iodef:MLString. The name of the payee.
+
+5.1.2. PostalAddress
+
+ 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.
+
+5.1.3. PayeeAmount
+
+ Zero or one value of type thraud:AmountType. See Section 5.5.
+
+5.2. FraudEventTransferType Class
+
+ The FraudEventTransferType class is used to report the payee
+ instructions for a fraudulent funds transfer or fraudulent funds
+ transfer attempt. Fraudsters sometimes use the same payee
+ instructions (including the amount) for multiple fraudulent funds
+ transfer attempts. By reporting the funds transfer instructions used
+ in the fraud, other organizations may be able to detect similar
+ fraudulent funds transfer attempts to the same payee.
+
+ The structure of the FraudEventTransferType class SHALL be as shown
+ in Figure 8.
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 10]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+ +--------------+
+ | FraudEvent- |
+ | TransferType |
+ +--------------+
+ | |<>--{0..1}--[ BankID ]
+ | |<>--{0..1}--[ AccountID ]
+ | |<>--{0..1}--[ AccountType ]
+ | |<>--{0..1}--[ TransferAmount ]
+ +--------------+
+
+ Figure 8. The FraudEventTransferType Class
+
+ The contents of the FraudEventTransferType class are described below.
+ At least one component MUST be present.
+
+5.2.1. BankID
+
+ 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.
+
+ +-------------------+
+ | BankIDType |
+ +-------------------+
+ | STRING |
+ | |
+ | STRING namespace |
+ +-------------------+
+
+ Figure 9. The BankIDType Class
+
+ 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.
+
+ http://www.openauthentication.org/thraud/resources/bank-id-
+ namespace.htm#american_bankers_association
+
+
+
+
+M'Raihi, et al. Informational [Page 11]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+ 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
+
+ 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.
+
+ 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.
+
+ 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.
+
+5.2.2. AccountID
+
+ 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.
+
+
+
+
+M'Raihi, et al. Informational [Page 12]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+5.2.3. AccountType
+
+ Zero or one value of type thraud:AccountTypeType. See Section 5.6.
+
+5.2.4. TransferAmount
+
+ Zero or one value of type thraud:AmountType. See Section 5.5.
+
+5.3. FraudEventIdentityType Class
+
+ 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.
+
+ The structure of the FraudEventIdentityType class SHALL be as shown
+ in Figure 10.
+
+ +--------------+
+ | FraudEvent- |
+ | IdentityType |
+ +--------------+
+ | |<>--{1..*}--[ IdentityComponent ]
+ +--------------+
+
+ Figure 10. The FraudEventIdentityType Class
+
+ The contents of the FraudEventIdentityType class are described below.
+
+5.3.1. IdentityComponent
+
+ One or more values of type iodef:ExtensionType. This specification
+ defines two extensions: EmailAddress and UserID.
+
+5.3.1.1. EmailAddress
+
+ 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.
+
+ The IdentityComponent.dtype attribute SHALL be set to the value
+ "string".
+
+ The IdentityComponent.meaning attribute SHALL be set to the value
+ "victim email address".
+
+
+
+
+M'Raihi, et al. Informational [Page 13]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+5.3.1.2. UserID
+
+ 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.
+
+ The IdentityComponent.type attribute SHALL be set to the value
+ "string".
+
+ The IdentityComponent.meaning attribute SHALL be set to the value
+ "victim user id".
+
+5.4. FraudEventOtherType Class
+
+ The FraudEventOtherType class SHALL be used to report fraudulent
+ events other than those detailed above, such as new event types that
+ may emerge at some time in the future. This class enables such
+ events to be reported, using this specification, even though the
+ specific characteristics of such events have not yet been formally
+ identified. By reporting the details of these unspecified event
+ types, other institutions may be able to detect similar fraudulent
+ activity.
+
+ The structure of the FraudEventOtherType class SHALL be as shown in
+ Figure 11.
+
+ +-------------+
+ | 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
+
+ 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
+
+
+
+M'Raihi, et al. Informational [Page 14]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+ their use in those classes. Therefore, their descriptions are not
+ duplicated here. Only components that are unique to the
+ FraudEventOtherType class are described below.
+
+5.4.1. OtherEventType
+
+ One value of type xs:anyURI. A name that classifies the event.
+
+ 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
+
+5.4.2. OtherEventDescription
+
+ Zero or one value of type iodef:MLString. A free-form textual
+ description of the event.
+
+5.5. AmountType Class
+
+ 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 |
+ +------------------+
+ | DECIMAL |
+ | |
+ | STRING currency |
+ +------------------+
+
+ Figure 12. The AmountType Class
+
+ The contents of the AmountType class are described below.
+
+5.5.1. Class Contents
+
+ REQUIRED DECIMAL. The amount of the payment or transfer.
+
+5.5.2. Currency
+
+ REQUIRED STRING. The three-letter currency code [ISO4217:2008].
+
+
+
+
+
+M'Raihi, et al. Informational [Page 15]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+5.6. AccountTypeType Class
+
+ The AccountTypeType class SHALL be as shown in Figure 13. It SHALL
+ be used to report the type of the destination account.
+
+ +-----------------+
+ | AccountTypeType |
+ +-----------------+
+ | STRING |
+ | |
+ | STRING lang |
+ +-----------------+
+
+ Figure 13. The AccountTypeType Class
+
+ Receiving organizations MUST be capable of processing contents
+ containing spelling variations.
+
+6. IODEF Profile for an Activity Thraud Report
+
+ This section describes the profile of the IODEF Incident class for a
+ compliant Activity Thraud Report.
+
+6.1. Mandatory Components
+
+ 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.
+
+ 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].
+
+ 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.
+
+
+
+
+M'Raihi, et al. Informational [Page 16]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+6.2. Recommended Components
+
+ 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].
+
+ 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
+
+6.3. Deprecated Components
+
+ This profile provides no guidance to receiving organizations on the
+ proper processing of the following components. Therefore, the
+ reporting organization has no assurance that the receiving
+ organization will handle them in an appropriate manner and SHOULD NOT
+ include them in a Thraud Report. However, receiving organizations
+ MUST NOT reject reports that do contain these components.
+
+ Incident.DetectTime
+ Incident.AlternativeID
+ Incident.RelatedActivity
+ Incident.StartTime
+ Incident.EndTime
+ Incident.ReportTime
+ Incident.Description
+ Incident.Method
+
+
+
+M'Raihi, et al. Informational [Page 17]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+ 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
+
+
+
+
+M'Raihi, et al. Informational [Page 18]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+7. IODEF Profile for a Signature Thraud Report
+
+ A Signature Thraud Report SHALL convey information about the behavior
+ associated with fraudulent events, rather than reporting the details
+ of the specific events themselves.
+
+ Sharing Signature Thraud Reports helps receiving organizations to
+ detect suspicious behavior in their own systems.
+
+ A Signature Thraud Report SHALL conform to the profile described in
+ Section 6.
+
+8. IODEF Additional Attribute Values
+
+ Additional IODEF attribute standard values are defined here.
+
+8.1. Purpose Attribute
+
+ The following additional values are defined for the Incident.purpose
+ attribute.
+
+ Add - The enclosed Thraud Record values SHOULD be added to the corpus
+ by the receiving organization.
+
+ Delete - The enclosed Thraud Record types SHOULD be deleted from the
+ corpus by the receiving organization.
+
+ 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.
+
+9. Security Considerations
+
+ 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.
+
+
+
+M'Raihi, et al. Informational [Page 19]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 20]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+10. IANA Considerations
+
+ This specification registers two identifiers:
+
+ o The media sub-type name "thraud+xml" in the standard registration
+ tree.
+
+ o The xml namespace identifier - urn:ietf:params:xml:ns:thraud-1.0.
+
+10.1. Media Sub-Type
+
+ Type name: application
+
+ Subtype name: thraud+xml
+
+ Required parameters: none
+
+ Optional parameters: "charset": same as the charset parameter of
+ application/xml, as specified in [RFC3023].
+
+ Encoding considerations: same as encoding considerations of
+ application/xml, as specified in [RFC3023].
+
+ Security considerations: in addition to the security considerations
+ described in Section 9, this registration has all of the security
+ considerations described in [RFC3023].
+
+ Interoperability considerations: None beyond the interoperability
+ considerations described in [RFC3023].
+
+ Published specification: the media type data format is defined in 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
+
+ Person and email address to contact for further information:
+ "D M'Raihi <davidietf@gmail.com>"
+
+ Intended usage: LIMITED USE
+
+
+
+
+
+M'Raihi, et al. Informational [Page 21]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+ Restrictions on usage: thraud media are intended for no usage other
+ than the exchange of fraud intelligence data.
+
+ Author: D M'Raihi
+
+ Change controller: the IESG
+
+10.2. XML Namespace
+
+ IANA has registered the xml namespace identifier:
+
+ 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
+
+ XML: None. Namespace URIs do not represent an XML specification.
+
+11. Conclusion
+
+ 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.
+
+12. References
+
+12.1. Normative References
+
+ [ISO13616-1:2007] Financial services - International bank account
+ number (IBAN) -- Part 1: Structure of the IBAN,
+ ISO 13616-1:2007.
+
+ [ISO4217:2008] Financial services - Codes for the representation
+ of currencies and funds, ISO 4217:2008.
+
+ [ISO9362:1994] Banking -- Banking telecommunication messages --
+ Bank identifier codes, ISO 9362:1994.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+M'Raihi, et al. Informational [Page 22]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+ [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML
+ Media Types", RFC 3023, January 2001.
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Schema for User Applications",
+ RFC 4519, June 2006.
+
+ [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The
+ Incident Object Description Exchange Format",
+ RFC 5070, December 2007.
+
+12.2. Informative References
+
+ [UML] Information technology -- Open Distributed
+ Processing -- Unified Modeling Language (UML)
+ Version 1.4.2, ISO/IEC 19501:2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 23]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+Appendix A. Thraud Record XML Schema
+
+<?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">
+
+
+
+M'Raihi, et al. Informational [Page 24]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+ <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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 25]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+Appendix B. Example of a Thraud Report
+
+<?xml version="1.0" encoding="UTF-8"?>
+<IODEF-Document xmlns="urn:ietf:params:xml:ns:iodef-1.0"
+xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-1.0"
+lang="en">
+ <Incident purpose="reporting">
+ <IncidentID name="fraud.openauthentication.org">908711
+ </IncidentID>
+ <ReportTime>2006-10-12T00:00:00-07:00</ReportTime>
+ <Assessment>
+ <Impact severity="high" completion="failed"/>
+ <Confidence rating="high"/>
+ </Assessment>
+ <Contact type="organization" role="creator">
+ <ContactName>Example Corp.</ContactName>
+ <Email>contact@example.com</Email>
+ <Telephone>+1.972.555.0150</Telephone>
+ </Contact>
+ <EventData>
+ <DetectTime>2006-10-12T07:42:21-08:00</DetectTime>
+ <Flow>
+ <System category="source">
+ <Node>
+ <Address category="ipv4-addr">192.0.2.53</Address>
+ </Node>
+ <Description>Source of numerous attacks</Description>
+ </System>
+ </Flow>
+ <AdditionalData dtype="xml">
+ <FraudEventTransfer xmlns="urn:ietf:params:xml:ns:thraud-
+1.0" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
+xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+xsi:schemaLocation="urn:ietf:params:xml:ns:thraud-1.0">
+ <BankID
+namespace="http://www.openauthentication.org/thraud/resources/
+bank-id-namespace.htm#american_bankers_association">123456789</BankID>
+ <AccountID>3456789</AccountID>
+ <AccountType lang="en">saving</AccountType>
+ <TransferAmount currency="USD">10000</TransferAmount>
+ </FraudEventTransfer>
+ </AdditionalData>
+ </EventData>
+ </Incident>
+</IODEF-Document>
+
+
+
+
+
+M'Raihi, et al. Informational [Page 26]
+
+RFC 5941 Sharing Transaction Fraud Data August 2010
+
+
+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
+
+
+Sharon Boeyen
+Entrust, Inc.
+1000 Innovation Drive
+Ottawa, ON, K2K 3E7
+Canada
+Phone: 1-613-270-3181
+EMail: 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
+
+
+Siddharth Bajaj
+VeriSign, Inc.
+487 E. Middlefield Road
+Mountain View, CA 94043
+USA
+Phone: 1-650-426-3458
+EMail: sbajaj@verisign.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 27]
+