Subject: [Id-event] Proposed text for txn and ordering

From: Phil Hunt <[email-masked]>
Date: Thu, 15 Sep 2016 15:28:52 -0700

Based on the feedback, I am proposing the following changes:

In the new attributes defined section, a new claim “txn” defined:
   txn
      An OPTIONAL single-valued String value that represents a unique
      transaction identifier.  In cases where multiple SETs are issued
      based on different event URIs, the transaction identifier MAY be
      used to correlate SETs to the same originating event or stateful
      change.

Regarding Ordering, I am proposing the following section:
2.2.  Idempotency and Ordering Considerations

   In many cases SETs will be issued by highly distributed systems and
   subscribers.  Without additional specification it is quite
   conceivable that the order of SETs received by a subscriber MAY be
   different from the order of the originating state changes or events.
   While the "iat" value may give a rough indication of SET order, it
   SHOULD NOT be relied upon unless the profiling SET token
   specification provides clarification.

   Profiling specifications are encouraged to consider whether the
   nature of SETs defined are "idempotent" in the sense that the order
   of receipt does not matter.  For example, in the case of token
   revocations, each SET can stand on its own and order has no impact.
   In contrast, a profiling SET specification related to provisioning
   might be highly dependent on ordering.  As an example: one SET
   indicates a new resource was created, while the next SET indicates
   the same resource is modified.  Non-Idempotent SET event
   specifications SHOULD choose to define a sequencing method such as aa
   claim used for the purpose or identifying the order of SETs as
   defined by the Feed Publisher or another method that is part of how
   SETs are distributed.
Thanks for your feedback.

Phil

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

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 15 Sep 2016 18:32:47 -0700

Sounds good to me.

Marius

On Thu, Sep 15, 2016 at 3:28 PM, Phil Hunt <[email-masked]> wrote:

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

---

From: Nicholas Roy <[email-masked]>
Date: Fri, 16 Sep 2016 08:15:27 -0600

+1

Nick

On 9/15/16 7:32 PM, Marius Scurtescu wrote:
> Sounds good to me.
>
> Marius
>
> On Thu, Sep 15, 2016 at 3:28 PM, Phil Hunt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     2.2. Idempotency and Ordering Considerations In many cases SETs
>     will be issued by highly distributed systems and subscribers.
>     Without additional specification it is quite conceivable that the
>     order of SETs received by a subscriber MAY be different from the
>     order of the originating state changes or events. While the "iat"
>     value may give a rough indication of SET order, it SHOULD NOT be
>     relied upon unless the profiling SET token specification provides
>     clarification. Profiling specifications are encouraged to consider
>     whether the nature of SETs defined are "idempotent" in the sense
>     that the order of receipt does not matter. For example, in the
>     case of token revocations, each SET can stand on its own and order
>     has no impact. In contrast, a profiling SET specification related
>     to provisioning might be highly dependent on ordering. As an
>     example: one SET indicates a new resource was created, while the
>     next SET indicates the same resource is modified. Non-Idempotent
>     SET event specifications SHOULD choose to define a sequencing
>     method such as aa claim used for the purpose or identifying the
>     order of SETs as defined by the Feed Publisher or another method
>     that is part of how SETs are distributed.
>
>     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>
>
>
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Fri, 16 Sep 2016 14:00:08 -0700

It occurs to me that the terminology for idempotency is wrong. Scim is idempotent in that any request can be repeated. However a series of transactions does have order and dependence. 

I will look for another way to express this or just drop the idempotence term. 

Phil

> On Sep 16, 2016, at 7:15 AM, Nicholas Roy <[email-masked]> wrote:
> 
> +1
> 
> Nick
>

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Fri, 16 Sep 2016 21:26:00 +0000

Is this even something we could define for abstract events?  Doesn't that semantics really associated with the type of event we are talking about?  I think this is a property that should be defined for a given type of event and not across all events.

Cheers,
Morteza

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 16, 2016 at 2:00 PM
To: Nicholas Roy <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Proposed text for txn and ordering

Phil

On Sep 16, 2016, at 7:15 AM, Nicholas Roy <[email-masked]<mailto:[email-masked]>> wrote:

+1

