Subject: Re: [Id-event] [Openid-specs-risc] Breaking out the distribution draft

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 1 Mar 2017 09:08:59 -0800

I think it is fine. 

The catch is that for this to work there has to be bi-directional data streams which in the case of RISC seems true. 

I don't see this as impacting the SEC EVENTs work other than as a use case. 

Phil

> On Feb 28, 2017, at 10:24 PM, Adam Dawes <[email-masked]> wrote:
> 
> Thanks for bringing this up Dick. I think you're worried about, when [email-masked] signs up for an account at Amazon, how would Amazon register to get events from Google. I think we can deal with this if Amazon sends a SET token to google with an "account created" event which would then create a registration at google for Amazon to receive events about alice@.
> 
> I think it is totally reasonable to think of account creation as a notifiable event. And in typical RISC fashion, it is up to the recipient to do what it will with the events. From Google's perspective, we would white list a set of partners where we have contracts to enable implicit registration. I think we should work out some response codes to make it clear to the sender whether the registration succeeded.
> 
> We didn't talk a lot about this in the F2F but is an idea that I had in my deck and I think it came up in Phil and my conversation last week. Phil, does the above give you any concerns? 
> 
>> On Tue, Feb 28, 2017 at 9:12 AM, Phil Hunt (IDM) <[email-masked]> wrote:
>> RISC use case is typically bi-directional so events can be used. It also works better because usually a receiver may add only or drop only depending on implicit or explicit federation. 
>> 
>> Adam argued for all other update items to be done OOB.  
>> 
>> That just left error signalling for the receiver to find out why events were not coming. 
>> 
>> We left it that scim can be quickly added for those that want full automated CRUD (oracle does). Buy it would not be required in core. 
>> 
>> Phil
>> 
>>> On Feb 28, 2017, at 8:32 AM, Hardt, Dick <[email-masked]> wrote:
>>> 
>>> Perhaps I am missing it, but I don’t see a mechanism for the receiver to add / delete which subjects the receiver is interested in. Is this not included, or am I misunderstanding what is below?
>>> 
>>>  
>>> 
>>> Or is that out of scope? If so, that seems odd as there is a control plane API in (3)
>>> 
>>>  
>>> 
>>> /Dick
>>> 
>>>  
>>> 
>>>  
>>> 
>>> On 2/28/17, 12:53 AM, someone claiming to be "Openid-specs-risc on behalf of Adam Dawes" <[email-masked] on behalf of [email-masked]> wrote:
>>> 
>>>  
>>> 
>>> I think this is great Phil. Thanks again for the detailed conversation where we were able to arrive at this.
>>> 
>>>  
>>> 
>>> On Mon, Feb 27, 2017 at 1:35 PM, Phil Hunt <[email-masked]> wrote:
>>> 
>>> Please confirm if you agree with the following:
>>> 
>>>  
>>> 
>>> I had previously promised to break up the distribution draft into components. I ran into some difficulty as to how subscribers (receivers) of events find out if the publisher is having problems delivering events. 
>>> 
>>>  
>>> 
>>> After some discussion with the RISC WG folks and Adam Dawes, I would like to propose that I break out a SET Transmission draft that includes the following:
>>> 
>>>  
>>> 
>>> 1.  Basic HTTPS POST profile to a specified endpoint.  It is up to the receiver to provide fault tolerance and high-availability that meets its own delivery assurance requirements.
>>> 
>>> 2.  A set of metadata that describes the endpoints, the encryption methods (eg. keys for signing and encrypting JWTs) etc.
>>> 
>>> 3.  A simple control plane API that allows a subscriber (receiver) to perform an HTTPS GET to obtain the current configuration and subscription (stream) status.  While compatible with SCIM, it will NOT require SCIM to be implemented. 
>>> 
>>> 4.  Configuration of subscriptions (streams) is done through out-of-scope administrative processes offered by event publishers.
>>> 
>>> 5.  In the initial profile, subscribers will not be able to “pause” streams automatically unless offered through the administrative interface of the publisher.
>>> 
>>>  
>>> 
>>> If people have a need for automated management, the basic idea is that you implement the POST and PATCH methods of SCIM and you are good to go. We don’t need to spend a lot of time on it as there is nothing special to do once the metadata for streams is defined.
>>> 
>>>  
>>> 
>>> Does this work for everyone?
>>> 
>>>  
>>> 
>>> Phil
>>> 
>>>  
>>> 
>>> Oracle Corporation, Identity Cloud Services & Identity Standards
>>> 
>>> @independentid
>>> 
>>> www.independentid.com
>>> 
>>> [email-masked]
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> 
>>> _______________________________________________
>>> Id-event mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/id-event
>>> 
>>> 
>>> 
>>> 
>>>  
>>> 
>>> --
>>> 
>>> Adam Dawes | Sr. Product Manager | [email-masked] | +1 650-214-2410
>>> 
>>>  
>>> 
> 
> 
> 
> -- 
> Adam Dawes | Sr. Product Manager | [email-masked] | +1 650-214-2410
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: "Hardt, Dick" <[email-masked]>
Date: Thu, 2 Mar 2017 00:46:39 +0000

