Subject: [Id-event] Ordering of SET events

From: Phil Hunt <[email-masked]>
Date: Tue, 13 Sep 2016 14:56:54 -0700

I think we may need to ensure we have the correct language on how subscribers can order events. Can they strictly depend on the order by which they are received, or can they use “iat”?

The issue is that when SETs are published they may be published by highly distributed systems were it is unreasonable to co-ordinate a sequence number in many cases.  This basically leads us to using timestamps.

Would it be reasonable to use “iat” for this purpose?  Keep in mind, we have discussed that “iat” corresponds to the time of the SET being generated (and optionally signed) and might not be the transaction time.

Do we need some sort of clarifying language on this?

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 13 Sep 2016 17:32:15 -0700

I think the only reasonable statement is that subscribers should not assume
any kind of ordering.

Is there a use case where subscribers care about ordering?

Marius

On Tue, Sep 13, 2016 at 2:56 PM, Phil Hunt <[email-masked]> wrote:

> I think we may need to ensure we have the correct language on how
> subscribers can order events. Can they strictly depend on the order by
> which they are received, or can they use “iat”?
>
> The issue is that when SETs are published they may be published by highly
> distributed systems were it is unreasonable to co-ordinate a sequence
> number in many cases.  This basically leads us to using timestamps.
>
> Would it be reasonable to use “iat” for this purpose?  Keep in mind, we
> have discussed that “iat” corresponds to the time of the SET being
> generated (and optionally signed) and might not be the transaction time.
>
> www.independentid.com
> [email-masked]
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 13 Sep 2016 19:23:57 -0700

>From a protocol perspective, I don't believe it's reasonable to use iat for
ordering purposes.  Either the use-cases demand ordered deliver, in which
case you account for it in protocol and architecture, or they don't.
Trying to approximate it via timestamps isn't the right solution.

---

From: Alan Karp <[email-masked]>
Date: Tue, 13 Sep 2016 19:30:09 -0700

Be careful of relying on timestamps from different machines.  There are
systems, such as Cassandra, that have run into problems.

--------------
Alan Karp

---

From: Phil Hunt <[email-masked]>
Date: Tue, 13 Sep 2016 21:57:33 -0700

I tend to agree. Timestamps are problematic. Yet they can be individually asserted (skew issues aside).  There may  also be different transaction time vs. SET issued at times.  If for performance reasons the feed publisher runs on a separate thread or even a separate server, than transaction time vs. iat may be substantially different. (e.g. 10 mins).

Regarding Marius’s question, the use case probably is important to SCIM Event cases.  Subscribers need to be able to track what order events occurred in.  For example user x was created and then user x was modified.  If those come out of sequence it could cause different conclusions by the subscriber.

On the other hand, OIDC Logout doesn’t care about ordering at all. It is just saying a single thing is revoked.

I think it is in issue we should mention, but leave it to profiling specs to solve. For example, the SCIM WG will have to either agree to use the order events are received or come up with some other mechanism.  

Failing a specific attribute that gives and order, the only other method I can think of is for the client to assume that the order of receipt of an event may be interpreted as significant.  However I’m not convinced this is true in many cases. 

Phil

@independentid

> On Sep 13, 2016, at 7:23 PM, Chuck Mortimore <[email-masked]> wrote:
> 
> From a protocol perspective, I don't believe it's reasonable to use iat for ordering purposes.  Either the use-cases demand ordered deliver, in which case you account for it in protocol and architecture, or they don't.   Trying to approximate it via timestamps isn't the right solution.
> 
> On Tue, Sep 13, 2016 at 2:56 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
> 
>

---

From: Vivek Biswas <[email-masked]>
Date: Wed, 14 Sep 2016 05:06:06 +0000 (UTC)

The timestamps can be further more problematic if the order of events are asynchronous.Its best to let the implementer implement the logic of ordering the events, if it is desired.Hence, the order of event field can be optional.-Vivek Biswas Consulting Member @Security Oracle 
      From: Phil Hunt <[email-masked]>
 To: Chuck Mortimore <[email-masked]> 
Cc: [email-masked]
 Sent: Tuesday, September 13, 2016 9:57 PM
 Subject: Re: [Id-event] Ordering of SET events
   
@[email-masked]

@[email-masked]

______________________________ _________________
Id-event mailing list
[email-masked]
https://www.ietf.org/mailman/ listinfo/id-event

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 13 Sep 2016 22:21:48 -0700

+1 

Other ideas?  

Phil

> On Sep 13, 2016, at 10:06 PM, Vivek Biswas <[email-masked]> wrote:
> 
> The timestamps can be further more problematic if the order of events are asynchronous.
> Its best to let the implementer implement the logic of ordering the events, if it is desired.
> Hence, the order of event field can be optional.
> -Vivek Biswas
>  Consulting Member @Security
>  Oracle
>