[Openid-specs-risc] subscription/enrolment - why do we need a receiver API for it?

Thu Mar 2 03:48:02 UTC 2017

On Wed, Mar 1, 2017 at 7:31 PM, Hardt, Dick <dick at amazon.com> wrote:

> If it is a control plane mechanism that is changing state, then it is a
> command, and may have an error. Sure, we can ignore any error, but that is
> a subobtimal control plane mechanism.
>
>
>
> Why all the pushback on a separate control plane Phil? Is it because you
> don’t want to write the spec?
>

I started this whole discussion after catching up with emails after a long
while. Not sure there was any pushback, but sending user enrollment
requests as regular SETs came up, I think Adam mentioned that, and I
assumed there was some talk about merging the two channels and requiring
full duplex.

>
>
> /Dick
>
>
>
> On 3/1/17, 7:03 PM, someone claiming to be "Phil Hunt (IDM)" <
> phil.hunt at oracle.com> wrote:
>
>
>
> Based on how we define events, SETs must not be viewed as commands.
>
>
>
> Therefore no errors are possible.
>
>
>
> One party is simply saying it has an interest or not in a subject. The
> receiver of the event may choose to action it deems appropriate.
>
> Phil
>
>
> On Mar 1, 2017, at 4:50 PM, Hardt, Dick <dick at amazon.com> wrote:
>
> This makes sense to me Marius.
>
>
>
> Btw: returning an error when you receive an event you don’t want to accept
> creates some tight coupling that is much more difficult to develop a
> distributed system as you need to look up each event on receipt and forces
> a synchronous architecture.
>
>
>
> /Dick
>
>
>
> On 3/1/17, 3:19 PM, someone claiming to be "Marius Scurtescu" <
> mscurtescu at google.com> wrote:
>
>
>
> Let me try a couple of concrete examples. I am slowly coming back online
> from a longer absence, sorry if I am missing any context.
>
>
>
> 1. Explicit Fed.
>
>
>
> IdP: Google, RP: ACME. User logs into ACME using Google as an IdP and user
> accepts Google presented authz consent page. ACME has Google issued client
> id and refresh token for this user. Google has explicit grant for ACME
> (backing refresh token). ACME has configured RISC either manually (at some
> Google provided management console) or through an API. RISC events are
> flowing both ways, from Google to ACME to the ACME configured endpoint and
> from ACME to Google to Google's documented (maybe also discoverable)
> endpoint.
>
>
>
> By default RISC is enabled both ways but at some point the user decides to
> opt out. The user could opt out at some Google settings page or at some
> ACME settings page.Ideally the opt-out action should disable the flow of
> RISC events in both directions and should be reflected in both settings
> pages. If user opts-out at the Google settings page then Google has to be
> able to communicate this decision to ACME, otherwise ACME will continue to
> send RISC events to Google. I think an API is needed. One cheap and
> imperfect solution is to rely on error messages when sending RISC events,
> once user opted-out Google could send a special error message to ACME when
> ACME sends RISC events and ACME could use this error message to opt-out the
> user on their side. This is imperfect because at least one more event is
> exchanged after the user decided to opt-out. Also, we should consider the
> case where the user decides to opt back in, and it again can be done on
> other settings page and it should be reflected on both. API is needed
> again. The API has to work both ways between Google and ACME.
>
>
>
>
>
> 2. Implicit Fed.
>
>
>
> User creates new Amazon account using gmail address. Amazon makes explicit
> enrollment call to Google and both Amazon and Google start exchanging RISC
> events for this user. Again, user can opt out at a settings page either at
> Google or Amazon and both should stop sending events and also reflect the
> new state in their settings page. Later user can opt back in. Same as with
> Explicit Fed above, I think API is needed.
>
>
>
>
>
> Makes sense?
>
>
>
> Marius
>
>
>
>
>
>
> Marius
>
>
>
> On Thu, Feb 23, 2017 at 9:18 AM, Phil Hunt <phil.hunt at oracle.com> wrote:
>
> 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….
>
>
>
> Summary:
>
> (This is explicit fed, could someone from Google/MS think through the
> email implicit fed case?)
>
>
>
> 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).
>
> * The IDP must have permission to share (presumably from the oauth
> dialog), and
>
> * The Resource service must also have permission to share (presumably at
> least from its registration OR ToS pages).
>
>
>
> For de-registration, the txer may turn off and the receiver may also turn
> off.
>
> ( I remain uneasy about the idea of bi-directional de-registration see
> below for enterprise)
>
>
>
> How to implement it (without an API):
>
>
>
> De-reg could be accomplished for RISC by sec event tokens (that signal
> removal from the feed/stream):
>
> * Account terminated / closed (either at the Resource/relying party or the
> iDP)
>
> * 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
>
> * others?
>
>
>
> 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.
>
>
>
> Enterprise Use Case Concern:
>
>
>
> 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.
>
>
>
> Phil
>
>
>
> Oracle Corporation, Identity Cloud Services & Identity Standards
>
> @independentid
>
> www.independentid.com
>
> phil.hunt at oracle.com
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Feb 21, 2017, at 9:24 AM, Hardt, Dick <dick at amazon.com> wrote:
>
>
>
> I still think that in the explicit fed, we will want to give the user the
> ability to terminate event sharing from either party.
>
>
>
> /Dick
>
>
>
> On 2/20/17, 10:42 PM, someone claiming to be "Phil Hunt (IDM)" <
> phil.hunt at oracle.com> wrote:
>
>
>
> 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.
>
>
>
> Try this...
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> The implicit federation case does seem different than explicit fed.
>
>
>
> 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.
>
>
>
> This could be handled by simple registration event (or personal identifier
> assigned event) SET sent by amazon to yahoo(assuming bi-directional
> transmission).
>
>
> Phil
>
>
> On Feb 20, 2017, at 9:18 PM, Hardt, Dick <dick at amazon.com> wrote:
>
> 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.
>
>
>
> 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.
>
>
>
> /Dick
>
>
>
> On 2/20/17, 8:32 PM, someone claiming to be "Phil Hunt (IDM)" <
> phil.hunt at oracle.com> wrote:
>
>
>
> Right, so in each scenario you describe the consent is with the entity
> transmitting the event. The publisher.
>
>
>
> If the user changes their mind they tell an entity to stop sharing
> events--that makes the entity the transmitter not the receiver.
>
>
>
> Therefore there is no need for an api that lets the receiver override the
> consent the publisher/transmitter has already collected.
>
> Phil
>
>
> On Feb 20, 2017, at 12:48 PM, Hardt, Dick <dick at amazon.com> wrote:
>
>
>
>
>
> On 2/19/17, 5:28 PM, someone claiming to be "Phil Hunt (IDM)" <
> phil.hunt at oracle.com> wrote:
>
>
>
> We are not connecting.
>
>
>
> One more try...
>
>
>
> 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).
>
>
>
> Amazon could ask before sending to the IdP.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> /Dick
>
>
>
>
> On Feb 19, 2017, at 4:36 PM, Hardt, Dick <dick at amazon.com> wrote:
>
> The receiver could signal to the transmitter what the user wants. The
> transmitter could confirm and/or query what the user wants.
>
>
>
> Yes, the transmitter decides if events are transmitted, but one would also
> expect the transmitter to respect the user’s preferences.
>
>
>
> /Dick
>
>
>
> On 2/19/17, 4:08 PM, someone claiming to be "Phil Hunt (IDM)" <
> phil.hunt at oracle.com> wrote:
>
>
>
> Thanks. However, I think the subscribe proposal may be backwards.
>
>
>
> Underlines for better clarity....
>
>
>
> If *transmitter (aka publisher) *expects to let its users (whether rp or
> idp) control whether *transmitter* transmits their events, why would you
> let the receiver control your users info?
>
>
>
> The per user subscription control requirement seems to be the prerogative
> of the transmitter (publisher) and not of the receiver.
>
> Phil
>
>
> On Feb 19, 2017, at 3:16 PM, Hardt, Dick <dick at amazon.com> wrote:
>
> I expect to let users opt out of sharing. I can envision giving the user
> an option to decline security event sharing when federating.
>
>
>
> We will need a standard API to subscribe subjects when we are not
> federating. The amazon.com use case where we are sharing security events
> based on email address.
>
>
>
> /Dick
>
>
>
> On 2/18/17, 3:34 PM, someone claiming to be "Phil Hunt" <
> phil.hunt at oracle.com> wrote:
>
>
>
> More importantly, I have not heard a case where users would be allowed to
> decline security event sharing and still consent to federation.
>
> 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.
>
>
>
> If that is the case I am not sure we need to have a standard api for
> registration of subscriber subjects.
>
>
> Phil
>
>
> On Feb 18, 2017, at 12:04 PM, Hardt, Dick <dick at amazon.com> wrote:
>
> Good question
>
>
>
> 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.
>
> -- Dick
>
>
> On Feb 18, 2017, at 8:55 AM, Phil Hunt <phil.hunt at oracle.com> wrote:
>
> A few questions following Thursday’s F2F…
>
>
>
> 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?
>
>
>
> Why wouldn’t an IDP just put a subject, who has consented to federation,
> in the event list for an audience automatically?
>
>
>
> 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?
>
>
>
> Phil
>
>
>
> Oracle Corporation, Identity Cloud Services & Identity Standards
>
> @independentid
>
> www.independentid.com
>
> phil.hunt at oracle.com
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-risc
>
>
>
>
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-risc
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170301/57a8a7a1/attachment-0001.html>