Mixing control plane and data plane is very concerning to me.

That is considered an anti-pattern in AWS. It complicates development, security and operations.

/Dick

On 2/28/17, 10:24 PM, someone claiming to be "Adam Dawes" <[email-masked]<mailto:[email-masked]>> wrote:

Thanks for bringing this up Dick. I think you're worried about, when [email-masked]<mailto:[email-masked]> signs up for an account at Amazon, how would Amazon register to get events from Google. I think we can deal with this if Amazon sends a SET token to google with an "account created" event which would then create a registration at google for Amazon to receive events about alice@.

On Tue, Feb 28, 2017 at 9:12 AM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
RISC use case is typically bi-directional so events can be used. It also works better because usually a receiver may add only or drop only depending on implicit or explicit federation.

Phil

On Feb 28, 2017, at 8:32 AM, Hardt, Dick <[email-masked]<mailto:[email-masked]>> wrote:
Perhaps I am missing it, but I don’t see a mechanism for the receiver to add / delete which subjects the receiver is interested in. Is this not included, or am I misunderstanding what is below?

/Dick

On 2/28/17, 12:53 AM, someone claiming to be "Openid-specs-risc on behalf of Adam Dawes" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On Mon, Feb 27, 2017 at 1:35 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Please confirm if you agree with the following:

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

--
Adam Dawes | Sr. Product Manager | [email-masked]<mailto:[email-masked]> | +1 650-214-2410<tel:(650)%20214-2410>

--
Adam Dawes | Sr. Product Manager | [email-masked]<mailto:[email-masked]> | +1 650-214-2410

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 1 Mar 2017 19:06:31 -0800

Depends on what you are expressing. If you are saying amazon has an interest in subject x, it is an event compatible with data plane. 

If you are saying amazon wants oracle to deliver events on subject x, that is a command and must be part of control. 

The problem is that no party should be forced to disclosed events because a third party says so. They must get consent from their subject. We should get legal to confirm this. 

My thought is that the event causes the receiver to subsequently confirm with the user for permission. 

Phil

> On Mar 1, 2017, at 4:46 PM, Hardt, Dick <[email-masked]> wrote:
> 
> On 2/28/17, 10:24 PM, someone claiming to be "Adam Dawes" <[email-masked]> wrote:
>

---

From: "Hardt, Dick" <[email-masked]>
Date: Thu, 2 Mar 2017 03:32:36 +0000

If Amazon says it no longer wants any events from oracle on subject X, that is clearly a command.

/Dick

On 3/1/17, 7:06 PM, someone claiming to be "Phil Hunt (IDM)" <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On Mar 1, 2017, at 4:46 PM, Hardt, Dick <[email-masked]<mailto:[email-masked]>> wrote:
Mixing control plane and data plane is very concerning to me.

/Dick

Phil

/Dick

Phil

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 1 Mar 2017 19:45:52 -0800

Right. 

But it can also be expressed as the issuer is not interested in events on subject x. The expectation is that the receiver than decides to remove the subject from the reciprocating feed. However it is not a command. 

It is the same subtle difference that the logout spec has. It is saying "this service provider has canceled sid y for subject x". The expectation is that the receiver cancels their local session z.

Phil

> On Mar 1, 2017, at 7:32 PM, Hardt, Dick <[email-masked]> wrote:
> 
> On 3/1/17, 7:06 PM, someone claiming to be "Phil Hunt (IDM)" <[email-masked]> wrote:
>

---

From: Adam Dawes <[email-masked]>
Date: Thu, 2 Mar 2017 00:01:03 -0800

> that is clearly a command.

I'm trying to understand that that really means. Amazon agrees that it will
no longer look for any 3rd party signals related to account security for
that user? Does that mean Amazon is no longer interested in password dumps
that are on the internet to try to better secure the account? That doesn't
seem to make any sense.

I understand you are trying to get at some privacy choice expressed by the
user on Amazon. I think that's the wrong model. The privacy event happens
with the Transmitter and that's where the user's preference to not disclose
to 3rd parties should take place. I think the actual RISC event of interest
that corresponds to your use case Dick, is email address changed or account
deleted at Amazon. Those are totally valid RISC signals and it would be
fully appropriate for the Transmitter to no longer send info about that
user to Amazon anymore.

I understand that we're kind of mixing the control plane and data plane
here. But going back to past conversations, the idea was that both
Transmitters and Receivers weren't compelled to do anything in particular.
I think this is more feature than bug.

