Internet Draft David M'Raihi
VeriSign
Category: Sharon Boeyen
Informational Entrust
Document: Michael Grandcolas
draft-mraihi-inch-thraud-00.txt Grandcolas Consulting LLC.
Siddharth Bajaj
VeriSign
Expires:
April 2007 October 2006
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 forum for Open
AuTHentication [OATH].
INCH-THRAUD Expires - April 2007 [Page 1]
How to Share Transaction Fraud (Thraud) Report Data October 2006
Table of Contents
1. Introduction...............................................3
2. Requirements Terminology...................................3
3. The Elements of Transaction Fraud Activity.................4
4. Thraud Activity Reporting via an IODEF-Document Incident...5
5. Fraud Report Element Definitions...........................7
5.1. The Fraud-Event-Payment element..........................7
5.1.1. Payee-Name..............................................8
5.1.2. Payee-Address-Line1.....................................8
5.1.3. Payee-address-Line2.....................................8
5.1.4. Payee-City..............................................8
5.1.5. Payee-Postal-Code.......................................8
5.1.6. Payee-Country...........................................8
5.1.7. Payee-Amount............................................9
5.2. The Fraud-Event-Transfer element.........................9
5.2.1. Bank-ID.................................................9
5.2.2. Account-ID..............................................9
5.2.3. Account-Type............................................9
5.2.4. Transfer-Amount.........................................9
5.3. The Fraud-Event-Identity element........................10
5.4. The Payee-Amount element................................10
5.4.1. Element contents.......................................10
5.4.2. Currency...............................................10
5.5. The Transfer-Amount element.............................11
5.5.1. Element contents.......................................11
5.5.2. Currency...............................................11
5.6. The Account-Type element................................11
6. IODEF Required Elements...................................12
6.1. Fraud Report............................................12
7. Security Considerations...................................13
7.1. Thraud Data Authenticity and Integrity..................13
7.2. Thraud Data Confidentiality and Privacy.................14
8. IANA Considerations.......................................14
9. Conclusion................................................14
10. Acknowledgements..........................................14
11. References................................................14
11.1. Normative...............................................14
11.2. Informative.............................................15
Appendix A. Fraud Extensions XML Schema.......................15
Appendix B. Example of a Thraud Report........................16
12. Authors' Addresses........................................17
13. Full Copyright Statement..................................18
14. Intellectual Property.....................................18
INCH-THRAUD Expires - April 2007 [Page 2]
How to Share Transaction Fraud (Thraud) Report Data October 2006
1. Introduction
Financial Institutions and Merchants are confronted with online
fraud attacks targeted against their customers through various
means. Today there is no formalized 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 fraud attack records will
be defined via an openly published XML Schema.
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.
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].
INCH-THRAUD Expires - April 2007 [Page 3]
How to Share Transaction Fraud (Thraud) Report Data October 2006
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
Transaction Fraud Activities are normally composed of the following
components.
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.
INCH-THRAUD Expires - April 2007 [Page 4]
How to Share Transaction Fraud (Thraud) Report Data October 2006
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's who hold 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 the Thraud Activity Reporting is to allow
financial organization and others who have detected fraud to share
information such as initiating IP addresses and transaction fraud
information (e.g. destination account numbers and amounts) with
other organizations so that they may use that information to block
future transaction fraud attempts of the same kind or from the same
source from occurring.
4. Thraud Activity Reporting via an IODEF-Document Incident
A Thraud Activity Report is an instance of an XML IODEF-Document
with 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.
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
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.
INCH-THRAUD Expires - April 2007 [Page 5]
How to Share Transaction Fraud (Thraud) Report Data October 2006
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
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.
INCH-THRAUD Expires - April 2007 [Page 6]
How to Share Transaction Fraud (Thraud) Report Data October 2006
5. Fraud Report Element Definitions
A fraud report consists of an extension to the
Incident/EventData/AdditionalData Element. The elements of the
fraud report will identify and capture information related to
payment fraud, transfer fraud and identity fraud.
A payment fraud report is structured as follows.
+--------------------------+
| EventData.AdditionalData |
+--------------------------+
| ENUM dtype (xml) |<>---------[ Fraud-Event-Payment ]
| |
+--------------------------+
Figure 3. The Fraud-Event-Payment extension
A funds transfer fraud report is structured as follows.
+--------------------------+
| EventData.AdditionalData |
+--------------------------+
| ENUM dtype (xml) |<>---------[ Fraud-Event-Transfer ]
| |
+--------------------------+
Figure 4. The Fraud-Event-Transfer extension
An identity fraud report is structured as follows.
+--------------------------+
| EventData.AdditionalData |
+--------------------------+
| ENUM dtype (xml) |<>---------[ Fraud-Event-Identity ]
| |
+--------------------------+
Figure 5. The Fraud-Event-Identity extension
5.1. The Fraud-Event-Payment element
The Fraud-Event-Payment element is used to report the payee
instructions for a fraudulent payment or fraudulent payment
attempt. Fraudsters sometimes use the same payee instructions for
multiple fraudulent payment attempts. By reporting the payment
INCH-THRAUD Expires - April 2007 [Page 7]
How to Share Transaction Fraud (Thraud) Report Data October 2006
instructions used, other institutions may be able to stop future
fraudulent payment attempts to the same payee.
The structure of the Fraud-Event-Payment element is:
+--------------------------+
|Fraud-Event-Payment |
+--------------------------+
| |<>--{0..1}--[ Payee-Name ]
| |<>--{0..1}--[ Payee-Addrees-Line1 ]
| |<>--{0..1}--[ Payee-Addrees-Line2 ]
| |<>--{0..1}--[ Payee-City ]
| |<>--{1..1}--[ Payee-Postal-Code ]
| |<>--{0..1}--[ Payee-Country ]
| |<>--{0..1}--[ Payee-Amount]
| |
+--------------------------+
Figure 6. The Fraud-Event-Payment element
The components of the Fraud-Event-Payment element are introduced
below.
5.1.1. Payee-Name
Zero or one value of STRING. The name of the payee.
5.1.2. Payee-Address-Line1
Zero or one value of STRING. The first line of the address of the
payee.
5.1.3. Payee-address-Line2
Zero or one value of STRING. The second line of the address of the
payee.
5.1.4. Payee-City
Zero or one value of STRING. The city of the payee.
5.1.5. Payee-Postal-Code
Zero or one value of STRING. The postal code of the payee.
5.1.6. Payee-Country
Zero or one value of STRING. The country of the payee.
INCH-THRAUD Expires - April 2007 [Page 8]
How to Share Transaction Fraud (Thraud) Report Data October 2006
5.1.7. Payee-Amount
Zero or one element of Payee-Amount.
5.2. The Fraud-Event-Transfer element
The Fraud-Event-Transfer element is used to report the payee
instructions for a fraudulent funds transfer or fraudulent funds
transfer attempt. Fraudsters sometimes use the same payee
instructions for multiple attempts. By reporting the funds transfer
instructions used, other institutions may be able to stop future
fraudulent payment attempts to the same payee.
+---------------------------+
|Fraud-Event-Transfer |
+---------------------------+
| |<>--{0..1}--[ Bank-ID ]
| |<>--{0..1}--[ Account-ID ]
| |<>--{0..1}--[ Account-Type ]
| |<>--{0..1}--[ Transfer-Amount ]
| |
+---------------------------+
Figure 7. The Fraud-Event-Transfer element
The components of the Fraud-Event-Transfer element are introduced
below.
5.2.1. Bank-ID
Zero or one value of STRING. The destination bank routing transit
ID or other FI id.
5.2.2. Account-ID
Zero or one value of STRING. The destination primary account
number.
5.2.3. Account-Type
Zero or one element of Account-Type.
5.2.4. Transfer-Amount
Zero or one element of Transfer-Amount.
INCH-THRAUD Expires - April 2007 [Page 9]
How to Share Transaction Fraud (Thraud) Report Data October 2006
5.3. The Fraud-Event-Identity element
The Fraud-Event-Identity element is used to report a fraudulent
impersonation or fraudulent impersonation attempt. By reporting
the funds event, other institutions may be able to stop future
fraudulent impersonation attempts.
+---------------------------+
|Fraud-Event-Identity |
+---------------------------+
| |
| |
+---------------------------+
Figure 8. The Fraud-Event-Identity element
The Fraud-Event-Identity element is empty.
5.4. The Payee-Amount element
The Payee-Amount element is used to report the amount of the
payment fraud, which may be common across a set of related fraud
attempts.
+--------------------+
|Payee-Amount |
+--------------------+
| DECIMAL |
| |
| STRING currency |
| |
+--------------------+
Figure 9. The Payee-Amount element
The components of the Payee-Amount element are introduced below.
5.4.1. Element contents
Required DECIMAL. Contains the amount of the payment.
5.4.2. Currency
Required STRING. The three letter currency code.
INCH-THRAUD Expires - April 2007 [Page 10]
How to Share Transaction Fraud (Thraud) Report Data October 2006
5.5. The Transfer-Amount element
The Transfer-Amount element is used to report the amount of the
funds transfer fraud, which may be common across a set of related
fraud attempts.
+--------------------+
|Transfer-Amount |
+--------------------+
| DECIMAL |
| |
| STRING currency |
| |
+--------------------+
Figure 10. The transfer-Amount element
The components of the Transfer-Amount element are introduced below.
5.5.1. Element contents
Required DECIMAL. Contains the amount of the funds transfer.
5.5.2. Currency
Required STRING. The three letter currency code.
5.6. The Account-Type element
The Account-Type element is used to report the type of the
destination account.
+--------------------+
|Account-Type |
+--------------------+
| ENUM (checking | |
| saving) |
| |
+--------------------+
Figure 11. The Account-Type element
Required ENUMERATION. Enumerated values are: 'checking' and
'saving'.
INCH-THRAUD Expires - April 2007 [Page 11]
How to Share Transaction Fraud (Thraud) Report Data October 2006
6. IODEF Required Elements
This section identifies attributes and elements that are required
to be present in a compliant fraud report. The required attributes
are a combination of those required by the base IODEF element and
those required by this profile. Attributes identified as required
SHALL be populated in conforming fraud reports.
+--------------+
| Incident |
+--------------+
| ENUM Purpose |---[ IncidentID ]
| |---[ ReportTime ]
| |---[ Assessment ]
| | ---> [ Impact ]
| | ---> [ Confidence ]
| |---[ Contact ]
| | ---> [ ContactName ]
| | ---> [ Email ]
| | ---> [ Contact ]
| | ---> [ ContactName ]
| | ---> [ Email ]
| | ---> [ Telephone ]
| |---[ EventData ]
| | ---> [ DetectTime ]
| | ---> [ Flow ]
| | | ---> [ System ]
| | | ---> [ Node ]
| | | ---> [ Address ]
| | | | ---> [ vlan-num ]
| | | ---> [ Location ]
| | | ---> [ NodeName ]
| | ---> [ AdditionalData ]
| | ---> [ Fraud-Event-XXX ]
+--------------+
Figure 12. IODEF Required Elements
6.1. Fraud Report
A compliant IODEF fraud report SHALL contain elements as described
below:
Purpose - The value 'reporting' indicates that the report contains
details of a new fraud incident to be added to the corpus. A new
value 'delete' must be added to indicate that further analysis by
the originator indicates that the incident was not fraudulent, and
so the incident should be deleted from the corpus.
IncidentID - As defined by IODEF.
INCH-THRAUD Expires - April 2007 [Page 12]
How to Share Transaction Fraud (Thraud) Report Data October 2006
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, this element MAY contain the name of the
consolidator, not the original reporting institution.
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.DetectTime - The date and time at which the fraud or
fraud attempt was detedted.
EventData.Flow.System.Node.Addres.vlan-num - The IPv4 or IPv6
address or subnet mask, depending upon the value of the
'Address@category' attribute.
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.
7. 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.
7.1. 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
INCH-THRAUD Expires - April 2007 [Page 13]
How to Share Transaction Fraud (Thraud) Report Data October 2006
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.
7.2. 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(<IncidentID Field>)
The OpaqueIdentifier can be used to reference the report without
disclosing the full organization identity.
8. IANA Considerations
This document has no actions for IANA.
9. 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.
10. Acknowledgements
We would like to thank Tim Moses for his extremely valuable
contribution to completing this draft document.
11. References
11.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.
INCH-THRAUD Expires - April 2007 [Page 14]
How to Share Transaction Fraud (Thraud) Report Data October 2006
11.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
<?xml version="1.0" encoding="UTF-8"?>
<xs:schematargetNamespace=
"http://www.openauthentication.org/fraud/protocol/v01/wd02"
xmlns:fraud=
"http://www.openauthentication.org/fraud/protocol/v01/wd02"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="Fraud-Event-Payment"
type="fraud:Fraud-Event-Payment-Type"/>
<xs:element name="Fraud-Event-Transfer"
type="fraud:Fraud-Event-Transfer-Type"/>
<xs:element name="Fraud-Event-Identity"
type="fraud:Fraud-Event-Identity-Type"/>
<xs:complexType name="Fraud-Event-Payment-Type">
<xs:sequence>
<xs:element name="Payee-Name" type="xs:string"
minOccurs="0"/>
<xs:element name="Payee-Addrees-Line1" type="xs:string"
minOccurs="0"/>
<xs:element name="Payee-Addrees-Line2" type="xs:string"
minOccurs="0"/>
<xs:element name="Payee-City" type="xs:string"
minOccurs="0"/>
<xs:element name="Payee-Postal-Code" type="xs:string"
minOccurs="0"/>
<xs:element name="Payee-Country" type="xs:string"
minOccurs="0"/>
<xs:element name="Payee-Amount" type="fraud:Amount-Type"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Fraud-Event-Transfer-Type">
<xs:sequence>
<xs:element name="Bank-ID" type="xs:string"
minOccurs="0"/>
<xs:element name="Account-ID" type="xs:string"
INCH-THRAUD Expires - April 2007 [Page 15]
How to Share Transaction Fraud (Thraud) Report Data October 2006
minOccurs="0"/>
<xs:element name="Account-Type" type="fraud:Account-Type-Type"
minOccurs="0"/>
<xs:element name="Transfer-Amount" type="fraud:Amount-Type"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Fraud-Event-Identity-Type"/>
<xs:simpleType name="Account-Type-Type">
<xs:restriction base="xs:string">
<xs:enumeration value="checking"/>
<xs:enumeration value="saving"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="Amount-Type">
<xs:simpleContent>
<xs:extension base="xs:decimal">
<xs:attribute name="Currency" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</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"
xmlns:thraud=
"http://www.openauthentication.org/fraud/protocol/v01/wd02"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-1.0" lang="en">
<Incident purpose="reporting">
<IncidentID name="fraud.openauthentication.org">908711
</IncidentID>
<ReportTime>2006-10-12T00:00:00-07:00</ReportTime>
<Assessment>
<Impact severity="high" completion="failed"/>
<Confidence rating="high"/>
</Assessment>
<Contact type="organization" role="creator">
<ContactName>Open Authentication</ContactName>
<Email>contact@openauthentication-fraud.com </Email>
</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>
INCH-THRAUD Expires - April 2007 [Page 16]
How to Share Transaction Fraud (Thraud) Report Data October 2006
</Node>
<Description>Source of numerous attacks</Description>
</System>
</Flow>
<AdditionalData dtype="xml">
<thraud:Fraud-Event-Transfer>
<thraud:Bank-ID>1234567</thraud:Bank-ID>
<thraud:Account-ID>3456789</thraud:Account-ID>
<thraud:Account-Type>saving</thraud:Account-Type>
<thraud:Transfer-Amount Currency="USD">10000
</thraud:Transfer-Amount>
</thraud:Fraud-Event-Transfer>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
12. Authors' Addresses
Primary point of contact (for sending comments and question):
David M'Raihi
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-3183
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
INCH-THRAUD Expires - April 2007 [Page 17]
How to Share Transaction Fraud (Thraud) Report Data October 2006
13. Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
14. 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.
INCH-THRAUD Expires - April 2007 [Page 18]
