[Openid-specs-risc] OpenID RISC Meeting Notes, Redmond, 20-Apr-18

Mike Jones Michael.Jones at microsoft.com
Fri Apr 20 21:37:59 UTC 2018

OpenID RISC Meeting Notes, Redmond, 20-Apr-18

Mark Atherton - Facebook compromised accounts team engineer
Stan Bounev - VeriClouds head of product management - identity threat management and intelligence
Mike Jones - Microsoft identity standards
Alex Kerametlian - Microsoft identity protection engineering team
Cheryl Kwan - Google identity program manager
Adam Dawes - Google identity team and identity developer tools and RISC working group chair
Luke Camery - Google identity product manager
Jeff Sakowicz - Microsoft PM consent framework and permissions models
Michael McLaughlin michmcla at microsoft.com<mailto:michmcla at microsoft.com> - Account protection
Roshni Chandrashekhar - Google identity engineer
Annabelle Backman - Amazon consumer identity engineer
Marius Scurtescu - Google federated identity team
Supranamaya (Soups) Ranjan - Coinbase lead of risk and data science

              Annabelle: SET, RISC Profile, Subjects, Event Types, Control Plane, Discovery and Keys, Delivery (Push, Poll)
              Explicit vs. Implicit
              Avoiding revealing correlations
              No support for batching events, by design

Data Exchanges
              Michael: Microsoft and Google have been sharing RISC data for about 2 years
                           Account identifiers and timestamps
                           Looking into tracking malicious activity across systems
                           Next step to take more actions based on the data
                           Bulk created accounts one of the factors to use
              Stan: Is the review automated or manual?
                           Michael: Currently manual but will have to be automated
              Adam: Currently just sending hijacking events
                           Dealing with recovery addresses
              Annabelle: Amazon has an initial implementation of the control plane
                           Need to connect to others
                           Have an endpoint set up to receive SETs
                                         Not yet doing anything with the data
              Marius: Google doesn't yet have the subscription support built
                            Google also has a receiving endpoint that doesn't process the data yet
                            Google's transmitter is fully implemented for the explicit use cases
              Adam: There are significant numbers of Facebook clients at Google
                           For account recovery
                           Facebook could start testing quickly when they're ready
              Marius: We just need a client_id to do manual registration

Legal Status
              Adam: Google created a draft agreement
                           Have received feedback from multiple parties on it
                           Held legal meeting at end of January
                           Goal to create a template stock agreement that is contributed to the OpenID Foundation
                           Google eventually plans to use a standard contract with all parties they're sharing data with
              Luke: Amazon has been providing feedback to Google on the legal agreement
              Mike: When the agreement has been updated, please send a copy to Mike Jones and Michael McLaughlin
              Marius: We only send events about users that the parties have in common for privacy reasons, etc.
                           The first step is to determine the set of users in common
                           This is currently happening by sending user identifiers in a way covered by the legal agreement
              Mike: Eventually the OpenID Foundation and OIX want there to be a multilateral agreement
                           But this is future work
              Adam: There may be three versions of the contract
                           Wet ink version for implicit partners
                                         People have to agree not to register for accounts that they don't have
                           Click-through version for recipients
                                         Don't necessarily expect data back from these participants
                           IDAS version - recognizing that they manage thousands of applications and identities for their customers
                                         Allow the IDAS vendors to act as an agent for their customers
                                         Would not allow re-sharing of RISC data

Spec Status
              We agreed to hold Implementer's Draft votes for the existing specs at the previous F2F meeting
              Adam: I had written a RISC Strawman spec that describes event handling practices
                           Do we want to merge that into the events draft before we hold the vote?
              Annabelle: Would we be giving the information too much weight if we put it into the spec itself
              Mike: It could be phrased as "for example" rather than as being prescriptive
              Adam: The events in his strawman spec don't really match the ones in the RISC Events spec
              Mike: I suggest we hold the Implementer's Draft votes now
              Marius: We can then do the descriptive/guidance work in parallel
              Marius will send Mike specs to review as OpenID Secretary as proposed Implementer's Drafts
              Adam will ask the working group to review them in parallel with Mike's review

Use of OAuth Bearer Tokens for authentication
              It's important to define enough details to enable interop
              We can define an interoperable mechanism in the RISC profile and say that other mechanisms can be used if agreed to by the parties
                           It needs to specify things like that the client_id is the audience value, what the issuer value is, etc.
              Marius will make these changes to the profile draft before we hold the Implementer's Draft vote

Data Deletion Request
              There could be a signal in the OAuth set saying that the end-user would like to opt out and request deletion of previously obtained data
              Annabelle: This seems out of place here
              Mark: I agree that this is out of place
              Adam: Just like OAuth providers should enable end-users to revoke tokens, they should enable them to request data deletion
              Marius: The delivery methods are not built to deliver commands
              Yesterday Brad Hill of Facebook discussed having a confirmation message with a tracking number after the action was done
              Mike: This doesn't feel like RISC - it feels like explicit account management
                           Mark will follow up with Brad
              Annabelle: Should we send this to the OAuth working group?
              Adam:  This is high priority for us. We would like to do this work.
              Mike: This isn't just an event.  There's an entire business process here.
              Annabelle: This is about management of data.  If there isn't a working group for this, maybe there should be.
              There was a discussion about whether this pertains to OAuth resource authorization or OpenID Connect identities or both
              Annabelle: GDPR is one of these.  There will be lots of others.
              Mark: Another example operation is "Show me what data you have about me".
              Mike: It might be good to have some prototypes happen to learn from before we approach standardization of this functionality
                           Stan: This might need to happen very soon