> Depends on what you are expressing. If you are saying amazon has an
> interest in subject x, it is an event compatible with data plane.
>
>
>
> If you are saying amazon wants oracle to deliver events on subject x, that
> is a command and must be part of control.
>
>
>
> The problem is that no party should be forced to disclosed events because
> a third party says so. They must get consent from their subject. We should
> get legal to confirm this.
>
>
>
> Thanks for bringing this up Dick. I think you're worried about, when
> [email-masked] signs up for an account at Amazon, how would Amazon
> register to get events from Google. I think we can deal with this if Amazon
> sends a SET token to google with an "account created" event which would
> then create a registration at google for Amazon to receive events about
> alice@.
>
>
>
> I think it is totally reasonable to think of account creation as a
> notifiable event. And in typical RISC fashion, it is up to the recipient to
> do what it will with the events. From Google's perspective, we would white
> list a set of partners where we have contracts to enable implicit
> registration. I think we should work out some response codes to make it
> clear to the sender whether the registration succeeded.
>
>
>
> We didn't talk a lot about this in the F2F but is an idea that I had in my
> deck and I think it came up in Phil and my conversation last week. Phil,
> does the above give you any concerns?
>
>
>
> RISC use case is typically bi-directional so events can be used. It also
> works better because usually a receiver may add only or drop only depending
> on implicit or explicit federation.
>
>
>
> We left it that scim can be quickly added for those that want full
> automated CRUD (oracle does). Buy it would not be required in core.
>
> Phil
>
>
> Perhaps I am missing it, but I don’t see a mechanism for the receiver to
> add / delete which subjects the receiver is interested in. Is this not
> included, or am I misunderstanding what is below?
>
>
>
> On 2/28/17, 12:53 AM, someone claiming to be "Openid-specs-risc on behalf
> of Adam Dawes" <[email-masked] on behalf of
> [email-masked]> wrote:
>
>
>
> I had previously promised to break up the distribution draft into
> components. I ran into some difficulty as to how subscribers (receivers) of
> events find out if the publisher is having problems delivering events.
>
>
>
> After some discussion with the RISC WG folks and Adam Dawes, I would like
> to propose that I break out a SET Transmission draft that includes the
> following:
>
>
>
> 1.  Basic HTTPS POST profile to a specified endpoint.  It is up to the
> receiver to provide fault tolerance and high-availability that meets its
> own delivery assurance requirements.
>
> 2.  A set of metadata that describes the endpoints, the encryption methods
> (eg. keys for signing and encrypting JWTs) etc.
>
> 3.  A simple control plane API that allows a subscriber (receiver) to
> perform an HTTPS GET to obtain the current configuration and subscription
> (stream) status.  While compatible with SCIM, it will NOT require SCIM to
> be implemented.
>
> 4.  Configuration of subscriptions (streams) is done through out-of-scope
> administrative processes offered by event publishers.
>
> 5.  In the initial profile, subscribers will not be able to “pause”
> streams automatically unless offered through the administrative interface
> of the publisher.
>
>
>
> If people have a need for automated management, the basic idea is that you
> implement the POST and PATCH methods of SCIM and you are good to go. We
> don’t need to spend a lot of time on it as there is nothing special to do
> once the metadata for streams is defined.
>
>
>
> <(650)%20214-2410>
> <(650)%20214-2410>

---

From: "Hardt, Dick" <[email-masked]>
Date: Thu, 2 Mar 2017 21:04:23 +0000

Sorry I did not include my use cases and am making you dig for them.

You have described the two use cases:

1)       User has opted out of Amazon and Google exchanging information. We want to tell Google we will no longer be sending signals, and ask Google to no longer send us signals.

2)       User has removed the email address from their Amazon account. Again, we want to let Google know we will no longer be sending signals, and that we no longer want Google to send us signals.

As for why do we need to tell Google to not send us signals, we do not want to receive information we should not see. A tenant of security is to not have access to something you don’t need. We would prefer to not receive the signal, rather than have to filter it out and drop it. We want to minimize the information we get. There are nuances about why that are not appropriate for discussion publicly.

/Dick

On 3/2/17, 12:01 AM, someone claiming to be "Adam Dawes" <[email-masked]<mailto:[email-masked]>> wrote:

[mage removed by sender.]

On Wed, Mar 1, 2017 at 7:32 PM, Hardt, Dick <[email-masked]<mailto:[email-masked]>> wrote:
If Amazon says it no longer wants any events from oracle on subject X, that is clearly a command.

I'm trying to understand that that really means. Amazon agrees that it will no longer look for any 3rd party signals related to account security for that user? Does that mean Amazon is no longer interested in password dumps that are on the internet to try to better secure the account? That doesn't seem to make any sense.

I understand you are trying to get at some privacy choice expressed by the user on Amazon. I think that's the wrong model. The privacy event happens with the Transmitter and that's where the user's preference to not disclose to 3rd parties should take place. I think the actual RISC event of interest that corresponds to your use case Dick, is email address changed or account deleted at Amazon. Those are totally valid RISC signals and it would be fully appropriate for the Transmitter to no longer send info about that user to Amazon anymore.

