Internet Draft David M'Raihi VeriSign Category: Sharon Boeyen Informational Entrust Document: Michael Grandcolas draft-mraihi-inch-thraud-02.txt Grandcolas Consulting LLC. Siddharth Bajaj VeriSign Expires: September 2007 March 2007 How to Share Transaction Fraud (Thraud) Report Data Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes a data-format and protocol for defining and exchanging Transaction Fraud (Thraud) Report Data. It extends the INCH WG's IODEF XML [IODEF] incident reporting format. Both inbound (Thraud Reports) and outbound (Thraud Watchlists) mechanisms are presented. This work has been endorsed by the Initiative for Open AuTHentication [OATH]. INCH-THRAUD Expires - September 2007 [Page 1] How to Share Transaction Fraud (Thraud) Report Data March 2007 Table of Contents 1. Introduction...............................................3 2. Requirements Terminology...................................4 3. The Elements of Transaction Fraud Activity.................4 4. Thraud Activity Reporting via an IODEF-Document Incident...5 5. Fraud Report Class Definitions.............................7 5.1. The FraudEventPayment class..............................8 5.1.1. PayeeName...............................................9 5.1.2. PayeeAddressLine1.......................................9 5.1.3. PayeeAddressLine2.......................................9 5.1.4. PayeeCity...............................................9 5.1.5. PayeePostalCode.........................................9 5.1.6. PayeeCountry............................................9 5.1.7. PayeeAmount.............................................9 5.2. The FraudEventTransfer class.............................9 5.2.1. BankID.................................................10 5.2.2. AccountID..............................................10 5.2.3. AccountType............................................10 5.2.4. TransferAmount.........................................10 5.3. The FraudEventIdentity class............................10 5.3.1. Component..............................................10 5.3.2. EmailAddress...........................................10 5.3.3. UserID.................................................11 5.4. The FraudEventOther class...............................11 5.4.1. OtherEventType.........................................12 5.4.2. OtherEventDescription..................................12 5.5. The PayeeAmount class...................................12 5.5.1. Class contents.........................................13 5.5.2. Currency...............................................13 5.6. The TransferAmount class................................13 5.6.1. Class contents.........................................13 5.6.2. Currency...............................................13 5.7. The AccountType class...................................13 6. IODEF Required Classes....................................14 6.1. Mandatory contents......................................14 6.2. Optional contents.......................................15 6.3. Fraud Event Signature Report............................16 7. IODEF Extensions..........................................16 7.2. purpose attribute.......................................16 8. Security Considerations...................................17 8.2. Thraud Data Authenticity and Integrity..................17 8.3. Thraud Data Confidentiality and Privacy.................17 8.4. Data Protection During Transit..........................17 9. IANA Considerations.......................................18 10. Conclusion................................................18 11. Acknowledgements..........................................18 12. References................................................18 INCH-THRAUD Expires - September 2007 [Page 2] How to Share Transaction Fraud (Thraud) Report Data March 2007 12.1. Normative...............................................18 12.2. Informative.............................................18 Appendix A. Fraud Extensions XML Schema.......................18 Appendix B. Example of a Thraud Report........................21 13. Authors' Addresses........................................21 14. Full Copyright Statement..................................22 15. Intellectual Property.....................................22 1. Introduction Financial institutions and merchants are confronted with online fraud attacks targeted against their customers through various means. Today there is no standardized data format and open protocol that organizations and law enforcement can use to share known/suspicious transaction fraud data. There is a clear opportunity for creating an open framework to enable organizations, using a variety of fraud monitoring products, to contribute information related to known or suspicious fraud activity. The very same framework should also formalize mechanisms for distributing correlated updates to all participating members. This internet draft introduces a data format to facilitate interoperability and exchange of transaction-related fraud data. More specifically, this document describes a data-format and protocol for defining and exchanging Transaction Fraud (Thraud) Report Data. It extends the INCH WG's IODEF XML [IODEF] incident reporting Format. Any verified organization can contribute online fraud attack records via openly defined protocols. The specific focus of this document is the proposal of XML document definitions for Fraud Reports and the protocols by which they can be exchanged. The document proposes a definition for both inbound (Thraud Reports) and outbound (Thraud Watchlists) mechanisms. In section 3 we introduce the different components of a transaction fraud. The reporting method via an IODEF-document is described in section 4, and we define the report elements in section 5. In the next section we describe the required elements with respect to the IODEF format and follow with security considerations in section 7. INCH-THRAUD Expires - September 2007 [Page 3] How to Share Transaction Fraud (Thraud) Report Data March 2007 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. The Elements of Transaction Fraud Activity +-------------------------------------+ | Fraudsters | | (collect & verify victim credentials| | via phishing, malware etc.} | +-------------------------------------+ | |recruit | |< ----------------------share profits------------------------ | ^ | | +-----------+ +--------------+ +--------+ | Fraud | | | | | | Executors | | Financial |----|Fraud | | | | Organization | |Dest. | | |--Open Dest. Account-->| | |Account | | | +--------------+ +--------+ | | ^ | | +--------------+ | | |--Attempt Transfer --->| Victim | +-------+ | | | Financial | |Victim | | | | Organization |--o--|Account| +-----------+ +--------------+ | +-------+ | +-----------+ | Fraud | | Detection | | Sensors | | (realtime/| | offline) | +-----------+ Figure 1. Transaction Fraud Elements INCH-THRAUD Expires - September 2007 [Page 4] How to Share Transaction Fraud (Thraud) Report Data March 2007 Transaction Fraud Activities are normally composed of the following entities: 1. The Fraudsters who collect victim's login credentials via various means, such as phishing, malware etc. And then verify (usually through login attempts) that those credentials are correct. At that time Fraudsters may either recruit Fraud executors directly or wholesale the collected credentials to other Fraudsters who will do the recruiting of the Fraud executors. 2. The Fraud Executors are those that actually will attempt the fraudulent transfer or payment. For fraudulent transfers, legitimate accounts at the same financial organization or a different one from the victim will be set up as the destination account for the fraudulent transfer. Alternatively a fraudulent payment attempt via check or electronic transfer to a named destination is attempted. 3. The Victims of both credential theft and transaction fraud. 4. The Financial Organization who holds either the victim/fraudster's accounts. 5. Sensors at the Financial Organization who attempt to detect fraudulent transaction attempts, either in realtime or offline. The intention of Thraud Reporting is to enable any organization that has detected fraud to share this information with other organizations. The receiving organization can use this information appropriately. For example, it could require manual review of transactions from 'risky' IP addresses that have been reported. 4. Thraud Activity Reporting via an IODEF-Document Incident A Thraud Activity Report is an instance of an XML IODEF-Document. Generally, these reports include added EventData, AdditionalData elements. The added elements compose a ThraudRecord Element. There may be multiple ThraudRecord Elements in a Thraud Activity Report. Required information with many optional items is populated into the ThraudRecord structure to a form a Thraud Activity Report. If the Thraud Activity Report describes a particular pattern of behaviour,or fraud event signature as described in section 6.3, rather than a specific fraud event, these additional elements may not be included. There are actually two types of Thraud Activity Reports an "inbound" and an "outbound" report. The "inbound" report is from a reporting organization to describe a transaction fraud. The "outbound" report is destined to subscribers, either through a INCH-THRAUD Expires - September 2007 [Page 5] How to Share Transaction Fraud (Thraud) Report Data March 2007 subscription or following a query to obtain (possibly correlated) information about fraud elements. The primary difference in the "inbound" and "outbound" reports is the removal in the "outbound" reports of reporting organization information in order to protect confidentiality. We elaborate on this aspect in section 7, Security Considerations. This document defines new EventData IODEF XML elements; then identifies the attributes that are required in a compliant Thraud Activity Report. The Appendicies contain sample Thraud Activity Reports and the complete XML Document Type Definition and schema. The Incident element with fraud extensions is summarized below. It provides a standardized representation for commonly exchanged incident data. For "inbound" reports it contains a unique identifier that is name spaced qualified by the domain name of the reporting organization. In "outbound" reports it contains an opaque unique identifier to protect privacy of data sources. The data elements in this document are expressed in Unified Modeling Language (UML) syntax. +------------------+ | Incident | +------------------+ | ENUM purpose |<>----------[ IncidentID ] | ENUM restriction |<>--{0..1}--[ AlternativeID ] | |<>--{0..1}--[ RelatedActivity ] | |<>--{0..*}--[ Description ] | |<>--{1..*}--[ Assessment ] | |<>--{0..*}--[ Method ] | |<>--{0..1}--[ DetectTime ] | |<>--{0..1}--[ StartTime ] | |<>--{0..1}--[ EndTime ] | |<>----------[ ReportTime ] | |<>--{1..*}--[ Contact ] | |<>--{0..*}--[ Expectation ] | |<>--{0..1}--[ History ] | |<>--{0..*}--[ EventData ] | | --> [ AdditionalData ] | | --> ThraudRecord (added) +------------------+ Figure 2. IODEF and Thraud Reporting INCH-THRAUD Expires - September 2007 [Page 6] How to Share Transaction Fraud (Thraud) Report Data March 2007 A Thraud Activity Report is composed of one IODEF Incident element, containing one or more EventData elements that contain one or more ThraudRecord elements. This document describes ThraudRecord elements for the EventData. AdditionalData element containing transaction fraud-related information that does not map to existing Incident or EventData attributes. One Incident report may contain information on multiple incidents. After the report identification information listed in the Incident element, each individual transaction fraud event is detailed within a single EventData structure. 5. Fraud Report Class Definitions A fraud report consists of an extension to the Incident.EventData.AdditionalData Element. The contents of the extension are associated with the dtype value 'xml'. The components of the fraud report identify and capture information related to payment fraud, transfer fraud, identity fraud and other types of fraud. A payment fraud report is structured as follows. +--------------------------+ | EventData.AdditionalData | +--------------------------+ | ENUM dtype (xml) |<>---------[ FraudEventPayment ] | | +--------------------------+ Figure 3. The FraudEventPayment extension A funds transfer fraud report is structured as follows. +--------------------------+ | EventData.AdditionalData | +--------------------------+ | ENUM dtype (xml) |<>---------[ FraudEventTransfer ] | | +--------------------------+ Figure 4. The FraudEventTransfer extension An identity fraud report is structured as follows. INCH-THRAUD Expires - September 2007 [Page 7] How to Share Transaction Fraud (Thraud) Report Data March 2007 +--------------------------+ | EventData.AdditionalData | +--------------------------+ | ENUM dtype (xml) |<>---------[ FraudEventIdentity ] | | +--------------------------+ Figure 5. The FraudEventIdentity extension An other fraud report is structured as follows. +--------------------------+ | EventData.AdditionalData | +--------------------------+ | ENUM dtype (xml) |<>------[ FraudEventOther ] | | +--------------------------+ Figure 6. The FraudEventOther extension 5.1. The FraudEventPayment class The FraudEventPayment class is used to report the 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 institutions may be able to stop future fraudulent payment attempts to the same payee. The structure of the FraudEventPayment class is as follows: +--------------------------+ |FraudEventPayment | +--------------------------+ | |<>--{0..1}--[ PayeeName ] | |<>--{0..1}--[ PayeeAddressLine1 ] | |<>--{0..1}--[ PayeeAddressLine2 ] | |<>--{0..1}--[ PayeeCity ] | |<>--{0..1}--[ PayeePostalCode ] | |<>--{0..1}--[ PayeeCountry ] | |<>--{0..1}--[ PayeeAmount] | | +--------------------------+ Figure 7. The FraudEventPayment class The components of the FraudEventPayment class are described below. INCH-THRAUD Expires - September 2007 [Page 8] How to Share Transaction Fraud (Thraud) Report Data March 2007 5.1.1. PayeeName Zero or one value of STRING. The name of the payee. 5.1.2. PayeeAddressLine1 Zero or one value of STRING. The first line of the address of the payee. 5.1.3. PayeeAddressLine2 Zero or one value of STRING. The second line of the address of the payee. 5.1.4. PayeeCity Zero or one value of STRING. The city of the payee. 5.1.5. PayeePostalCode Zero or one value of STRING. The postal code of the payee. 5.1.6. PayeeCountry Zero or one value of STRING. The country of the payee. 5.1.7. PayeeAmount Zero or one instances of type AmountType. 5.2. The FraudEventTransfer class The FraudEventTransfer 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 institutions may be able to stop future fraudulent funds transfer attempts to the same payee. +---------------------------+ |FraudEventTransfer | +---------------------------+ | |<>--{0..1}--[ BankID ] | |<>--{0..1}--[ AccountID ] | |<>--{0..1}--[ AccountType ] | |<>--{0..1}--[ TransferAmount ] | | +---------------------------+ INCH-THRAUD Expires - September 2007 [Page 9] How to Share Transaction Fraud (Thraud) Report Data March 2007 Figure 8. The FraudEventTransfer class The components of the FraudEventTransfer class are described below. 5.2.1. BankID Zero or one value of STRING. The destination bank routing transit ID or other FI id. 5.2.2. AccountID Zero or one value of STRING. The destination primary account number. 5.2.3. AccountType Zero or one instance of type AccountTypeType. 5.2.4. TransferAmount Zero or one instance of type AmountType. 5.3. The FraudEventIdentity class The FraudEventIdentity 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 future fraudulent impersonation attempts. +-------------------------+ |FraudEventIdentity | +-------------------------+ | |<>--{0..*}--[ IdentityComponent] | | +-------------------------+ Figure 9. The FraudEventIdentity class The components of the FraudEventIdentity class are described below. 5.3.1. Component Zero to many instances of type iodef:ExtensionType. This specification defines two extensions: EmailAddress and UserID. 5.3.2. EmailAddress INCH-THRAUD Expires - September 2007 [Page 10] How to Share Transaction Fraud (Thraud) Report Data March 2007 In reporting an identity fraud event, the reporting institution MAY include the victim's email address. This SHALL be achieved by adding an element of type iodef:ExtensionType in the IdentityComponent element. The data type of the extension contents SHALL be xs:string. It SHALL contain the email address 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 email address". 5.3.3. UserID In reporting an identity fraud event, the reporting institution MAY include the victim's user id. This SHALL be achieved by adding an element of type iodef:ExtensionType in the IdentityComponent element. The data type of the extension 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. The FraudEventOther class The FraudEventOther class is used to report fraudulent events other than those detailed above, such as new event types that emerge and become problematic. This class enables such events to be reported, using this same specification and format, even though the specific characteristics of such events have not yet been formally structured and formatted. By reporting the details of these unspecified event types, other institutions may be able to stop future fraudulent activity. The structure of the FraudEventOther class is as follows: +--------------------------+ |FraudEventOther | +--------------------------+ | |<>--{1..*}--[ OtherEventType ] | |<>--{0..1}--[ PayeeName ] | |<>--{0..1}--[ PayeeAddressLine1 ] | |<>--{0..1}--[ PayeeAddressLine2 ] | |<>--{0..1}--[ PayeeCity ] INCH-THRAUD Expires - September 2007 [Page 11] How to Share Transaction Fraud (Thraud) Report Data March 2007 | |<>--{0..1}--[ PayeePostalCode ] | |<>--{0..1}--[ PayeeCountry ] | |<>--{0..1}--[ BankID ] | |<>--{0..1}--[ AccountID ] | |<>--{0..1}--[ AccountType ] | |<>--{0..1}--[ PayeeAmount ] | |<>--{0..1}--[ OtherEventDescription ] | | +--------------------------+ Figure 10. The FraudEventOther class Many of the components of the FraudEventOther class are also components of the FraudEventPayment or FraudEventTransfer class. Their use in the FraudEventOther class is identical. Therefore the descriptions are not duplicated here. The components that are unique to the FraudEventOther class are described below. 5.4.1. OtherEventType One or more values of STRING. A name that classifies the activity. 5.4.2. OtherEventDescription Zero or one values of STRING. A free form textual description of the activity. 5.5. The PayeeAmount class The PayeeAmount class is used to report the amount of the payment fraud, which may be common across a set of related fraud attempts. +--------------------+ |PayeeAmount | +--------------------+ | DECIMAL | | | | STRING currency | | | +--------------------+ Figure 11. The PayeeAmount class The components of the PayeeAmount class are described below. INCH-THRAUD Expires - September 2007 [Page 12] How to Share Transaction Fraud (Thraud) Report Data March 2007 5.5.1. Class contents Required DECIMAL. The amount of the payment. 5.5.2. Currency Required STRING. The three letter currency code. 5.6. The TransferAmount class The TransferAmount class is used to report the amount of the funds transfer fraud, which may be common across a set of related fraud attempts. +--------------------+ |TransferAmount | +--------------------+ | DECIMAL | | | | STRING currency | | | +--------------------+ Figure 12. The TransferAmount class The components of the TransferAmount class are described below. 5.6.1. Class contents Required DECIMAL. The amount of the funds transfer. 5.6.2. Currency Required STRING. The three letter currency code. 5.7. The AccountType class The AccountType class is used to report the type of the destination account. +--------------------+ |AccountType | +--------------------+ | ENUM (brokerage | | | checking | | | corporate | | | mortgage | | INCH-THRAUD Expires - September 2007 [Page 13] How to Share Transaction Fraud (Thraud) Report Data March 2007 | retirement | | | saving) | | | +--------------------+ Figure 13. The AccountType class Required ENUMERATION. Enumerated values are: 'brokerage', 'checking', 'corporate', 'mortgage', 'retirement' and 'saving'. 6. IODEF Required Classes This section identifies elements of the IODEF Incident class in a compliant fraud report. +--------------+ | Incident | +--------------+ | ENUM Purpose |---[ IncidentID ] | |---[ ReportTime ] | |---[ Assessment ] | | ---> [ Impact ] | | ---> [ Confidence ] | |---[ Contact ] | | ---> [ ContactName ] | | ---> [ Email ] | | ---> [ Contact ] | | ---> [ ContactName ] | | ---> [ Email ] | | ---> [ Telephone ] | |---[ EventData ] | | ---> [ DetectTime ] | | ---> [ Flow ] | | | ---> [ System ] | | | ---> [ Node ] | | | ---> [ Service ] | | | | ---> [ Application ] | | | ---> [ Address ] | | | | ---> [ vlan-num ] | | | ---> [ Location ] | | | ---> [ NodeName ] | | ---> [ AdditionalData ] | | ---> [ FraudEventXXX ] +--------------+ Figure 14. IODEF Required classes 6.1. Mandatory contents INCH-THRAUD Expires - September 2007 [Page 14] How to Share Transaction Fraud (Thraud) Report Data March 2007 A compliant IODEF fraud report SHALL contain data items as described below: Purpose - See Section 7.1. IncidentID - As defined by IODEF. ReportTime - As defined by IODEF. Assessment.Impact - As defined by IODEF. Assessment.Confidence - As defined by IODEF. Contact.Email - A contact email address for the reporting institution. Contact.ContactName - The name of the reporting institution. In case the reporting institute has consolidated reports from other institutions, elements of this class MAY contain the name of the consolidator, instead of the original reporting institution. EventData.DetectTime - The date and time at which the fraud or fraud attempt was detected. This data item is mandatory for specific fraud event reports. However it is optional for fraud event signature reports described in 6.3. 6.2. Optional contents A compliant IODEF fraud report SHOULD contain data items as described below. Contact.Contact.ContactName - The name of the reporting fraud analyst. Contact.Contact.Email - The email address of the reporting fraud analyst. Contact.Contact.Telephone - The telephone number of the reporting fraud analyst. EventData.Flow.System.Service.Application - Information about the software used by the attacker, including the type and version of operating system, communication and application software. EventData.Flow.System.Node.Addres.vlan-num - The IPv4 or IPv6 address or subnet mask, depending upon the accompanying value of the 'Address@category' attribute. INCH-THRAUD Expires - September 2007 [Page 15] How to Share Transaction Fraud (Thraud) Report Data March 2007 EventData.Flow.System.Node.Location - The name and address of the owner of the DNS domain from which the fraud or fraud attempt was executed. EventData.Flow.System.Node.NodeName - As defined by IODEF. 6.3. Fraud Event Signature Report A fraud event signature report conveys information about the behavior associated with fraudulent events, rather than reporting the specific events themselves. An example of a fraud event signature might include a customer performing a wire transfer of over $5,000.00 views email address and wire transfer within a single session, has changed email address within the past 2 weeks and performed at least 2 bill payments to the same payee within a single week. Sharing fraud event signature information enables recipients to detect similar behavior in their own systems. A fraud event signature report contains data items as shown below: Purpose - Includes value "reporting". IncidentID - As defined by IODEF. ReportTime - As defined by IODEF. Assessment.Impact - Includes the severity attribute. Method.Reference.ReferenceName - A name for the specific fraud event signature. Method.URL - A URL that represents the detailed definition of the fraud event signature. Method.Description - A brief description of the behavior covered by the fraud event signature. Contact.Email - A contact email address for the reporting institution. Contact.ContactName - The name of the reporting institution. 7. IODEF Extensions 7.2. purpose attribute The following additional values are defined for the IODEF.Incident@purpose attribute. INCH-THRAUD Expires - September 2007 [Page 16] How to Share Transaction Fraud (Thraud) Report Data March 2007 Add - The identified fraud event SHOULD be added to the corpus by the recipient. delete - The identified fraud event SHOULD be deleted from the corpus by the recipient. Modify - The identified elements of the fraud event SHOULD be replaced in the corpus by the supplied values. Where no corresponding element exists in the corpus, the element SHOULD be added to the corpus by the recipient. 8. Security Considerations This document focuses on the data format for exchanging transaction fraud data. The critical security concerns are the validity of submitted information (Thraud Reports) and outbound information (Thraud Watchlists) sent upon a query, as well as the protection of contributors privacy when sharing the data. 8.2. Thraud Data Authenticity and Integrity The Thraud Reports SHOULD be digitally signed. This would guarantee the origin and integrity of the submitted information. A possible method is to use the optional IODEF XML signature as defined in [IODEF]. The potential recipients of Thraud Reports SHOULD be able to verify these digital signatures. 8.3. Thraud Data Confidentiality and Privacy The Thraud Reports MAY be encrypted when stored for future usage. Contributors of Thraud Reports might not be willing to disclose fraudulent transactions attached to their name. A simple mechanism MUST enable the query of any data to return a valid reponse without disclosing the unique Identifier of a specific organization. We suggest to use an opaque identifier for each report in order to index privately the reports. A hash function (e.g. SHA-1) MAY be used to generate the opaque identifier from the organization name: OpaqueIdentifier = SHA-1() The OpaqueIdentifier can be used to reference the report without disclosing the full organization identity. 8.4. Data Protection During Transit In addition to protecting thraud data when stored, the data also needs to be protected during transit. This specification does not INCH-THRAUD Expires - September 2007 [Page 17] How to Share Transaction Fraud (Thraud) Report Data March 2007 mandate a particular transport protocol for transmitting thraud data. However, the protocol must enable the thraud data to be digitally signed and encrypted during transit. It is recommended that commonly used secure protocols, such as HTTPS, SSL and SOAP over EV SSL be used. 9. IANA Considerations This document has no actions for IANA. 10. Conclusion This internet draft introduced Transaction Fraud (Thraud) reporting mechanisms to enable the sharing of Fraud data. Based on the IODEF- document format, the proposed extension should facilitate interoperability and provide increase security for online applications. 11. Acknowledgements We would like to thank Tim Moses for his extremely valuable contribution to completing this draft document. 12. References 12.1. Normative [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3668] S. Bradner, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 12.2. Informative [OATH] Initiative for Open AuTHentication http://www.openauthentication.org [IODEF] R. Danyliw, J. Meijer and Y. Demchenko, The Incident Object Description Exchange Format http://tools.ietf.org/wg/inch/draft-ietf-inch-iodef/draft-ietf- inch-iodef-10.txt Appendix A. Fraud Extensions XML Schema INCH-THRAUD Expires - September 2007 [Page 19] How to Share Transaction Fraud (Thraud) Report Data March 2007 INCH-THRAUD Expires - September 2007 [Page 20] How to Share Transaction Fraud (Thraud) Report Data March 2007 Appendix B. Example of a Thraud Report 908711 2006-10-12T00:00:00-07:00 Open Authentication contact@openauthentication-fraud.com 2006-10-12T07:42:21-08:00
192.0.2.53
 Source of numerous attacks 1234567 3456789 saving 10000 13. Authors' Addresses Primary point of contact (for sending comments and question): David M'Raihi INCH-THRAUD Expires - September 2007 [Page 21] How to Share Transaction Fraud (Thraud) Report Data March 2007 VeriSign, Inc. 685 E. Middlefield Road Phone: 1-650-426-3832 Mountain View, 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. 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 Phone: 1-650-426-3458 Mountain View, CA 94043 USA Email: sbajaj@verisign.com 14. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 15. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. INCH-THRAUD Expires - September 2007 [Page 22] How to Share Transaction Fraud (Thraud) Report Data March 2007 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. INCH-THRAUD Expires - September 2007 [Page 23]