Internet Draft David M'Raihi
Category: Informational VeriSign
Document: draft-mraihi-inch-thraud-06.txt Sharon Boeyen
Expires: November 2008 Entrust
Michael Grandcolas
Grandcolas Consulting
LLC
Siddharth Bajaj
VeriSign
May 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) reporting data. It extends the
Incident Handling Working Group (INCH WG) Incident Object
Description Exchange Format (IODEF) incident reporting document
format.
Sharing Transaction Fraud Data May 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
9.1. Origin Authentication and Data Integrity 17
9.2. Access Control 17
9.3. Transport Confidentiality 17
10. IANA Considerations 17
11. Conclusion 17
12. References 18
12.1. Normative 18
12.2. Informative 18
13. Authors' Addresses 18
14. Full Copyright Statement 19
15. Intellectual Property 19
Appendix A. Thraud Record XML Schema 20
Appendix B. Example of a Thraud Report 21
M'RAIHI Expires - November 2008 [Page 2]
Sharing Transaction Fraud Data May 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).
While inbound reports commonly identify the contributor of the
report, as this may be useful in evaluating the quality of the
information it contains and in contacting the source for the
purpose of clarification, 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 - November 2008 [Page 3]
Sharing Transaction Fraud Data May 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 - November 2008 [Page 4]
Sharing Transaction Fraud Data May 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 - November 2008 [Page 5]
Sharing Transaction Fraud Data May 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 - November 2008 [Page 6]
Sharing Transaction Fraud Data May 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 corresonding 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 - November 2008 [Page 7]
Sharing Transaction Fraud Data May 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 - November 2008 [Page 8]
Sharing Transaction Fraud Data May 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 - November 2008 [Page 9]
Sharing Transaction Fraud Data May 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 (FI) 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 - November 2008 [Page 10]
Sharing Transaction Fraud Data May 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 - November 2008 [Page 11]
Sharing Transaction Fraud Data May 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 - November 2008 [Page 12]
Sharing Transaction Fraud Data May 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 - November 2008 [Page 13]
Sharing Transaction Fraud Data May 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 - November 2008 [Page 14]
Sharing Transaction Fraud Data May 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 - November 2008 [Page 15]
Sharing Transaction Fraud Data May 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 data format for exchanging transaction
fraud data. The most critical security concerns are the validity
of inbound and outbound Thraud Reports, as well as the
protection of the contributors' anonymity when further sharing
the data. This requires the following security services: origin
authentication, data integrity, access control and transport
confidentiality.
M'RAIHI Expires - November 2008 [Page 16]
Sharing Transaction Fraud Data May 2008
9.1. Origin Authentication and Data Integrity
Acceptance by the recipient of reports introduced by an
attacker, or modification of genuine reports by an attacker, may
impact the effectiveness of the recipient's fraud detection
program. Therefore, Thraud Reports MUST be protected for origin
authentication and data integrity. These protections guarantee
the origin and integrity of the submitted information. Any
mechanism that is acceptable to both parties MAY be used.
9.2. Access Control
Contributors of Thraud Reports might not be willing to allow
further disclosure of fraudulent transaction data to be
associated with them. So, in order to prevent inadvertent
disclosure of that information, Thraud Reports SHOULD be
encrypted while in storage.
9.3. Transport Confidentiality
In addition to protecting the confidentiality of Thraud data
while in storage, the data SHOULD be protected during transit.
Any mechanism that is acceptable to both parties MAY be used.
10. IANA Considerations
IANA is requested to reserve an XML namespace identifier for the
Thraud schema. The following value is suggested:
urn:ietf:params:xml:ns:thraud-1.0
IANA is also requested to reserve a MIME media type for Thraud
Reports. The following value is suggested:
application/thraud+xml
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.
M'RAIHI Expires - November 2008 [Page 17]
Sharing Transaction Fraud Data May 2008
12. References
12.1. Normative
[RFC2119] S. Bradner, "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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
[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.
12.2. Informative
[OATH] Initiative for Open AuTHentication
http://www.openauthentication.org
[UML] ISO/IEC 19501:2005 Information technology - Open
Distributed Processing - Unified Modeling Language (UML) Version
1.4.2.
[XMLSIG] W3C XML-Signature Syntax and Processing - W3C
Recommendation 12 February 2002.
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
M'RAIHI Expires - November 2008 [Page 18]
Sharing Transaction Fraud Data May 2008
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
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
M'RAIHI Expires - November 2008 [Page 19]
Sharing Transaction Fraud Data May 2008
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
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:thraud-1.0"
xmlns:thraud="urn:ietf:params:xml:ns:thraud-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation="http://www.cert.org/ietf/inch/schema/draft-ietf-
inch-iodef-140.xsd"/>
<xs:element name="FraudEventPayment"
type="thraud:FraudEventPaymentType"/>
<xs:element name="FraudEventTransfer"
type="thraud:FraudEventTransferType"/>
<xs:element name="FraudEventIdentity"
type="thraud:FraudEventIdentityType"/>
<xs:element name="FraudEventOther"
type="thraud:FraudEventOtherType"/>
<xs:complexType name="FraudEventPaymentType">
<xs:sequence>
<xs:element name="PayeeName" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="PostalAddress" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="PayeeAmount" type="thraud:AmountType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FraudEventTransferType">
<xs:sequence>
<xs:element name="BankID" type="thraud:BankIDType"
minOccurs="0"/>
<xs:element name="AccountID" type="xs:string" minOccurs="0"/>
<xs:element name="AccountType" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="TransferAmount" type="thraud:AmountType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FraudEventIdentityType">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="IdentityComponent"
type="iodef:ExtensionType"/>
M'RAIHI Expires - November 2008 [Page 20]
Sharing Transaction Fraud Data May 2008
</xs:sequence>
</xs:complexType>
<xs:complexType name="FraudEventOtherType">
<xs:sequence>
<xs:element name="OtherEventType" type="iodef:MLStringType"/>
<xs:element name="PayeeName" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="PostalAddress" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="BankID" type="thraud:BankIDType"
minOccurs="0"/>
<xs:element name="AccountID" type="xs:string" minOccurs="0"/>
<xs:element name="AccountType" type="iodef:MLStringType"
minOccurs="0"/>
<xs:element name="PayeeAmount" type="thraud:AmountType"
minOccurs="0"/>
<xs:element name="OtherEventDescription"
type="iodef:MLStringType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AmountType">
<xs:simpleContent>
<xs:extension base="xs:decimal">
<xs:attribute name="currency" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="BankIDType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="namespace" type="xs:string"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="UserId" type="xs:string"/>
</xs:schema>
Appendix B. Example of a Thraud Report
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-1.0
http://www.cert.org/ietf/inch/schema/draft-ietf-inch-iodef-
140.xsd" lang="en">
<Incident purpose="reporting">
<IncidentID name="fraud.openauthentication.org">908711
</IncidentID>
M'RAIHI Expires - November 2008 [Page 21]
Sharing Transaction Fraud Data May 2008
<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@example.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>
</Node>
<Description>Source of numerous attacks</Description>
</System>
</Flow>
<AdditionalData dtype="xml">
<FraudEventTransfer xmlns="urn:ietf:params:xml:ns:thraud-
1.0" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:thraud-1.0
http://www.openauthentication.org/thraud/Schema1-0.xsd">
<BankID namespace="American Bankers Association routing
code">1234567</BankID>
<AccountID>3456789</AccountID>
<AccountType lang="en">saving</AccountType>
<TransferAmount currency="USD">10000</TransferAmount>
</FraudEventTransfer>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
M'RAIHI Expires - November 2008 [Page 22]