I understand that we're kind of mixing the control plane and data plane here. But going back to past conversations, the idea was that both Transmitters and Receivers weren't compelled to do anything in particular. I think this is more feature than bug.

/Dick

Phil

/Dick

Phil

/Dick

Phil

---

From: Phil Hunt <[email-masked]>
Date: Thu, 2 Mar 2017 13:55:07 -0800

So, in both cases, what Adam says works with eventing principles.  In your case, you would issue an event along the lines of Subject personal identifier added or removed. 

For example, if [email-masked] registered with Amazon, you would figure out that Oracle,com will want to know, if the user (me) gave Amazon the consent, my profile would be added to the Amazon->Oracle feed.  Amazon then immediately sends the identifier (or account) added event to Oracle.com.   Notice that the event is simply a notification that a subject has changed state AT amazon. It is in no way a command.

Then, upon receiving the event from Amazon, Oracle.com is informed that the Subject personal identifier ([email-masked]) was added at Amazon. The Oracle system consults local policy, obtains consent if necessary and then adds [email-masked] to the reciprocating feed for Amazon.

When I close my account at Amazon, the exact same process occurs. Amazon issues an account closed notification (or just identifier removed).  Oracle clears the subject from its reciprocating feed if appropriate.  Oracle may also make other conclusion.
 
AN IMPORTANT OBSERVATION:  Adam has talked about how the addition of an identifier (e.g. an email address) is also itself a security event because hackers will often do this.  So in this example, Oracle (the IDP for [email-masked]) may also mark my account as potentially under attack for a period of time in its own security system.

This is an example of the power of eventing.  Rather than sending a command from Amazon to Oracle, Amazon simply states a fact that has occurred in its own domain and the receiver and draw its own conclusions to act upon it. In this case, the relationship is identified and the feeds are updated, but ALSO the security systems are notified in case [email-masked] has been hijacked.

Have I got this right Adam?

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Mar 2, 2017, at 1:04 PM, Hardt, Dick <[email-masked]> wrote:
> 
> On 3/2/17, 12:01 AM, someone claiming to be "Adam Dawes" <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 
>  
> On Wed, Mar 1, 2017 at 7:32 PM, Hardt, Dick <[email-masked] <mailto:[email-masked]>> wrote:
> On 3/1/17, 7:06 PM, someone claiming to be "Phil Hunt (IDM)" <[email-masked] <mailto:[email-masked]>> wrote:
>  
> On Mar 1, 2017, at 4:46 PM, Hardt, Dick <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On 2/28/17, 10:24 PM, someone claiming to be "Adam Dawes" <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Thanks for bringing this up Dick. I think you're worried about, when [email-masked] <mailto:[email-masked]> signs up for an account at Amazon, how would Amazon register to get events from Google. I think we can deal with this if Amazon sends a SET token to google with an "account created" event which would then create a registration at google for Amazon to receive events about alice@. 
>  
> On Tue, Feb 28, 2017 at 9:12 AM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
> On Feb 28, 2017, at 8:32 AM, Hardt, Dick <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On 2/28/17, 12:53 AM, someone claiming to be "Openid-specs-risc on behalf of Adam Dawes" <[email-masked] <mailto:[email-masked]> on behalf [email-masked] <mailto:[email-masked]>> wrote:
>  
> On Mon, Feb 27, 2017 at 1:35 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> www.independentid.com <http://www.independentid.com/>
> [email-masked] <mailto:[email-masked]>
>  
>  
>  
>  
>  
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
> 
> 
>  
> -- 
> Adam Dawes | Sr. Product Manager | [email-masked] <mailto:[email-masked]> | +1 650-214-2410 <tel:(650)%20214-2410>
>  
> 
> 
>  
> -- 
> Adam Dawes | Sr. Product Manager | [email-masked] <mailto:[email-masked]> | +1 650-214-2410 <tel:(650)%20214-2410>
>  
> 
> 
>  
> -- 
> Adam Dawes | Sr. Product Manager | [email-masked] <mailto:[email-masked]> | +1 650-214-2410
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>

---

From: "Hardt, Dick" <[email-masked]>
Date: Fri, 3 Mar 2017 02:16:13 +0000

If we were not dealing with bad guys, then this could work, but we are. Let me explain.

The bad guy gets access to the user’s account, and the first thing he does is disable sharing between Amazon and Google.

Amazon sends an event to Google saying that the user has disabled sharing. This is a very useful signal to Google for detecting account take over, as this is a behavior that may happen when an account is taken over.

According to your design though, at this time, Google will no longer send events to Amazon, and Amazon should no longer send events to Google since we have made the control signal of stopping sharing (control plane) to be implicit in this security event signal (data plane).

