<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">OpenID RISC Meeting Notes, Redmond, 20-Apr-18<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Mark Atherton – Facebook compromised accounts team engineer<o:p></o:p></p>
<p class="MsoNormal">Stan Bounev – VeriClouds head of product management – identity threat management and intelligence<o:p></o:p></p>
<p class="MsoNormal">Mike Jones – Microsoft identity standards<o:p></o:p></p>
<p class="MsoNormal">Alex Kerametlian – Microsoft identity protection engineering team<o:p></o:p></p>
<p class="MsoNormal">Cheryl Kwan – Google identity program manager <o:p></o:p></p>
<p class="MsoNormal">Adam Dawes – Google identity team and identity developer tools and RISC working group chair<o:p></o:p></p>
<p class="MsoNormal">Luke Camery – Google identity product manager<o:p></o:p></p>
<p class="MsoNormal">Jeff Sakowicz – Microsoft PM consent framework and permissions models<o:p></o:p></p>
<p class="MsoNormal">Michael McLaughlin <a href="mailto:michmcla@microsoft.com">michmcla@microsoft.com</a> – Account protection<o:p></o:p></p>
<p class="MsoNormal">Roshni Chandrashekhar – Google identity engineer<o:p></o:p></p>
<p class="MsoNormal">Annabelle Backman – Amazon consumer identity engineer<o:p></o:p></p>
<p class="MsoNormal">Marius Scurtescu – Google federated identity team<o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Segoe UI",sans-serif">Supranamaya (</span>Soups) Ranjan - Coinbase lead of risk and data science<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Primer<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: SET, RISC Profile, Subjects, Event Types, Control Plane, Discovery and Keys, Delivery (Push, Poll)<o:p></o:p></p>
<p class="MsoNormal"> Explicit vs. Implicit<o:p></o:p></p>
<p class="MsoNormal"> Avoiding revealing correlations<o:p></o:p></p>
<p class="MsoNormal"> No support for batching events, by design<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Data Exchanges<o:p></o:p></p>
<p class="MsoNormal"> Michael: Microsoft and Google have been sharing RISC data for about 2 years<o:p></o:p></p>
<p class="MsoNormal"> Account identifiers and timestamps<o:p></o:p></p>
<p class="MsoNormal"> Looking into tracking malicious activity across systems<o:p></o:p></p>
<p class="MsoNormal"> Next step to take more actions based on the data<o:p></o:p></p>
<p class="MsoNormal"> Bulk created accounts one of the factors to use<o:p></o:p></p>
<p class="MsoNormal"> Stan: Is the review automated or manual?<o:p></o:p></p>
<p class="MsoNormal"> Michael: Currently manual but will have to be automated<o:p></o:p></p>
<p class="MsoNormal"> Adam: Currently just sending hijacking events<o:p></o:p></p>
<p class="MsoNormal"> Dealing with recovery addresses<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: Amazon has an initial implementation of the control plane<o:p></o:p></p>
<p class="MsoNormal"> Need to connect to others<o:p></o:p></p>
<p class="MsoNormal"> Have an endpoint set up to receive SETs<o:p></o:p></p>
<p class="MsoNormal"> Not yet doing anything with the data<o:p></o:p></p>
<p class="MsoNormal"> Marius: Google doesn’t yet have the subscription support built<o:p></o:p></p>
<p class="MsoNormal"> Google also has a receiving endpoint that doesn’t process the data yet<o:p></o:p></p>
<p class="MsoNormal"> Google’s transmitter is fully implemented for the explicit use cases<o:p></o:p></p>
<p class="MsoNormal"> Adam: There are significant numbers of Facebook clients at Google<o:p></o:p></p>
<p class="MsoNormal"> For account recovery<o:p></o:p></p>
<p class="MsoNormal"> Facebook could start testing quickly when they’re ready<o:p></o:p></p>
<p class="MsoNormal"> Marius: We just need a client_id to do manual registration<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Legal Status<o:p></o:p></p>
<p class="MsoNormal"> Adam: Google created a draft agreement<o:p></o:p></p>
<p class="MsoNormal"> Have received feedback from multiple parties on it<o:p></o:p></p>
<p class="MsoNormal"> Held legal meeting at end of January<o:p></o:p></p>
<p class="MsoNormal"> Goal to create a template stock agreement that is contributed to the OpenID Foundation<o:p></o:p></p>
<p class="MsoNormal"> Google eventually plans to use a standard contract with all parties they’re sharing data with<o:p></o:p></p>
<p class="MsoNormal"> Luke: Amazon has been providing feedback to Google on the legal agreement<o:p></o:p></p>
<p class="MsoNormal"> Mike: When the agreement has been updated, please send a copy to Mike Jones and Michael McLaughlin<o:p></o:p></p>
<p class="MsoNormal"> Marius: We only send events about users that the parties have in common for privacy reasons, etc.<o:p></o:p></p>
<p class="MsoNormal"> The first step is to determine the set of users in common<o:p></o:p></p>
<p class="MsoNormal"> This is currently happening by sending user identifiers in a way covered by the legal agreement<o:p></o:p></p>
<p class="MsoNormal"> Mike: Eventually the OpenID Foundation and OIX want there to be a multilateral agreement<o:p></o:p></p>
<p class="MsoNormal"> But this is future work<o:p></o:p></p>
<p class="MsoNormal"> Adam: There may be three versions of the contract<o:p></o:p></p>
<p class="MsoNormal"> Wet ink version for implicit partners<o:p></o:p></p>
<p class="MsoNormal"> People have to agree not to register for accounts that they don’t have<o:p></o:p></p>
<p class="MsoNormal"> Click-through version for recipients<o:p></o:p></p>
<p class="MsoNormal"> Don’t necessarily expect data back from these participants<o:p></o:p></p>
<p class="MsoNormal"> IDAS version – recognizing that they manage thousands of applications and identities for their customers<o:p></o:p></p>
<p class="MsoNormal"> Allow the IDAS vendors to act as an agent for their customers<o:p></o:p></p>
<p class="MsoNormal"> Would not allow re-sharing of RISC data<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Spec Status<o:p></o:p></p>
<p class="MsoNormal"> We agreed to hold Implementer’s Draft votes for the existing specs at the previous F2F meeting<o:p></o:p></p>
<p class="MsoNormal"> Adam: I had written a RISC Strawman spec that describes event handling practices<o:p></o:p></p>
<p class="MsoNormal"> Do we want to merge that into the events draft before we hold the vote?<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: Would we be giving the information too much weight if we put it into the spec itself<o:p></o:p></p>
<p class="MsoNormal"> Mike: It could be phrased as “for example” rather than as being prescriptive<o:p></o:p></p>
<p class="MsoNormal"> Adam: The events in his strawman spec don’t really match the ones in the RISC Events spec<o:p></o:p></p>
<p class="MsoNormal"> Mike: I suggest we hold the Implementer’s Draft votes now<o:p></o:p></p>
<p class="MsoNormal"> Marius: We can then do the descriptive/guidance work in parallel<o:p></o:p></p>
<p class="MsoNormal"> Marius will send Mike specs to review as OpenID Secretary as proposed Implementer’s Drafts<o:p></o:p></p>
<p class="MsoNormal"> Adam will ask the working group to review them in parallel with Mike’s review<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Use of OAuth Bearer Tokens for authentication<o:p></o:p></p>
<p class="MsoNormal"> It’s important to define enough details to enable interop<o:p></o:p></p>
<p class="MsoNormal"> We can define an interoperable mechanism in the RISC profile and say that other mechanisms can be used if agreed to by the parties<o:p></o:p></p>
<p class="MsoNormal"> It needs to specify things like that the client_id is the audience value, what the issuer value is, etc.<o:p></o:p></p>
<p class="MsoNormal"> Marius will make these changes to the profile draft before we hold the Implementer’s Draft vote<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Data Deletion Request<o:p></o:p></p>
<p class="MsoNormal"> 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<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: This seems out of place here<o:p></o:p></p>
<p class="MsoNormal"> Mark: I agree that this is out of place<o:p></o:p></p>
<p class="MsoNormal"> Adam: Just like OAuth providers should enable end-users to revoke tokens, they should enable them to request data deletion<o:p></o:p></p>
<p class="MsoNormal"> Marius: The delivery methods are not built to deliver commands<o:p></o:p></p>
<p class="MsoNormal"> Yesterday Brad Hill of Facebook discussed having a confirmation message with a tracking number after the action was done<o:p></o:p></p>
<p class="MsoNormal"> Mike: This doesn’t feel like RISC – it feels like explicit account management<o:p></o:p></p>
<p class="MsoNormal"> Mark will follow up with Brad<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: Should we send this to the OAuth working group?<o:p></o:p></p>
<p class="MsoNormal"> Adam: This is high priority for us. We would like to do this work.<o:p></o:p></p>
<p class="MsoNormal"> Mike: This isn’t just an event. There’s an entire business process here.<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: This is about management of data. If there isn’t a working group for this, maybe there should be.<o:p></o:p></p>
<p class="MsoNormal"> There was a discussion about whether this pertains to OAuth resource authorization or OpenID Connect identities or both<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: GDPR is one of these. There will be lots of others.<o:p></o:p></p>
<p class="MsoNormal"> Mark: Another example operation is “Show me what data you have about me”.<o:p></o:p></p>
<p class="MsoNormal"> Mike: It might be good to have some prototypes happen to learn from before we approach standardization of this functionality<o:p></o:p></p>
<p class="MsoNormal"> Stan: This might need to happen very soon<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Exchange of events between non-identity providers<o:p></o:p></p>
<p class="MsoNormal"> Stan: Are you working on enabling sharing between parties that aren’t identity providers?<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: Yes. IdP to RP certainly makes sense.<o:p></o:p></p>
<p class="MsoNormal"> Adam: Other cases may be less clear<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: A lot of the events are not specific to identity providers<o:p></o:p></p>
<p class="MsoNormal"> They are often about accounts – not just accounts at IdPs<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">OAuth Client Configuration Change Events<o:p></o:p></p>
<p class="MsoNormal"> Some additional possible client change events were discussed at the account protection summit yesterday<o:p></o:p></p>
<p class="MsoNormal"> There is currently a client credential changed event<o:p></o:p></p>
<p class="MsoNormal"> Could be that the credentials, owner, endpoints, branding changed<o:p></o:p></p>
<p class="MsoNormal"> Maybe have event arguments to express this?<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: There’s value in having credential changed be machine readable<o:p></o:p></p>
<p class="MsoNormal"> Mike: We want to drive creation of new events based on when there are actually deployments wanting to do things based on those events<o:p></o:p></p>
<p class="MsoNormal"> Adam: I’d rather keep this free-form with a human-readable description, for now<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Account Protection Summit<o:p></o:p></p>
<p class="MsoNormal"> Some members attended an account protection summit yesterday. Some discussion topics were:<o:p></o:p></p>
<p class="MsoNormal"> Mark: One thing talked about was how to make self-reports of account compromise actionable<o:p></o:p></p>
<p class="MsoNormal"> Microsoft shared progress on this front with attendees<o:p></o:p></p>
<p class="MsoNormal"> Mark: Discussions on the value of 2FA<o:p></o:p></p>
<p class="MsoNormal"> Mark: Password spraying attacks<o:p></o:p></p>
<p class="MsoNormal"> Adam: Discussions of policies to decide whether to allow access to data through OAuth or not<o:p></o:p></p>
<p class="MsoNormal"> Not protocol discussions but more business and helping the user do the right things<o:p></o:p></p>
<p class="MsoNormal"> Mark: Sharing information on IP addresses<o:p></o:p></p>
<p class="MsoNormal"> Including what do we do in an IPv6 world?<o:p></o:p></p>
<p class="MsoNormal"> Luke: A lot of the large providers are having the same issues<o:p></o:p></p>
<p class="MsoNormal"> Cheryl: Glad to see people can now get resources to work on these problems<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: Surprised by the degree to which companies are moving from a laissez-faire approach to a more paternalistic approach<o:p></o:p></p>
<p class="MsoNormal"> Marius: The Microsoft Research work on password requirements was valuable<o:p></o:p></p>
<p class="MsoNormal"> For instance, requiring password changes actually tend to make them more guessable<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Potential misuse of RISC signals<o:p></o:p></p>
<p class="MsoNormal"> DOS attacks may be possible<o:p></o:p></p>
<p class="MsoNormal"> If you have the IdPs issuer key, that’s a much bigger problem than being able to send RISC signals<o:p></o:p></p>
<p class="MsoNormal"> Mark: I wanted to make sure that deliberate misuse was considered as we develop RISC<o:p></o:p></p>
<p class="MsoNormal"> Stan: Also, what if there’s a bug and a lot of events are sent that didn’t actually happen?<o:p></o:p></p>
<p class="MsoNormal"> Stan: Whether to notify users of problems and how to needs careful consideration?<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: It might not be productive to tell users that an action was triggered by a security event<o:p></o:p></p>
<p class="MsoNormal"> Adam: Do we want an “undo” operation?<o:p></o:p></p>
<p class="MsoNormal"> Mike: Having “undo” would result in a state explosion and additional complexity<o:p></o:p></p>
<p class="MsoNormal"> Marius: We need a counterpart to “account credential change required”<o:p></o:p></p>
<p class="MsoNormal"> Such as “account credential changed”<o:p></o:p></p>
<p class="MsoNormal"> Marius: Having an “account rolled back” event may be useful in some circumstances<o:p></o:p></p>
<p class="MsoNormal"> Adam: I’m not aware of actual account rollback implementations<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Enrollment of Linked ID<o:p></o:p></p>
<p class="MsoNormal"> There may be multiple identifiers associated with an account<o:p></o:p></p>
<p class="MsoNormal"> Such as multiple e-mail addresses<o:p></o:p></p>
<p class="MsoNormal"> Mark: These probably should be handled as multiple subscriptions<o:p></o:p></p>
<p class="MsoNormal"> Marius: Two Google accounts using the same hotmail address<o:p></o:p></p>
<p class="MsoNormal"> Microsoft might not know which Google account the event about the hotmail account pertains to<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: Phone number and e-mail address are not unique identifiers at the sender<o:p></o:p></p>
<p class="MsoNormal"> Ambiguity is possible in these circumstances<o:p></o:p></p>
<p class="MsoNormal"> Marius: We might need to add a directed identifier to disambiguate which account the event pertains to<o:p></o:p></p>
<p class="MsoNormal"> Mike: We would want the actual risk teams involved in specifying any of this<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: This might be more pertinent to identity use cases than RISC use cases<o:p></o:p></p>
<p class="MsoNormal"> Adam: Should we consider representing information like this to the subject identifier?<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: Once there’s a clear need for that that’s been demonstrated<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Stream Deletion<o:p></o:p></p>
<p class="MsoNormal"> Marius: There is currently no mechanism for clients to delete streams<o:p></o:p></p>
<p class="MsoNormal"> They will want this if they want to stop receiving events<o:p></o:p></p>
<p class="MsoNormal"> I am considering adding an HTTP DELETE verb<o:p></o:p></p>
<p class="MsoNormal"> People felt like it was too early to do this now<o:p></o:p></p>
<p class="MsoNormal"> Marius will send an e-mail about this<o:p></o:p></p>
<p class="MsoNormal"> Marius: Statuses of the stream are currently Enabled, Disabled, Paused<o:p></o:p></p>
<p class="MsoNormal"> Roshni thought that Suspended might be a better name for Disabled<o:p></o:p></p>
<p class="MsoNormal"> Mike: “Suspended” is bad because it has two meanings in English<o:p></o:p></p>
<p class="MsoNormal"> Mark: Is it even reasonable to ask the sender to buffer messages for paused receivers?<o:p></o:p></p>
<p class="MsoNormal"> Annabelle: We’ll have to determine this based on implementation and deployment experience<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Use Cases<o:p></o:p></p>
<p class="MsoNormal"> Marius has an action item to create a RISC use cases document and submit it to the RISC working group<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Change of Control Events<o:p></o:p></p>
<p class="MsoNormal"> Marius: A redirect_uri can go bad if the domain it’s located within expires<o:p></o:p></p>
<p class="MsoNormal"> Adam: Domain expiration is public information<o:p></o:p></p>
<p class="MsoNormal"> Marius: Selling a domain is a gray area<o:p></o:p></p>
<p class="MsoNormal"> Adam: This may or may not have security implications<o:p></o:p></p>
<p class="MsoNormal"> For instance, Facebook acquiring Instagram<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Dashes and Underscores<o:p></o:p></p>
<p class="MsoNormal"> Marius: When should we be using dashes versus underscores in names?<o:p></o:p></p>
<p class="MsoNormal"> Mike: URIs tend to use dashes for historical reasons<o:p></o:p></p>
<p class="MsoNormal"> Mike: Names for JSON objects should use underscores<o:p></o:p></p>
<p class="MsoNormal"> Names for subject identifiers (which use JSON) should use underscores rather than dashes<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>