<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Folks…I’m just trying to digest the thread Dick and I have been having. The following is a summary, and a bit of an exploration on how this might work. I’ve also put in some comments on the enterprise vs. consumer case….</div><div class=""><br class=""></div><div class="">Summary:</div><div class="">(This is explicit fed, could someone from Google/MS think through the email implicit fed case?)<br class=""><div class=""><br class=""></div></div>So, it looks like (at least for OAuth style federation), that only the transmitter can ENABLE notification. This happens at either end (IDP or RP in their transmitter role). <div class="">* The IDP must have permission to share (presumably from the oauth dialog), and </div><div class="">* The Resource service must also have permission to share (presumably at least from its registration OR ToS pages).<div class=""><br class=""></div><div class=""><div class="">For de-registration, the txer may turn off and the receiver may also turn off. </div><div class=""><div class="">( I remain uneasy about the idea of bi-directional de-registration see below for enterprise)</div><div class=""><br class=""></div><div class="">How to implement it (without an API):</div><div class=""><br class=""></div><div class="">De-reg could be accomplished for RISC by sec event tokens (that signal removal from the feed/stream):</div><div class="">* Account terminated / closed (either at the Resource/relying party or the iDP)</div><div class="">* Security Consent Declined (at either end) - if one party issues a security consent declined should the receiver do the same on its transmitter channel? Note that while security consent is declined, the federated delegation consent may remain</div><div class="">* others?</div><div class=""><br class=""></div><div class="">If we structure the de-registration as an event, and follow the semantic meaning of an event (not a command but a statement of fact), then the RP would be saying “I am no longer interested in events for subject: xx”. The IDP, upon receiving the event has to evaluate its own policy and meaning to determine if the user gets de-registered from the stream. In consumer cases, the answer is almost always yes (would some events still be delivered?). In the enterprise case, a de-reg event may trigger other IDM workflows (like de-provisioning) which may or may not result in the subjects removal from the stream.</div><div class=""><br class=""></div><div class="">Enterprise Use Case Concern:</div><div class=""><br class=""></div><div class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; line-height: normal; border-spacing: 0px;"><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""></div></div></div></span></div></div></div></div></div></div><div class="">The reason I remain uneasy about Rcvrs declining consent is that in enterprise cases, there is a larger hub spoke relationship between IDPs and RPs. Many of those RPs will tend to work as part of the same SSO domain. It may not make as much sense of have a single RP suddenly be able to shut down consent for a subject especially when consent is part of employment policy terms.</div><div class=""><br class=""></div><div class="">Phil</div><div class=""><div class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><span class="Apple-style-span" style="border-collapse: separate; line-height: normal; border-spacing: 0px;"><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class=""><br class=""></div><div class="">Oracle Corporation, Identity Cloud Services & Identity Standards</div><div class="">@independentid</div><div class=""><a href="http://www.independentid.com" class="">www.independentid.com</a></div></div></div></div></span><a href="mailto:phil.hunt@oracle.com" class="" style="orphans: 2; widows: 2;">phil.hunt@oracle.com</a></div><div class=""><br class=""></div></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Feb 21, 2017, at 9:24 AM, Hardt, Dick <<a href="mailto:dick@amazon.com" class="">dick@amazon.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class="">I still think that in the explicit fed, we will want to give the user the ability to terminate event sharing from either party.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class="">/Dick<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class=""><o:p class=""> </o:p></span></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">On 2/20/17, 10:42 PM, someone claiming to be "Phil Hunt (IDM)" <<a href="mailto:phil.hunt@oracle.com" style="color: purple; text-decoration: underline;" class="">phil.hunt@oracle.com</a>> wrote:<o:p class=""></o:p></div></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">I think I see the issue now. Implicit and explicit are different in how flows initiate and thus consent/subscription initiates backwards to one-another. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">Try this...<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">In an oauth or oidc flow (explicit fed), the publisher has already obtained consent as part of the authorization dialog. In doing so the publisher adds the user to the feeds associate with the audience of the authorization. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">A user who does not give consent will not be shared at all with amazon. No need for amazon to change override (it should not know about the user). In this scenario, Amazon should not be allowed to override. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">The implicit federation case does seem different than explicit fed. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">With implicit fed, the publisher of the events is not where the initial action takes place (the site where the user gave a personal identifier or email). For example a yahoo user gives amazon their yahoo mail for recovery. Yahoo is the SET publisher for this email address. In this case yahoo needs to be notified. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">This could be handled by simple registration event (or personal identifier assigned event) SET sent by amazon to yahoo(assuming bi-directional transmission). <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><br class="">Phil<o:p class=""></o:p></div></div><div class=""><p class="MsoNormal" style="margin: 0in 0in 12pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';"><br class="">On Feb 20, 2017, at 9:18 PM, Hardt, Dick <<a href="mailto:dick@amazon.com" style="color: purple; text-decoration: underline;" class="">dick@amazon.com</a>> wrote:<o:p class=""></o:p></p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class="">Um, no. My example clearly states that Amazon is going to tell Google to stop sending events. Note that both parties are transmitters and receivers. A good UX for the user is to only have to tell one of them to stop sharing.</span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class=""> </span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class="">What are you trying to convey here? As I stated further down, when there is no explicit consent by the user, we still need an API.</span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class=""> </span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class="">/Dick</span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class=""> </span><o:p class=""></o:p></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class="">On 2/20/17, 8:32 PM, someone claiming to be "Phil Hunt (IDM)" <<a href="mailto:phil.hunt@oracle.com" style="color: purple; text-decoration: underline;" class="">phil.hunt@oracle.com</a>> wrote:<o:p class=""></o:p></div></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class="">Right, so in each scenario you describe the consent is with the entity transmitting the event. The publisher. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class="">If the user changes their mind they tell an entity to stop sharing events--that makes the entity the transmitter not the receiver. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class="">Therefore there is no need for an api that lets the receiver override the consent the publisher/transmitter has already collected. <br class=""><br class="">Phil<o:p class=""></o:p></div></div><div class=""><p class="MsoNormal" style="margin: 0in 0in 12pt 1in; font-size: 12pt; font-family: 'Times New Roman';"><br class="">On Feb 20, 2017, at 12:48 PM, Hardt, Dick <<a href="mailto:dick@amazon.com" style="color: purple; text-decoration: underline;" class="">dick@amazon.com</a>> wrote:<o:p class=""></o:p></p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class=""> </span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class=""> </span><o:p class=""></o:p></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">On 2/19/17, 5:28 PM, someone claiming to be "Phil Hunt (IDM)" <<a href="mailto:phil.hunt@oracle.com" style="color: purple; text-decoration: underline;" class="">phil.hunt@oracle.com</a>> wrote:<o:p class=""></o:p></div></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">We are not connecting. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">One more try...<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">So yes amazon could ask but i am asking why amazon would need to override the consent the user already granted with the transmitter (eg idp). <o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class="">Amazon could ask before sending to the IdP.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">You might ask as an rp if you can share events back to the idp. But again you are the issuer. So you issue events based on whether the user consented in your domain to share back to the idp. Again the idp doesn't need to control your rp issues event stream--at least from a privacy perspective. <o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class="">After the fact, the user could decide she does not want Amazon and Google to share info. That decision could be at either Amazon or Google. If at Amazon, then the RP is calling the IdP to ask it to stop sending signals. This is the only way that the IdP will know the user wanted to stop sharing. Seems like a bad UX for the user to have to go to both the RP and the IdP to stop sharing.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class="">Your orignal question was why do we need a control API. Even if we don’t support the use cases above, it is needed when we are sharing signals based on an email. The IdP does not know the user is at the RP until the RP tells it.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class="">/Dick<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><p class="MsoNormal" style="margin: 0in 0in 12pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';"><br class="">On Feb 19, 2017, at 4:36 PM, Hardt, Dick <<a href="mailto:dick@amazon.com" style="color: purple; text-decoration: underline;" class="">dick@amazon.com</a>> wrote:<o:p class=""></o:p></p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class="">The receiver could signal to the transmitter what the user wants. The transmitter could confirm and/or query what the user wants.</span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class=""> </span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class="">Yes, the transmitter decides if events are transmitted, but one would also expect the transmitter to respect the user’s preferences.</span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class=""> </span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class="">/Dick</span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class=""> </span><o:p class=""></o:p></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">On 2/19/17, 4:08 PM, someone claiming to be "Phil Hunt (IDM)" <<a href="mailto:phil.hunt@oracle.com" style="color: purple; text-decoration: underline;" class="">phil.hunt@oracle.com</a>> wrote:<o:p class=""></o:p></div></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">Thanks. However, I think the subscribe proposal may be backwards. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">Underlines for better clarity....<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">If<span class="Apple-converted-space"> </span><u class="">transmitter (aka publisher) </u>expects to let its users (whether rp or idp) control whether<span class="Apple-converted-space"> </span><u class="">transmitter</u><span class="Apple-converted-space"> </span>transmits their events, why would you let the receiver control your users info?<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">The per user subscription control requirement seems to be the prerogative of the transmitter (publisher) and not of the receiver. <br class=""><br class="">Phil<o:p class=""></o:p></div></div><div class=""><p class="MsoNormal" style="margin: 0in 0in 12pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';"><br class="">On Feb 19, 2017, at 3:16 PM, Hardt, Dick <<a href="mailto:dick@amazon.com" style="color: purple; text-decoration: underline;" class="">dick@amazon.com</a>> wrote:<o:p class=""></o:p></p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class="">I expect to let users opt out of sharing. I can envision giving the user an option to decline security event sharing when federating.</span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class=""> </span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class="">We will need a standard API to subscribe subjects when we are not federating. The<span class="Apple-converted-space"> </span><a href="http://amazon.com/" style="color: purple; text-decoration: underline;" class="">amazon.com</a><span class="Apple-converted-space"> </span>use case where we are sharing security events based on email address.</span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class=""> </span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class="">/Dick</span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="font-size: 11pt; font-family: Calibri;" class=""> </span><o:p class=""></o:p></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">On 2/18/17, 3:34 PM, someone claiming to be "Phil Hunt" <<a href="mailto:phil.hunt@oracle.com" style="color: purple; text-decoration: underline;" class="">phil.hunt@oracle.com</a>> wrote:<o:p class=""></o:p></div></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">More importantly, I have not heard a case where users would be allowed to decline security event sharing and still consent to federation. <br class=""><br class="">The consent we've talked about is part of legal terms in the explicit dialog or of service provider TOS when users supply a foreign recovery email. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">If that is the case I am not sure we need to have a standard api for registration of subscriber subjects. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""><br class="">Phil<o:p class=""></o:p></div></div><div class=""><p class="MsoNormal" style="margin: 0in 0in 12pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';"><br class="">On Feb 18, 2017, at 12:04 PM, Hardt, Dick <<a href="mailto:dick@amazon.com" style="color: purple; text-decoration: underline;" class="">dick@amazon.com</a>> wrote:<o:p class=""></o:p></p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">Good question<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';" class="">When Adam was labeling the implicit and explicit RPs, I originally thought the implicit was the OAuth flow as there was an implicit subscription by the RP of RISC events.<br class=""><br class="">-- Dick<o:p class=""></o:p></div></div><div class=""><p class="MsoNormal" style="margin: 0in 0in 12pt 1.5in; font-size: 12pt; font-family: 'Times New Roman';"><br class="">On Feb 18, 2017, at 8:55 AM, Phil Hunt <<a href="mailto:phil.hunt@oracle.com" style="color: purple; text-decoration: underline;" class="">phil.hunt@oracle.com</a>> wrote:<o:p class=""></o:p></p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class="">A few questions following Thursday’s F2F…<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class="">Is there ever a time in RISC where a user who has chosen to federate would not be added to the stream between providers? And if so, doesn’t the IDP already know this? Why wouldn’t an IDP who is a transmitter just do this automatically? <span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class="">Why wouldn’t an IDP just put a subject, who has consented to federation, in the event list for an audience automatically? <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class="">What purpose does it serve to have the receiver call back to register the subject if the receiver has already agreed to an event stream?<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="" class="">Phil</span><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="" class=""> </span><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="" class="">Oracle Corporation, Identity Cloud Services & Identity Standards</span><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="" class="">@independentid</span><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="" class=""><a href="http://www.independentid.com/" style="color: purple; text-decoration: underline;" class="">www.independentid.com</a></span><o:p class=""></o:p></div></div></div></div></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="" class=""><a href="mailto:phil.hunt@oracle.com" style="color: purple; text-decoration: underline;" class="">phil.hunt@oracle.com</a></span><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="" class=""> </span><o:p class=""></o:p></div></div></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="" class=""> </span><o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="" class=""> </span><o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""><span style="" class=""> </span><o:p class=""></o:p></div></div><p class="MsoNormal" style="margin: 0in 0in 12pt 1in; font-size: 12pt; font-family: 'Times New Roman';"> <o:p class=""></o:p></p></div><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class=""> <o:p class=""></o:p></div></div></div></blockquote><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt 1in; font-size: 12pt; font-family: 'Times New Roman';" class="">_______________________________________________<br class="">Openid-specs-risc mailing list<br class=""><a href="mailto:Openid-specs-risc@lists.openid.net" style="color: purple; text-decoration: underline;" class="">Openid-specs-risc@lists.openid.net</a><br class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-risc" style="color: purple; text-decoration: underline;" class="">http://lists.openid.net/mailman/listinfo/openid-specs-risc</a><o:p class=""></o:p></div></div></blockquote></div></blockquote></div></blockquote></div></blockquote></div></blockquote></div></blockquote></div></div></blockquote></div><br class=""></div></div></div></div></body></html>