[OIDFSC] AATOC Working Group Charter
Breno de Medeiros
breno at google.com
Mon Mar 2 18:06:31 UTC 2015
+1 for WG formation.
On Mon, Mar 2, 2015 at 9:11 AM, Mike Jones <Michael.Jones at microsoft.com>
wrote:
> Per http://openid.net/foundation/specs-council/, the current specs
> council members are:
>
> · John Bradley
>
> · Tim Bray
>
> · Ashish Jain
>
> · Mike Jones
>
> · Breno de Medeiros
>
> · Chuck Mortimore
>
> · Nat Sakimura
>
> At this point that leaves Tim, Breno, and Chuck left to vote.
>
>
>
> -- Mike
>
>
>
> *From:* John Bradley [mailto:ve7jtb at ve7jtb.com]
> *Sent:* Monday, March 02, 2015 12:04 AM
> *To:* Adam Dawes
> *Cc:* Nat Sakimura; Ashish Jain; Mike Jones; Chuck Mortimore; John Ehrig;
> Andrew Nash; openid-specs-council at lists.openid.net; aatoc at googlegroups.com
> *Subject:* Re: [OIDFSC] AATOC Working Group Charter
>
>
>
> No you have to give the other members of the specs council time to vote.
>
>
>
> However I also vote to approve the creation of the working group with the
> charter.
>
>
>
> That makes 3 yes and no opposed at this point.
>
>
>
> After approval people sign the IPR to join the WG.
>
> Then there is a WG founding meeting where the members vote to adopt the
> charter.
>
>
>
> After that you are a full WG.
>
>
>
> John B.
>
>
>
>
>
> On Mar 2, 2015, at 8:15 AM, Adam Dawes <adawes at google.com> wrote:
>
>
>
> Does this mean that we're an official working group now?
>
>
>
> On Sun, Mar 1, 2015 at 4:59 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>
> +1
>
> =nat via iPhone
>
>
> 2015/03/02 2:33、Ashish Jain <ashishjain at vmware.com> のメッセージ:
>
> +1
>
>
>
> *From: *Mike Jones <Michael.Jones at microsoft.com>
> *Date: *Friday, February 27, 2015 at 4:54 PM
> *To: *Adam Dawes <adawes at google.com>, John Bradley <ve7jtb at ve7jtb.com>
> *Cc: *Chuck Mortimore <cmortimore at salesforce.com>, John Ehrig <
> jehrig at inventures.com>, Andrew Nash <andrew at confyrm.com>, "
> openid-specs-council at lists.openid.net" <
> openid-specs-council at lists.openid.net>, Ashish Jain <ashishjain at vmware.com>,
> Nat Sakimura <sakimura at gmail.com>, "aatoc at googlegroups.com" <
> aatoc at googlegroups.com>
> *Subject: *RE: [OIDFSC] AATOC Working Group Charter
>
>
>
> I approve of the creation of this working group with this charter.
> ------------------------------
>
> *From: *Adam Dawes <adawes at google.com>
> *Sent: *2/27/2015 11:22 AM
> *To: *John Bradley <ve7jtb at ve7jtb.com>
> *Cc: *Chuck Mortimore <cmortimore at salesforce.com>; Mike Jones
> <Michael.Jones at microsoft.com>; John Ehrig <jehrig at inventures.com>; Andrew
> Nash <andrew at confyrm.com>; openid-specs-council at lists.openid.net; Ashish
> Jain <ashishjain at vmware.com>; Nat Sakimura <sakimura at gmail.com>;
> aatoc at googlegroups.com
> *Subject: *Re: [OIDFSC] AATOC Working Group Charter
>
> We had our weekly meeting today and everyone was okay with the Trust
> Framework addition. We also made an update to the language around privacy
> considerations. Here is the updated text:
>
>
> 1) Working Group name:
>
> Abuse and Account Take-Over Coordination Working Group
> 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.
> 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 considered against both (a) applicable regulations,
> policies, and the principles of user notice, choice and consent, and (b)
> the recognized benefits of protecting users’ accounts and data from abuse.
> The group will consider ways to address such potential privacy implications
> 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.
>
>
>
> *Trust Framework*
>
> A trust framework defining roles and responsibilities of parties sharing
> user security event information
>
>
>
> 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 or Trust
> Framework.
>
>
> 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=AwMF_g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=IR5tru86Ihv2g1IjtatpVdYMQcw52SU4UWhhLzaHxts&s=zsaUoprw8-hewGW9RwEVxCJdDksLM2tfwwQC40jny3Q&e=>
> .
>
>
>
> On Thu, Feb 26, 2015 at 10:36 PM, Adam Dawes <adawes at google.com> wrote:
>
> I'm resubmitting back under the name of AATOC since Linked In has already
> executed an IPR with that name as well as adding the Trust Framework
> deliverable.
>
>
> AATOC Charter
>
>
> 1) Working Group name:
>
> Abuse and Account Take-Over Coordination Working Group (AATOC Working
> Group)
> 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.
> 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.
>
>
>
> *Trust Framework*
>
> A trust framework defining roles and responsibilities of parties sharing
> user security event information
>
>
>
> 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 or Trust
> Framework.
>
>
> 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=AwMF_g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=IR5tru86Ihv2g1IjtatpVdYMQcw52SU4UWhhLzaHxts&s=zsaUoprw8-hewGW9RwEVxCJdDksLM2tfwwQC40jny3Q&e=>
> .
>
>
>
>
>
> On Thu, Feb 26, 2015 at 2:06 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>
> You can start joining the Friday calls now.
>
>
>
> We need to finalize the charter before people need to worry about signing
> the WG IPR.
>
> Sent from my iPhone
>
>
> On Feb 26, 2015, at 4:56 PM, Chuck Mortimore <cmortimore at salesforce.com>
> wrote:
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMF_g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=IR5tru86Ihv2g1IjtatpVdYMQcw52SU4UWhhLzaHxts&s=zsaUoprw8-hewGW9RwEVxCJdDksLM2tfwwQC40jny3Q&e=>
> .
>
>
>
>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__m.whitehouse.gov_the-2Dpress-2Doffice_2015_02_13_executive-2Dorder-2Dpromoting-2Dprivate-2Dsector-2Dcybersecurity-2Dinformation-2Dshari&d=AwMF_g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=IR5tru86Ihv2g1IjtatpVdYMQcw52SU4UWhhLzaHxts&s=Ymz_Lkzf4BW4FvJ38IDtvVKeQPQkd2kDaKuoWlotzrs&e=>,
> 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/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMF_g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=IR5tru86Ihv2g1IjtatpVdYMQcw52SU4UWhhLzaHxts&s=ZBjiNJFuAuQhY9EfZmff4-R5LvM5fz_i_xoQXnZzNBg&e=>
> @_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://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_aatoc_CAOJhRMYKX6O8LVPzCf8x-252BFDnmuMuLDH8RdssTXqZ1YeU54bLNA-2540mail.gmail.com-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dfooter&d=AwMF_g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=IR5tru86Ihv2g1IjtatpVdYMQcw52SU4UWhhLzaHxts&s=5lX731FD9xPT7XHaq_TymfCgMB4LpcDi1T_6AH4z2UE&e=>
> .
> For more options, visit https://groups.google.com/d/optout
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=AwMF_g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=IR5tru86Ihv2g1IjtatpVdYMQcw52SU4UWhhLzaHxts&s=_ArfcCFBHUilGTdBgpsiBBSJ1Yqz0rX_H5s7Jfmkq-o&e=>
> .
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150302/d161cd0a/attachment-0001.html>
More information about the specs-council
mailing list