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

Tue Feb 21 06:42:24 UTC 2017

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170220/7ac5627d/attachment.html>