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

Hardt, Dick dick at amazon.com
Thu Mar 2 05:03:46 UTC 2017


Ok, that is an interesting perspective Phil. I agree that adding a user is an event, but it also is a command that Amazon wants to get signals from Google on that user. And conversely, we want to send a command that says we don’t want to get signals. We are expecting that we are changing the state in what data we get as opposed to an event that will be used as input to the risk engine. As I stated earlier, those are going to quite different parts of the whole system.

There are also the use cases of Amazon exchanging data with Identity Analytics. We would be exchanging a hash of identities to see if we share a user. If we do, we would return a status that there was a match, and then we would start sharing signals. If we don’t then we would return a status that there was no match. A control plane API aligns better for this interaction.

On 3/1/17, 8:17 PM, someone claiming to be "Phil Hunt (IDM)" <phil.hunt at oracle.com<mailto:phil.hunt at oracle.com>> wrote:

Dick,

You would not be sending an add subject command as an event through the data plane.

What would more likely happen is that amazon would issue an event that subject phil.hunt at oracle.com<mailto:phil.hunt at oracle.com> has been registered as a user to amazon. Oracle upon receiving that event would add phil.hunt at oracle.com<mailto:phil.hunt at oracle.com> to the amazon feed based on policy or consent.

That is a data plane solution that also meets your assertion that crud isn't needed in the control api.

If you disagree we can stick with the current distribution draft that has a restful control api for which all you would need is to add a members attribute to the stream.

Phil

On Mar 1, 2017, at 7:48 PM, Marius Scurtescu <mscurtescu at google.com<mailto:mscurtescu at google.com>> wrote:
On Wed, Mar 1, 2017 at 7:31 PM, Hardt, Dick <dick at amazon.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<http://www.independentid.com>
phil.hunt at oracle.com<mailto:phil.hunt at oracle.com>






On Feb 21, 2017, at 9:24 AM, Hardt, Dick <dick at amazon.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto:dick at amazon.com>> wrote:


On 2/19/17, 5:28 PM, someone claiming to be "Phil Hunt (IDM)" <phil.hunt at oracle.com<mailto: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<mailto: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<mailto: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<mailto: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<http://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<mailto: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<mailto: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<mailto: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<http://www.independentid.com/>
phil.hunt at oracle.com<mailto:phil.hunt at oracle.com>






_______________________________________________
Openid-specs-risc mailing list
Openid-specs-risc at lists.openid.net<mailto: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<mailto: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/20170302/9ef8c70b/attachment-0001.html>


More information about the Openid-specs-risc mailing list