[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
Primer
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