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 <http://openid.net/intellectual-property/>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150224/3d0aadab/attachment-0001.html>

Search Discussions

  • Nat Sakimura at Feb 25, 2015 at 12:56 am
    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@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 <http://openid.net/intellectual-property/>.





    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150225/9cbff044/attachment-0001.html>
  • John Bradley at Feb 25, 2015 at 1:33 am
    I have reviewed the charter and am OK with that change.



    On Feb 24, 2015, at 7:56 PM, Nat Sakimura wrote:

    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 <mailto:adawes@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 <http://openid.net/intellectual-property/>.



    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/ <http://nat.sakimura.org/>
    @_nat_en

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150224/5dc2d652/attachment-0001.html>
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 4326 bytes
    Desc: not available
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150224/5dc2d652/attachment-0001.p7s>
  • Mike Jones at Feb 25, 2015 at 1:52 am
    I agree with the title change.


    I would suggest that one additional scope item and one additional deliverable be added, worded along these lines:


    Scope
    Trust Frameworks


    ? Defining sample or actual trust frameworks enabling account takeover coordination is within scope


    Proposed Deliverables
    ATO Trust Framework


    ? A trust framework defining roles and responsibilities of parties sharing account takeover information


                                                                     -- Mike


    From: specs-council [mailto:openid-specs-council-bounces at lists.openid.net] On Behalf Of John Bradley
    Sent: Tuesday, February 24, 2015 5:34 PM
    To: Nat Sakimura
    Cc: Adam Dawes; openid-specs-council at lists.openid.net
    Subject: Re: [OIDFSC] AATOC Working Group Charter


    I have reviewed the charter and am OK with that change.




    On Feb 24, 2015, at 7:56 PM, Nat Sakimura <sakimura at gmail.comwrote:


    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<mailto:adawes@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<http://openid.net/intellectual-property/>.






    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en


    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150225/af9c33bb/attachment-0001.html>
  • Ashish Jain at Feb 25, 2015 at 1:59 am
    I understand the need to be precise but ATO WG can probably convey the same message.


    From: Nat Sakimura <sakimura at gmail.com<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>
    Cc: "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:adawes@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 at Feb 25, 2015 at 2:09 am
    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@vmware.com>:

    I understand the need to be precise but ATO WG can probably convey the
    same message.

    From: Nat Sakimura <sakimura@gmail.com>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes@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@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/
    @_nat_en
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150225/5b736bef/attachment-0001.html>
  • Ashish Jain at Feb 25, 2015 at 2:25 am
    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler


    From: Nat Sakimura <sakimura at gmail.com<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain at vmware.com<mailto:ashishjain@vmware.com>>
    Cc: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>, "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:ashishjain@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<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>
    Cc: "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:adawes@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 at Feb 25, 2015 at 2:40 am
    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@vmware.com>:

    I?m not objecting?merely suggesting that referring it as Account
    Takeover WG is simpler

    From: Nat Sakimura <sakimura@gmail.com>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain@vmware.com>
    Cc: Adam Dawes <adawes@google.com>, "openid-specs-council at lists.openid.net"
    <openid-specs-council@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@vmware.com>:
    I understand the need to be precise but ATO WG can probably convey the
    same message.

    From: Nat Sakimura <sakimura@gmail.com>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes@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@google.com>:
    I would like to form a new work group, AATOC. Here is our proposed
    charter:

    AATOC Charter
    1) Working Group name:

    Abuse and Account Takeover Coordination Group (AATOC)

    2) Purpose

    The goal of AATOC is to provide data sharing schemas, privacy
    recommendations and protocols to:


    -

    Share information about important security events in order to thwart
    attackers from leveraging compromised accounts from one Service Provider to
    gain access to accounts on other Service Providers (mobile or web
    application developers and owners).
    -

    Enable users and providers to coordinate in order to securely
    restore accounts following a compromise.


    Internet accounts that use email addresses or phone numbers as the
    primary identifier for the account will be the initial focus.
    2) Scope

    The group will define:

    -

    Security events
    These are events ? whether directly authentication-related or
    occurring at another time in the user flow ? that take place on one service
    that could also have security implications on other Service Providers. The
    group will develop a taxonomy of security events and a common set of
    semantics to express relevant information about a security event.

    -

    Privacy Implications
    Sharing security information amongst providers has potential privacy
    implications for both end users and service providers. These privacy
    implications must be balanced against the recognized benefits of protecting
    users? accounts and data from abuse. The group will consider ways to
    optimize this balance when defining mechanisms to handle the various
    security events and recommend best practices for the industry.



    -

    Communications mechanisms
    Define bindings for the use of an existing transport protocol
    defined elsewhere.



    -

    Event schema
    Define a schema describing relevant events and relationships to
    allow for dissemination between interested and authorized parties.



    -

    Account recovery mechanisms

    Standardized mechanism(s) to allow providers to signal that a user has
    regained control of an account, or allow a user to explicitly restore
    control of a previously compromised account, with or without direct user
    involvement.
    Out of scope:

    Determining the account quality/reputation of a user on a particular
    service and communicating that to others.

    Definition of APIs and underlying mechanisms for connecting to,
    interacting with and operating centralized databases or intelligence
    clearinghouses when these are used to communicate security events between
    account providers.

    4) Proposed Deliverables

    The group proposes the following Non-Specification deliverables:

    Security Event and Account Lifecycle Schema

    -

    A taxonomy of security events and a common set of semantics to
    express relevant information about a security event and its relationships
    to other relevant data, events or indicators.

    Security Event Privacy Guidelines

    A set of recommendations on how to minimize the privacy impact on users
    and service providers while improving security, and how to provide
    appropriate privacy disclosures, labeling and access control guidelines
    around information in the Security Event Schema.

    The group proposes the following Specification deliverables:

    Communications Mechanisms

    Define bindings for the event messages to an already existing transport
    protocol to promote interoperability of sending event information to
    another Service Provider. This will allow a Service Provider to implement a
    single piece of infrastructure that would be able to send or receive event
    information to any other service provider.

    Order of Deliverables

    The group will work to produce the Security Event and Account Lifecycle
    Schema before beginning work on the Communications Mechanism.

    5) Anticipated audience or users

    -

    Service Providers who manage their own account systems which require
    an email address or phone number for registration.
    -

    Account and email providers that understand key security events that
    happen to a user?s account.
    -

    Identity as a Service (IDaaS) vendors that manage account and
    authentication systems for their customers.
    -

    Users seeking to regain control of a compromised account.


    6) Language

    English

    7) Method of work:

    E-mail discussions on the working group mailing list, working group
    conference calls, and face-to-face meetings from time to time.

    8) Basis for determining when the work is completed:

    Rough consensus and running code. The work will be completed once it is
    apparent that maximal consensus on the draft has been achieved, consistent
    with the purpose and scope.

    Background information
    Related work:

    -

    RFC6545 Real-time Inter-network Defense (RID)
    -

    RFC6546 Transport of Real-time Inter-network Defense (RID) Messages
    over HTTP/TLS
    -

    RFC6684 Guidelines and Template for Defining Extensions to the
    Incident Object Description Exchange Format (IODEF)
    -

    draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator
    Exchange
    -

    ISO/IEC 27002:2013 Information technology ? Security techniques ?
    Code of practice for information security controls
    -

    ISO/IEC 27035:2011 Information technology ? Security techniques ?
    Information security incident management



    Proposers

    -

    Adam Dawes, Google
    -

    Mark Risher, Google
    -

    Trent Adams, Paypal
    -

    George Fletcher, AOL
    -

    Andrew Nash, Confyrm
    -

    Nat Sakimura, Nomura Research Institute
    -

    John Bradley, Ping Identity
    -

    Henrik Biering, Peercraft

    Anticipated contributions:

    ?Security event reporting between Service Providers 1.0? under the OpenID
    Foundation?s IPR Policy
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=yV7iQ-h1QNIAyTmfXm6S6vIszebI2q_snUSkFyjxlkg&e=>
    .


    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=jmKQL3OD_c7eJXduzdJt5OJefY8ZjNiYCoAm8g-7oOA&e=>
    @_nat_en


    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=dibzrL00q20lgLcDv94EYh8Ums_bAaYivHuqDQgNfSI&s=jq4oX-tF55oVVtUOW6sW0RsihIhuUzSlJVyRWCVyAhQ&e=>
    @_nat_en





    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150225/1ef3ab04/attachment-0001.html>
  • Ashish Jain at Feb 25, 2015 at 2:55 am
    Well?from that line of thinking do you want to Abuse it and then do Account takeover :-).


    From: Nat Sakimura <sakimura at gmail.com<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 6:40 PM
    To: Ashish Jain <ashishjain at vmware.com<mailto:ashishjain@vmware.com>>
    Cc: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>, "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>>
    Subject: Re: [OIDFSC] AATOC Working Group Charter


    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<mailto:ashishjain@vmware.com>>:
    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler


    From: Nat Sakimura <sakimura at gmail.com<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain at vmware.com<mailto:ashishjain@vmware.com>>
    Cc: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>, "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:ashishjain@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<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>
    Cc: "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:adawes@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=>.
  • John Bradley at Feb 25, 2015 at 2:56 am
    That is a different WG outside of the OIDF;)

    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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 <mailto:ashishjain@vmware.com>>:
    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler

    From: Nat Sakimura <sakimura at gmail.com <mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain at vmware.com <mailto:ashishjain@vmware.com>>
    Cc: Adam Dawes <adawes at google.com <mailto:adawes@google.com>>, "openid-specs-council at lists.openid.net <mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net <mailto:openid-specs-council@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 <mailto:ashishjain@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 <mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes at google.com <mailto:adawes@google.com>>
    Cc: "openid-specs-council at lists.openid.net <mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net <mailto:openid-specs-council@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 <mailto:adawes@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/ <http://nat.sakimura.org/>
    @_nat_en

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150224/7cf1f70d/attachment-0001.html>
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 4326 bytes
    Desc: not available
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150224/7cf1f70d/attachment-0001.p7s>
  • Nat Sakimura at Feb 25, 2015 at 3:13 am
    While we are in the title, in view of the recent executive order
    http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari,
    we might suggest including the name "Information Sharing and analysis",
    e.g., AATISAC.
    2015?2?25?(?)?11:59 John Bradley <ve7jtb@ve7jtb.com>:

    That is a different WG outside of the OIDF;)

    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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@vmware.com>:
    I?m not objecting?merely suggesting that referring it as Account
    Takeover WG is simpler

    From: Nat Sakimura <sakimura@gmail.com>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain@vmware.com>
    Cc: Adam Dawes <adawes@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@vmware.com>:
    I understand the need to be precise but ATO WG can probably convey the
    same message.

    From: Nat Sakimura <sakimura@gmail.com>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes@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@google.com>:
    I would like to form a new work group, AATOC. Here is our proposed
    charter:

    AATOC Charter
    1) Working Group name:

    Abuse and Account Takeover Coordination Group (AATOC)

    2) Purpose
    The goal of AATOC is to provide data sharing schemas, privacy
    recommendations and protocols to:


    - Share information about important security events in order to
    thwart attackers from leveraging compromised accounts from one Service
    Provider to gain access to accounts on other Service Providers (mobile or
    web application developers and owners).
    - Enable users and providers to coordinate in order to securely
    restore accounts following a compromise.


    Internet accounts that use email addresses or phone numbers as the
    primary identifier for the account will be the initial focus.
    2) Scope
    The group will define:

    - Security events
    These are events ? whether directly authentication-related or
    occurring at another time in the user flow ? that take place on one service
    that could also have security implications on other Service Providers. The
    group will develop a taxonomy of security events and a common set of
    semantics to express relevant information about a security event.

    - Privacy Implications
    Sharing security information amongst providers has potential
    privacy implications for both end users and service providers. These
    privacy implications must be balanced against the recognized benefits of
    protecting users? accounts and data from abuse. The group will consider
    ways to optimize this balance when defining mechanisms to handle the
    various security events and recommend best practices for the industry.



    - Communications mechanisms
    Define bindings for the use of an existing transport protocol
    defined elsewhere.



    - Event schema
    Define a schema describing relevant events and relationships to
    allow for dissemination between interested and authorized parties.



    - Account recovery mechanisms

    Standardized mechanism(s) to allow providers to signal that a user has
    regained control of an account, or allow a user to explicitly restore
    control of a previously compromised account, with or without direct user
    involvement.
    Out of scope:
    Determining the account quality/reputation of a user on a particular
    service and communicating that to others.

    Definition of APIs and underlying mechanisms for connecting to,
    interacting with and operating centralized databases or intelligence
    clearinghouses when these are used to communicate security events between
    account providers.

    4) Proposed Deliverables
    The group proposes the following Non-Specification deliverables:

    Security Event and Account Lifecycle Schema

    - A taxonomy of security events and a common set of semantics to
    express relevant information about a security event and its relationships
    to other relevant data, events or indicators.

    Security Event Privacy Guidelines
    A set of recommendations on how to minimize the privacy impact on users
    and service providers while improving security, and how to provide
    appropriate privacy disclosures, labeling and access control guidelines
    around information in the Security Event Schema.

    The group proposes the following Specification deliverables:

    Communications Mechanisms
    Define bindings for the event messages to an already existing transport
    protocol to promote interoperability of sending event information to
    another Service Provider. This will allow a Service Provider to implement a
    single piece of infrastructure that would be able to send or receive event
    information to any other service provider.

    Order of Deliverables
    The group will work to produce the Security Event and Account Lifecycle
    Schema before beginning work on the Communications Mechanism.

    5) Anticipated audience or users

    - Service Providers who manage their own account systems which
    require an email address or phone number for registration.
    - Account and email providers that understand key security events
    that happen to a user?s account.
    - Identity as a Service (IDaaS) vendors that manage account and
    authentication systems for their customers.
    - Users seeking to regain control of a compromised account.


    6) Language
    English

    7) Method of work:

    E-mail discussions on the working group mailing list, working group
    conference calls, and face-to-face meetings from time to time.

    8) Basis for determining when the work is completed:

    Rough consensus and running code. The work will be completed once it is
    apparent that maximal consensus on the draft has been achieved, consistent
    with the purpose and scope.

    Background information
    Related work:

    - RFC6545 Real-time Inter-network Defense (RID)
    - RFC6546 Transport of Real-time Inter-network Defense (RID)
    Messages over HTTP/TLS
    - RFC6684 Guidelines and Template for Defining Extensions to the
    Incident Object Description Exchange Format (IODEF)
    - draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator
    Exchange
    - ISO/IEC 27002:2013 Information technology ? Security techniques
    ? Code of practice for information security controls
    - ISO/IEC 27035:2011 Information technology ? Security techniques ?
    Information security incident management



    Proposers

    - Adam Dawes, Google
    - Mark Risher, Google
    - Trent Adams, Paypal
    - George Fletcher, AOL
    - Andrew Nash, Confyrm
    - Nat Sakimura, Nomura Research Institute
    - John Bradley, Ping Identity
    -

    Henrik Biering, Peercraft

    Anticipated contributions:
    ?Security event reporting between Service Providers 1.0? under the OpenID
    Foundation?s IPR Policy
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=yV7iQ-h1QNIAyTmfXm6S6vIszebI2q_snUSkFyjxlkg&e=>
    .


    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=jmKQL3OD_c7eJXduzdJt5OJefY8ZjNiYCoAm8g-7oOA&e=>
    @_nat_en


    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=dibzrL00q20lgLcDv94EYh8Ums_bAaYivHuqDQgNfSI&s=jq4oX-tF55oVVtUOW6sW0RsihIhuUzSlJVyRWCVyAhQ&e=>
    @_nat_en


    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150225/8e7915bb/attachment-0001.html>
  • Adam Dawes at Feb 25, 2015 at 7:00 am
    +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 wrote:

    While we are in the title, in view of the recent executive order
    http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari,
    we might suggest including the name "Information Sharing and analysis",
    e.g., AATISAC.
    2015?2?25?(?)?11:59 John Bradley <ve7jtb@ve7jtb.com>:

    That is a different WG outside of the OIDF;)
    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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@vmware.com>:
    I?m not objecting?merely suggesting that referring it as Account
    Takeover WG is simpler

    From: Nat Sakimura <sakimura@gmail.com>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain@vmware.com>
    Cc: Adam Dawes <adawes@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@vmware.com>:
    I understand the need to be precise but ATO WG can probably convey
    the same message.

    From: Nat Sakimura <sakimura@gmail.com>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes@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@google.com>:
    I would like to form a new work group, AATOC. Here is our proposed
    charter:

    AATOC Charter
    1) Working Group name:

    Abuse and Account Takeover Coordination Group (AATOC)

    2) Purpose
    The goal of AATOC is to provide data sharing schemas, privacy
    recommendations and protocols to:


    - Share information about important security events in order to
    thwart attackers from leveraging compromised accounts from one Service
    Provider to gain access to accounts on other Service Providers (mobile or
    web application developers and owners).
    - Enable users and providers to coordinate in order to securely
    restore accounts following a compromise.


    Internet accounts that use email addresses or phone numbers as the
    primary identifier for the account will be the initial focus.
    2) Scope
    The group will define:

    - Security events
    These are events ? whether directly authentication-related or
    occurring at another time in the user flow ? that take place on one service
    that could also have security implications on other Service Providers. The
    group will develop a taxonomy of security events and a common set of
    semantics to express relevant information about a security event.

    - Privacy Implications
    Sharing security information amongst providers has potential
    privacy implications for both end users and service providers. These
    privacy implications must be balanced against the recognized benefits of
    protecting users? accounts and data from abuse. The group will consider
    ways to optimize this balance when defining mechanisms to handle the
    various security events and recommend best practices for the industry.



    - Communications mechanisms
    Define bindings for the use of an existing transport protocol
    defined elsewhere.



    - Event schema
    Define a schema describing relevant events and relationships to
    allow for dissemination between interested and authorized parties.



    - Account recovery mechanisms

    Standardized mechanism(s) to allow providers to signal that a user has
    regained control of an account, or allow a user to explicitly restore
    control of a previously compromised account, with or without direct user
    involvement.
    Out of scope:
    Determining the account quality/reputation of a user on a particular
    service and communicating that to others.

    Definition of APIs and underlying mechanisms for connecting to,
    interacting with and operating centralized databases or intelligence
    clearinghouses when these are used to communicate security events between
    account providers.

    4) Proposed Deliverables
    The group proposes the following Non-Specification deliverables:

    Security Event and Account Lifecycle Schema

    - A taxonomy of security events and a common set of semantics to
    express relevant information about a security event and its relationships
    to other relevant data, events or indicators.

    Security Event Privacy Guidelines
    A set of recommendations on how to minimize the privacy impact on
    users and service providers while improving security, and how to provide
    appropriate privacy disclosures, labeling and access control guidelines
    around information in the Security Event Schema.

    The group proposes the following Specification deliverables:

    Communications Mechanisms
    Define bindings for the event messages to an already existing
    transport protocol to promote interoperability of sending event information
    to another Service Provider. This will allow a Service Provider to
    implement a single piece of infrastructure that would be able to send or
    receive event information to any other service provider.

    Order of Deliverables
    The group will work to produce the Security Event and Account
    Lifecycle Schema before beginning work on the Communications Mechanism.

    5) Anticipated audience or users

    - Service Providers who manage their own account systems which
    require an email address or phone number for registration.
    - Account and email providers that understand key security events
    that happen to a user?s account.
    - Identity as a Service (IDaaS) vendors that manage account and
    authentication systems for their customers.
    - Users seeking to regain control of a compromised account.


    6) Language
    English

    7) Method of work:

    E-mail discussions on the working group mailing list, working group
    conference calls, and face-to-face meetings from time to time.

    8) Basis for determining when the work is completed:

    Rough consensus and running code. The work will be completed once it
    is apparent that maximal consensus on the draft has been achieved,
    consistent with the purpose and scope.

    Background information
    Related work:

    - RFC6545 Real-time Inter-network Defense (RID)
    - RFC6546 Transport of Real-time Inter-network Defense (RID)
    Messages over HTTP/TLS
    - RFC6684 Guidelines and Template for Defining Extensions to the
    Incident Object Description Exchange Format (IODEF)
    - draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator
    Exchange
    - ISO/IEC 27002:2013 Information technology ? Security techniques
    ? Code of practice for information security controls
    - ISO/IEC 27035:2011 Information technology ? Security techniques
    ? Information security incident management



    Proposers

    - Adam Dawes, Google
    - Mark Risher, Google
    - Trent Adams, Paypal
    - George Fletcher, AOL
    - Andrew Nash, Confyrm
    - Nat Sakimura, Nomura Research Institute
    - John Bradley, Ping Identity
    -

    Henrik Biering, Peercraft

    Anticipated contributions:
    ?Security event reporting between Service Providers 1.0? under the OpenID
    Foundation?s IPR Policy
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=yV7iQ-h1QNIAyTmfXm6S6vIszebI2q_snUSkFyjxlkg&e=>
    .


    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=jmKQL3OD_c7eJXduzdJt5OJefY8ZjNiYCoAm8g-7oOA&e=>
    @_nat_en


    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=dibzrL00q20lgLcDv94EYh8Ums_bAaYivHuqDQgNfSI&s=jq4oX-tF55oVVtUOW6sW0RsihIhuUzSlJVyRWCVyAhQ&e=>
    @_nat_en


    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150224/3182c8e3/attachment-0001.html>
  • Mike Jones at Feb 25, 2015 at 5:41 pm
    ?Takeover? is one word. So it would more correctly be ?Abuse and Account Takeover Coordination Working Group (AATC Working Group)?.


    One example of a trust framework in action is the set of bilateral agreements that Google has in place with people like AOL, Microsoft, Yahoo, etc. that specify the requirements that their IdPs must fulfill for Google to agree to be a relying party for them. A more general version of this would be applicable to anyone who wanted to participate and it would be registered with OIX. Not that any of this should be included in the charter for this working group.


    I think it?s important to say that Trust Frameworks are in scope and that one or more Trust Frameworks may be produced. It?s not critical that you know exactly what they are going to be like at chartering time.


    Adam, can you please resend an updated charter to the list with the revised title and the new scope and deliverable items for the Specs Council to review?


                                                                 Thanks,
                                                                 -- Mike


    From: specs-council [mailto:openid-specs-council-bounces at lists.openid.net] On Behalf Of Adam Dawes
    Sent: Tuesday, February 24, 2015 11:01 PM
    To: Nat Sakimura
    Cc: John Bradley; Ashish Jain; openid-specs-council at lists.openid.net; aatoc at googlegroups.com
    Subject: Re: [OIDFSC] AATOC Working Group Charter


    +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.comwrote:
    While we are in the title, in view of the recent executive order http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari, we might suggest including the name "Information Sharing and analysis", e.g., AATISAC.
    2015?2?25?(?)?11:59 John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>:


    That is a different WG outside of the OIDF;)


    On Feb 24, 2015, at 9:40 PM, Nat Sakimura <sakimura at gmail.comwrote:


    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<mailto:ashishjain@vmware.com>>:
    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler


    From: Nat Sakimura <sakimura at gmail.com<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain at vmware.com<mailto:ashishjain@vmware.com>>
    Cc: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>, "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:ashishjain@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<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>
    Cc: "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:adawes@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=>.
  • Adam Dawes at Feb 26, 2015 at 8:06 am
    Okay, I've revised the charter, with a new name, USESC (I couldn't fathom
    losing the "O" in AATOC). It doesn't have quite the ring but it's a bit
    more general which is useful since I think what will be produced will have
    uses beyond abuse and account takeovers. I've also included a deliverable
    on trust frameworks.


    Here it is:
    USESC Charter
    1) Working Group name:


    User Security Event Sharing and Coordination Working Group (USESC Working
    Group)
    2) Purpose


    The goal of USESC is to provide data sharing schemas, privacy
    recommendations and protocols to:




        -


        Share information about important security events related to user
        accounts in order to thwart attackers from leveraging compromised accounts
        from one Service Provider to gain access to accounts on other Service
        Providers (mobile or web application developers and owners).
        -


        Enable users and providers to coordinate in order to securely restore
        accounts following a compromise.




    Internet accounts that use email addresses or phone numbers as the primary
    identifier for the account will be the initial focus.
    3) Scope


    The group will define:


        -


        Security events
        These are events ? whether directly authentication-related or occurring
        at another time in the user flow ? that take place on one service that
        could also have security implications on other Service Providers. The group
        will develop a taxonomy of security events and a common set of semantics to
        express relevant information about a security event.


        -


        Privacy Implications
        Sharing security information amongst providers has potential privacy
        implications for both end users and service providers. These privacy
        implications must be balanced against the recognized benefits of protecting
        users? accounts and data from abuse. The group will consider ways to
        optimize this balance when defining mechanisms to handle the various
        security events and recommend best practices for the industry.






        -


        Communications mechanisms
        Define bindings for the use of an existing transport protocol defined
        elsewhere.






        -


        Event schema
        Define a schema describing relevant events and relationships to allow
        for dissemination between interested and authorized parties.


        -


        Trust Frameworks
        Define at least one model for the conditions under which information
        would be shared.






        -


        Account recovery mechanisms


    Standardized mechanism(s) to allow providers to signal that a user has
    regained control of an account, or allow a user to explicitly restore
    control of a previously compromised account, with or without direct user
    involvement.
    Out of scope:


    Determining the account quality/reputation of a user on a particular
    service and communicating that to others.


    Definition of APIs and underlying mechanisms for connecting to, interacting
    with and operating centralized databases or intelligence clearinghouses
    when these are used to communicate security events between account
    providers.


    4) Proposed Deliverables


    The group proposes the following Non-Specification deliverables:


    Security Event and Account Lifecycle Schema


        -


        A taxonomy of security events and a common set of semantics to express
        relevant information about a security event and its relationships to other
        relevant data, events or indicators.




    Security Event Privacy Guidelines


    A set of recommendations on how to minimize the privacy impact on users and
    service providers while improving security, and how to provide appropriate
    privacy disclosures, labeling and access control guidelines around
    information in the Security Event Schema.


    The group proposes the following Specification deliverables:


    Communications Mechanisms


    Define bindings for the event messages to an already existing transport
    protocol to promote interoperability of sending event information to
    another Service Provider. This will allow a Service Provider to implement a
    single piece of infrastructure that would be able to send or receive event
    information to any other service provider.


    Order of Deliverables


    The group will work to produce the Security Event and Account Lifecycle
    Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users


        -


        Service Providers who manage their own account systems which require an
        email address or phone number for registration.
        -


        Account and email providers that understand key security events that
        happen to a user?s account.
        -


        Identity as a Service (IDaaS) vendors that manage account and
        authentication systems for their customers.
        -


        Users seeking to regain control of a compromised account.




    6) Language


    English


    7) Method of work:


    E-mail discussions on the working group mailing list, working group
    conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:


    Rough consensus and running code. The work will be completed once it is
    apparent that maximal consensus on the draft has been achieved, consistent
    with the purpose and scope.


    Background information
    Related work:


        -


        RFC6545 Real-time Inter-network Defense (RID)
        -


        RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over
        HTTP/TLS
        -


        RFC6684 Guidelines and Template for Defining Extensions to the Incident
        Object Description Exchange Format (IODEF)
        -


        draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator Exchange
        -


        ISO/IEC 27002:2013 Information technology ? Security techniques ? Code
        of practice for information security controls
        -


        ISO/IEC 27035:2011 Information technology ? Security techniques ?
        Information security incident management






    Proposers


        -


        Adam Dawes, Google
        -


        Mark Risher, Google
        -


        Trent Adams, Paypal
        -


        George Fletcher, AOL
        -


        Andrew Nash, Confyrm
        -


        Nat Sakimura, Nomura Research Institute
        -


        John Bradley, Ping Identity
        -


        Henrik Biering, Peercraft


    Anticipated contributions:


    ?Security event reporting between Service Providers 1.0? under the OpenID
    Foundation?s IPR Policy <http://openid.net/intellectual-property/>.




    On Wed, Feb 25, 2015 at 5:37 PM, Andrew Nash 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 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 wrote:

    While we are in the title, in view of the recent executive order
    http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari,
    we might suggest including the name "Information Sharing and analysis",
    e.g., AATISAC.
    2015?2?25?(?)?11:59 John Bradley <ve7jtb@ve7jtb.com>:

    That is a different WG outside of the OIDF;)
    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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@vmware.com>:
    I?m not objecting?merely suggesting that referring it as Account
    Takeover WG is simpler

    From: Nat Sakimura <sakimura@gmail.com>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain@vmware.com>
    Cc: Adam Dawes <adawes@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@vmware.com>:
    I understand the need to be precise but ATO WG can probably convey
    the same message.

    From: Nat Sakimura <sakimura@gmail.com>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes@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@google.com>:
    I would like to form a new work group, AATOC. Here is our proposed
    charter:

    AATOC Charter
    1) Working Group name:

    Abuse and Account Takeover Coordination Group (AATOC)

    2) Purpose
    The goal of AATOC is to provide data sharing schemas, privacy
    recommendations and protocols to:


    - Share information about important security events in order to
    thwart attackers from leveraging compromised accounts from one Service
    Provider to gain access to accounts on other Service Providers (mobile or
    web application developers and owners).
    - Enable users and providers to coordinate in order to securely
    restore accounts following a compromise.


    Internet accounts that use email addresses or phone numbers as the
    primary identifier for the account will be the initial focus.
    2) Scope
    The group will define:

    - Security events
    These are events ? whether directly authentication-related or
    occurring at another time in the user flow ? that take place on one service
    that could also have security implications on other Service Providers. The
    group will develop a taxonomy of security events and a common set of
    semantics to express relevant information about a security event.

    - Privacy Implications
    Sharing security information amongst providers has potential
    privacy implications for both end users and service providers. These
    privacy implications must be balanced against the recognized benefits of
    protecting users? accounts and data from abuse. The group will consider
    ways to optimize this balance when defining mechanisms to handle the
    various security events and recommend best practices for the industry.



    - Communications mechanisms
    Define bindings for the use of an existing transport protocol
    defined elsewhere.



    - Event schema
    Define a schema describing relevant events and relationships to
    allow for dissemination between interested and authorized parties.



    - Account recovery mechanisms

    Standardized mechanism(s) to allow providers to signal that a user
    has regained control of an account, or allow a user to explicitly restore
    control of a previously compromised account, with or without direct user
    involvement.
    Out of scope:
    Determining the account quality/reputation of a user on a particular
    service and communicating that to others.

    Definition of APIs and underlying mechanisms for connecting to,
    interacting with and operating centralized databases or intelligence
    clearinghouses when these are used to communicate security events between
    account providers.

    4) Proposed Deliverables
    The group proposes the following Non-Specification deliverables:

    Security Event and Account Lifecycle Schema

    - A taxonomy of security events and a common set of semantics to
    express relevant information about a security event and its relationships
    to other relevant data, events or indicators.

    Security Event Privacy Guidelines
    A set of recommendations on how to minimize the privacy impact on
    users and service providers while improving security, and how to provide
    appropriate privacy disclosures, labeling and access control guidelines
    around information in the Security Event Schema.

    The group proposes the following Specification deliverables:

    Communications Mechanisms
    Define bindings for the event messages to an already existing
    transport protocol to promote interoperability of sending event information
    to another Service Provider. This will allow a Service Provider to
    implement a single piece of infrastructure that would be able to send or
    receive event information to any other service provider.

    Order of Deliverables
    The group will work to produce the Security Event and Account
    Lifecycle Schema before beginning work on the Communications Mechanism.

    5) Anticipated audience or users

    - Service Providers who manage their own account systems which
    require an email address or phone number for registration.
    - Account and email providers that understand key security
    events that happen to a user?s account.
    - Identity as a Service (IDaaS) vendors that manage account and
    authentication systems for their customers.
    - Users seeking to regain control of a compromised account.


    6) Language
    English

    7) Method of work:

    E-mail discussions on the working group mailing list, working group
    conference calls, and face-to-face meetings from time to time.

    8) Basis for determining when the work is completed:

    Rough consensus and running code. The work will be completed once it
    is apparent that maximal consensus on the draft has been achieved,
    consistent with the purpose and scope.

    Background information
    Related work:

    - RFC6545 Real-time Inter-network Defense (RID)
    - RFC6546 Transport of Real-time Inter-network Defense (RID)
    Messages over HTTP/TLS
    - RFC6684 Guidelines and Template for Defining Extensions to the
    Incident Object Description Exchange Format (IODEF)
    - draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator
    Exchange
    - ISO/IEC 27002:2013 Information technology ? Security
    techniques ? Code of practice for information security controls
    - ISO/IEC 27035:2011 Information technology ? Security
    techniques ? Information security incident management



    Proposers

    - Adam Dawes, Google
    - Mark Risher, Google
    - Trent Adams, Paypal
    - George Fletcher, AOL
    - Andrew Nash, Confyrm
    - Nat Sakimura, Nomura Research Institute
    - John Bradley, Ping Identity
    -

    Henrik Biering, Peercraft

    Anticipated contributions:
    ?Security event reporting between Service Providers 1.0? under the OpenID
    Foundation?s IPR Policy
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=yV7iQ-h1QNIAyTmfXm6S6vIszebI2q_snUSkFyjxlkg&e=>
    .


    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=jmKQL3OD_c7eJXduzdJt5OJefY8ZjNiYCoAm8g-7oOA&e=>
    @_nat_en


    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=dibzrL00q20lgLcDv94EYh8Ums_bAaYivHuqDQgNfSI&s=jq4oX-tF55oVVtUOW6sW0RsihIhuUzSlJVyRWCVyAhQ&e=>
    @_nat_en


    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en

    --
    You received this message because you are subscribed to the Google Groups
    "Abuse and ATO Coordination" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to aatoc+unsubscribe at googlegroups.com.
    To post to this group, send email to aatoc at googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com
    <https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com?utm_medium=email&utm_source=footer>
    .
    For more options, visit https://groups.google.com/d/optout.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150226/8e64ae3e/attachment-0001.html>
  • John Ehrig at Feb 26, 2015 at 2:59 pm
    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] On Behalf Of Adam Dawes
    Sent: Thursday, February 26, 2015 1:06 AM
    To: Andrew Nash
    Cc: John Bradley; openid-specs-council at lists.openid.net; Ashish Jain; Nat Sakimura; aatoc at googlegroups.com
    Subject: Re: [OIDFSC] AATOC Working Group Charter


    Okay, I've revised the charter, with a new name, USESC (I couldn't fathom losing the "O" in AATOC). It doesn't have quite the ring but it's a bit more general which is useful since I think what will be produced will have uses beyond abuse and account takeovers. I've also included a deliverable on trust frameworks.


    Here it is:
    USESC Charter


    1) Working Group name:


    User Security Event Sharing and Coordination Working Group (USESC Working Group)


    2) Purpose


    The goal of USESC is to provide data sharing schemas, privacy recommendations and protocols to:




    ? Share information about important security events related to user accounts in order to thwart attackers from leveraging compromised accounts from one Service Provider to gain access to accounts on other Service Providers (mobile or web application developers and owners).


    ? Enable users and providers to coordinate in order to securely restore accounts following a compromise.




    Internet accounts that use email addresses or phone numbers as the primary identifier for the account will be the initial focus.


    3) Scope


    The group will define:


    ? Security events
    These are events ? whether directly authentication-related or occurring at another time in the user flow ? that take place on one service that could also have security implications on other Service Providers. The group will develop a taxonomy of security events and a common set of semantics to express relevant information about a security event.


    ? Privacy Implications
    Sharing security information amongst providers has potential privacy implications for both end users and service providers. These privacy implications must be balanced against the recognized benefits of protecting users? accounts and data from abuse. The group will consider ways to optimize this balance when defining mechanisms to handle the various security events and recommend best practices for the industry.




    ? Communications mechanisms
    Define bindings for the use of an existing transport protocol defined elsewhere.




    ? Event schema
    Define a schema describing relevant events and relationships to allow for dissemination between interested and authorized parties.


    ? Trust Frameworks
    Define at least one model for the conditions under which information would be shared.




    ? Account recovery mechanisms


    Standardized mechanism(s) to allow providers to signal that a user has regained control of an account, or allow a user to explicitly restore control of a previously compromised account, with or without direct user involvement.


    Out of scope:


    Determining the account quality/reputation of a user on a particular service and communicating that to others.




    Definition of APIs and underlying mechanisms for connecting to, interacting with and operating centralized databases or intelligence clearinghouses when these are used to communicate security events between account providers.


    4) Proposed Deliverables


    The group proposes the following Non-Specification deliverables:




    Security Event and Account Lifecycle Schema


    ? A taxonomy of security events and a common set of semantics to express relevant information about a security event and its relationships to other relevant data, events or indicators.




    Security Event Privacy Guidelines


    A set of recommendations on how to minimize the privacy impact on users and service providers while improving security, and how to provide appropriate privacy disclosures, labeling and access control guidelines around information in the Security Event Schema.




    The group proposes the following Specification deliverables:




    Communications Mechanisms


    Define bindings for the event messages to an already existing transport protocol to promote interoperability of sending event information to another Service Provider. This will allow a Service Provider to implement a single piece of infrastructure that would be able to send or receive event information to any other service provider.




    Order of Deliverables


    The group will work to produce the Security Event and Account Lifecycle Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users


    ? Service Providers who manage their own account systems which require an email address or phone number for registration.


    ? Account and email providers that understand key security events that happen to a user?s account.


    ? Identity as a Service (IDaaS) vendors that manage account and authentication systems for their customers.


    ? Users seeking to regain control of a compromised account.


    6) Language


    English


    7) Method of work:


    E-mail discussions on the working group mailing list, working group conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:


    Rough consensus and running code. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope.


    Background information


    Related work:


    ? RFC6545 Real-time Inter-network Defense (RID)


    ? RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS


    ? RFC6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)


    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator Exchange


    ? ISO/IEC 27002:2013 Information technology ? Security techniques ? Code of practice for information security controls


    ? ISO/IEC 27035:2011 Information technology ? Security techniques ? Information security incident management


    Proposers


    ? Adam Dawes, Google


    ? Mark Risher, Google


    ? Trent Adams, Paypal


    ? George Fletcher, AOL


    ? Andrew Nash, Confyrm


    ? Nat Sakimura, Nomura Research Institute


    ? John Bradley, Ping Identity


    ? Henrik Biering, Peercraft


    Anticipated contributions:


    ?Security event reporting between Service Providers 1.0? under the OpenID Foundation?s IPR Policy<http://openid.net/intellectual-property/>.




    On Wed, Feb 25, 2015 at 5:37 PM, Andrew Nash <andrew at confyrm.comwrote:
    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.comwrote:
    +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.comwrote:
    While we are in the title, in view of the recent executive order http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari, we might suggest including the name "Information Sharing and analysis", e.g., AATISAC.
    2015?2?25?(?)?11:59 John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>:


    That is a different WG outside of the OIDF;)


    On Feb 24, 2015, at 9:40 PM, Nat Sakimura <sakimura at gmail.comwrote:


    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<mailto:ashishjain@vmware.com>>:
    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler


    From: Nat Sakimura <sakimura at gmail.com<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain at vmware.com<mailto:ashishjain@vmware.com>>
    Cc: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>, "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:ashishjain@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<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>
    Cc: "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:adawes@google.com>>:
    I would like to form a new work group, AATOC. Here is our proposed charter:


    AATOC Charter


    1) Working Group name:


    Abuse and Account Takeover Coordination Group (AATOC)


    2) Purpose
    The goal of AATOC is to provide data sharing schemas, privacy recommendations and protocols to:


    ? Share information about important security events in order to thwart attackers from leveraging compromised accounts from one Service Provider to gain access to accounts on other Service Providers (mobile or web application developers and owners).
    ? Enable users and providers to coordinate in order to securely restore accounts following a compromise.


    Internet accounts that use email addresses or phone numbers as the primary identifier for the account will be the initial focus.
    2) Scope
    The group will define:
    ? Security events
    These are events ? whether directly authentication-related or occurring at another time in the user flow ? that take place on one service that could also have security implications on other Service Providers. The group will develop a taxonomy of security events and a common set of semantics to express relevant information about a security event.
    ? Privacy Implications
    Sharing security information amongst providers has potential privacy implications for both end users and service providers. These privacy implications must be balanced against the recognized benefits of protecting users? accounts and data from abuse. The group will consider ways to optimize this balance when defining mechanisms to handle the various security events and recommend best practices for the industry.


    ? Communications mechanisms
    Define bindings for the use of an existing transport protocol defined elsewhere.


    ? Event schema
    Define a schema describing relevant events and relationships to allow for dissemination between interested and authorized parties.


    ? Account recovery mechanisms
    Standardized mechanism(s) to allow providers to signal that a user has regained control of an account, or allow a user to explicitly restore control of a previously compromised account, with or without direct user involvement.
    Out of scope:
    Determining the account quality/reputation of a user on a particular service and communicating that to others.


    Definition of APIs and underlying mechanisms for connecting to, interacting with and operating centralized databases or intelligence clearinghouses when these are used to communicate security events between account providers.


    4) Proposed Deliverables
    The group proposes the following Non-Specification deliverables:


    Security Event and Account Lifecycle Schema
    ? A taxonomy of security events and a common set of semantics to express relevant information about a security event and its relationships to other relevant data, events or indicators.
    Security Event Privacy Guidelines
    A set of recommendations on how to minimize the privacy impact on users and service providers while improving security, and how to provide appropriate privacy disclosures, labeling and access control guidelines around information in the Security Event Schema.


    The group proposes the following Specification deliverables:


    Communications Mechanisms
    Define bindings for the event messages to an already existing transport protocol to promote interoperability of sending event information to another Service Provider. This will allow a Service Provider to implement a single piece of infrastructure that would be able to send or receive event information to any other service provider.


    Order of Deliverables
    The group will work to produce the Security Event and Account Lifecycle Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users
    ? Service Providers who manage their own account systems which require an email address or phone number for registration.
    ? Account and email providers that understand key security events that happen to a user?s account.
    ? Identity as a Service (IDaaS) vendors that manage account and authentication systems for their customers.
    ? Users seeking to regain control of a compromised account.


    6) Language
    English


    7) Method of work:


    E-mail discussions on the working group mailing list, working group conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:


    Rough consensus and running code. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope.


    Background information


    Related work:
    ? RFC6545 Real-time Inter-network Defense (RID)
    ? RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS
    ? RFC6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)
    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator Exchange
    ? ISO/IEC 27002:2013 Information technology ? Security techniques ? Code of practice for information security controls
    ? ISO/IEC 27035:2011 Information technology ? Security techniques ? Information security incident management


    Proposers
    ? Adam Dawes, Google
    ? Mark Risher, Google
    ? Trent Adams, Paypal
    ? George Fletcher, AOL
    ? Andrew Nash, Confyrm
    ? Nat Sakimura, Nomura Research Institute
    ? John Bradley, Ping Identity


    ? Henrik Biering, Peercraft


    Anticipated contributions:
    ?Security event reporting between Service Providers 1.0? under the OpenID Foundation?s IPR Policy<https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=yV7iQ-h1QNIAyTmfXm6S6vIszebI2q_snUSkFyjxlkg&e=>.






    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=jmKQL3OD_c7eJXduzdJt5OJefY8ZjNiYCoAm8g-7oOA&e=>
    @_nat_en






    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=dibzrL00q20lgLcDv94EYh8Ums_bAaYivHuqDQgNfSI&s=jq4oX-tF55oVVtUOW6sW0RsihIhuUzSlJVyRWCVyAhQ&e=>
    @_nat_en






    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en




    --
    You received this message because you are subscribed to the Google Groups "Abuse and ATO Coordination" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to aatoc+unsubscribe at googlegroups.com<mailto:aatoc+unsubscribe@googlegroups.com>.
    To post to this group, send email to aatoc at googlegroups.com<mailto:aatoc@googlegroups.com>.
    To view this discussion on the web visit https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com<https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
    For more options, visit https://groups.google.com/d/optout.




    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150226/6e501025/attachment-0001.html>
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: OpenID Foundation-Contribution Agreement-10151.pdf
    Type: application/pdf
    Size: 647026 bytes
    Desc: OpenID Foundation-Contribution Agreement-10151.pdf
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150226/6e501025/attachment-0001.pdf>
  • Mike Jones at Feb 26, 2015 at 4:30 pm
    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] 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<mailto:openid-specs-council@lists.openid.net>; Ashish Jain; Nat Sakimura; aatoc at googlegroups.com<mailto:aatoc@googlegroups.com>
    Subject: Re: [OIDFSC] AATOC Working Group Charter


    Okay, I've revised the charter, with a new name, USESC (I couldn't fathom losing the "O" in AATOC). It doesn't have quite the ring but it's a bit more general which is useful since I think what will be produced will have uses beyond abuse and account takeovers. I've also included a deliverable on trust frameworks.


    Here it is:
    USESC Charter


    1) Working Group name:


    User Security Event Sharing and Coordination Working Group (USESC Working Group)


    2) Purpose


    The goal of USESC is to provide data sharing schemas, privacy recommendations and protocols to:




    ? Share information about important security events related to user accounts in order to thwart attackers from leveraging compromised accounts from one Service Provider to gain access to accounts on other Service Providers (mobile or web application developers and owners).


    ? Enable users and providers to coordinate in order to securely restore accounts following a compromise.




    Internet accounts that use email addresses or phone numbers as the primary identifier for the account will be the initial focus.


    3) Scope


    The group will define:


    ? Security events
    These are events ? whether directly authentication-related or occurring at another time in the user flow ? that take place on one service that could also have security implications on other Service Providers. The group will develop a taxonomy of security events and a common set of semantics to express relevant information about a security event.


    ? Privacy Implications
    Sharing security information amongst providers has potential privacy implications for both end users and service providers. These privacy implications must be balanced against the recognized benefits of protecting users? accounts and data from abuse. The group will consider ways to optimize this balance when defining mechanisms to handle the various security events and recommend best practices for the industry.




    ? Communications mechanisms
    Define bindings for the use of an existing transport protocol defined elsewhere.




    ? Event schema
    Define a schema describing relevant events and relationships to allow for dissemination between interested and authorized parties.


    ? Trust Frameworks
    Define at least one model for the conditions under which information would be shared.




    ? Account recovery mechanisms


    Standardized mechanism(s) to allow providers to signal that a user has regained control of an account, or allow a user to explicitly restore control of a previously compromised account, with or without direct user involvement.


    Out of scope:


    Determining the account quality/reputation of a user on a particular service and communicating that to others.




    Definition of APIs and underlying mechanisms for connecting to, interacting with and operating centralized databases or intelligence clearinghouses when these are used to communicate security events between account providers.


    4) Proposed Deliverables


    The group proposes the following Non-Specification deliverables:




    Security Event and Account Lifecycle Schema


    ? A taxonomy of security events and a common set of semantics to express relevant information about a security event and its relationships to other relevant data, events or indicators.




    Security Event Privacy Guidelines


    A set of recommendations on how to minimize the privacy impact on users and service providers while improving security, and how to provide appropriate privacy disclosures, labeling and access control guidelines around information in the Security Event Schema.




    The group proposes the following Specification deliverables:




    Communications Mechanisms


    Define bindings for the event messages to an already existing transport protocol to promote interoperability of sending event information to another Service Provider. This will allow a Service Provider to implement a single piece of infrastructure that would be able to send or receive event information to any other service provider.




    Order of Deliverables


    The group will work to produce the Security Event and Account Lifecycle Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users


    ? Service Providers who manage their own account systems which require an email address or phone number for registration.


    ? Account and email providers that understand key security events that happen to a user?s account.


    ? Identity as a Service (IDaaS) vendors that manage account and authentication systems for their customers.


    ? Users seeking to regain control of a compromised account.


    6) Language


    English


    7) Method of work:


    E-mail discussions on the working group mailing list, working group conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:


    Rough consensus and running code. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope.


    Background information


    Related work:


    ? RFC6545 Real-time Inter-network Defense (RID)


    ? RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS


    ? RFC6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)


    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator Exchange


    ? ISO/IEC 27002:2013 Information technology ? Security techniques ? Code of practice for information security controls


    ? ISO/IEC 27035:2011 Information technology ? Security techniques ? Information security incident management


    Proposers


    ? Adam Dawes, Google


    ? Mark Risher, Google


    ? Trent Adams, Paypal


    ? George Fletcher, AOL


    ? Andrew Nash, Confyrm


    ? Nat Sakimura, Nomura Research Institute


    ? John Bradley, Ping Identity


    ? Henrik Biering, Peercraft


    Anticipated contributions:


    ?Security event reporting between Service Providers 1.0? under the OpenID Foundation?s IPR Policy<http://openid.net/intellectual-property/>.




    On Wed, Feb 25, 2015 at 5:37 PM, Andrew Nash <andrew at confyrm.comwrote:
    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.comwrote:
    +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.comwrote:
    While we are in the title, in view of the recent executive order http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari, we might suggest including the name "Information Sharing and analysis", e.g., AATISAC.
    2015?2?25?(?)?11:59 John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>:


    That is a different WG outside of the OIDF;)


    On Feb 24, 2015, at 9:40 PM, Nat Sakimura <sakimura at gmail.comwrote:


    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<mailto:ashishjain@vmware.com>>:
    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler


    From: Nat Sakimura <sakimura at gmail.com<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain at vmware.com<mailto:ashishjain@vmware.com>>
    Cc: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>, "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:ashishjain@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<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>
    Cc: "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:adawes@google.com>>:
    I would like to form a new work group, AATOC. Here is our proposed charter:


    AATOC Charter


    1) Working Group name:


    Abuse and Account Takeover Coordination Group (AATOC)


    2) Purpose
    The goal of AATOC is to provide data sharing schemas, privacy recommendations and protocols to:


    ? Share information about important security events in order to thwart attackers from leveraging compromised accounts from one Service Provider to gain access to accounts on other Service Providers (mobile or web application developers and owners).
    ? Enable users and providers to coordinate in order to securely restore accounts following a compromise.


    Internet accounts that use email addresses or phone numbers as the primary identifier for the account will be the initial focus.
    2) Scope
    The group will define:
    ? Security events
    These are events ? whether directly authentication-related or occurring at another time in the user flow ? that take place on one service that could also have security implications on other Service Providers. The group will develop a taxonomy of security events and a common set of semantics to express relevant information about a security event.
    ? Privacy Implications
    Sharing security information amongst providers has potential privacy implications for both end users and service providers. These privacy implications must be balanced against the recognized benefits of protecting users? accounts and data from abuse. The group will consider ways to optimize this balance when defining mechanisms to handle the various security events and recommend best practices for the industry.


    ? Communications mechanisms
    Define bindings for the use of an existing transport protocol defined elsewhere.


    ? Event schema
    Define a schema describing relevant events and relationships to allow for dissemination between interested and authorized parties.


    ? Account recovery mechanisms
    Standardized mechanism(s) to allow providers to signal that a user has regained control of an account, or allow a user to explicitly restore control of a previously compromised account, with or without direct user involvement.
    Out of scope:
    Determining the account quality/reputation of a user on a particular service and communicating that to others.


    Definition of APIs and underlying mechanisms for connecting to, interacting with and operating centralized databases or intelligence clearinghouses when these are used to communicate security events between account providers.


    4) Proposed Deliverables
    The group proposes the following Non-Specification deliverables:


    Security Event and Account Lifecycle Schema
    ? A taxonomy of security events and a common set of semantics to express relevant information about a security event and its relationships to other relevant data, events or indicators.
    Security Event Privacy Guidelines
    A set of recommendations on how to minimize the privacy impact on users and service providers while improving security, and how to provide appropriate privacy disclosures, labeling and access control guidelines around information in the Security Event Schema.


    The group proposes the following Specification deliverables:


    Communications Mechanisms
    Define bindings for the event messages to an already existing transport protocol to promote interoperability of sending event information to another Service Provider. This will allow a Service Provider to implement a single piece of infrastructure that would be able to send or receive event information to any other service provider.


    Order of Deliverables
    The group will work to produce the Security Event and Account Lifecycle Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users
    ? Service Providers who manage their own account systems which require an email address or phone number for registration.
    ? Account and email providers that understand key security events that happen to a user?s account.
    ? Identity as a Service (IDaaS) vendors that manage account and authentication systems for their customers.
    ? Users seeking to regain control of a compromised account.


    6) Language
    English


    7) Method of work:


    E-mail discussions on the working group mailing list, working group conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:


    Rough consensus and running code. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope.


    Background information


    Related work:
    ? RFC6545 Real-time Inter-network Defense (RID)
    ? RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS
    ? RFC6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)
    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator Exchange
    ? ISO/IEC 27002:2013 Information technology ? Security techniques ? Code of practice for information security controls
    ? ISO/IEC 27035:2011 Information technology ? Security techniques ? Information security incident management


    Proposers
    ? Adam Dawes, Google
    ? Mark Risher, Google
    ? Trent Adams, Paypal
    ? George Fletcher, AOL
    ? Andrew Nash, Confyrm
    ? Nat Sakimura, Nomura Research Institute
    ? John Bradley, Ping Identity


    ? Henrik Biering, Peercraft


    Anticipated contributions:
    ?Security event reporting between Service Providers 1.0? under the OpenID Foundation?s IPR Policy<https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=yV7iQ-h1QNIAyTmfXm6S6vIszebI2q_snUSkFyjxlkg&e=>.






    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=jmKQL3OD_c7eJXduzdJt5OJefY8ZjNiYCoAm8g-7oOA&e=>
    @_nat_en






    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=dibzrL00q20lgLcDv94EYh8Ums_bAaYivHuqDQgNfSI&s=jq4oX-tF55oVVtUOW6sW0RsihIhuUzSlJVyRWCVyAhQ&e=>
    @_nat_en






    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en




    --
    You received this message because you are subscribed to the Google Groups "Abuse and ATO Coordination" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to aatoc+unsubscribe at googlegroups.com<mailto:aatoc+unsubscribe@googlegroups.com>.
    To post to this group, send email to aatoc at googlegroups.com<mailto:aatoc@googlegroups.com>.
    To view this discussion on the web visit https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com<https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
    For more options, visit https://groups.google.com/d/optout.




    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150226/8bac3a67/attachment-0001.html>
  • John Ehrig at Feb 26, 2015 at 4:45 pm
    Linked-in


    From: specs-council [mailto:openid-specs-council-bounces at lists.openid.net] On Behalf Of Mike Jones
    Sent: Thursday, February 26, 2015 9:31 AM
    To: John Ehrig; Adam Dawes; 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


    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<mailto:openid-specs-council@lists.openid.net>; aatoc at googlegroups.com<mailto:aatoc@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] 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<mailto:openid-specs-council@lists.openid.net>; Ashish Jain; Nat Sakimura; aatoc at googlegroups.com<mailto:aatoc@googlegroups.com>
    Subject: Re: [OIDFSC] AATOC Working Group Charter


    Okay, I've revised the charter, with a new name, USESC (I couldn't fathom losing the "O" in AATOC). It doesn't have quite the ring but it's a bit more general which is useful since I think what will be produced will have uses beyond abuse and account takeovers. I've also included a deliverable on trust frameworks.


    Here it is:
    USESC Charter


    1) Working Group name:


    User Security Event Sharing and Coordination Working Group (USESC Working Group)


    2) Purpose


    The goal of USESC is to provide data sharing schemas, privacy recommendations and protocols to:




    ? Share information about important security events related to user accounts in order to thwart attackers from leveraging compromised accounts from one Service Provider to gain access to accounts on other Service Providers (mobile or web application developers and owners).


    ? Enable users and providers to coordinate in order to securely restore accounts following a compromise.




    Internet accounts that use email addresses or phone numbers as the primary identifier for the account will be the initial focus.


    3) Scope


    The group will define:


    ? Security events
    These are events ? whether directly authentication-related or occurring at another time in the user flow ? that take place on one service that could also have security implications on other Service Providers. The group will develop a taxonomy of security events and a common set of semantics to express relevant information about a security event.


    ? Privacy Implications
    Sharing security information amongst providers has potential privacy implications for both end users and service providers. These privacy implications must be balanced against the recognized benefits of protecting users? accounts and data from abuse. The group will consider ways to optimize this balance when defining mechanisms to handle the various security events and recommend best practices for the industry.




    ? Communications mechanisms
    Define bindings for the use of an existing transport protocol defined elsewhere.




    ? Event schema
    Define a schema describing relevant events and relationships to allow for dissemination between interested and authorized parties.


    ? Trust Frameworks
    Define at least one model for the conditions under which information would be shared.




    ? Account recovery mechanisms


    Standardized mechanism(s) to allow providers to signal that a user has regained control of an account, or allow a user to explicitly restore control of a previously compromised account, with or without direct user involvement.


    Out of scope:


    Determining the account quality/reputation of a user on a particular service and communicating that to others.




    Definition of APIs and underlying mechanisms for connecting to, interacting with and operating centralized databases or intelligence clearinghouses when these are used to communicate security events between account providers.


    4) Proposed Deliverables


    The group proposes the following Non-Specification deliverables:




    Security Event and Account Lifecycle Schema


    ? A taxonomy of security events and a common set of semantics to express relevant information about a security event and its relationships to other relevant data, events or indicators.




    Security Event Privacy Guidelines


    A set of recommendations on how to minimize the privacy impact on users and service providers while improving security, and how to provide appropriate privacy disclosures, labeling and access control guidelines around information in the Security Event Schema.




    The group proposes the following Specification deliverables:




    Communications Mechanisms


    Define bindings for the event messages to an already existing transport protocol to promote interoperability of sending event information to another Service Provider. This will allow a Service Provider to implement a single piece of infrastructure that would be able to send or receive event information to any other service provider.




    Order of Deliverables


    The group will work to produce the Security Event and Account Lifecycle Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users


    ? Service Providers who manage their own account systems which require an email address or phone number for registration.


    ? Account and email providers that understand key security events that happen to a user?s account.


    ? Identity as a Service (IDaaS) vendors that manage account and authentication systems for their customers.


    ? Users seeking to regain control of a compromised account.


    6) Language


    English


    7) Method of work:


    E-mail discussions on the working group mailing list, working group conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:


    Rough consensus and running code. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope.


    Background information


    Related work:


    ? RFC6545 Real-time Inter-network Defense (RID)


    ? RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS


    ? RFC6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)


    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator Exchange


    ? ISO/IEC 27002:2013 Information technology ? Security techniques ? Code of practice for information security controls


    ? ISO/IEC 27035:2011 Information technology ? Security techniques ? Information security incident management


    Proposers


    ? Adam Dawes, Google


    ? Mark Risher, Google


    ? Trent Adams, Paypal


    ? George Fletcher, AOL


    ? Andrew Nash, Confyrm


    ? Nat Sakimura, Nomura Research Institute


    ? John Bradley, Ping Identity


    ? Henrik Biering, Peercraft


    Anticipated contributions:


    ?Security event reporting between Service Providers 1.0? under the OpenID Foundation?s IPR Policy<http://openid.net/intellectual-property/>.




    On Wed, Feb 25, 2015 at 5:37 PM, Andrew Nash <andrew at confyrm.comwrote:
    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.comwrote:
    +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.comwrote:
    While we are in the title, in view of the recent executive order http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari, we might suggest including the name "Information Sharing and analysis", e.g., AATISAC.
    2015?2?25?(?)?11:59 John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>:


    That is a different WG outside of the OIDF;)


    On Feb 24, 2015, at 9:40 PM, Nat Sakimura <sakimura at gmail.comwrote:


    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<mailto:ashishjain@vmware.com>>:
    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler


    From: Nat Sakimura <sakimura at gmail.com<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain at vmware.com<mailto:ashishjain@vmware.com>>
    Cc: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>, "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:ashishjain@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<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>
    Cc: "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:adawes@google.com>>:
    I would like to form a new work group, AATOC. Here is our proposed charter:


    AATOC Charter


    1) Working Group name:


    Abuse and Account Takeover Coordination Group (AATOC)


    2) Purpose
    The goal of AATOC is to provide data sharing schemas, privacy recommendations and protocols to:


    ? Share information about important security events in order to thwart attackers from leveraging compromised accounts from one Service Provider to gain access to accounts on other Service Providers (mobile or web application developers and owners).
    ? Enable users and providers to coordinate in order to securely restore accounts following a compromise.


    Internet accounts that use email addresses or phone numbers as the primary identifier for the account will be the initial focus.
    2) Scope
    The group will define:
    ? Security events
    These are events ? whether directly authentication-related or occurring at another time in the user flow ? that take place on one service that could also have security implications on other Service Providers. The group will develop a taxonomy of security events and a common set of semantics to express relevant information about a security event.
    ? Privacy Implications
    Sharing security information amongst providers has potential privacy implications for both end users and service providers. These privacy implications must be balanced against the recognized benefits of protecting users? accounts and data from abuse. The group will consider ways to optimize this balance when defining mechanisms to handle the various security events and recommend best practices for the industry.


    ? Communications mechanisms
    Define bindings for the use of an existing transport protocol defined elsewhere.


    ? Event schema
    Define a schema describing relevant events and relationships to allow for dissemination between interested and authorized parties.


    ? Account recovery mechanisms
    Standardized mechanism(s) to allow providers to signal that a user has regained control of an account, or allow a user to explicitly restore control of a previously compromised account, with or without direct user involvement.
    Out of scope:
    Determining the account quality/reputation of a user on a particular service and communicating that to others.


    Definition of APIs and underlying mechanisms for connecting to, interacting with and operating centralized databases or intelligence clearinghouses when these are used to communicate security events between account providers.


    4) Proposed Deliverables
    The group proposes the following Non-Specification deliverables:


    Security Event and Account Lifecycle Schema
    ? A taxonomy of security events and a common set of semantics to express relevant information about a security event and its relationships to other relevant data, events or indicators.
    Security Event Privacy Guidelines
    A set of recommendations on how to minimize the privacy impact on users and service providers while improving security, and how to provide appropriate privacy disclosures, labeling and access control guidelines around information in the Security Event Schema.


    The group proposes the following Specification deliverables:


    Communications Mechanisms
    Define bindings for the event messages to an already existing transport protocol to promote interoperability of sending event information to another Service Provider. This will allow a Service Provider to implement a single piece of infrastructure that would be able to send or receive event information to any other service provider.


    Order of Deliverables
    The group will work to produce the Security Event and Account Lifecycle Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users
    ? Service Providers who manage their own account systems which require an email address or phone number for registration.
    ? Account and email providers that understand key security events that happen to a user?s account.
    ? Identity as a Service (IDaaS) vendors that manage account and authentication systems for their customers.
    ? Users seeking to regain control of a compromised account.


    6) Language
    English


    7) Method of work:


    E-mail discussions on the working group mailing list, working group conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:


    Rough consensus and running code. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope.


    Background information


    Related work:
    ? RFC6545 Real-time Inter-network Defense (RID)
    ? RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS
    ? RFC6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)
    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator Exchange
    ? ISO/IEC 27002:2013 Information technology ? Security techniques ? Code of practice for information security controls
    ? ISO/IEC 27035:2011 Information technology ? Security techniques ? Information security incident management


    Proposers
    ? Adam Dawes, Google
    ? Mark Risher, Google
    ? Trent Adams, Paypal
    ? George Fletcher, AOL
    ? Andrew Nash, Confyrm
    ? Nat Sakimura, Nomura Research Institute
    ? John Bradley, Ping Identity


    ? Henrik Biering, Peercraft


    Anticipated contributions:
    ?Security event reporting between Service Providers 1.0? under the OpenID Foundation?s IPR Policy<https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=yV7iQ-h1QNIAyTmfXm6S6vIszebI2q_snUSkFyjxlkg&e=>.






    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=jmKQL3OD_c7eJXduzdJt5OJefY8ZjNiYCoAm8g-7oOA&e=>
    @_nat_en






    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=dibzrL00q20lgLcDv94EYh8Ums_bAaYivHuqDQgNfSI&s=jq4oX-tF55oVVtUOW6sW0RsihIhuUzSlJVyRWCVyAhQ&e=>
    @_nat_en






    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en




    --
    You received this message because you are subscribed to the Google Groups "Abuse and ATO Coordination" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to aatoc+unsubscribe at googlegroups.com<mailto:aatoc+unsubscribe@googlegroups.com>.
    To post to this group, send email to aatoc at googlegroups.com<mailto:aatoc@googlegroups.com>.
    To view this discussion on the web visit https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com<https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
    For more options, visit https://groups.google.com/d/optout.




    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150226/9b395059/attachment-0001.html>
  • Chuck Mortimore at Feb 26, 2015 at 9:56 pm
    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 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@lists.openid.net>] *On Behalf Of *Adam Dawes
    *Sent:* Thursday, February 26, 2015 1:06 AM
    *To:* Andrew Nash
    *Cc:* John Bradley; openid-specs-council at lists.openid.net; Ashish Jain;
    Nat Sakimura; aatoc at googlegroups.com
    *Subject:* Re: [OIDFSC] AATOC Working Group Charter



    Okay, I've revised the charter, with a new name, USESC (I couldn't fathom
    losing the "O" in AATOC). It doesn't have quite the ring but it's a bit
    more general which is useful since I think what will be produced will have
    uses beyond abuse and account takeovers. I've also included a deliverable
    on trust frameworks.



    Here it is:
    USESC Charter


    1) Working Group name:

    User Security Event Sharing and Coordination Working Group (USESC Working
    Group)
    2) Purpose

    The goal of USESC is to provide data sharing schemas, privacy
    recommendations and protocols to:



    ? Share information about important security events related to
    user accounts in order to thwart attackers from leveraging compromised
    accounts from one Service Provider to gain access to accounts on other
    Service Providers (mobile or web application developers and owners).

    ? Enable users and providers to coordinate in order to securely
    restore accounts following a compromise.



    Internet accounts that use email addresses or phone numbers as the primary
    identifier for the account will be the initial focus.
    3) Scope

    The group will define:

    ? *Security events*
    These are events ? whether directly authentication-related or occurring at
    another time in the user flow ? that take place on one service that could
    also have security implications on other Service Providers. The group will
    develop a taxonomy of security events and a common set of semantics to
    express relevant information about a security event.

    ? *Privacy Implications*
    Sharing security information amongst providers has potential privacy
    implications for both end users and service providers. These privacy
    implications must be balanced against the recognized benefits of protecting
    users? accounts and data from abuse. The group will consider ways to
    optimize this balance when defining mechanisms to handle the various
    security events and recommend best practices for the industry.



    ? *Communications mechanisms*
    Define bindings for the use of an existing transport protocol defined
    elsewhere.



    ? *Event schema*
    Define a schema describing relevant events and relationships to allow for
    dissemination between interested and authorized parties.

    ? *Trust Frameworks*
    Define at least one model for the conditions under which information would
    be shared.



    ? *Account recovery mechanisms*

    Standardized mechanism(s) to allow providers to signal that a user has
    regained control of an account, or allow a user to explicitly restore
    control of a previously compromised account, with or without direct user
    involvement.
    Out of scope:

    Determining the account quality/reputation of a user on a particular
    service and communicating that to others.



    Definition of APIs and underlying mechanisms for connecting to,
    interacting with and operating centralized databases or intelligence
    clearinghouses when these are used to communicate security events between
    account providers.


    4) Proposed Deliverables

    The group proposes the following *Non-Specification* deliverables:



    *Security Event and Account Lifecycle Schema*

    ? A taxonomy of security events and a common set of semantics to
    express relevant information about a security event and its relationships
    to other relevant data, events or indicators.



    *Security Event Privacy Guidelines*

    A set of recommendations on how to minimize the privacy impact on users
    and service providers while improving security, and how to provide
    appropriate privacy disclosures, labeling and access control guidelines
    around information in the Security Event Schema.



    The group proposes the following *Specification *deliverables:



    *Communications Mechanisms*

    Define bindings for the event messages to an already existing transport
    protocol to promote interoperability of sending event information to
    another Service Provider. This will allow a Service Provider to implement a
    single piece of infrastructure that would be able to send or receive event
    information to any other service provider.



    *Order of Deliverables*

    The group will work to produce the Security Event and Account Lifecycle
    Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users

    ? Service Providers who manage their own account systems which
    require an email address or phone number for registration.

    ? Account and email providers that understand key security events
    that happen to a user?s account.

    ? Identity as a Service (IDaaS) vendors that manage account and
    authentication systems for their customers.

    ? Users seeking to regain control of a compromised account.


    6) Language

    English


    7) Method of work:

    E-mail discussions on the working group mailing list, working group
    conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:

    Rough consensus and running code. The work will be completed once it is
    apparent that maximal consensus on the draft has been achieved, consistent
    with the purpose and scope.


    Background information


    Related work:

    ? RFC6545 Real-time Inter-network Defense (RID)

    ? RFC6546 Transport of Real-time Inter-network Defense (RID)
    Messages over HTTP/TLS

    ? RFC6684 Guidelines and Template for Defining Extensions to the
    Incident Object Description Exchange Format (IODEF)

    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator
    Exchange

    ? ISO/IEC 27002:2013 Information technology ? Security techniques
    ? Code of practice for information security controls

    ? ISO/IEC 27035:2011 Information technology ? Security techniques
    ? Information security incident management


    Proposers

    ? Adam Dawes, Google

    ? Mark Risher, Google

    ? Trent Adams, Paypal

    ? George Fletcher, AOL

    ? Andrew Nash, Confyrm

    ? Nat Sakimura, Nomura Research Institute

    ? John Bradley, Ping Identity

    ? Henrik Biering, Peercraft
    Anticipated contributions:

    ?Security event reporting between Service Providers 1.0? under the OpenID
    Foundation?s IPR Policy <http://openid.net/intellectual-property/>.





    On Wed, Feb 25, 2015 at 5:37 PM, Andrew Nash 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 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 wrote:

    While we are in the title, in view of the recent executive order
    http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari,
    we might suggest including the name "Information Sharing and analysis",
    e.g., AATISAC.

    2015?2?25?(?)?11:59 John Bradley <ve7jtb@ve7jtb.com>:



    That is a different WG outside of the OIDF;)



    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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@vmware.com>:

    I?m not objecting?merely suggesting that referring it as Account Takeover
    WG is simpler



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 6:09 PM
    *To: *Ashish Jain <ashishjain@vmware.com>
    *Cc: *Adam Dawes <adawes@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@vmware.com>:

    I understand the need to be precise but ATO WG can probably convey the
    same message.



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 4:56 PM
    *To: *Adam Dawes <adawes@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@google.com>:

    I would like to form a new work group, AATOC. Here is our proposed charter:


    AATOC Charter


    1) Working Group name:

    Abuse and Account Takeover Coordination Group (AATOC)


    2) Purpose

    The goal of AATOC is to provide data sharing schemas, privacy
    recommendations and protocols to:



    ? Share information about important security events in order to
    thwart attackers from leveraging compromised accounts from one Service
    Provider to gain access to accounts on other Service Providers (mobile or
    web application developers and owners).

    ? Enable users and providers to coordinate in order to securely
    restore accounts following a compromise.



    Internet accounts that use email addresses or phone numbers as the primary
    identifier for the account will be the initial focus.
    2) Scope

    The group will define:

    ? *Security events*
    These are events ? whether directly authentication-related or occurring at
    another time in the user flow ? that take place on one service that could
    also have security implications on other Service Providers. The group will
    develop a taxonomy of security events and a common set of semantics to
    express relevant information about a security event.

    ? *Privacy Implications*
    Sharing security information amongst providers has potential privacy
    implications for both end users and service providers. These privacy
    implications must be balanced against the recognized benefits of protecting
    users? accounts and data from abuse. The group will consider ways to
    optimize this balance when defining mechanisms to handle the various
    security events and recommend best practices for the industry.



    ? *Communications mechanisms*
    Define bindings for the use of an existing transport protocol defined
    elsewhere.



    ? *Event schema*
    Define a schema describing relevant events and relationships to allow for
    dissemination between interested and authorized parties.



    ? *Account recovery mechanisms*

    Standardized mechanism(s) to allow providers to signal that a user has
    regained control of an account, or allow a user to explicitly restore
    control of a previously compromised account, with or without direct user
    involvement.
    Out of scope:

    Determining the account quality/reputation of a user on a particular
    service and communicating that to others.



    Definition of APIs and underlying mechanisms for connecting to,
    interacting with and operating centralized databases or intelligence
    clearinghouses when these are used to communicate security events between
    account providers.


    4) Proposed Deliverables

    The group proposes the following *Non-Specification* deliverables:



    *Security Event and Account Lifecycle Schema*

    ? A taxonomy of security events and a common set of semantics to
    express relevant information about a security event and its relationships
    to other relevant data, events or indicators.

    *Security Event Privacy Guidelines*

    A set of recommendations on how to minimize the privacy impact on users
    and service providers while improving security, and how to provide
    appropriate privacy disclosures, labeling and access control guidelines
    around information in the Security Event Schema.



    The group proposes the following *Specification *deliverables:



    *Communications Mechanisms*

    Define bindings for the event messages to an already existing transport
    protocol to promote interoperability of sending event information to
    another Service Provider. This will allow a Service Provider to implement a
    single piece of infrastructure that would be able to send or receive event
    information to any other service provider.



    *Order of Deliverables*

    The group will work to produce the Security Event and Account Lifecycle
    Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users

    ? Service Providers who manage their own account systems which
    require an email address or phone number for registration.

    ? Account and email providers that understand key security events
    that happen to a user?s account.

    ? Identity as a Service (IDaaS) vendors that manage account and
    authentication systems for their customers.

    ? Users seeking to regain control of a compromised account.


    6) Language

    English


    7) Method of work:

    E-mail discussions on the working group mailing list, working group
    conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:

    Rough consensus and running code. The work will be completed once it is
    apparent that maximal consensus on the draft has been achieved, consistent
    with the purpose and scope.


    Background information


    Related work:

    ? RFC6545 Real-time Inter-network Defense (RID)

    ? RFC6546 Transport of Real-time Inter-network Defense (RID)
    Messages over HTTP/TLS

    ? RFC6684 Guidelines and Template for Defining Extensions to the
    Incident Object Description Exchange Format (IODEF)

    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator
    Exchange

    ? ISO/IEC 27002:2013 Information technology ? Security techniques
    ? Code of practice for information security controls

    ? ISO/IEC 27035:2011 Information technology ? Security techniques
    ? Information security incident management


    Proposers

    ? Adam Dawes, Google

    ? Mark Risher, Google

    ? Trent Adams, Paypal

    ? George Fletcher, AOL

    ? Andrew Nash, Confyrm

    ? Nat Sakimura, Nomura Research Institute

    ? John Bradley, Ping Identity

    ? Henrik Biering, Peercraft
    Anticipated contributions:

    ?Security event reporting between Service Providers 1.0? under the OpenID
    Foundation?s IPR Policy
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=yV7iQ-h1QNIAyTmfXm6S6vIszebI2q_snUSkFyjxlkg&e=>
    .





    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=jmKQL3OD_c7eJXduzdJt5OJefY8ZjNiYCoAm8g-7oOA&e=>
    @_nat_en





    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=dibzrL00q20lgLcDv94EYh8Ums_bAaYivHuqDQgNfSI&s=jq4oX-tF55oVVtUOW6sW0RsihIhuUzSlJVyRWCVyAhQ&e=>
    @_nat_en





    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en





    --
    You received this message because you are subscribed to the Google Groups
    "Abuse and ATO Coordination" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to aatoc+unsubscribe at googlegroups.com.
    To post to this group, send email to aatoc at googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com
    <https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com?utm_medium=email&utm_source=footer>
    .
    For more options, visit https://groups.google.com/d/optout.



    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150226/158c2d89/attachment-0001.html>
  • John Bradley at Feb 26, 2015 at 10:06 pm
    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 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 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] 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.




    On Wed, Feb 25, 2015 at 5:37 PM, Andrew Nash 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 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 wrote:

    While we are in the title, in view of the recent executive order http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari, we might suggest including the name "Information Sharing and analysis", e.g., AATISAC.

    2015?2?25?(?)?11:59 John Bradley <ve7jtb@ve7jtb.com>:



    That is a different WG outside of the OIDF;)



    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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@vmware.com>:

    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler



    From: Nat Sakimura <sakimura@gmail.com>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain@vmware.com>
    Cc: Adam Dawes <adawes@google.com>, "openid-specs-council at lists.openid.net" <openid-specs-council@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@vmware.com>:

    I understand the need to be precise but ATO WG can probably convey the same message.



    From: Nat Sakimura <sakimura@gmail.com>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes@google.com>
    Cc: "openid-specs-council at lists.openid.net" <openid-specs-council@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@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.






    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en






    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en






    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en





    --
    You received this message because you are subscribed to the Google Groups "Abuse and ATO Coordination" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to aatoc+unsubscribe at googlegroups.com.
    To post to this group, send email to aatoc at googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150226/b4394e8f/attachment-0001.html>
  • Adam Dawes at Feb 27, 2015 at 6:36 am
    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 <http://openid.net/intellectual-property/>.




    On Thu, Feb 26, 2015 at 2:06 PM, John Bradley 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 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 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@lists.openid.net>] *On Behalf Of *Adam
    Dawes
    *Sent:* Thursday, February 26, 2015 1:06 AM
    *To:* Andrew Nash
    *Cc:* John Bradley; openid-specs-council at lists.openid.net; Ashish Jain;
    Nat Sakimura; aatoc at googlegroups.com
    *Subject:* Re: [OIDFSC] AATOC Working Group Charter



    Okay, I've revised the charter, with a new name, USESC (I couldn't fathom
    losing the "O" in AATOC). It doesn't have quite the ring but it's a bit
    more general which is useful since I think what will be produced will have
    uses beyond abuse and account takeovers. I've also included a deliverable
    on trust frameworks.



    Here it is:
    USESC Charter


    1) Working Group name:

    User Security Event Sharing and Coordination Working Group (USESC Working
    Group)
    2) Purpose

    The goal of USESC is to provide data sharing schemas, privacy
    recommendations and protocols to:



    ? Share information about important security events related to
    user accounts in order to thwart attackers from leveraging compromised
    accounts from one Service Provider to gain access to accounts on other
    Service Providers (mobile or web application developers and owners).

    ? Enable users and providers to coordinate in order to securely
    restore accounts following a compromise.



    Internet accounts that use email addresses or phone numbers as the
    primary identifier for the account will be the initial focus.
    3) Scope

    The group will define:

    ? *Security events*
    These are events ? whether directly authentication-related or occurring
    at another time in the user flow ? that take place on one service that
    could also have security implications on other Service Providers. The group
    will develop a taxonomy of security events and a common set of semantics to
    express relevant information about a security event.

    ? *Privacy Implications*
    Sharing security information amongst providers has potential privacy
    implications for both end users and service providers. These privacy
    implications must be balanced against the recognized benefits of protecting
    users? accounts and data from abuse. The group will consider ways to
    optimize this balance when defining mechanisms to handle the various
    security events and recommend best practices for the industry.



    ? *Communications mechanisms*
    Define bindings for the use of an existing transport protocol defined
    elsewhere.



    ? *Event schema*
    Define a schema describing relevant events and relationships to allow for
    dissemination between interested and authorized parties.

    ? *Trust Frameworks*
    Define at least one model for the conditions under which information
    would be shared.



    ? *Account recovery mechanisms*

    Standardized mechanism(s) to allow providers to signal that a user has
    regained control of an account, or allow a user to explicitly restore
    control of a previously compromised account, with or without direct user
    involvement.
    Out of scope:

    Determining the account quality/reputation of a user on a particular
    service and communicating that to others.



    Definition of APIs and underlying mechanisms for connecting to,
    interacting with and operating centralized databases or intelligence
    clearinghouses when these are used to communicate security events between
    account providers.


    4) Proposed Deliverables

    The group proposes the following *Non-Specification* deliverables:



    *Security Event and Account Lifecycle Schema*

    ? A taxonomy of security events and a common set of semantics to
    express relevant information about a security event and its relationships
    to other relevant data, events or indicators.



    *Security Event Privacy Guidelines*

    A set of recommendations on how to minimize the privacy impact on users
    and service providers while improving security, and how to provide
    appropriate privacy disclosures, labeling and access control guidelines
    around information in the Security Event Schema.



    The group proposes the following *Specification *deliverables:



    *Communications Mechanisms*

    Define bindings for the event messages to an already existing transport
    protocol to promote interoperability of sending event information to
    another Service Provider. This will allow a Service Provider to implement a
    single piece of infrastructure that would be able to send or receive event
    information to any other service provider.



    *Order of Deliverables*

    The group will work to produce the Security Event and Account Lifecycle
    Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users

    ? Service Providers who manage their own account systems which
    require an email address or phone number for registration.

    ? Account and email providers that understand key security events
    that happen to a user?s account.

    ? Identity as a Service (IDaaS) vendors that manage account and
    authentication systems for their customers.

    ? Users seeking to regain control of a compromised account.


    6) Language

    English


    7) Method of work:

    E-mail discussions on the working group mailing list, working group
    conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:

    Rough consensus and running code. The work will be completed once it is
    apparent that maximal consensus on the draft has been achieved, consistent
    with the purpose and scope.


    Background information


    Related work:

    ? RFC6545 Real-time Inter-network Defense (RID)

    ? RFC6546 Transport of Real-time Inter-network Defense (RID)
    Messages over HTTP/TLS

    ? RFC6684 Guidelines and Template for Defining Extensions to the
    Incident Object Description Exchange Format (IODEF)

    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator
    Exchange

    ? ISO/IEC 27002:2013 Information technology ? Security
    techniques ? Code of practice for information security controls

    ? ISO/IEC 27035:2011 Information technology ? Security techniques
    ? Information security incident management


    Proposers

    ? Adam Dawes, Google

    ? Mark Risher, Google

    ? Trent Adams, Paypal

    ? George Fletcher, AOL

    ? Andrew Nash, Confyrm

    ? Nat Sakimura, Nomura Research Institute

    ? John Bradley, Ping Identity

    ? Henrik Biering, Peercraft
    Anticipated contributions:

    ?Security event reporting between Service Providers 1.0? under the OpenID
    Foundation?s IPR Policy <http://openid.net/intellectual-property/>.





    On Wed, Feb 25, 2015 at 5:37 PM, Andrew Nash 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 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 wrote:

    While we are in the title, in view of the recent executive order
    http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari,
    we might suggest including the name "Information Sharing and analysis",
    e.g., AATISAC.

    2015?2?25?(?)?11:59 John Bradley <ve7jtb@ve7jtb.com>:



    That is a different WG outside of the OIDF;)



    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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@vmware.com>:

    I?m not objecting?merely suggesting that referring it as Account Takeover
    WG is simpler



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 6:09 PM
    *To: *Ashish Jain <ashishjain@vmware.com>
    *Cc: *Adam Dawes <adawes@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@vmware.com>:

    I understand the need to be precise but ATO WG can probably convey the
    same message.



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 4:56 PM
    *To: *Adam Dawes <adawes@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@google.com>:

    I would like to form a new work group, AATOC. Here is our proposed
    charter:


    AATOC Charter


    1) Working Group name:

    Abuse and Account Takeover Coordination Group (AATOC)


    2) Purpose

    The goal of AATOC is to provide data sharing schemas, privacy
    recommendations and protocols to:



    ? Share information about important security events in order to
    thwart attackers from leveraging compromised accounts from one Service
    Provider to gain access to accounts on other Service Providers (mobile or
    web application developers and owners).

    ? Enable users and providers to coordinate in order to securely
    restore accounts following a compromise.



    Internet accounts that use email addresses or phone numbers as the
    primary identifier for the account will be the initial focus.
    2) Scope

    The group will define:

    ? *Security events*
    These are events ? whether directly authentication-related or occurring
    at another time in the user flow ? that take place on one service that
    could also have security implications on other Service Providers. The group
    will develop a taxonomy of security events and a common set of semantics to
    express relevant information about a security event.

    ? *Privacy Implications*
    Sharing security information amongst providers has potential privacy
    implications for both end users and service providers. These privacy
    implications must be balanced against the recognized benefits of protecting
    users? accounts and data from abuse. The group will consider ways to
    optimize this balance when defining mechanisms to handle the various
    security events and recommend best practices for the industry.



    ? *Communications mechanisms*
    Define bindings for the use of an existing transport protocol defined
    elsewhere.



    ? *Event schema*
    Define a schema describing relevant events and relationships to allow for
    dissemination between interested and authorized parties.



    ? *Account recovery mechanisms*

    Standardized mechanism(s) to allow providers to signal that a user has
    regained control of an account, or allow a user to explicitly restore
    control of a previously compromised account, with or without direct user
    involvement.
    Out of scope:

    Determining the account quality/reputation of a user on a particular
    service and communicating that to others.



    Definition of APIs and underlying mechanisms for connecting to,
    interacting with and operating centralized databases or intelligence
    clearinghouses when these are used to communicate security events between
    account providers.


    4) Proposed Deliverables

    The group proposes the following *Non-Specification* deliverables:



    *Security Event and Account Lifecycle Schema*

    ? A taxonomy of security events and a common set of semantics to
    express relevant information about a security event and its relationships
    to other relevant data, events or indicators.

    *Security Event Privacy Guidelines*

    A set of recommendations on how to minimize the privacy impact on users
    and service providers while improving security, and how to provide
    appropriate privacy disclosures, labeling and access control guidelines
    around information in the Security Event Schema.



    The group proposes the following *Specification *deliverables:



    *Communications Mechanisms*

    Define bindings for the event messages to an already existing transport
    protocol to promote interoperability of sending event information to
    another Service Provider. This will allow a Service Provider to implement a
    single piece of infrastructure that would be able to send or receive event
    information to any other service provider.



    *Order of Deliverables*

    The group will work to produce the Security Event and Account Lifecycle
    Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users

    ? Service Providers who manage their own account systems which
    require an email address or phone number for registration.

    ? Account and email providers that understand key security events
    that happen to a user?s account.

    ? Identity as a Service (IDaaS) vendors that manage account and
    authentication systems for their customers.

    ? Users seeking to regain control of a compromised account.


    6) Language

    English


    7) Method of work:

    E-mail discussions on the working group mailing list, working group
    conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:

    Rough consensus and running code. The work will be completed once it is
    apparent that maximal consensus on the draft has been achieved, consistent
    with the purpose and scope.


    Background information


    Related work:

    ? RFC6545 Real-time Inter-network Defense (RID)

    ? RFC6546 Transport of Real-time Inter-network Defense (RID)
    Messages over HTTP/TLS

    ? RFC6684 Guidelines and Template for Defining Extensions to the
    Incident Object Description Exchange Format (IODEF)

    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator
    Exchange

    ? ISO/IEC 27002:2013 Information technology ? Security
    techniques ? Code of practice for information security controls

    ? ISO/IEC 27035:2011 Information technology ? Security techniques
    ? Information security incident management


    Proposers

    ? Adam Dawes, Google

    ? Mark Risher, Google

    ? Trent Adams, Paypal

    ? George Fletcher, AOL

    ? Andrew Nash, Confyrm

    ? Nat Sakimura, Nomura Research Institute

    ? John Bradley, Ping Identity

    ? Henrik Biering, Peercraft
    Anticipated contributions:

    ?Security event reporting between Service Providers 1.0? under the OpenID
    Foundation?s IPR Policy
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=yV7iQ-h1QNIAyTmfXm6S6vIszebI2q_snUSkFyjxlkg&e=>
    .





    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=jmKQL3OD_c7eJXduzdJt5OJefY8ZjNiYCoAm8g-7oOA&e=>
    @_nat_en





    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=dibzrL00q20lgLcDv94EYh8Ums_bAaYivHuqDQgNfSI&s=jq4oX-tF55oVVtUOW6sW0RsihIhuUzSlJVyRWCVyAhQ&e=>
    @_nat_en





    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en





    --
    You received this message because you are subscribed to the Google Groups
    "Abuse and ATO Coordination" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to aatoc+unsubscribe at googlegroups.com.
    To post to this group, send email to aatoc at googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com
    <https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com?utm_medium=email&utm_source=footer>
    .
    For more options, visit https://groups.google.com/d/optout.



    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150226/1dcf6783/attachment-0001.html>
  • Adam Dawes at Feb 27, 2015 at 7:21 pm
    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
    <http://openid.net/intellectual-property/>.


    On Thu, Feb 26, 2015 at 10:36 PM, Adam Dawes 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 <http://openid.net/intellectual-property/>.

    On Thu, Feb 26, 2015 at 2:06 PM, John Bradley 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@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@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@lists.openid.net>] *On Behalf Of *Adam
    Dawes
    *Sent:* Thursday, February 26, 2015 1:06 AM
    *To:* Andrew Nash
    *Cc:* John Bradley; openid-specs-council at lists.openid.net; Ashish Jain;
    Nat Sakimura; aatoc at googlegroups.com
    *Subject:* Re: [OIDFSC] AATOC Working Group Charter



    Okay, I've revised the charter, with a new name, USESC (I couldn't
    fathom losing the "O" in AATOC). It doesn't have quite the ring but it's a
    bit more general which is useful since I think what will be produced will
    have uses beyond abuse and account takeovers. I've also included a
    deliverable on trust frameworks.



    Here it is:
    USESC Charter


    1) Working Group name:

    User Security Event Sharing and Coordination Working Group (USESC
    Working Group)
    2) Purpose

    The goal of USESC is to provide data sharing schemas, privacy
    recommendations and protocols to:



    ? Share information about important security events related to
    user accounts in order to thwart attackers from leveraging compromised
    accounts from one Service Provider to gain access to accounts on other
    Service Providers (mobile or web application developers and owners).

    ? Enable users and providers to coordinate in order to securely
    restore accounts following a compromise.



    Internet accounts that use email addresses or phone numbers as the
    primary identifier for the account will be the initial focus.
    3) Scope

    The group will define:

    ? *Security events*
    These are events ? whether directly authentication-related or occurring
    at another time in the user flow ? that take place on one service that
    could also have security implications on other Service Providers. The group
    will develop a taxonomy of security events and a common set of semantics to
    express relevant information about a security event.

    ? *Privacy Implications*
    Sharing security information amongst providers has potential privacy
    implications for both end users and service providers. These privacy
    implications must be balanced against the recognized benefits of protecting
    users? accounts and data from abuse. The group will consider ways to
    optimize this balance when defining mechanisms to handle the various
    security events and recommend best practices for the industry.



    ? *Communications mechanisms*
    Define bindings for the use of an existing transport protocol defined
    elsewhere.



    ? *Event schema*
    Define a schema describing relevant events and relationships to allow
    for dissemination between interested and authorized parties.

    ? *Trust Frameworks*
    Define at least one model for the conditions under which information
    would be shared.



    ? *Account recovery mechanisms*

    Standardized mechanism(s) to allow providers to signal that a user has
    regained control of an account, or allow a user to explicitly restore
    control of a previously compromised account, with or without direct user
    involvement.
    Out of scope:

    Determining the account quality/reputation of a user on a particular
    service and communicating that to others.



    Definition of APIs and underlying mechanisms for connecting to,
    interacting with and operating centralized databases or intelligence
    clearinghouses when these are used to communicate security events between
    account providers.


    4) Proposed Deliverables

    The group proposes the following *Non-Specification* deliverables:



    *Security Event and Account Lifecycle Schema*

    ? A taxonomy of security events and a common set of semantics to
    express relevant information about a security event and its relationships
    to other relevant data, events or indicators.



    *Security Event Privacy Guidelines*

    A set of recommendations on how to minimize the privacy impact on users
    and service providers while improving security, and how to provide
    appropriate privacy disclosures, labeling and access control guidelines
    around information in the Security Event Schema.



    The group proposes the following *Specification *deliverables:



    *Communications Mechanisms*

    Define bindings for the event messages to an already existing transport
    protocol to promote interoperability of sending event information to
    another Service Provider. This will allow a Service Provider to implement a
    single piece of infrastructure that would be able to send or receive event
    information to any other service provider.



    *Order of Deliverables*

    The group will work to produce the Security Event and Account Lifecycle
    Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users

    ? Service Providers who manage their own account systems which
    require an email address or phone number for registration.

    ? Account and email providers that understand key security
    events that happen to a user?s account.

    ? Identity as a Service (IDaaS) vendors that manage account and
    authentication systems for their customers.

    ? Users seeking to regain control of a compromised account.


    6) Language

    English


    7) Method of work:

    E-mail discussions on the working group mailing list, working group
    conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:

    Rough consensus and running code. The work will be completed once it is
    apparent that maximal consensus on the draft has been achieved, consistent
    with the purpose and scope.


    Background information


    Related work:

    ? RFC6545 Real-time Inter-network Defense (RID)

    ? RFC6546 Transport of Real-time Inter-network Defense (RID)
    Messages over HTTP/TLS

    ? RFC6684 Guidelines and Template for Defining Extensions to the
    Incident Object Description Exchange Format (IODEF)

    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator
    Exchange

    ? ISO/IEC 27002:2013 Information technology ? Security
    techniques ? Code of practice for information security controls

    ? ISO/IEC 27035:2011 Information technology ? Security
    techniques ? Information security incident management


    Proposers

    ? Adam Dawes, Google

    ? Mark Risher, Google

    ? Trent Adams, Paypal

    ? George Fletcher, AOL

    ? Andrew Nash, Confyrm

    ? Nat Sakimura, Nomura Research Institute

    ? John Bradley, Ping Identity

    ? Henrik Biering, Peercraft
    Anticipated contributions:

    ?Security event reporting between Service Providers 1.0? under the OpenID
    Foundation?s IPR Policy <http://openid.net/intellectual-property/>.





    On Wed, Feb 25, 2015 at 5:37 PM, Andrew Nash 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 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@gmail.com>
    wrote:

    While we are in the title, in view of the recent executive order
    http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari,
    we might suggest including the name "Information Sharing and analysis",
    e.g., AATISAC.

    2015?2?25?(?)?11:59 John Bradley <ve7jtb@ve7jtb.com>:



    That is a different WG outside of the OIDF;)



    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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@vmware.com>:

    I?m not objecting?merely suggesting that referring it as Account
    Takeover WG is simpler



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 6:09 PM
    *To: *Ashish Jain <ashishjain@vmware.com>
    *Cc: *Adam Dawes <adawes@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@vmware.com>:

    I understand the need to be precise but ATO WG can probably convey the
    same message.



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 4:56 PM
    *To: *Adam Dawes <adawes@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@google.com>:

    I would like to form a new work group, AATOC. Here is our proposed
    charter:


    AATOC Charter


    1) Working Group name:

    Abuse and Account Takeover Coordination Group (AATOC)


    2) Purpose

    The goal of AATOC is to provide data sharing schemas, privacy
    recommendations and protocols to:



    ? Share information about important security events in order to
    thwart attackers from leveraging compromised accounts from one Service
    Provider to gain access to accounts on other Service Providers (mobile or
    web application developers and owners).

    ? Enable users and providers to coordinate in order to securely
    restore accounts following a compromise.



    Internet accounts that use email addresses or phone numbers as the
    primary identifier for the account will be the initial focus.
    2) Scope

    The group will define:

    ? *Security events*
    These are events ? whether directly authentication-related or occurring
    at another time in the user flow ? that take place on one service that
    could also have security implications on other Service Providers. The group
    will develop a taxonomy of security events and a common set of semantics to
    express relevant information about a security event.

    ? *Privacy Implications*
    Sharing security information amongst providers has potential privacy
    implications for both end users and service providers. These privacy
    implications must be balanced against the recognized benefits of protecting
    users? accounts and data from abuse. The group will consider ways to
    optimize this balance when defining mechanisms to handle the various
    security events and recommend best practices for the industry.



    ? *Communications mechanisms*
    Define bindings for the use of an existing transport protocol defined
    elsewhere.



    ? *Event schema*
    Define a schema describing relevant events and relationships to allow
    for dissemination between interested and authorized parties.



    ? *Account recovery mechanisms*

    Standardized mechanism(s) to allow providers to signal that a user has
    regained control of an account, or allow a user to explicitly restore
    control of a previously compromised account, with or without direct user
    involvement.
    Out of scope:

    Determining the account quality/reputation of a user on a particular
    service and communicating that to others.



    Definition of APIs and underlying mechanisms for connecting to,
    interacting with and operating centralized databases or intelligence
    clearinghouses when these are used to communicate security events between
    account providers.


    4) Proposed Deliverables

    The group proposes the following *Non-Specification* deliverables:



    *Security Event and Account Lifecycle Schema*

    ? A taxonomy of security events and a common set of semantics to
    express relevant information about a security event and its relationships
    to other relevant data, events or indicators.

    *Security Event Privacy Guidelines*

    A set of recommendations on how to minimize the privacy impact on users
    and service providers while improving security, and how to provide
    appropriate privacy disclosures, labeling and access control guidelines
    around information in the Security Event Schema.



    The group proposes the following *Specification *deliverables:



    *Communications Mechanisms*

    Define bindings for the event messages to an already existing transport
    protocol to promote interoperability of sending event information to
    another Service Provider. This will allow a Service Provider to implement a
    single piece of infrastructure that would be able to send or receive event
    information to any other service provider.



    *Order of Deliverables*

    The group will work to produce the Security Event and Account Lifecycle
    Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users

    ? Service Providers who manage their own account systems which
    require an email address or phone number for registration.

    ? Account and email providers that understand key security
    events that happen to a user?s account.

    ? Identity as a Service (IDaaS) vendors that manage account and
    authentication systems for their customers.

    ? Users seeking to regain control of a compromised account.


    6) Language

    English


    7) Method of work:

    E-mail discussions on the working group mailing list, working group
    conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:

    Rough consensus and running code. The work will be completed once it is
    apparent that maximal consensus on the draft has been achieved, consistent
    with the purpose and scope.


    Background information


    Related work:

    ? RFC6545 Real-time Inter-network Defense (RID)

    ? RFC6546 Transport of Real-time Inter-network Defense (RID)
    Messages over HTTP/TLS

    ? RFC6684 Guidelines and Template for Defining Extensions to the
    Incident Object Description Exchange Format (IODEF)

    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator
    Exchange

    ? ISO/IEC 27002:2013 Information technology ? Security
    techniques ? Code of practice for information security controls

    ? ISO/IEC 27035:2011 Information technology ? Security
    techniques ? Information security incident management


    Proposers

    ? Adam Dawes, Google

    ? Mark Risher, Google

    ? Trent Adams, Paypal

    ? George Fletcher, AOL

    ? Andrew Nash, Confyrm

    ? Nat Sakimura, Nomura Research Institute

    ? John Bradley, Ping Identity

    ? Henrik Biering, Peercraft
    Anticipated contributions:

    ?Security event reporting between Service Providers 1.0? under the OpenID
    Foundation?s IPR Policy
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=yV7iQ-h1QNIAyTmfXm6S6vIszebI2q_snUSkFyjxlkg&e=>
    .





    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=jmKQL3OD_c7eJXduzdJt5OJefY8ZjNiYCoAm8g-7oOA&e=>
    @_nat_en





    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=dibzrL00q20lgLcDv94EYh8Ums_bAaYivHuqDQgNfSI&s=jq4oX-tF55oVVtUOW6sW0RsihIhuUzSlJVyRWCVyAhQ&e=>
    @_nat_en





    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en





    --
    You received this message because you are subscribed to the Google
    Groups "Abuse and ATO Coordination" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to aatoc+unsubscribe at googlegroups.com.
    To post to this group, send email to aatoc at googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com
    <https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com?utm_medium=email&utm_source=footer>
    .
    For more options, visit https://groups.google.com/d/optout.



    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150227/99fb31fb/attachment-0001.html>
  • Mike Jones at Feb 28, 2015 at 12:54 am
    I approve of the creation of this working group with this charter.
    ________________________________
    From: Adam Dawes<mailto:adawes@google.com>
    Sent: ?2/?27/?2015 11:22 AM
    To: John Bradley<mailto:ve7jtb@ve7jtb.com>
    Cc: Chuck Mortimore<mailto:cmortimore@salesforce.com>; Mike Jones<mailto:michael.jones@microsoft.com>; John Ehrig<mailto:jehrig@inventures.com>; Andrew Nash<mailto:andrew@confyrm.com>; openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>; Ashish Jain<mailto:ashishjain@vmware.com>; Nat Sakimura<mailto:sakimura@gmail.com>; aatoc at googlegroups.com<mailto:aatoc@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<http://openid.net/intellectual-property/>.


    On Thu, Feb 26, 2015 at 10:36 PM, Adam Dawes <adawes at google.comwrote:
    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<http://openid.net/intellectual-property/>.




    On Thu, Feb 26, 2015 at 2:06 PM, John Bradley <ve7jtb at ve7jtb.comwrote:
    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.comwrote:


    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.comwrote:
    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<mailto:openid-specs-council-bounces@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<mailto:openid-specs-council@lists.openid.net>; aatoc at googlegroups.com<mailto:aatoc@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] 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<mailto:openid-specs-council@lists.openid.net>; Ashish Jain; Nat Sakimura; aatoc at googlegroups.com<mailto:aatoc@googlegroups.com>
    Subject: Re: [OIDFSC] AATOC Working Group Charter


    Okay, I've revised the charter, with a new name, USESC (I couldn't fathom losing the "O" in AATOC). It doesn't have quite the ring but it's a bit more general which is useful since I think what will be produced will have uses beyond abuse and account takeovers. I've also included a deliverable on trust frameworks.


    Here it is:
    USESC Charter


    1) Working Group name:


    User Security Event Sharing and Coordination Working Group (USESC Working Group)


    2) Purpose


    The goal of USESC is to provide data sharing schemas, privacy recommendations and protocols to:




    ? Share information about important security events related to user accounts in order to thwart attackers from leveraging compromised accounts from one Service Provider to gain access to accounts on other Service Providers (mobile or web application developers and owners).


    ? Enable users and providers to coordinate in order to securely restore accounts following a compromise.




    Internet accounts that use email addresses or phone numbers as the primary identifier for the account will be the initial focus.


    3) Scope


    The group will define:


    ? Security events
    These are events ? whether directly authentication-related or occurring at another time in the user flow ? that take place on one service that could also have security implications on other Service Providers. The group will develop a taxonomy of security events and a common set of semantics to express relevant information about a security event.


    ? Privacy Implications
    Sharing security information amongst providers has potential privacy implications for both end users and service providers. These privacy implications must be balanced against the recognized benefits of protecting users? accounts and data from abuse. The group will consider ways to optimize this balance when defining mechanisms to handle the various security events and recommend best practices for the industry.




    ? Communications mechanisms
    Define bindings for the use of an existing transport protocol defined elsewhere.




    ? Event schema
    Define a schema describing relevant events and relationships to allow for dissemination between interested and authorized parties.


    ? Trust Frameworks
    Define at least one model for the conditions under which information would be shared.




    ? Account recovery mechanisms


    Standardized mechanism(s) to allow providers to signal that a user has regained control of an account, or allow a user to explicitly restore control of a previously compromised account, with or without direct user involvement.


    Out of scope:


    Determining the account quality/reputation of a user on a particular service and communicating that to others.




    Definition of APIs and underlying mechanisms for connecting to, interacting with and operating centralized databases or intelligence clearinghouses when these are used to communicate security events between account providers.


    4) Proposed Deliverables


    The group proposes the following Non-Specification deliverables:




    Security Event and Account Lifecycle Schema


    ? A taxonomy of security events and a common set of semantics to express relevant information about a security event and its relationships to other relevant data, events or indicators.




    Security Event Privacy Guidelines


    A set of recommendations on how to minimize the privacy impact on users and service providers while improving security, and how to provide appropriate privacy disclosures, labeling and access control guidelines around information in the Security Event Schema.




    The group proposes the following Specification deliverables:




    Communications Mechanisms


    Define bindings for the event messages to an already existing transport protocol to promote interoperability of sending event information to another Service Provider. This will allow a Service Provider to implement a single piece of infrastructure that would be able to send or receive event information to any other service provider.




    Order of Deliverables


    The group will work to produce the Security Event and Account Lifecycle Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users


    ? Service Providers who manage their own account systems which require an email address or phone number for registration.


    ? Account and email providers that understand key security events that happen to a user?s account.


    ? Identity as a Service (IDaaS) vendors that manage account and authentication systems for their customers.


    ? Users seeking to regain control of a compromised account.


    6) Language


    English


    7) Method of work:


    E-mail discussions on the working group mailing list, working group conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:


    Rough consensus and running code. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope.


    Background information


    Related work:


    ? RFC6545 Real-time Inter-network Defense (RID)


    ? RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS


    ? RFC6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)


    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator Exchange


    ? ISO/IEC 27002:2013 Information technology ? Security techniques ? Code of practice for information security controls


    ? ISO/IEC 27035:2011 Information technology ? Security techniques ? Information security incident management


    Proposers


    ? Adam Dawes, Google


    ? Mark Risher, Google


    ? Trent Adams, Paypal


    ? George Fletcher, AOL


    ? Andrew Nash, Confyrm


    ? Nat Sakimura, Nomura Research Institute


    ? John Bradley, Ping Identity


    ? Henrik Biering, Peercraft


    Anticipated contributions:


    ?Security event reporting between Service Providers 1.0? under the OpenID Foundation?s IPR Policy<http://openid.net/intellectual-property/>.




    On Wed, Feb 25, 2015 at 5:37 PM, Andrew Nash <andrew at confyrm.comwrote:
    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.comwrote:
    +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.comwrote:
    While we are in the title, in view of the recent executive order http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari, we might suggest including the name "Information Sharing and analysis", e.g., AATISAC.
    2015?2?25?(?)?11:59 John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>:


    That is a different WG outside of the OIDF;)


    On Feb 24, 2015, at 9:40 PM, Nat Sakimura <sakimura at gmail.comwrote:


    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<mailto:ashishjain@vmware.com>>:
    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler


    From: Nat Sakimura <sakimura at gmail.com<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain at vmware.com<mailto:ashishjain@vmware.com>>
    Cc: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>, "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:ashishjain@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<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>
    Cc: "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:adawes@google.com>>:
    I would like to form a new work group, AATOC. Here is our proposed charter:


    AATOC Charter


    1) Working Group name:


    Abuse and Account Takeover Coordination Group (AATOC)


    2) Purpose
    The goal of AATOC is to provide data sharing schemas, privacy recommendations and protocols to:


    ? Share information about important security events in order to thwart attackers from leveraging compromised accounts from one Service Provider to gain access to accounts on other Service Providers (mobile or web application developers and owners).
    ? Enable users and providers to coordinate in order to securely restore accounts following a compromise.


    Internet accounts that use email addresses or phone numbers as the primary identifier for the account will be the initial focus.
    2) Scope
    The group will define:
    ? Security events
    These are events ? whether directly authentication-related or occurring at another time in the user flow ? that take place on one service that could also have security implications on other Service Providers. The group will develop a taxonomy of security events and a common set of semantics to express relevant information about a security event.
    ? Privacy Implications
    Sharing security information amongst providers has potential privacy implications for both end users and service providers. These privacy implications must be balanced against the recognized benefits of protecting users? accounts and data from abuse. The group will consider ways to optimize this balance when defining mechanisms to handle the various security events and recommend best practices for the industry.


    ? Communications mechanisms
    Define bindings for the use of an existing transport protocol defined elsewhere.


    ? Event schema
    Define a schema describing relevant events and relationships to allow for dissemination between interested and authorized parties.


    ? Account recovery mechanisms
    Standardized mechanism(s) to allow providers to signal that a user has regained control of an account, or allow a user to explicitly restore control of a previously compromised account, with or without direct user involvement.
    Out of scope:
    Determining the account quality/reputation of a user on a particular service and communicating that to others.


    Definition of APIs and underlying mechanisms for connecting to, interacting with and operating centralized databases or intelligence clearinghouses when these are used to communicate security events between account providers.


    4) Proposed Deliverables
    The group proposes the following Non-Specification deliverables:


    Security Event and Account Lifecycle Schema
    ? A taxonomy of security events and a common set of semantics to express relevant information about a security event and its relationships to other relevant data, events or indicators.
    Security Event Privacy Guidelines
    A set of recommendations on how to minimize the privacy impact on users and service providers while improving security, and how to provide appropriate privacy disclosures, labeling and access control guidelines around information in the Security Event Schema.


    The group proposes the following Specification deliverables:


    Communications Mechanisms
    Define bindings for the event messages to an already existing transport protocol to promote interoperability of sending event information to another Service Provider. This will allow a Service Provider to implement a single piece of infrastructure that would be able to send or receive event information to any other service provider.


    Order of Deliverables
    The group will work to produce the Security Event and Account Lifecycle Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users
    ? Service Providers who manage their own account systems which require an email address or phone number for registration.
    ? Account and email providers that understand key security events that happen to a user?s account.
    ? Identity as a Service (IDaaS) vendors that manage account and authentication systems for their customers.
    ? Users seeking to regain control of a compromised account.


    6) Language
    English


    7) Method of work:


    E-mail discussions on the working group mailing list, working group conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:


    Rough consensus and running code. The work will be completed once it is apparent that maximal consensus on the draft has been achieved, consistent with the purpose and scope.


    Background information


    Related work:
    ? RFC6545 Real-time Inter-network Defense (RID)
    ? RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS
    ? RFC6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)
    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator Exchange
    ? ISO/IEC 27002:2013 Information technology ? Security techniques ? Code of practice for information security controls
    ? ISO/IEC 27035:2011 Information technology ? Security techniques ? Information security incident management


    Proposers
    ? Adam Dawes, Google
    ? Mark Risher, Google
    ? Trent Adams, Paypal
    ? George Fletcher, AOL
    ? Andrew Nash, Confyrm
    ? Nat Sakimura, Nomura Research Institute
    ? John Bradley, Ping Identity


    ? Henrik Biering, Peercraft


    Anticipated contributions:
    ?Security event reporting between Service Providers 1.0? under the OpenID Foundation?s IPR Policy<https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=yV7iQ-h1QNIAyTmfXm6S6vIszebI2q_snUSkFyjxlkg&e=>.






    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=jmKQL3OD_c7eJXduzdJt5OJefY8ZjNiYCoAm8g-7oOA&e=>
    @_nat_en






    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=dibzrL00q20lgLcDv94EYh8Ums_bAaYivHuqDQgNfSI&s=jq4oX-tF55oVVtUOW6sW0RsihIhuUzSlJVyRWCVyAhQ&e=>
    @_nat_en






    --
    Nat Sakimura (=nat)
    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en




    --
    You received this message because you are subscribed to the Google Groups "Abuse and ATO Coordination" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to aatoc+unsubscribe at googlegroups.com<mailto:aatoc+unsubscribe@googlegroups.com>.
    To post to this group, send email to aatoc at googlegroups.com<mailto:aatoc@googlegroups.com>.
    To view this discussion on the web visit https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com<https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
    For more options, visit https://groups.google.com/d/optout.










    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150228/480d1f11/attachment-0001.html>
  • Ashish Jain at Mar 1, 2015 at 5:33 pm
    +1


    From: Mike Jones <Michael.Jones at microsoft.com<mailto:michael.jones@microsoft.com>>
    Date: Friday, February 27, 2015 at 4:54 PM
    To: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>
    Cc: Chuck Mortimore <cmortimore at salesforce.com<mailto:cmortimore@salesforce.com>>, John Ehrig <jehrig at inventures.com<mailto:jehrig@inventures.com>>, Andrew Nash <andrew at confyrm.com<mailto:andrew@confyrm.com>>, "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>>, Ashish Jain <ashishjain at vmware.com<mailto:ashishjain@vmware.com>>, Nat Sakimura <sakimura at gmail.com<mailto:sakimura@gmail.com>>, "aatoc at googlegroups.com<mailto:aatoc@googlegroups.com>" <aatoc at googlegroups.com<mailto:aatoc@googlegroups.com>>
    Subject: RE: [OIDFSC] AATOC Working Group Charter


    I approve of the creation of this working group with this charter.
    ________________________________
    From: Adam Dawes<mailto:adawes@google.com>
    Sent: ?2/?27/?2015 11:22 AM
    To: John Bradley<mailto:ve7jtb@ve7jtb.com>
    Cc: Chuck Mortimore<mailto:cmortimore@salesforce.com>; Mike Jones<mailto:michael.jones@microsoft.com>; John Ehrig<mailto:jehrig@inventures.com>; Andrew Nash<mailto:andrew@confyrm.com>; openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>; Ashish Jain<mailto:ashishjain@vmware.com>; Nat Sakimura<mailto:sakimura@gmail.com>; aatoc at googlegroups.com<mailto:aatoc@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.comwrote:
    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.comwrote:
    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.comwrote:


    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.comwrote:
    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<mailto:openid-specs-council-bounces@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<mailto:openid-specs-council@lists.openid.net>; aatoc at googlegroups.com<mailto:aatoc@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] 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<mailto:openid-specs-council@lists.openid.net>; Ashish Jain; Nat Sakimura; aatoc at googlegroups.com<mailto:aatoc@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.comwrote:
    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.comwrote:
    +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.comwrote:
    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<mailto:ve7jtb@ve7jtb.com>>:


    That is a different WG outside of the OIDF;)


    On Feb 24, 2015, at 9:40 PM, Nat Sakimura <sakimura at gmail.comwrote:


    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<mailto:ashishjain@vmware.com>>:
    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler


    From: Nat Sakimura <sakimura at gmail.com<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain at vmware.com<mailto:ashishjain@vmware.com>>
    Cc: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>, "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:ashishjain@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<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>
    Cc: "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:adawes@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<mailto:aatoc+unsubscribe@googlegroups.com>.
    To post to this group, send email to aatoc at googlegroups.com<mailto:aatoc@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/2a03beb4/attachment-0001.html>
  • Nat Sakimura at Mar 2, 2015 at 12:59 am
    +1


    =nat via iPhone


    2015/03/02 2:33?Ashish Jain <ashishjain@vmware.com> ??????:

    +1

    From: Mike Jones <michael.jones@microsoft.com>
    Date: Friday, February 27, 2015 at 4:54 PM
    To: Adam Dawes <adawes@google.com>, John Bradley <ve7jtb@ve7jtb.com>
    Cc: Chuck Mortimore <cmortimore@salesforce.com>, John Ehrig <jehrig@inventures.com>, Andrew Nash <andrew@confyrm.com>, "openid-specs-council at lists.openid.net" <openid-specs-council@lists.openid.net>, Ashish Jain <ashishjain@vmware.com>, Nat Sakimura <sakimura@gmail.com>, "aatoc at googlegroups.com" <aatoc@googlegroups.com>
    Subject: RE: [OIDFSC] AATOC Working Group Charter

    I approve of the creation of this working group with this charter.
    From: Adam Dawes
    Sent: ?2/?27/?2015 11:22 AM
    To: John Bradley
    Cc: Chuck Mortimore; Mike Jones; John Ehrig; Andrew Nash; openid-specs-council at lists.openid.net; Ashish Jain; Nat Sakimura; 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.
    On Thu, Feb 26, 2015 at 10:36 PM, Adam Dawes 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.

    On Thu, Feb 26, 2015 at 2:06 PM, John Bradley 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 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 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] 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.




    On Wed, Feb 25, 2015 at 5:37 PM, Andrew Nash 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 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 wrote:

    While we are in the title, in view of the recent executive order http://m.whitehouse.gov/the-press-office/2015/02/13/executive-order-promoting-private-sector-cybersecurity-information-shari, we might suggest including the name "Information Sharing and analysis", e.g., AATISAC.

    2015?2?25?(?)?11:59 John Bradley <ve7jtb@ve7jtb.com>:



    That is a different WG outside of the OIDF;)



    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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@vmware.com>:

    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler



    From: Nat Sakimura <sakimura@gmail.com>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain@vmware.com>
    Cc: Adam Dawes <adawes@google.com>, "openid-specs-council at lists.openid.net" <openid-specs-council@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@vmware.com>:

    I understand the need to be precise but ATO WG can probably convey the same message.



    From: Nat Sakimura <sakimura@gmail.com>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes@google.com>
    Cc: "openid-specs-council at lists.openid.net" <openid-specs-council@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@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.






    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en






    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en






    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    @_nat_en





    --
    You received this message because you are subscribed to the Google Groups "Abuse and ATO Coordination" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to aatoc+unsubscribe at googlegroups.com.
    To post to this group, send email to aatoc at googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150302/ebb4efe2/attachment-0001.html>
  • Adam Dawes at Mar 2, 2015 at 7:15 am
    Does this mean that we're an official working group now?


    On Sun, Mar 1, 2015 at 4:59 PM, Nat Sakimura wrote:

    +1

    =nat via iPhone

    2015/03/02 2:33?Ashish Jain <ashishjain@vmware.com> ??????:

    +1

    From: Mike Jones <michael.jones@microsoft.com>
    Date: Friday, February 27, 2015 at 4:54 PM
    To: Adam Dawes <adawes@google.com>, John Bradley <ve7jtb@ve7jtb.com>
    Cc: Chuck Mortimore <cmortimore@salesforce.com>, John Ehrig <
    jehrig at inventures.com>, Andrew Nash <andrew@confyrm.com>, "
    openid-specs-council at lists.openid.net" <
    openid-specs-council at lists.openid.net>, Ashish Jain <ashishjain@vmware.com>,
    Nat Sakimura <sakimura@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@google.com>
    Sent: ?2/?27/?2015 11:22 AM
    To: John Bradley <ve7jtb@ve7jtb.com>
    Cc: Chuck Mortimore <cmortimore@salesforce.com>; Mike Jones
    <michael.jones@microsoft.com>; John Ehrig <jehrig@inventures.com>; Andrew
    Nash <andrew@confyrm.com>; openid-specs-council at lists.openid.net; Ashish
    Jain <ashishjain@vmware.com>; Nat Sakimura <sakimura@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 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 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@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@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@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 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@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@ve7jtb.com>:



    That is a different WG outside of the OIDF;)



    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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@vmware.com>:

    I?m not objecting?merely suggesting that referring it as Account
    Takeover WG is simpler



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 6:09 PM
    *To: *Ashish Jain <ashishjain@vmware.com>
    *Cc: *Adam Dawes <adawes@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@vmware.com>:

    I understand the need to be precise but ATO WG can probably convey the
    same message.



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 4:56 PM
    *To: *Adam Dawes <adawes@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@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>
  • John Bradley at Mar 2, 2015 at 8:03 am
    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 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 <mailto:ashishjain@vmware.com>> ??????:
    +1

    From: Mike Jones <Michael.Jones at microsoft.com <mailto:michael.jones@microsoft.com>>
    Date: Friday, February 27, 2015 at 4:54 PM
    To: Adam Dawes <adawes at google.com <mailto:adawes@google.com>>, John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb@ve7jtb.com>>
    Cc: Chuck Mortimore <cmortimore at salesforce.com <mailto:cmortimore@salesforce.com>>, John Ehrig <jehrig at inventures.com <mailto:jehrig@inventures.com>>, Andrew Nash <andrew at confyrm.com <mailto:andrew@confyrm.com>>, "openid-specs-council at lists.openid.net <mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net <mailto:openid-specs-council@lists.openid.net>>, Ashish Jain <ashishjain at vmware.com <mailto:ashishjain@vmware.com>>, Nat Sakimura <sakimura at gmail.com <mailto:sakimura@gmail.com>>, "aatoc at googlegroups.com <mailto:aatoc@googlegroups.com>" <aatoc at googlegroups.com <mailto:aatoc@googlegroups.com>>
    Subject: RE: [OIDFSC] AATOC Working Group Charter

    I approve of the creation of this working group with this charter.
    From: Adam Dawes <mailto:adawes@google.com>
    Sent: ?2/?27/?2015 11:22 AM
    To: John Bradley <mailto:ve7jtb@ve7jtb.com>
    Cc: Chuck Mortimore <mailto:cmortimore@salesforce.com>; Mike Jones <mailto:michael.jones@microsoft.com>; John Ehrig <mailto:jehrig@inventures.com>; Andrew Nash <mailto:andrew@confyrm.com>; openid-specs-council at lists.openid.net <mailto:openid-specs-council@lists.openid.net>; Ashish Jain <mailto:ashishjain@vmware.com>; Nat Sakimura <mailto:sakimura@gmail.com>; aatoc at googlegroups.com <mailto:aatoc@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 <mailto:openid-specs-council-bounces@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 <mailto:openid-specs-council@lists.openid.net>; aatoc at googlegroups.com <mailto:aatoc@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 <mailto:openid-specs-council-bounces@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 <mailto:openid-specs-council@lists.openid.net>; Ashish Jain; Nat Sakimura; aatoc at googlegroups.com <mailto:aatoc@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 <mailto:ve7jtb@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 <mailto:ashishjain@vmware.com>>:

    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler



    From: Nat Sakimura <sakimura at gmail.com <mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain at vmware.com <mailto:ashishjain@vmware.com>>
    Cc: Adam Dawes <adawes at google.com <mailto:adawes@google.com>>, "openid-specs-council at lists.openid.net <mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net <mailto:openid-specs-council@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 <mailto:ashishjain@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 <mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes at google.com <mailto:adawes@google.com>>
    Cc: "openid-specs-council at lists.openid.net <mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net <mailto:openid-specs-council@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 <mailto:adawes@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 <mailto:aatoc+unsubscribe@googlegroups.com>.
    To post to this group, send email to aatoc at googlegroups.com <mailto:aatoc@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/20150302/b3fe18ea/attachment-0001.html>
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 4326 bytes
    Desc: not available
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150302/b3fe18ea/attachment-0001.p7s>
  • Mike Jones at Mar 2, 2015 at 5:11 pm
    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.comwrote:


    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.comwrote:
    +1


    =nat via iPhone


    2015/03/02 2:33?Ashish Jain <ashishjain at vmware.com<mailto:ashishjain@vmware.com>> ??????:
    +1


    From: Mike Jones <Michael.Jones at microsoft.com<mailto:michael.jones@microsoft.com>>
    Date: Friday, February 27, 2015 at 4:54 PM
    To: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>
    Cc: Chuck Mortimore <cmortimore at salesforce.com<mailto:cmortimore@salesforce.com>>, John Ehrig <jehrig at inventures.com<mailto:jehrig@inventures.com>>, Andrew Nash <andrew at confyrm.com<mailto:andrew@confyrm.com>>, "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>>, Ashish Jain <ashishjain at vmware.com<mailto:ashishjain@vmware.com>>, Nat Sakimura <sakimura at gmail.com<mailto:sakimura@gmail.com>>, "aatoc at googlegroups.com<mailto:aatoc@googlegroups.com>" <aatoc at googlegroups.com<mailto:aatoc@googlegroups.com>>
    Subject: RE: [OIDFSC] AATOC Working Group Charter


    I approve of the creation of this working group with this charter.
    ________________________________
    From: Adam Dawes<mailto:adawes@google.com>
    Sent: ?2/?27/?2015 11:22 AM
    To: John Bradley<mailto:ve7jtb@ve7jtb.com>
    Cc: Chuck Mortimore<mailto:cmortimore@salesforce.com>; Mike Jones<mailto:michael.jones@microsoft.com>; John Ehrig<mailto:jehrig@inventures.com>; Andrew Nash<mailto:andrew@confyrm.com>; openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>; Ashish Jain<mailto:ashishjain@vmware.com>; Nat Sakimura<mailto:sakimura@gmail.com>; aatoc at googlegroups.com<mailto:aatoc@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.comwrote:
    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.comwrote:
    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.comwrote:
    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.comwrote:
    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<mailto:openid-specs-council-bounces@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<mailto:openid-specs-council@lists.openid.net>; aatoc at googlegroups.com<mailto:aatoc@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] 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<mailto:openid-specs-council@lists.openid.net>; Ashish Jain; Nat Sakimura; aatoc at googlegroups.com<mailto:aatoc@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.comwrote:
    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.comwrote:
    +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.comwrote:
    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<mailto:ve7jtb@ve7jtb.com>>:


    That is a different WG outside of the OIDF;)


    On Feb 24, 2015, at 9:40 PM, Nat Sakimura <sakimura at gmail.comwrote:


    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<mailto:ashishjain@vmware.com>>:
    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler


    From: Nat Sakimura <sakimura at gmail.com<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain at vmware.com<mailto:ashishjain@vmware.com>>
    Cc: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>, "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:ashishjain@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<mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes at google.com<mailto:adawes@google.com>>
    Cc: "openid-specs-council at lists.openid.net<mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net<mailto:openid-specs-council@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<mailto:adawes@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<mailto:aatoc+unsubscribe@googlegroups.com>.
    To post to this group, send email to aatoc at googlegroups.com<mailto:aatoc@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/20150302/6f387245/attachment-0001.html>
  • Breno de Medeiros at Mar 2, 2015 at 6:06 pm
    +1 for WG formation.


    On Mon, Mar 2, 2015 at 9:11 AM, Mike Jones 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 wrote:



    Does this mean that we're an official working group now?



    On Sun, Mar 1, 2015 at 4:59 PM, Nat Sakimura wrote:

    +1

    =nat via iPhone


    2015/03/02 2:33?Ashish Jain <ashishjain@vmware.com> ??????:

    +1



    *From: *Mike Jones <michael.jones@microsoft.com>
    *Date: *Friday, February 27, 2015 at 4:54 PM
    *To: *Adam Dawes <adawes@google.com>, John Bradley <ve7jtb@ve7jtb.com>
    *Cc: *Chuck Mortimore <cmortimore@salesforce.com>, John Ehrig <
    jehrig at inventures.com>, Andrew Nash <andrew@confyrm.com>, "
    openid-specs-council at lists.openid.net" <
    openid-specs-council at lists.openid.net>, Ashish Jain <ashishjain@vmware.com>,
    Nat Sakimura <sakimura@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@google.com>
    *Sent: *?2/?27/?2015 11:22 AM
    *To: *John Bradley <ve7jtb@ve7jtb.com>
    *Cc: *Chuck Mortimore <cmortimore@salesforce.com>; Mike Jones
    <michael.jones@microsoft.com>; John Ehrig <jehrig@inventures.com>; Andrew
    Nash <andrew@confyrm.com>; openid-specs-council at lists.openid.net; Ashish
    Jain <ashishjain@vmware.com>; Nat Sakimura <sakimura@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 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 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 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 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@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 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 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 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@ve7jtb.com>:



    That is a different WG outside of the OIDF;)



    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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@vmware.com>:

    I?m not objecting?merely suggesting that referring it as Account Takeover
    WG is simpler



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 6:09 PM
    *To: *Ashish Jain <ashishjain@vmware.com>
    *Cc: *Adam Dawes <adawes@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@vmware.com>:

    I understand the need to be precise but ATO WG can probably convey the
    same message.



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 4:56 PM
    *To: *Adam Dawes <adawes@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@google.com>:

    I would like to form a new work group, AATOC. Here is our proposed charter:


    AATOC Charter


    1) Working Group name:

    Abuse and Account Takeover Coordination Group (AATOC)


    2) Purpose

    The goal of AATOC is to provide data sharing schemas, privacy
    recommendations and protocols to:



    ? Share information about important security events in order to
    thwart attackers from leveraging compromised accounts from one Service
    Provider to gain access to accounts on other Service Providers (mobile or
    web application developers and owners).

    ? Enable users and providers to coordinate in order to securely
    restore accounts following a compromise.



    Internet accounts that use email addresses or phone numbers as the primary
    identifier for the account will be the initial focus.
    2) Scope

    The group will define:

    ? *Security events*
    These are events ? whether directly authentication-related or occurring at
    another time in the user flow ? that take place on one service that could
    also have security implications on other Service Providers. The group will
    develop a taxonomy of security events and a common set of semantics to
    express relevant information about a security event.

    ? *Privacy Implications*
    Sharing security information amongst providers has potential privacy
    implications for both end users and service providers. These privacy
    implications must be balanced against the recognized benefits of protecting
    users? accounts and data from abuse. The group will consider ways to
    optimize this balance when defining mechanisms to handle the various
    security events and recommend best practices for the industry.



    ? *Communications mechanisms*
    Define bindings for the use of an existing transport protocol defined
    elsewhere.



    ? *Event schema*
    Define a schema describing relevant events and relationships to allow for
    dissemination between interested and authorized parties.



    ? *Account recovery mechanisms*

    Standardized mechanism(s) to allow providers to signal that a user has
    regained control of an account, or allow a user to explicitly restore
    control of a previously compromised account, with or without direct user
    involvement.
    Out of scope:

    Determining the account quality/reputation of a user on a particular
    service and communicating that to others.



    Definition of APIs and underlying mechanisms for connecting to,
    interacting with and operating centralized databases or intelligence
    clearinghouses when these are used to communicate security events between
    account providers.


    4) Proposed Deliverables

    The group proposes the following *Non-Specification* deliverables:



    *Security Event and Account Lifecycle Schema*

    ? A taxonomy of security events and a common set of semantics to
    express relevant information about a security event and its relationships
    to other relevant data, events or indicators.

    *Security Event Privacy Guidelines*

    A set of recommendations on how to minimize the privacy impact on users
    and service providers while improving security, and how to provide
    appropriate privacy disclosures, labeling and access control guidelines
    around information in the Security Event Schema.



    The group proposes the following *Specification *deliverables:



    *Communications Mechanisms*

    Define bindings for the event messages to an already existing transport
    protocol to promote interoperability of sending event information to
    another Service Provider. This will allow a Service Provider to implement a
    single piece of infrastructure that would be able to send or receive event
    information to any other service provider.



    *Order of Deliverables*

    The group will work to produce the Security Event and Account Lifecycle
    Schema before beginning work on the Communications Mechanism.


    5) Anticipated audience or users

    ? Service Providers who manage their own account systems which
    require an email address or phone number for registration.

    ? Account and email providers that understand key security events
    that happen to a user?s account.

    ? Identity as a Service (IDaaS) vendors that manage account and
    authentication systems for their customers.

    ? Users seeking to regain control of a compromised account.


    6) Language

    English


    7) Method of work:

    E-mail discussions on the working group mailing list, working group
    conference calls, and face-to-face meetings from time to time.


    8) Basis for determining when the work is completed:

    Rough consensus and running code. The work will be completed once it is
    apparent that maximal consensus on the draft has been achieved, consistent
    with the purpose and scope.


    Background information


    Related work:

    ? RFC6545 Real-time Inter-network Defense (RID)

    ? RFC6546 Transport of Real-time Inter-network Defense (RID)
    Messages over HTTP/TLS

    ? RFC6684 Guidelines and Template for Defining Extensions to the
    Incident Object Description Exchange Format (IODEF)

    ? draft-ietf-mile-rolie Resource-Oriented Lightweight Indicator
    Exchange

    ? ISO/IEC 27002:2013 Information technology ? Security techniques
    ? Code of practice for information security controls

    ? ISO/IEC 27035:2011 Information technology ? Security techniques
    ? Information security incident management


    Proposers

    ? Adam Dawes, Google

    ? Mark Risher, Google

    ? Trent Adams, Paypal

    ? George Fletcher, AOL

    ? Andrew Nash, Confyrm

    ? Nat Sakimura, Nomura Research Institute

    ? John Bradley, Ping Identity

    ? Henrik Biering, Peercraft
    Anticipated contributions:

    ?Security event reporting between Service Providers 1.0? under the OpenID
    Foundation?s IPR Policy
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_intellectual-2Dproperty_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=yV7iQ-h1QNIAyTmfXm6S6vIszebI2q_snUSkFyjxlkg&e=>
    .





    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=his8oMG2sVamzBa3dQLPovSTmI9fUVGF3mbIZ4ZzISQ&s=jmKQL3OD_c7eJXduzdJt5OJefY8ZjNiYCoAm8g-7oOA&e=>
    @_nat_en





    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=dibzrL00q20lgLcDv94EYh8Ums_bAaYivHuqDQgNfSI&s=jq4oX-tF55oVVtUOW6sW0RsihIhuUzSlJVyRWCVyAhQ&e=>
    @_nat_en





    --

    Nat Sakimura (=nat)

    Chairman, OpenID Foundation
    http://nat.sakimura.org/
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=AwMF_g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=IR5tru86Ihv2g1IjtatpVdYMQcw52SU4UWhhLzaHxts&s=ZBjiNJFuAuQhY9EfZmff4-R5LvM5fz_i_xoQXnZzNBg&e=>
    @_nat_en





    --
    You received this message because you are subscribed to the Google Groups
    "Abuse and ATO Coordination" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to aatoc+unsubscribe at googlegroups.com.
    To post to this group, send email to aatoc at googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/aatoc/CAOJhRMYKX6O8LVPzCf8x%2BFDnmuMuLDH8RdssTXqZ1YeU54bLNA%40mail.gmail.com
    <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_aatoc_CAOJhRMYKX6O8LVPzCf8x-252BFDnmuMuLDH8RdssTXqZ1YeU54bLNA-2540mail.gmail.com-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dfooter&d=AwMF_g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=IR5tru86Ihv2g1IjtatpVdYMQcw52SU4UWhhLzaHxts&s=5lX731FD9xPT7XHaq_TymfCgMB4LpcDi1T_6AH4z2UE&e=>
    .
    For more options, visit https://groups.google.com/d/optout
    <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=AwMF_g&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=PDGu4NI-duocVzLKrMLVZV9ccYh2Q-1cXto7c2DRReM&m=IR5tru86Ihv2g1IjtatpVdYMQcw52SU4UWhhLzaHxts&s=_ArfcCFBHUilGTdBgpsiBBSJ1Yqz0rX_H5s7Jfmkq-o&e=>
    .


















    --
    --Breno
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150302/d161cd0a/attachment-0001.html>
  • Chuck Mortimore at Mar 2, 2015 at 7:12 pm
    +1 for formation with that charter!


    On Mon, Mar 2, 2015 at 10:06 AM, Breno de Medeiros wrote:

    +1 for WG formation.
    On Mon, Mar 2, 2015 at 9:11 AM, Mike Jones 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 wrote:



    Does this mean that we're an official working group now?



    On Sun, Mar 1, 2015 at 4:59 PM, Nat Sakimura wrote:

    +1

    =nat via iPhone


    2015/03/02 2:33?Ashish Jain <ashishjain@vmware.com> ??????:

    +1



    *From: *Mike Jones <michael.jones@microsoft.com>
    *Date: *Friday, February 27, 2015 at 4:54 PM
    *To: *Adam Dawes <adawes@google.com>, John Bradley <ve7jtb@ve7jtb.com>
    *Cc: *Chuck Mortimore <cmortimore@salesforce.com>, John Ehrig <
    jehrig at inventures.com>, Andrew Nash <andrew@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@gmail.com>, "
    aatoc at googlegroups.com" <aatoc@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@google.com>
    *Sent: *?2/?27/?2015 11:22 AM
    *To: *John Bradley <ve7jtb@ve7jtb.com>
    *Cc: *Chuck Mortimore <cmortimore@salesforce.com>; Mike Jones
    <michael.jones@microsoft.com>; John Ehrig <jehrig@inventures.com>; Andrew
    Nash <andrew@confyrm.com>; openid-specs-council at lists.openid.net; Ashish
    Jain <ashishjain@vmware.com>; Nat Sakimura <sakimura@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 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 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@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@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@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 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 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 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@ve7jtb.com>:



    That is a different WG outside of the OIDF;)



    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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@vmware.com>:

    I?m not objecting?merely suggesting that referring it as Account Takeover
    WG is simpler



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 6:09 PM
    *To: *Ashish Jain <ashishjain@vmware.com>
    *Cc: *Adam Dawes <adawes@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@vmware.com>:

    I understand the need to be precise but ATO WG can probably convey the
    same message.



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 4:56 PM
    *To: *Adam Dawes <adawes@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@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>
  • Adam Dawes at Mar 6, 2015 at 6:14 am
    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 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 wrote:



    Does this mean that we're an official working group now?



    On Sun, Mar 1, 2015 at 4:59 PM, Nat Sakimura wrote:

    +1

    =nat via iPhone


    2015/03/02 2:33?Ashish Jain <ashishjain@vmware.com> ??????:

    +1



    *From: *Mike Jones <michael.jones@microsoft.com>
    *Date: *Friday, February 27, 2015 at 4:54 PM
    *To: *Adam Dawes <adawes@google.com>, John Bradley <ve7jtb@ve7jtb.com>
    *Cc: *Chuck Mortimore <cmortimore@salesforce.com>, John Ehrig <
    jehrig at inventures.com>, Andrew Nash <andrew@confyrm.com>, "
    openid-specs-council at lists.openid.net" <
    openid-specs-council at lists.openid.net>, Ashish Jain <ashishjain@vmware.com>,
    Nat Sakimura <sakimura@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@google.com>
    *Sent: *?2/?27/?2015 11:22 AM
    *To: *John Bradley <ve7jtb@ve7jtb.com>
    *Cc: *Chuck Mortimore <cmortimore@salesforce.com>; Mike Jones
    <michael.jones@microsoft.com>; John Ehrig <jehrig@inventures.com>; Andrew
    Nash <andrew@confyrm.com>; openid-specs-council at lists.openid.net; Ashish
    Jain <ashishjain@vmware.com>; Nat Sakimura <sakimura@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 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 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 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 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@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 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 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 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@ve7jtb.com>:



    That is a different WG outside of the OIDF;)



    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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@vmware.com>:

    I?m not objecting?merely suggesting that referring it as Account Takeover
    WG is simpler



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 6:09 PM
    *To: *Ashish Jain <ashishjain@vmware.com>
    *Cc: *Adam Dawes <adawes@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@vmware.com>:

    I understand the need to be precise but ATO WG can probably convey the
    same message.



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 4:56 PM
    *To: *Adam Dawes <adawes@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@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/20150305/b332dff8/attachment-0001.html>
  • John Bradley at Mar 6, 2015 at 8:30 am
    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 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/ <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 <mailto:ve7jtb@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 <mailto:openid-specs-council@lists.openid.net>; aatoc at googlegroups.com <mailto:aatoc@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 <mailto:ashishjain@vmware.com>> ??????:

    +1



    From: Mike Jones <Michael.Jones at microsoft.com <mailto:michael.jones@microsoft.com>>
    Date: Friday, February 27, 2015 at 4:54 PM
    To: Adam Dawes <adawes at google.com <mailto:adawes@google.com>>, John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb@ve7jtb.com>>
    Cc: Chuck Mortimore <cmortimore at salesforce.com <mailto:cmortimore@salesforce.com>>, John Ehrig <jehrig at inventures.com <mailto:jehrig@inventures.com>>, Andrew Nash <andrew at confyrm.com <mailto:andrew@confyrm.com>>, "openid-specs-council at lists.openid.net <mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net <mailto:openid-specs-council@lists.openid.net>>, Ashish Jain <ashishjain at vmware.com <mailto:ashishjain@vmware.com>>, Nat Sakimura <sakimura at gmail.com <mailto:sakimura@gmail.com>>, "aatoc at googlegroups.com <mailto:aatoc@googlegroups.com>" <aatoc at googlegroups.com <mailto:aatoc@googlegroups.com>>
    Subject: RE: [OIDFSC] AATOC Working Group Charter



    I approve of the creation of this working group with this charter.

    From: Adam Dawes <mailto:adawes@google.com>
    Sent: ?2/?27/?2015 11:22 AM
    To: John Bradley <mailto:ve7jtb@ve7jtb.com>
    Cc: Chuck Mortimore <mailto:cmortimore@salesforce.com>; Mike Jones <mailto:michael.jones@microsoft.com>; John Ehrig <mailto:jehrig@inventures.com>; Andrew Nash <mailto:andrew@confyrm.com>; openid-specs-council at lists.openid.net <mailto:openid-specs-council@lists.openid.net>; Ashish Jain <mailto:ashishjain@vmware.com>; Nat Sakimura <mailto:sakimura@gmail.com>; aatoc at googlegroups.com <mailto:aatoc@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 <mailto:openid-specs-council-bounces@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 <mailto:openid-specs-council@lists.openid.net>; aatoc at googlegroups.com <mailto:aatoc@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 <mailto:openid-specs-council-bounces@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 <mailto:openid-specs-council@lists.openid.net>; Ashish Jain; Nat Sakimura; aatoc at googlegroups.com <mailto:aatoc@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 <mailto:ve7jtb@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 <mailto:ashishjain@vmware.com>>:

    I?m not objecting?merely suggesting that referring it as Account Takeover WG is simpler



    From: Nat Sakimura <sakimura at gmail.com <mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 6:09 PM
    To: Ashish Jain <ashishjain at vmware.com <mailto:ashishjain@vmware.com>>
    Cc: Adam Dawes <adawes at google.com <mailto:adawes@google.com>>, "openid-specs-council at lists.openid.net <mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net <mailto:openid-specs-council@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 <mailto:ashishjain@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 <mailto:sakimura@gmail.com>>
    Date: Tuesday, February 24, 2015 at 4:56 PM
    To: Adam Dawes <adawes at google.com <mailto:adawes@google.com>>
    Cc: "openid-specs-council at lists.openid.net <mailto:openid-specs-council@lists.openid.net>" <openid-specs-council at lists.openid.net <mailto:openid-specs-council@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 <mailto:adawes@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 <mailto:aatoc+unsubscribe@googlegroups.com>.
    To post to this group, send email to aatoc at googlegroups.com <mailto:aatoc@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/20150306/74912776/attachment-0001.html>
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 4326 bytes
    Desc: not available
    URL: <http://lists.openid.net/pipermail/openid-specs-council/attachments/20150306/74912776/attachment-0001.p7s>
  • Adam Dawes at Mar 6, 2015 at 9:30 am
    I've already pinged him. I guess we'll have to wait...


    On Fri, Mar 6, 2015 at 12:30 AM, John Bradley 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 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 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 wrote:



    Does this mean that we're an official working group now?



    On Sun, Mar 1, 2015 at 4:59 PM, Nat Sakimura wrote:

    +1

    =nat via iPhone


    2015/03/02 2:33?Ashish Jain <ashishjain@vmware.com> ??????:

    +1



    *From: *Mike Jones <michael.jones@microsoft.com>
    *Date: *Friday, February 27, 2015 at 4:54 PM
    *To: *Adam Dawes <adawes@google.com>, John Bradley <ve7jtb@ve7jtb.com>
    *Cc: *Chuck Mortimore <cmortimore@salesforce.com>, John Ehrig <
    jehrig at inventures.com>, Andrew Nash <andrew@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@gmail.com>, "
    aatoc at googlegroups.com" <aatoc@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@google.com>
    *Sent: *?2/?27/?2015 11:22 AM
    *To: *John Bradley <ve7jtb@ve7jtb.com>
    *Cc: *Chuck Mortimore <cmortimore@salesforce.com>; Mike Jones
    <michael.jones@microsoft.com>; John Ehrig <jehrig@inventures.com>; Andrew
    Nash <andrew@confyrm.com>; openid-specs-council at lists.openid.net; Ashish
    Jain <ashishjain@vmware.com>; Nat Sakimura <sakimura@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 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 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@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@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@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 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 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 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@ve7jtb.com>:



    That is a different WG outside of the OIDF;)



    On Feb 24, 2015, at 9:40 PM, Nat Sakimura 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@vmware.com>:

    I?m not objecting?merely suggesting that referring it as Account Takeover
    WG is simpler



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 6:09 PM
    *To: *Ashish Jain <ashishjain@vmware.com>
    *Cc: *Adam Dawes <adawes@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@vmware.com>:

    I understand the need to be precise but ATO WG can probably convey the
    same message.



    *From: *Nat Sakimura <sakimura@gmail.com>
    *Date: *Tuesday, February 24, 2015 at 4:56 PM
    *To: *Adam Dawes <adawes@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@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/20150306/20fca6d8/attachment-0001.html>
  • Nat Sakimura at Mar 6, 2015 at 5:35 pm
    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 wrote:

    I've already pinged him. I guess we'll have to wait...
    On Fri, Mar 6, 2015 at 12:30 AM, John Bradley 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 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
    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 wrote:



    Does this mean that we're an official working group now?



    On Sun, Mar 1, 2015 at 4:59 PM, Nat Sakimura <sakimura@gmail.com>
    wrote:

    +1

    =nat via iPhone


    2015/03/02 2:33?Ashish Jain <ashishjain@vmware.com> ??????:

    +1



    *From: *Mike Jones <michael.jones@microsoft.com>
    *Date: *Friday, February 27, 2015 at 4:54 PM
    *To: *Adam Dawes <adawes@google.com>, John Bradley
    <ve7jtb@ve7jtb.com> *Cc: *Chuck Mortimore
    <cmortimore@salesforce.com>, John Ehrig <jehrig@inventures.com>,
    Andrew Nash <andrew@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@gmail.com>, "
    aatoc at googlegroups.com" <aatoc@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@google.com>
    *Sent: *?2/?27/?2015 11:22 AM
    *To: *John Bradley <ve7jtb@ve7jtb.com>
    *Cc: *Chuck Mortimore <cmortimore@salesforce.com>; Mike Jones
    <michael.jones@microsoft.com>; John Ehrig <jehrig@inventures.com>;
    Andrew Nash <andrew@confyrm.com>;
    openid-specs-council at lists.openid.net; Ashish Jain
    <ashishjain@vmware.com>; Nat Sakimura <sakimura@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@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@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
    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
    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@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
    <