Now, Amazon no longer sees any events from Google, and will no longer send events to Google – at PRECISELY the time when the two of them need to be sharing security events since the account has been compromised.

If we have a separate control plane, then when the user disables sharing, Amazon can tell the user they will stop sharing in X time to enable Amazon to continue to protect the user for that period in case disabling was unauthorized. Amazon will send Google the message that sharing was disabled on the data plane, and X time later will send Google a control plane message to disable sharing.

/Dick

On 3/2/17, 1:55 PM, someone claiming to be "Phil Hunt" <[email-masked]<mailto:[email-masked]>> wrote:

For example, if [email-masked]<mailto:[email-masked]> registered with Amazon, you would figure out that Oracle,com will want to know, if the user (me) gave Amazon the consent, my profile would be added to the Amazon->Oracle feed.  Amazon then immediately sends the identifier (or account) added event to Oracle.com<http://oracle.com>.   Notice that the event is simply a notification that a subject has changed state AT amazon. It is in no way a command.

Then, upon receiving the event from Amazon, Oracle.com<http://oracle.com> is informed that the Subject personal identifier ([email-masked]<mailto:[email-masked]>) was added at Amazon. The Oracle system consults local policy, obtains consent if necessary and then adds [email-masked]<mailto:[email-masked]> to the reciprocating feed for Amazon.

AN IMPORTANT OBSERVATION:  Adam has talked about how the addition of an identifier (e.g. an email address) is also itself a security event because hackers will often do this.  So in this example, Oracle (the IDP for [email-masked]<mailto:[email-masked]>) may also mark my account as potentially under attack for a period of time in its own security system.

This is an example of the power of eventing.  Rather than sending a command from Amazon to Oracle, Amazon simply states a fact that has occurred in its own domain and the receiver and draw its own conclusions to act upon it. In this case, the relationship is identified and the feeds are updated, but ALSO the security systems are notified in case [email-masked]<mailto:[email-masked]> has been hijacked.

Phil

On Mar 2, 2017, at 1:04 PM, Hardt, Dick <[email-masked]<mailto:[email-masked]>> wrote:

/Dick

/Dick

Phil

/Dick

Phil

/Dick

On 2/28/17, 12:53 AM, someone claiming to be "Openid-specs-risc on behalf of Adam Dawes" <[email-masked]<mailto:[email-masked]> on behalf [email-masked]<mailto:[email-masked]>> wrote:

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Sat, 4 Mar 2017 12:42:36 -0800

Dick,

The idea that an issuer might have been compromised/tricked/whatever by a bad actor is exactly is why commands through the control plane are bad. 

Receivers have to assume that Events simply state changes that have occurred within the issuer (e.g. Amazon). The receiver is always free to question the event (e.g. was amazon fooled, was it a symptom).  I believe the controller of an identity information (a transmitter) is always responsible to the user on disclosure and needs to have consent and act based on its own conclusions.  If Amazon sent Google (or anyone else) a signal, I would expect Google to accept the event and make a risk judgement independently.  They might:

* Process the event and adjust feeds
* Process the event and mark the account at risk for a period of time
* Ignore the event
* Seek confirmation from the user directly first
* Wait a period of time before actually removing the user from the feed in case recovery is needed or subsequent suspicious activity occurs.

This is the kind of event-sequence scenario that I expect the RISC WG will be sorting through.

Because of the fact that receivers must make judgement calls, it is better not to issue commands.  The receiver must always reconcile the event based on what it knows of the subject and take independent action.  This is the very thing that makes an event different from a command.  An event signals something that has occurred within the context of the issuer, and the receiver takes independent action upon notification.  IMO, that’s exactly what your case demands.

Phil

> On Mar 2, 2017, at 6:16 PM, Hardt, Dick <[email-masked]> wrote:
> 
> On 3/2/17, 1:55 PM, someone claiming to be "Phil Hunt" <[email-masked] <mailto:[email-masked]>> wrote:
>  
> For example, if [email-masked] <mailto:[email-masked]> registered with Amazon, you would figure out that Oracle,com will want to know, if the user (me) gave Amazon the consent, my profile would be added to the Amazon->Oracle feed.  Amazon then immediately sends the identifier (or account) added event to Oracle.com <http://oracle.com/>.   Notice that the event is simply a notification that a subject has changed state AT amazon. It is in no way a command.
>  
> Then, upon receiving the event from Amazon, Oracle.com <http://oracle.com/> is informed that the Subject personal identifier ([email-masked] <mailto:[email-masked]>) was added at Amazon. The Oracle system consults local policy, obtains consent if necessary and then adds [email-masked] <mailto:[email-masked]> to the reciprocating feed for Amazon.
>  
> AN IMPORTANT OBSERVATION:  Adam has talked about how the addition of an identifier (e.g. an email address) is also itself a security event because hackers will often do this.  So in this example, Oracle (the IDP for [email-masked] <mailto:[email-masked]>) may also mark my account as potentially under attack for a period of time in its own security system.
>  
> This is an example of the power of eventing.  Rather than sending a command from Amazon to Oracle, Amazon simply states a fact that has occurred in its own domain and the receiver and draw its own conclusions to act upon it. In this case, the relationship is identified and the feeds are updated, but ALSO the security systems are notified in case [email-masked] <mailto:[email-masked]> has been hijacked.
>  
> On Mar 2, 2017, at 1:04 PM, Hardt, Dick <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Hardt, Dick" <[email-masked]>
Date: Mon, 6 Mar 2017 00:20:40 +0000

