[OIDFSC] AATOC Working Group Charter
Adam Dawes
adawes at google.com
Mon Mar 2 07:15:05 UTC 2015
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=>
>>>> .
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150301/cc7761cc/attachment-0001.html>
More information about the specs-council
mailing list