[OIDFSC] AATOC Working Group Charter

[Mike Jones]

I agree with the title change.

I would suggest that one additional scope item and one additional deliverable be added, worded along these lines:

Scope
Trust Frameworks

·         Defining sample or actual trust frameworks enabling account takeover coordination is within scope

Proposed Deliverables
ATO Trust Framework

·         A trust framework defining roles and responsibilities of parties sharing account takeover information

                                                                -- Mike

From: specs-council [mailto:openid-specs-council-bounces at lists.openid.net] On Behalf Of John Bradley
Sent: Tuesday, February 24, 2015 5:34 PM
To: Nat Sakimura
Cc: Adam Dawes; openid-specs-council at lists.openid.net
Subject: Re: [OIDFSC] AATOC Working Group Charter

I have reviewed the charter and am OK with that change.


On Feb 24, 2015, at 7:56 PM, Nat Sakimura <sakimura at gmail.com<mailto:sakimura at gmail.com>> wrote:

Dear Specs Council members,

It looks generally fine, with one friendly amendment:

Change the title of the working group from:
Abuse and Account Takeover Coordination Group

to:
Abuse and Account Takeover Coordination Working Group

as "Abuse and Account Takeover Coordination Group Working Group" is a bit awkward.
I am fine with putting it as just "Abuse and Account Takeover Coordination" as well, since there is a precedence for it.

Could any specs council member respond early in this thread if you have any objection or friendly amendment. We have been a bit slack lately that we have been relying on two weeks limit to execute a charter, but we should be able to act more quickly.

Cheers,

Nat


2015-02-24 19:02 GMT+09:00 Adam Dawes <adawes at google.com<mailto:adawes at google.com>>:
I would like to form a new work group, AATOC. Here is our proposed charter:

AATOC Charter

1) Working Group name:
Abuse and Account Takeover Coordination Group (AATOC)

2) Purpose
The goal of AATOC is to provide data sharing schemas, privacy recommendations and protocols to:

·         Share information about important security events in order to thwart attackers from leveraging compromised accounts from one Service Provider to gain access to accounts on other Service Providers (mobile or web application developers and owners).
·         Enable users and providers to coordinate in order to securely restore accounts following a compromise.

Internet accounts that use email addresses or phone numbers as the primary identifier for the account will be the initial focus.
2) Scope
The group will define:
·         Security events
These are events – whether directly authentication-related or occurring at another time in the user flow – that take place on one service that could also have security implications on other Service Providers. The group will develop a taxonomy of security events and a common set of semantics to express relevant information about a security event.


·         Privacy Implications
Sharing security information amongst providers has potential privacy implications for both end users and service providers. These privacy implications must be balanced against the recognized benefits of protecting users’ accounts and data from abuse.  The group will consider ways to optimize this balance when defining mechanisms to handle the various security events and recommend best practices for the industry.

·         Communications mechanisms
Define bindings for the use of an existing transport protocol defined elsewhere.

·         Event schema
Define a schema describing relevant events and relationships to allow for dissemination between interested and authorized parties.

·         Account recovery mechanisms
Standardized mechanism(s) to allow providers to signal that a user has regained control of an account, or allow a user to explicitly restore control of a previously compromised account, with or without direct user involvement.
Out of scope:
Determining the account quality/reputation of a user on a particular service and communicating that to others.

Definition of APIs and underlying mechanisms for connecting to, interacting with and operating centralized databases or intelligence clearinghouses when these are used to communicate security events between account providers.

4) Proposed Deliverables
The group proposes the following Non-Specification deliverables:

Security Event and Account Lifecycle Schema
·         A taxonomy of security events and a common set of semantics to express relevant information about a security event and its relationships to other relevant data, events or indicators.
Security Event Privacy Guidelines
A set of recommendations on how to minimize the privacy impact on users and service providers while improving security, and how to provide appropriate privacy disclosures, labeling and access control guidelines around information in the Security Event Schema.

The group proposes the following Specification deliverables:

Communications Mechanisms
Define bindings for the event messages to an already existing transport protocol to promote interoperability of sending event information to another Service Provider. This will allow a Service Provider to implement a single piece of infrastructure that would be able to send or receive event information to any other service provider.

Order of Deliverables
The group will work to produce the Security Event and Account Lifecycle Schema before beginning work on the Communications Mechanism.

5) Anticipated audience or users
·         Service Providers who manage their own account systems which require an email address or phone number for registration.
·         Account and email providers that understand key security events that happen to a user’s account.
·         Identity as a Service (IDaaS) vendors that manage account and authentication systems for their customers.
·         Users seeking to regain control of a compromised account.

6) Language
English

7) Method of work:
E-mail discussions on the working group mailing list, working group conference calls, and face-to-face meetings from time to time.

8) Basis for determining when the work is completed:
Rough consensus and running code. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope.

Background information

Related work:
·         RFC6545 Real-time Inter-network Defense (RID)
·         RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS
·         RFC6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)
·         draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator Exchange
·         ISO/IEC 27002:2013  Information technology — Security techniques — Code of practice for information security controls
·         ISO/IEC 27035:2011 Information technology — Security techniques — Information security incident management

Proposers
·         Adam Dawes, Google
·         Mark Risher, Google
·         Trent Adams, Paypal
·         George Fletcher, AOL
·         Andrew Nash, Confyrm
·         Nat Sakimura, Nomura Research Institute
·         John Bradley, Ping Identity
·         Henrik Biering, Peercraft
Anticipated contributions:
“Security event reporting between Service Providers 1.0” under the OpenID Foundation’s IPR Policy<http://openid.net/intellectual-property/>.



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150225/af9c33bb/attachment-0001.html>