Exchange of events between non-identity providers
              Stan: Are you working on enabling sharing between parties that aren't identity providers?
              Annabelle: Yes.  IdP to RP certainly makes sense.
              Adam: Other cases may be less clear
              Annabelle: A lot of the events are not specific to identity providers
                           They are often about accounts - not just accounts at IdPs

OAuth Client Configuration Change Events
              Some additional possible client change events were discussed at the account protection summit yesterday
                           There is currently a client credential changed event
                           Could be that the credentials, owner, endpoints, branding changed
              Maybe have event arguments to express this?
              Annabelle: There's value in having credential changed be machine readable
              Mike: We want to drive creation of new events based on when there are actually deployments wanting to do things based on those events
              Adam: I'd rather keep this free-form with a human-readable description, for now

Account Protection Summit
              Some members attended an account protection summit yesterday.  Some discussion topics were:
              Mark: One thing talked about was how to make self-reports of account compromise actionable
                           Microsoft shared progress on this front with attendees
              Mark: Discussions on the value of 2FA
              Mark: Password spraying attacks
              Adam: Discussions of policies to decide whether to allow access to data through OAuth or not
                           Not protocol discussions but more business and helping the user do the right things
              Mark: Sharing information on IP addresses
                           Including what do we do in an IPv6 world?
              Luke: A lot of the large providers are having the same issues
                           Cheryl: Glad to see people can now get resources to work on these problems
              Annabelle: Surprised by the degree to which companies are moving from a laissez-faire approach to a more paternalistic approach
              Marius: The Microsoft Research work on password requirements was valuable
                           For instance, requiring password changes actually tend to make them more guessable

Potential misuse of RISC signals
              DOS attacks may be possible
              If you have the IdPs issuer key, that's a much bigger problem than being able to send RISC signals
              Mark: I wanted to make sure that deliberate misuse was considered as we develop RISC
              Stan: Also, what if there's a bug and a lot of events are sent that didn't actually happen?
              Stan: Whether to notify users of problems and how to needs careful consideration?
                           Annabelle: It might not be productive to tell users that an action was triggered by a security event
              Adam: Do we want an "undo" operation?
                           Mike: Having "undo" would result in a state explosion and additional complexity
              Marius: We need a counterpart to "account credential change required"
                           Such as "account credential changed"
              Marius: Having an "account rolled back" event may be useful in some circumstances
                           Adam: I'm not aware of actual account rollback implementations

Enrollment of Linked ID
              There may be multiple identifiers associated with an account
                           Such as multiple e-mail addresses
                           Mark: These probably should be handled as multiple subscriptions
              Marius: Two Google accounts using the same hotmail address
                           Microsoft might not know which Google account the event about the hotmail account pertains to
              Annabelle: Phone number and e-mail address are not unique identifiers at the sender
                           Ambiguity is possible in these circumstances
              Marius: We might need to add a directed identifier to disambiguate which account the event pertains to
                           Mike: We would want the actual risk teams involved in specifying any of this
              Annabelle: This might be more pertinent to identity use cases than RISC use cases
              Adam: Should we consider representing information like this to the subject identifier?
              Annabelle: Once there's a clear need for that that's been demonstrated

Stream Deletion
              Marius: There is currently no mechanism for clients to delete streams
                           They will want this if they want to stop receiving events
                            I am considering adding an HTTP DELETE verb
              People felt like it was too early to do this now
              Marius will send an e-mail about this
              Marius: Statuses of the stream are currently Enabled, Disabled, Paused
                           Roshni thought that Suspended might be a better name for Disabled
                           Mike: "Suspended" is bad because it has two meanings in English
              Mark: Is it even reasonable to ask the sender to buffer messages for paused receivers?
                            Annabelle: We'll have to determine this based on implementation and deployment experience

Use Cases
              Marius has an action item to create a RISC use cases document and submit it to the RISC working group

Change of Control Events
              Marius: A redirect_uri can go bad if the domain it's located within expires
              Adam: Domain expiration is public information
              Marius: Selling a domain is a gray area
                           Adam: This may or may not have security implications
                           For instance, Facebook acquiring Instagram

Dashes and Underscores
              Marius: When should we be using dashes versus underscores in names?
              Mike: URIs tend to use dashes for historical reasons
              Mike: Names for JSON objects should use underscores
              Names for subject identifiers (which use JSON) should use underscores rather than dashes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20180420/9eb1f7fe/attachment-0001.html>

More information about the Openid-specs-risc mailing list