Subject: [Id-event] Transaction identifier for SETs

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

In discussing SET schema with a bunch of people, it is becoming clear that in many cases, a simple state change in a system could trigger many different types of SET feeds generating 4 or 5 SETs for the same transaction.

For example, a user’s profile is changed in SCIM.  This could trigger:

*  A SCIM modify event
*  A RISC event (account reset)
*  Access log event 
*  OAuth /Connect events (e.g. reset session)

Normally each of these events would each have their own JTI.  There would be a separate subscriber for each.  But I can envision some systems operationally that will want to look at these events together (e.g. devOps).

It seems useful to have a common attribute “txn” which would be a unique identifier for the source transaction.  Thus if a system receives more than one event type (directly or indirectly) it can detect whether the 2 or more events are about the same transaction.

I propose to add this to the core spec as an optional value.

Any objections?

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:29:51 -0700

It might be extremely difficult or impossible for a publisher to
consistently set a correct txn. Would txn be useful at all if a publisher
is setting it as "best effort"?

Not objecting to adding as optional, just wondering if it is realistic to
set an expectation here.

Marius

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

> In discussing SET schema with a bunch of people, it is becoming clear that
> in many cases, a simple state change in a system could trigger many
> different types of SET feeds generating 4 or 5 SETs for the same
> transaction.
>
> Normally each of these events would each have their own JTI.  There would
> be a separate subscriber for each.  But I can envision some systems
> operationally that will want to look at these events together (e.g. devOps).
>
> It seems useful to have a common attribute “txn” which would be a unique
> identifier for the source transaction.  Thus if a system receives more than
> one event type (directly or indirectly) it can detect whether the 2 or more
> events are about the same transaction.
>
> 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:25:22 -0700

If it's added, I'd make sure the txn identifier is clearly relative/unique
by issuer.

---

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

To be clear, the scenario is the publisher is issuing multiple SETs against for a single transaction. So the publisher can for example generate a GUID and then just puts that value on each different SET issued against the same event.

In most cases, since each subscriber cares about a different “version of the event” (e.g. RISC vs. SCIM), they likely won’t need to correlate. 

This seems to come up in DevOps when an operator is trying to trans what happened where.  The receiver of a RISC event could report back the TXN id, which might be useful to tracing it back in say an access log or some other system.

I agree with Marius, that if a sequential number is desired that could be very difficult to implement in practice assuming things like clusters and multi-data centers.

Phil

@independentid

> On Sep 13, 2016, at 7:25 PM, Chuck Mortimore <[email-masked]> wrote:
> 
> If it's added, I'd make sure the txn identifier is clearly relative/unique by issuer.
> 
> On Tue, Sep 13, 2016 at 2:52 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>
> 
>