[OIDFSC] AATOC Working Group Charter
Nat Sakimura
sakimura at gmail.com
Wed Feb 25 03:13:05 UTC 2015
While we are in the title, in view of the recent executive order
http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari,
we might suggest including the name "Information Sharing and analysis",
e.g., AATISAC.
2015年2月25日(水)、11:59 John Bradley <ve7jtb at ve7jtb.com>:
> That is a different WG outside of the OIDF;)
>
> On Feb 24, 2015, at 9:40 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>
> Simplicity wins, but does not it sound like the WG is creating a protocol
> to take over accounts ;-) ?
>
> 2015-02-25 11:25 GMT+09:00 Ashish Jain <ashishjain at vmware.com>:
>
>> I’m not objecting…merely suggesting that referring it as Account
>> Takeover WG is simpler
>>
>> From: Nat Sakimura <sakimura at gmail.com>
>> Date: Tuesday, February 24, 2015 at 6:09 PM
>> To: Ashish Jain <ashishjain at vmware.com>
>> Cc: Adam Dawes <adawes at google.com>, "
>> openid-specs-council at lists.openid.net" <
>> openid-specs-council at lists.openid.net>
>>
>> Subject: Re: [OIDFSC] AATOC Working Group Charter
>>
>> I am fine with ATO WG as well. My objection was that the name had the
>> Group in it, which is not a defined word in OpenID Process, so the WG name
>> would become AATOC Group WG, which is repeating "Group" and awkward. It is
>> just an editorial stuff.
>>
>> Are you objecting to the first A and the last C of AATOC?
>>
>>
>>
>> 2015-02-25 10:59 GMT+09:00 Ashish Jain <ashishjain at vmware.com>:
>>
>>> I understand the need to be precise but ATO WG can probably convey the
>>> same message.
>>>
>>> From: Nat Sakimura <sakimura at gmail.com>
>>> Date: Tuesday, February 24, 2015 at 4:56 PM
>>> To: Adam Dawes <adawes at google.com>
>>> Cc: "openid-specs-council at lists.openid.net" <
>>> openid-specs-council at lists.openid.net>
>>> Subject: Re: [OIDFSC] AATOC Working Group Charter
>>>
>>> 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>:
>>>
>>>> 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
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=yV7iQ-h1QNIAyTmfXm6S6vIszebI2q_snUSkFyjxlkg&e=>
>>>> .
>>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=jmKQL3OD_c7eJXduzdJt5OJefY8ZjNiYCoAm8g-7oOA&e=>
>>> @_nat_en
>>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=dibzrL00q20lgLcDv94EYh8Ums_bAaYivHuqDQgNfSI&s=jq4oX-tF55oVVtUOW6sW0RsihIhuUzSlJVyRWCVyAhQ&e=>
>> @_nat_en
>>
>
>
>
> --
> 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/8e7915bb/attachment-0001.html>
More information about the specs-council
mailing list