Hi Phil

I’m not following your logic below. Let me know what is wrong in the following:

When Amazon sends Google an event, we only want them to put that into their risk analysis. It is just bad design to have the event have another, unintended, or unknown side effect.

When Amazon sends Google a control signal to start or stop sending messages, I expect them to stop or start sending messages.

Mixing those two concepts is going to lead to lots of confusion on expectations of what will happen. For example, if for reasons unknown to Amazon, we just stop getting messages from Google, that sounds super difficult to debug, particularly at scale.

If your real concern is that you don’t want to write a specification for the control plane, that is a different discussion. I’m certain we can find someone else to do the work, and I appreciate that if it is not important to Oracle, then you would have little incentive to do that work. No worries.

/Dick

On 3/4/17, 12:42 PM, someone claiming to be "Phil Hunt" <[email-masked]<mailto:[email-masked]>> wrote:

Dick,

Phil

On Mar 2, 2017, at 6:16 PM, Hardt, Dick <[email-masked]<mailto:[email-masked]>> wrote:

/Dick

For example, if [email-masked]<mailto:[email-masked]> registered with Amazon, you would figure out that Oracle,com will want to know, if the user (me) gave Amazon the consent, my profile would be added to the Amazon->Oracle feed.  Amazon then immediately sends the identifier (or account) added event to Oracle.com<http://oracle.com/>.   Notice that the event is simply a notification that a subject has changed state AT amazon. It is in no way a command.

Then, upon receiving the event from Amazon, Oracle.com<http://oracle.com/> is informed that the Subject personal identifier ([email-masked]<mailto:[email-masked]>) was added at Amazon. The Oracle system consults local policy, obtains consent if necessary and then adds [email-masked]<mailto:[email-masked]> to the reciprocating feed for Amazon.

Phil

/Dick

/Dick

Phil

/Dick

Phil

/Dick

Phil

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Sun, 5 Mar 2017 17:43:27 -0800

I am just following your logic. Because amazon might be fooled (eg stolen session), google must make its own decision about a state change occurring at amazon. Eg a session cookie may have been copied and is now weilded by an attacker. 

Making a command format means google must comply and amazon is claiming it cannot be fooled. That means the breach is propagted. We do not want that. 

I am saying control api is just for the stream config and its access mgmt. 

The data plane is about the subject state change signals. 

Your usecase is a subject state change which can be called into question and is clearly part of the duplexed data plane. 

Phil

> On Mar 5, 2017, at 4:20 PM, Hardt, Dick <[email-masked]> wrote:
> 
> Hi Phil
>  
> On 3/4/17, 12:42 PM, someone claiming to be "Phil Hunt" <[email-masked]> wrote:
>  
> Dick,
>  
> On 3/2/17, 1:55 PM, someone claiming to be "Phil Hunt" <[email-masked]> wrote:
>  
> On 3/2/17, 12:01 AM, someone claiming to be "Adam Dawes" <[email-masked]> wrote:
>  
>  
> On 2/28/17, 12:53 AM, someone claiming to be "Openid-specs-risc on behalf of Adam Dawes" <[email-masked] on behalf [email-masked]> wrote:
>

---

From: Adam Dawes <[email-masked]>
Date: Mon, 6 Mar 2017 00:00:24 -0800

I want to make another argument for subscription management to happen
within the data channel. The main case where we expect to be a publisher of
RISC signals is through explicit OAuth relationships. We intend to send
RISC signals to the applications we know the user uses as evidenced by an
OAuth (including SSO) relationship.

In this case, I think it adds significant overhead to separate the control
plane from the data plane. We expect that in most large consumer SSO
scenarios like ours, most recipients sites will simply want to set up an
end point to receive security signals from IDPs like us and won't bother to
publish signals back. This is totally fine with us as we don't think there
are large numbers of parties that would be able to provide risk signals of
quality and lowering the effort will increase adoption for these
RP/receivers when they don't have to build a control plane to simply
receive signals.

Furthermore, I think it would be confusing for us to support two different
subscription management models, one via OAuth grants where subscription
happens with the life of the token and another model where the underlying
account events and subscription management happen asynchronously.

On Sun, Mar 5, 2017 at 5:43 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

