[OIDFSC] AATOC Working Group Charter
Nat Sakimura
n-sakimura at nri.co.jp
Fri Mar 6 17:35:42 UTC 2015
I did ping as well.... and this is precisely why I have put time limit in place.
Before, there was no time limit and it was taking forever...
On Fri, 6 Mar 2015 01:30:52 -0800
Adam Dawes <adawes at google.com> wrote:
> I've already pinged him. I guess we'll have to wait...
>
> On Fri, Mar 6, 2015 at 12:30 AM, John Bradley <ve7jtb at ve7jtb.com>
> wrote:
>
> > No the specs council is appointed from current and past editors.
> > Tim is still current if inattentive. Some one can ping him,
> > otherwise there is a two week time limit for objections.
> >
> > Close but not done.
> >
> > John B.
> >
> > On Mar 6, 2015, at 7:14 AM, Adam Dawes <adawes at google.com> wrote:
> >
> > I think we have +1's from all but Tim Bray. I don't believe Tim is
> > active as an editor for Account Chooser any more, that mantle has
> > probably passed to Pam.
> >
> > Are we done yet?
> >
> > 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=>
> >> .
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
--
Nat Sakimura (n-sakimura at nri.co.jp)
Nomura Research Institute, Ltd.
本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信
することを意図しております。意図された受取人以外の方によるこれらの情報の
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受
信されたメールを削除していただきますようお願い致します。 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.
More information about the specs-council
mailing list