[OIDFSC] AATOC Working Group Charter
Chuck Mortimore
cmortimore at salesforce.com
Mon Mar 2 19:12:30 UTC 2015
+1 for formation with that charter!
On Mon, Mar 2, 2015 at 10:06 AM, Breno de Medeiros <breno at google.com> wrote:
> +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/fd025223/attachment-0001.html>
More information about the specs-council
mailing list