> I am just following your logic. Because amazon might be fooled (eg stolen
> session), google must make its own decision about a state change occurring
> at amazon. Eg a session cookie may have been copied and is now weilded by
> an attacker.
>
> Making a command format means google must comply and amazon is claiming it
> cannot be fooled. That means the breach is propagted. We do not want that.
>
> Your usecase is a subject state change which can be called into question
> and is clearly part of the duplexed data plane.
>
> Phil
>
> When Amazon sends Google an event, we only want them to put that into
> their risk analysis. It is just bad design to have the event have another,
> unintended, or unknown side effect.
>
>
>
> When Amazon sends Google a control signal to start or stop sending
> messages, I expect them to stop or start sending messages.
>
>
>
> Mixing those two concepts is going to lead to lots of confusion on
> expectations of what will happen. For example, if for reasons unknown to
> Amazon, we just stop getting messages from Google, that sounds super
> difficult to debug, particularly at scale.
>
>
>
> >>>>
>
>
>
> If your real concern is that you don’t want to write a specification for
> the control plane, that is a different discussion. I’m certain we can find
> someone else to do the work, and I appreciate that if it is not important
> to Oracle, then you would have little incentive to do that work. No worries.
>
>
>
> /Dick
>
>
>
> The idea that an issuer might have been compromised/tricked/whatever by a
> bad actor is exactly is why commands through the control plane are bad.
>
>
>
> Receivers have to assume that Events simply state changes that have
> occurred within the issuer (e.g. Amazon). The receiver is always free to
> question the event (e.g. was amazon fooled, was it a symptom).  I believe
> the controller of an identity information (a transmitter) is always
> responsible to the user on disclosure and needs to have consent and act
> based on its own conclusions.  If Amazon sent Google (or anyone else) a
> signal, I would expect Google to accept the event and make a risk judgement
> independently.  They might:
>
>
>
> * Wait a period of time before actually removing the user from the feed in
> case recovery is needed or subsequent suspicious activity occurs.
>
>
>
> Because of the fact that receivers must make judgement calls, it is better
> not to issue commands.  The receiver must always reconcile the event based
> on what it knows of the subject and take independent action.  This is the
> very thing that makes an event different from a command.  An event signals
> something that has occurred within the context of the issuer, and the
> receiver takes independent action upon notification.  IMO, that’s exactly
> what your case demands.
>
>
>
>
>
> Phil
>
>
>
> The bad guy gets access to the user’s account, and the first thing he does
> is disable sharing between Amazon and Google.
>
>
>
> Amazon sends an event to Google saying that the user has disabled sharing.
> This is a very useful signal to Google for detecting account take over, as
> this is a behavior that may happen when an account is taken over.
>
>
>
> According to your design though, at this time, Google will no longer send
> events to Amazon, and Amazon should no longer send events to Google since
> we have made the control signal of stopping sharing (control plane) to be
> implicit in this security event signal (data plane).
>
>
>
> Now, Amazon no longer sees any events from Google, and will no longer send
> events to Google – at PRECISELY the time when the two of them need to be
> sharing security events since the account has been compromised.
>
>
>
> If we have a separate control plane, then when the user disables sharing,
> Amazon can tell the user they will stop sharing in X time to enable Amazon
> to continue to protect the user for that period in case disabling was
> unauthorized. Amazon will send Google the message that sharing was disabled
> on the data plane, and X time later will send Google a control plane
> message to disable sharing.
>
>
>
> /Dick
>
>
>
>
>
>
>
>
>
> So, in both cases, what Adam says works with eventing principles.  In your
> case, you would issue an event along the lines of Subject personal
> identifier added or removed.
>
>
>
> For example, if [email-masked] registered with Amazon, you would
> figure out that Oracle,com will want to know, if the user (me) gave Amazon
> the consent, my profile would be added to the Amazon->Oracle feed.  Amazon
> then immediately sends the identifier (or account) added event to
> Oracle.com <http://oracle.com/>.   Notice that the event is simply a
> notification that a subject has changed state AT amazon. It is in no way a
> command.
>
>
>
> Then, upon receiving the event from Amazon, Oracle.com
> <http://oracle.com/> is informed that the Subject personal identifier (
> [email-masked]) was added at Amazon. The Oracle system consults
> local policy, obtains consent if necessary and then adds
> [email-masked] to the reciprocating feed for Amazon.
>
>
>
> When I close my account at Amazon, the exact same process occurs. Amazon
> issues an account closed notification (or just identifier removed).  Oracle
> clears the subject from its reciprocating feed if appropriate.  Oracle may
> also make other conclusion.
>
>
>
> AN IMPORTANT OBSERVATION:  Adam has talked about how the addition of an
> identifier (e.g. an email address) is also itself a security event because
> hackers will often do this.  So in this example, Oracle (the IDP for
> [email-masked]) may also mark my account as potentially under
> attack for a period of time in its own security system.
>
>
>
> This is an example of the power of eventing.  Rather than sending a
> command from Amazon to Oracle, Amazon simply states a fact that has
> occurred in its own domain and the receiver and draw its own conclusions to
> act upon it. In this case, the relationship is identified and the feeds are
> updated, but ALSO the security systems are notified in case
> [email-masked] has been hijacked.
>
>
>
> 1)       User has opted out of Amazon and Google exchanging information.
> We want to tell Google we will no longer be sending signals, and ask Google
> to no longer send us signals.
>
> 2)       User has removed the email address from their Amazon account.
> Again, we want to let Google know we will no longer be sending signals, and
> that we no longer want Google to send us signals.
>
>
>
> As for why do we need to tell Google to not send us signals, we do not
> want to receive information we should not see. A tenant of security is to
> not have access to something you don’t need. We would prefer to not receive
> the signal, rather than have to filter it out and drop it. We want to
> minimize the information we get. There are nuances about why that are not
> appropriate for discussion publicly.
>
>
>
> /Dick
>
>
>
> I'm trying to understand that that really means. Amazon agrees that it
> will no longer look for any 3rd party signals related to account security
> for that user? Does that mean Amazon is no longer interested in password
> dumps that are on the internet to try to better secure the account? That
> doesn't seem to make any sense.
>
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 6 Mar 2017 07:53:28 -0800

