[OIDFSC] AATOC Working Group Charter
Chuck Mortimore
cmortimore at salesforce.com
Thu Feb 26 21:56:28 UTC 2015
Our incident response team want's to participate. Should we just wait
for the mailing list, or is there a way to get working on the agreement?
On Thu, Feb 26, 2015 at 8:30 AM, Mike Jones <Michael.Jones at microsoft.com>
wrote:
> I’d hold off posting it until the working group has been created. Given
> that the intent is clear, I’m OK with accepting the agreement as-is, but
> would defer to others if they’d prefer that it be revised before being
> posted.
>
>
>
> Out of curiosity, who was the agreement from?
>
>
>
> *From:* specs-council [mailto:
> openid-specs-council-bounces at lists.openid.net] *On Behalf Of *John Ehrig
> *Sent:* Thursday, February 26, 2015 7:00 AM
> *To:* Adam Dawes; Andrew Nash
> *Cc:* John Bradley; Nat Sakimura; Ashish Jain;
> openid-specs-council at lists.openid.net; aatoc at googlegroups.com
> *Subject:* Re: [OIDFSC] AATOC Working Group Charter
>
>
>
> Hi All,
>
>
>
> I have already received a contribution agreement for this WG (under the
> “old” name, however) (see attached). Can we accept it under the old name.,
> should I go ahead and post it to the website now, or should I wait until
> the WG is actually approved?
>
>
>
> Please let me know.
>
>
>
> Thanks!
>
>
>
> *From:* specs-council [
> mailto:openid-specs-council-bounces at lists.openid.net
> <openid-specs-council-bounces at lists.openid.net>] *On Behalf Of *Adam Dawes
> *Sent:* Thursday, February 26, 2015 1:06 AM
> *To:* Andrew Nash
> *Cc:* John Bradley; openid-specs-council at lists.openid.net; Ashish Jain;
> Nat Sakimura; aatoc at googlegroups.com
> *Subject:* Re: [OIDFSC] AATOC Working Group Charter
>
>
>
> Okay, I've revised the charter, with a new name, USESC (I couldn't fathom
> losing the "O" in AATOC). It doesn't have quite the ring but it's a bit
> more general which is useful since I think what will be produced will have
> uses beyond abuse and account takeovers. I've also included a deliverable
> on trust frameworks.
>
>
>
> Here it is:
> USESC Charter
>
>
> 1) Working Group name:
>
> User Security Event Sharing and Coordination Working Group (USESC Working
> Group)
> 2) Purpose
>
> The goal of USESC is to provide data sharing schemas, privacy
> recommendations and protocols to:
>
>
>
> · Share information about important security events related to
> user accounts 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.
> 3) 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.
>
> · *Trust Frameworks*
> Define at least one model for the conditions under which information would
> be shared.
>
>
>
> · *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/>.
>
>
>
>
>
> On Wed, Feb 25, 2015 at 5:37 PM, Andrew Nash <andrew at confyrm.com> wrote:
>
> Trent,
>
>
>
> we (Confyrm) have started work on a number of aspects of a trust framework
> in conjunction with Tom Smedinghoff as part of the work we did with the Uk
> Govt and the NSTIC pilot - still early but hopefully will bootstrap some of
> the work here
>
>
>
> --Andrew
>
>
>
> On Tue, Feb 24, 2015 at 11:00 PM, 'Adam Dawes' via Abuse and ATO
> Coordination <aatoc at googlegroups.com> wrote:
>
> +aatoc-list
>
>
>
> For name, I agree with Nat's suggestion of 'Abuse and Account Take Over
> Coordination Work Group (AATOC Work Group)'. This just prevents a name
> change for everyone as well as the mailing list mechanics.
>
>
>
> @mike, I think your suggestions about defining trust frameworks also make
> sense. Do you have any good examples of where this has been done? Will need
> to discuss this with the rest of the group but in our discussion of
> transport, there have been some implicit trust framework concepts at play.
> In the end, I think there may be different models about with whom info is
> shared. This will depend on the specific data we define, the quality of
> data that service providers can share, and the relevant privacy policies of
> those providers.
>
>
>
> thanks,
>
> AD
>
>
>
> On Tue, Feb 24, 2015 at 7:13 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>
> 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
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Abuse and ATO Coordination" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aatoc+unsubscribe at googlegroups.com.
> To post to this group, send email to aatoc at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com
> <https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150226/158c2d89/attachment-0001.html>
More information about the specs-council
mailing list