Skip to main content

Sharing Transaction Fraud Data
draft-mraihi-inch-thraud-09

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5941.
Authors Sharon Boeyen , David M'Raihi , Michael Grandcolas , Siddharth Bajaj
Last updated 2015-10-14 (Latest revision 2009-12-22)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Reviews
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 5941 (Informational)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Tim Polk
Send notices to dmraihi@verisign.com
draft-mraihi-inch-thraud-09
Internet Draft                                  David M'Raihi 
       Category: Informational                              VeriSign 
       Document: draft-mraihi-inch-thraud-09.txt       Sharon Boeyen 
       Expires: June 2010                                    Entrust 
                                                  Michael Grandcolas 
                                               Grandcolas Consulting 
                                                                 LLC 
                                                     Siddharth Bajaj 
                                                            VeriSign 
                                                   December 22, 2009 
        
                        Sharing Transaction Fraud Data 
        
       Status of this Memo 
        
       This Internet-Draft is submitted to IETF in full conformance 
       with the provisions of BCP 78 and BCP 79. 
        
       Internet-Drafts are working documents of the Internet 
       Engineering Task Force (IETF), its areas, and its working 
       groups.  Note that other groups may also distribute working 
       documents as Internet-Drafts. 
        
       Internet-Drafts are draft documents valid for a maximum of six 
       months and may be updated, replaced, or obsoleted by other 
       documents at any time.  It is inappropriate to use Internet-
       Drafts as reference material or to cite them other than as "work 
       in progress." 
        
       The list of current Internet-Drafts can be accessed at  
       http://www.ietf.org/ietf/1id-abstracts.txt. 
        
       The list of Internet-Draft Shadow Directories can be accessed at 
       http://www.ietf.org/shadow.html. 
        
       This Internet-Draft will expire on June 22, 2010. 
        
       Copyright Notice 
        
       Copyright (c) 2009 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 BSD License.
        
        
   
   
        
                     Sharing Transaction Fraud Data     December 2009 
        
       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. 

        
       M'RAIHI            Expires - June 2010              [Page 2] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
                          Table of Contents 
        
       1. Introduction                                               4 
       2. Requirements Terminology                                   5 
       3. Anatomy of a Transaction Fraud                             5 
       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                                            12 
       5.2.4. TransferAmount                                         13 
       5.3. FraudEventIdentityType Class                             13 
       5.3.1. IdentityComponent                                      13 
       5.4. FraudEventOtherType Class                                14 
       5.4.1. OtherEventType                                         14 
       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                                    15 
       6. IODEF Profile for an Activity Thraud Report                16 
       6.1. Mandatory components                                     16 
       6.2. Recommended Components                                   16 
       6.3. Deprecated Components                                    17 
       7. IODEF profile for a Signature Thraud Report                18 
       8. IODEF Additional Attribute Values                          19 
       8.1. Purpose Attribute                                        19 
       9. Security considerations                                    19 
       10. IANA considerations                                       20 
       10.1. Media sub-type                                          20 
       10.2. XML namespace                                           21 
       11. Conclusion                                                21 
       12. References                                                22 
       12.1. Normative                                               22 
       12.2. Informative                                             22 
       13. Authors' Addresses                                        22 
       Appendix A.  Thraud Record XML Schema                         24 
       Appendix B.  Example of a Thraud Report                       25 
        

        
       M'RAIHI            Expires - June 2010              [Page 3] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
       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 SOAP). And outbound reports will either be 
       distributed using 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. But, 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. In section 6 we describe the Activity 
       Thraud Report profile of the IODEF specification. And in section 
       7 the profile for a Signature Thraud Report is described. In 
       section 8 we define new attribute values for the IODEF Incident 
        
       M'RAIHI            Expires - June 2010              [Page 4] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
       class. Security considerations are described in section 9. And, 
       section 10 contains a request to IANA to register 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]. 
        
       3.           Anatomy of a Transaction Fraud 
        
       The actors in a typical transaction fraud are shown in Figure 1. 

        
       M'RAIHI            Expires - June 2010              [Page 5] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
       +--------------------------------------+ 
       |             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 are individuals or organizations that collect 
       victims' login credentials using a variety of means, including 
       phishing and malware, and verify them (usually by attempting to 
       login 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. 
        
           2. Fraud Executors are individuals who attempt the 
       fraudulent funds transfer or payment. In the case of fraudulent 
       funds transfers, an account at 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. 
        
       M'RAIHI            Expires - June 2010              [Page 6] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
        
           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            Expires - June 2010              [Page 7] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
         +-------------+ 
         | 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 AddtionalData: 
       FraudEventPayment, FraudEventTransfer, FraudEventIdentity and 
       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 
        
       A funds-transfer Thraud Record SHALL be structured as shown in 
       Figure 4. See also section 5.2. 
        
        
       M'RAIHI            Expires - June 2010              [Page 8] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
              +------------------+ 
              | 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 
       oragnizations 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            Expires - June 2010              [Page 9] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
              +-------------+ 
              | 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 Sections 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            Expires - June 2010              [Page 10] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
              +--------------+ 
              | 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. 
        
            http://www.openauthentication.org/thraud/resources/bank-id-
            namespace.htm#american_bankers_association 
         
       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#canadian_payments_association 
        

        
       M'RAIHI            Expires - June 2010              [Page 11] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
       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#iso13616_1_2007 
        
       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#iso9362_1994 
        
       The eight character Bank Identifier Code [ISO9362:1994] 
       registered to the financial organization that holds the account, 
       as administered by SWIFT. 
        
       Other namespace values MUST be agreed between 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. So, 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. 
        
       5.2.3.               AccountType 
        
       Zero or one value of type thraud:AccountTypeType. See section 
       5.6. 
        
       M'RAIHI            Expires - June 2010              [Page 12] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
        
       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".  
        
       5.3.1.2.                 UserID 
        
       In reporting an identity fraud event, the reporting institution 
       MAY include the victim's user id. This SHALL be achieved by 
       placing an object of type iodef:ExtensionType in the 
       IdentityComponent object. The data type of the extension 
        
       M'RAIHI            Expires - June 2010              [Page 13] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
       contents SHALL be xs:string. It SHALL contain the user id 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 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. 
        

        
       M'RAIHI            Expires - June 2010              [Page 14] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
       A list of registered other event type identifiers is maintained 
       at: 
        
            http://www.openauthentication.org/thraud/resources/other-
            event-type 
        
       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]. 
        
       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. 

        
       M'RAIHI            Expires - June 2010              [Page 15] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
        
              +-----------------+ 
              | 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 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. 
        
       6.2.             Recommended Components 
        
       Receiving organizations SHOULD be capable of processing the 
       following components.  However, they MUST NOT reject documents 
       either because they are present or absent. 
        

        
       M'RAIHI            Expires - June 2010              [Page 16] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
       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 
       Incident.History 
       Incident.AdditionalData 
       Incident.ext-purpose 
       Incident.IncidentID.instance 
       Incident.Contact.Description 
       Incident.Contact.RegistyHandle 
       Incident.Contact.PostalAddress 
       Incident.Contact.Fax 
       Incident.Contact.TimeZone 
        
       M'RAIHI            Expires - June 2010              [Page 17] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
       Incident.Contact.AdditionalData 
       Incident.Contact.Contact.Description 
       Incident.Contact.Contact.RegistyHandle 
       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 
        
       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. 
        

        
       M'RAIHI            Expires - June 2010              [Page 18] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
       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. 
        
       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. 
        
       M'RAIHI            Expires - June 2010              [Page 19] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
        
       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. 
        
       10.            IANA considerations 
        
       This specification proposes the registration of two identifiers: 
        
        - The media sub-type name 'thraud+xml' in the standard 
       registration tree. 
        
        - 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. 
        
        
       M'RAIHI            Expires - June 2010              [Page 20] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
       Optional parameters: 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: this registration has all of the 
       security considerations described in [RFC3023] in addition to 
       those in section 9, above. 
        
       Interoperability considerations: this registration has all of 
       the interoperability considerations described in [RFC3023]. 
        
       Published specification: the media type data format is defined 
       in this specification. 
        
       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, dmraihi@verisign.com 
        
       Intended usage - LIMITED USAGE 
        
       Restrictions on usage: thraud media are intended for no usage 
       other than the exchange of fraud intelligence data. 
        
       Author: D M'Raihi 
        
       Change controller: D M'Raihi 
        
       10.2.              XML namespace 
        
       IANA is requested to register the xml namespace identifier: 
       urn:ietf:params:xml:ns:thraud-1.0. 
        
       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. 
        

        
       M'RAIHI            Expires - June 2010              [Page 21] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
       12.            References 
        
       12.1.              Normative 
        
           [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]  S. Bradner, "Key words for use in RFCs to 
       Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 
        
           [RFC3023]  M. Murata, "XML Media Types", RFC 3023, Jan 2001. 
        
           [RFC4519]  A. Sciberras, "Schema for User Applications", RFC 
       4519, June 2006. 
        
           [RFC5070]  R. Danyliw, The Incident Object Description 
       Exchange Format, RFC 5070, December 2007, available at: 
       http://www.rfc-editor.org/rfc/rfc5070.txt 
        
       12.2.              Informative 
        
           [UML]      Information technology - Open Distributed 
       Processing - Unified Modeling Language (UML) Version 1.4.2, 
       ISO/IEC 19501:2005. 
        
       13.            Authors' Addresses 
        
           Primary point of contact (for sending comments and 
       questions): 
        
           David M'Raihi 
           VeriSign, Inc. 
           685 E. Middlefield Road 
           Mountain View          Phone: 1-650-426-3832 
           CA 94043 USA           Email: dmraihi@verisign.com 
        
           Other Authors' contact information: 
        
           Sharon Boeyen 
           Entrust Inc. 
           1000 Innovation Drive  Phone: 1-613-270-3181 
           Ottawa, ON, K2K 3E7    Email: sharon.boeyen@entrust.com 
        
           Michael Grandcolas 
           Grandcolas Consulting LLC. 
        
       M'RAIHI            Expires - June 2010              [Page 22] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
           247 Ocean Park Blvd.   Phone: 1-310-399-1747 
           Santa Monica, Ca 90405 Email: michael.grandcolas@hotmail.com 
        
           Siddharth Bajaj 
           VeriSign, Inc. 
           487 E. Middlefield Road 
           Mountain View          Phone: 1-650-426-3458 
           CA 94043 USA           Email: sbajaj@verisign.com 
        

        
       M'RAIHI            Expires - June 2010              [Page 23] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
        
       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"> 
         <xs:sequence> 
          <xs:element name="OtherEventType" type="xs:anyURI"/> 

        
       M'RAIHI            Expires - June 2010              [Page 24] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
          <xs:element name="PayeeName" type="iodef:MLStringType" 
       minOccurs="0"/> 
          <xs:element name="PostalAddress" type="iodef:MLStringType" 
       minOccurs="0"/> 
          <xs:element name="BankID" type="thraud:BankIDType" 
       minOccurs="0"/> 
          <xs:element name="AccountID" type="xs:string" minOccurs="0"/> 
          <xs:element name="AccountType" type="iodef:MLStringType" 
       minOccurs="0"/> 
          <xs:element name="PayeeAmount" type="thraud:AmountType" 
       minOccurs="0"/> 
          <xs:element name="OtherEventDescription" 
       type="iodef:MLStringType" minOccurs="0"/> 
         </xs:sequence> 
        </xs:complexType> 
        <xs:complexType name="AmountType"> 
         <xs:simpleContent> 
          <xs:extension base="xs:decimal"> 
           <xs:attribute name="currency" type="xs:string"/> 
          </xs:extension> 
         </xs:simpleContent> 
        </xs:complexType> 
        <xs:complexType name="BankIDType"> 
         <xs:simpleContent> 
          <xs:extension base="xs:string"> 
           <xs:attribute name="namespace" type="xs:anyURI" 
       use="required"/> 
          </xs:extension> 
         </xs:simpleContent> 
        </xs:complexType> 
        <xs:element name="UserId" type="xs:string"/> 
       </xs:schema> 
        
       Appendix B.  Example of a Thraud Report 
        
       <?xml version="1.0" encoding="UTF-8"?> 
       <IODEF-Document xmlns="urn:ietf:params:xml:ns:iodef-1.0" 
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
       xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-1.0 
       http://www.cert.org/ietf/inch/schema/rfc5070.xsd" 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> 
        
       M'RAIHI            Expires - June 2010              [Page 25] 
        
        
                     Sharing Transaction Fraud Data     December 2009 
        
           </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  
       http://www.openauthentication.org/thraud/Schema1-0.xsd"> 
            <BankID 
       namespace="http://www.openauthentication.org/thraud/resources/ba
       nk-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            Expires - June 2010              [Page 26]