[OIDFSC] AATOC Working Group Charter
Nat Sakimura
sakimura at gmail.com
Wed Feb 25 02:40:47 UTC 2015
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/1ef3ab04/attachment-0001.html>
More information about the specs-council
mailing list