Nick

Marius

On Thu, Sep 15, 2016 at 3:28 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Based on the feedback, I am proposing the following changes:

In the new attributes defined section, a new claim "txn" defined:

   txn

Phil

@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

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

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

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Fri, 16 Sep 2016 17:34:37 -0700

Txn needs to be available in all types. 

Phil

> On Sep 16, 2016, at 2:26 PM, Morteza Ansari (moransar) <[email-masked]> wrote:
> 
> Is this even something we could define for abstract events?  Doesn’t that semantics really associated with the type of event we are talking about?  I think this is a property that should be defined for a given type of event and not across all events.
> 
> 
> Cheers,
> Morteza
> 
> From: Id-event <[email-masked]> on behalf of Phil Hunt <[email-masked]>
> To: Nicholas Roy <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>>> [email-masked]://www.ietf.org/mailman/listinfo/id-event
>>

---

From: William Denniss <[email-masked]>
Date: Fri, 16 Sep 2016 18:01:12 -0700

+1 looks good.

On Fri, Sep 16, 2016 at 5:34 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

> Is this even something we could define for abstract events?  Doesn’t that
> semantics really associated with the type of event we are talking about?  I
> think this is a property that should be defined for a given type of event
> and not across all events.
>
>
> Cheers,
> Morteza
>
> It occurs to me that the terminology for idempotency is wrong. Scim is
> idempotent in that any request can be repeated. However a series of
> transactions does have order and dependence.
>
> Id-event mailing [email-masked]://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Sat, 17 Sep 2016 02:45:52 +0000

Yes, I agree on that front. I was talking about semantics around txn such as idempotency.

Cheers,
Morteza

On Sep 16, 2016, at 5:34 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On Sep 16, 2016, at 2:26 PM, Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
Morteza

Phil

+1

Nick

Marius

   txn

Phil

@independentid

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Fri, 16 Sep 2016 19:57:43 -0700

:)

Phil

> On Sep 16, 2016, at 7:45 PM, Morteza Ansari (moransar) <[email-masked]> wrote:
> 
> On Sep 16, 2016, at 5:34 PM, Phil Hunt (IDM) <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Sun, 18 Sep 2016 23:56:45 +0000

I’d like to agree with Morteza that transactional semantics is entirely dependent upon the nature and use of the JWT and is not something we should try to describe generally, because doing so will necessarily exclude important use cases.  I’m fine with defining a “txn” (transaction ID) claim somewhere as long as we make it clear that it can be used in any JWT and it is in no way SET-specific.  We should also say that the precise meaning and use of the transaction identifier is dependent upon the application use case.

I would leave out the language about “likely to be highly distributed”, at least in the event token spec.  I say that because events will also be used in simple point-to-point delivery relationships with nothing distributed about it.  I don’t want to imply that SETs aren’t appropriate for simple, non-distributed use cases.  If we want to say things about ordering, that should probably happen in the transport spec if it is anticipated that legal implementations of the transport spec will be able result in event reordering.

Phil, could you revise your proposed wording accordingly and recirculate for review?

                                                       Thanks again,
                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt (IDM)
Sent: Friday, September 16, 2016 7:58 PM
To: Morteza Ansari (moransar) <[email-masked]>
Cc: Nicholas Roy <[email-masked]>; [email-masked]
Subject: Re: [Id-event] Proposed text for txn and ordering

:)

Phil

On Sep 16, 2016, at 7:45 PM, Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>> wrote:
Yes, I agree on that front. I was talking about semantics around txn such as idempotency.

Cheers,
Morteza

Phil

Cheers,
Morteza

Phil

Nick

Marius

   txn

      change.

   SETs are distributed.

Phil

@independentid

Id-event mailing list

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 19 Sep 2016 08:34:37 -0700

We need to be able to correlate SETs back to a common initiating transaction. 

However if I understand you are suggesting txn might be asserted inbound as kind of a through the layers txn id (eg in an auth tkn). 

Yes i can see that is ok. However usually oauth txns are usually multi transactional. And so meaning is different. 

Can you propose text?

Phil

> On Sep 18, 2016, at 4:56 PM, Mike Jones <[email-masked]> wrote:
>