Internet Draft David M'Raihi Category: Informational VeriSign Document: draft-mraihi-inch-thraud-07.txt Sharon Boeyen Expires: January 2009 Entrust Michael Grandcolas Grandcolas Consulting LLC Siddharth Bajaj VeriSign July 2008 Sharing Transaction Fraud 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 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. Sharing Transaction Fraud Data July 2008 Table of Contents 1. Introduction 3 2. Requirements Terminology 4 3. Anatomy of a Transaction Fraud 4 4. IODEF-Document Incident Class 6 5. Thraud Record Class Definitions 7 5.1. FraudEventPaymentType Class 8 5.1.1. PayeeName 9 5.1.2. PostalAddress 9 5.1.3. PayeeAmount 9 5.2. FraudEventTransferType Class 9 5.2.1. BankID 10 5.2.2. AccountID 10 5.2.3. AccountType 10 5.2.4. TransferAmount 10 5.3. FraudEventIdentityType Class 11 5.3.1. IdentityComponent 11 5.4. FraudEventOtherType Class 12 5.4.1. OtherEventType 12 5.4.2. OtherEventDescription 13 5.5. AmountType Class 13 5.5.1. Class Contents 13 5.5.2. Currency 13 5.6. AccountTypeType Class 13 6. IODEF Profile for an Activity Thraud Report 14 6.1. Mandatory components 14 6.2. Recommended Components 14 6.3. Deprecated Components 15 7. IODEF profile for a Signature Thraud Report 15 8. IODEF Additional Attribute Values 16 8.1. Purpose Attribute 16 9. Security considerations 16 10. IANA considerations 18 10.1. Media sub-type 18 10.2. XML namespace 19 11. Conclusion 19 12. References 19 12.1. Normative 19 12.2. Informative 20 13. Authors' Addresses 20 14. Full Copyright Statement 20 15. Intellectual Property 21 Appendix A. Thraud Record XML Schema 21 Appendix B. Example of a Thraud Report 23 M'RAIHI Expires - January 2009 [Page 2] Sharing Transaction Fraud Data July 2008 1. Introduction Financial institutions 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 institutions 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 institutions 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 should be submitted using a push-style protocol (such as email or SOAP). And outbound reports may 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 have been, 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 [IODEF]. 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 M'RAIHI Expires - January 2009 [Page 3] Sharing Transaction Fraud Data July 2008 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 class. Security considerations are described in section 9. 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]. 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 - January 2009 [Page 4] Sharing Transaction Fraud Data July 2008 +--------------------------------------+ | 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 M'RAIHI Expires - January 2009 [Page 5] Sharing Transaction Fraud Data July 2008 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. The Financial Organization that holds either the victim's or the Fraud Executor's account. 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 [IODEF]. The report SHALL contain at least one Incident object. 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 shown in Figure 2. M'RAIHI Expires - January 2009 [Page 6] Sharing Transaction Fraud Data July 2008 +-------------+ | 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 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 Expires - January 2009 [Page 7] Sharing Transaction Fraud Data July 2008 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 institutions 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 - January 2009 [Page 8] Sharing Transaction Fraud Data July 2008 +-------------+ | 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 [RFC 4519], 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 institutions 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 - January 2009 [Page 9] Sharing Transaction Fraud Data July 2008 +--------------+ | 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 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:string and SHALL identify the bank id numbering system (the destination bank routing transit ID or other Financial Institution id). +-------------------+ | BankIDType | +-------------------+ | STRING | | | | STRING namespace | +-------------------+ Figure 9. The BankIDType class 5.2.2. AccountID Zero or one value of type xs:string. The destination primary account number. 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. M'RAIHI Expires - January 2009 [Page 10] Sharing Transaction Fraud Data July 2008 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 | +--------------+ | |<>--{0..*}--[ IdentityComponent ] +--------------+ Figure 10. The FraudEventIdentityType class The contents of the FraudEventIdentityType class are described below. At least one component MUST be present. 5.3.1. IdentityComponent Zero 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 contents SHALL be xs:string. It SHALL contain the user id of the intended fraud victim. M'RAIHI Expires - January 2009 [Page 11] Sharing Transaction Fraud Data July 2008 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 iodef:MLString. A name that classifies the event. M'RAIHI Expires - January 2009 [Page 12] Sharing Transaction Fraud Data July 2008 5.4.2. OtherEventDescription Zero or one values 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 [ISO 4217]. 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 Recipients MUST be capable of processing contents containing spelling errors. M'RAIHI Expires - January 2009 [Page 13] Sharing Transaction Fraud Data July 2008 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 [IODEF]. The following components of that data model, while optional in IODEF, are REQUIRED in a conformant Thraud Report. Recipients MAY reject documents that do not contain all these components. Therefore, originators MUST populate them all. Except where noted, these components SHALL be interpreted as described in [IODEF]. Incident.purpose Incident.IncidentID Incident.ReportTime Incident.Assessment Incident.Assessment.Impact Incident.Assessment.Confidence Incident.Contact Incident.Contact.Email – An email address at which the reporting institution may be contacted. Incident.Contact.ContactName - The name of the reporting institution. In case the reporting institution acts as a consolidator of reports from other institutions, elements of this class SHALL contain the name of the consolidator. Incident.EventData Incident.EventData.DetectTime - The date and time at which the fraud or fraud attempt was detected. Incident.EventData.AdditionalData – SHALL contain exactly one Thraud Record. 6.2. Recommended Components Recipients SHOULD be capable of processing the following objects. However, they MUST NOT reject documents either because they are present or absent. If available, originators SHOULD include these components in Thraud Reports. Except where noted, these elements SHALL be interpreted as described in [IODEF]. Incident.Contact.Contact.ContactName - The name of the reporting fraud analyst. M'RAIHI Expires - January 2009 [Page 14] Sharing Transaction Fraud Data July 2008 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 Incident.EventData.Flow Incident.EventData.Flow.System Incident.EventData.Flow.System.Service Incident.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. Incident.EventData.Flow.System.Node Incident.EventData.Flow.System.Node.Address Incident.EventData.Flow.System.Node.Address.category Incident.EventData.Flow.System.Node.Address.vlan-num - The IPv4 or IPv6 address or subnet mask locating the node from which the fraud was executed, depending upon the accompanying value of the 'category' attribute. Incident.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. Incident.EventData.Flow.System.Node.NodeName 6.3. Deprecated Components This profile provides no guidance to recipients on the proper processing of the following components. Therefore, the originator has no assurance that the recipient will handle them in an appropriate manner and SHOULD NOT include them in a Thraud Report. However, recipients MUST NOT reject reports that contain these components. Incident.ext-purpose Incident.restriction Incident.AlternativeID Incident.RelatedActivity Incident.StartTime Incident.EndTime Incident.Description Incident.Method Incident.History Incident.AdditionalData 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. M'RAIHI Expires - January 2009 [Page 15] Sharing Transaction Fraud Data July 2008 Sharing Signature Thraud Reports enables recipients to detect suspicious behavior in their own systems. A Signature Thraud Report SHALL conform to the profile described in section 6, with the exception that the following additional components MUST be included. Except where noted, these elements SHALL be interpreted as described in [IODEF]. Incident.Assessment.Impact.severity Incident.Method.Reference.ReferenceName - A name that identifies the Signature Thraud Report. Incident.Method.URL - A URI that identifies the signature. It is NOT REQUIRED that the URI be dereferenceable. Incident.Method.Description - A brief description of the behavior covered by the signature. 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 recipient. Delete - The enclosed Thraud Record types SHOULD be deleted from the corpus by the recipient. 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 recipient. 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. M'RAIHI Expires - January 2009 [Page 16] Sharing Transaction Fraud Data July 2008 Fraudsters may attempt to introduce reports that delete or modify incident information in the corpus. Therefore, origin authentication MUST be employed. Human review SHOULD be performed prior to implementing modifications to the corpus. Fraudsters may attempt to interrupt or redirect submissions, thereby preventing the sharing of intelligence concerning their fraud strategies. Therefore, authenticated receipts SHOULD be employed. Fraudsters may attempt to impersonate legitimate submitters, thereby poisoning their reputations, and rendering ineffective their future submissions. Origin authentication MUST be used to ensure that the sources of reports are properly identified. Fraudsters that can view incident reports may adapt their fraud strategies to avoid detection. Therefore, reports MUST be protected by confidentiality services including transport encryption and access control. In order to prevent inadvertent disclosure of incident data, incident reports SHOULD be encrypted while in storage. The submitter of an incident report may incorrectly identify legitimate activity as a fraud incident. This may lead to denial of service by an entity that relies on the report or information derived from the report. Relying parties 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. Relying parties SHOULD use reports to step-up authentication assurance, rather than simply deny service. A relying party 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 submitters 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. M'RAIHI Expires - January 2009 [Page 17] Sharing Transaction Fraud Data July 2008 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: same as the charset parameter of application/xml as specified in RFC3023. Optional parameters: none 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 numbers: see RFC3023 File extension: xml Macintosh file type codes: none M'RAIHI Expires - January 2009 [Page 18] Sharing Transaction Fraud Data July 2008 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 transaction fraud (Thraud) reporting mechanisms that enable 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 [IODEF] R. Danyliw, J. Meijer and Y. Demchenko, The Incident Object Description Exchange Format, available at: http://tools.ietf.org/wg/inch/draft-ietf-inch-iodef/draft-ietf- inch-iodef-10.txt [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 3023] M. Murata, "XML Media Types", RFC 3023, Jan 2001. [ISO 4217] International Organization for Standardization, "International Standard: Codes for the representation of currencies and funds, ISO 4217:2001", August 2001. [RFC 4519] Sciberras, A., "Schema for User Applications", RFC 4519, June 2006. M'RAIHI Expires - January 2009 [Page 19] Sharing Transaction Fraud Data July 2008 12.2. Informative [UML] ISO/IEC 19501:2005 Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2. 13. Authors' Addresses Primary point of contact (for sending comments and question): 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. 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 14. Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 M'RAIHI Expires - January 2009 [Page 20] Sharing Transaction Fraud Data July 2008 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. 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. Appendix A. Thraud Record XML Schema M'RAIHI Expires - January 2009 [Page 21] Sharing Transaction Fraud Data July 2008 M'RAIHI Expires - January 2009 [Page 22] Sharing Transaction Fraud Data July 2008 Appendix B. Example of a Thraud Report 908711 2006-10-12T00:00:00-07:00 Open Authentication contact@example.com 2006-10-12T07:42:21-08:00
192.0.2.53
 Source of numerous attacks M'RAIHI Expires - January 2009 [Page 23] Sharing Transaction Fraud Data July 2008 1234567 3456789 saving 10000 M'RAIHI Expires - January 2009 [Page 24]