I think you are suggesting one way or simplex 

If the receiver wants to tell the issuer to remove or add something the only possible reverse channel is the control plane. 

In the risc case most are duplexed so there is a reverse data plane channel. 

I have been assuming that for idp/rp signaling that no mgmt is needed since idps would filter entities based on audience. IOW they would only issue events based on current active sessions and tokens in flight. But if you want more account state stuff...

The third scenario is SCIM where provisioning signaling is being done. In this case entities in feed are managed via entitlements or a group which either party can update. 

Phil

> On Mar 6, 2017, at 12:00 AM, Adam Dawes <[email-masked]> wrote:
> 
> I want to make another argument for subscription management to happen within the data channel. The main case where we expect to be a publisher of RISC signals is through explicit OAuth relationships. We intend to send RISC signals to the applications we know the user uses as evidenced by an OAuth (including SSO) relationship. 
> 
> In this case, I think it adds significant overhead to separate the control plane from the data plane. We expect that in most large consumer SSO scenarios like ours, most recipients sites will simply want to set up an end point to receive security signals from IDPs like us and won't bother to publish signals back. This is totally fine with us as we don't think there are large numbers of parties that would be able to provide risk signals of quality and lowering the effort will increase adoption for these RP/receivers when they don't have to build a control plane to simply receive signals. 
> 
> Furthermore, I think it would be confusing for us to support two different subscription management models, one via OAuth grants where subscription happens with the life of the token and another model where the underlying account events and subscription management happen asynchronously. 
> 
>> On Sun, Mar 5, 2017 at 5:43 PM, Phil Hunt (IDM) <[email-masked]> wrote:

---

From: "Hardt, Dick" <[email-masked]>
Date: Mon, 6 Mar 2017 15:57:21 +0000

I’m not comfortable talking about the security implications of what we will do on a public list.

When Amazon decides it wants to stop sharing with Google, and wants Google to stop sharing with Amazon, we will be really certain we want that to happen, and we want Google to stop sharing. We then have deterministic behavior, and it is a command.

When Amazon sends an event to Google, Google can process that however they want to process. It is just data.

/Dick

On 3/5/17, 5:43 PM, someone claiming to be "Phil Hunt (IDM)" <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On Mar 5, 2017, at 4:20 PM, Hardt, Dick <[email-masked]<mailto:[email-masked]>> wrote:
Hi Phil

/Dick

Dick,

Phil

/Dick

Phil

/Dick

/Dick

Phil

/Dick

Phil

/Dick

Phil

---

From: "Hardt, Dick" <[email-masked]>
Date: Mon, 6 Mar 2017 16:03:02 +0000

Given your scenario Adam, I did not expect there would be commands in the SSO scenario. What would they be?

From an implementation point of view for peer arrangements as there would be between Google and Amazon, a separate control plane from data plane has a number of implementation advantages.

The data plane is a set of events, and all the receiver needs to do to respond is acknowledge receipt. The event can go in an event bus and be processed at some point in time. It is an asynchronous call.

Commands will expect to change state and report errors. This implies that commands are synchronous.

The implementations for asynchronous vs synchronous calls are quite different, particularly at scale.

/Dick

On 3/6/17, 12:00 AM, someone claiming to be "Adam Dawes" <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Mar 5, 2017 at 5:43 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
I am just following your logic. Because amazon might be fooled (eg stolen session), google must make its own decision about a state change occurring at amazon. Eg a session cookie may have been copied and is now weilded by an attacker.

Phil

/Dick

Dick,

Phil

/Dick

Phil

/Dick

/Dick

Phil

/Dick

Phil

/Dick

Phil