[appsdesh]

I was thinking about submitting this PR for a while, and in today's SSWG call @thomasdarimont raised this topic

The use case: a user starts an agent task and gets a txn value. When the task finishes, the Transmitter wants to send session-revoked for that workload only.

The current Subject Identifier formats can already express this. The missing piece is a named member in the complex format that tells the Receiver the identifier refers to an agent or workload, and not to a user or device.

Examples
A workload alone, using a workload identifier:

"sub_id": {
  "format": "complex",
  "workload": {
    "format": "uri",
    "uri": "wimse://example.com/workload1"
  }
}

If the Receiver can tell from context that the subject is a workload, a simple uri subject also works:

"sub_id": {
  "format": "uri",
  "uri": "wimse://example.com/workload1"
}

A specific run of a workload. The session member carries the txn value as an opaque identifier, so a session-revoked event applies to that run only:

"sub_id": {
  "format": "complex",
  "workload": {
    "format": "uri",
    "uri": "wimse://example.com/workload1"
  },
  "session": {
    "format": "opaque",
    "id": "<session ID>"
  }
}

[thomasdarimont]

During todays SSF WG call @identitymonk noted that the meaning "txn" claim is somewhat loosely defined at the moment so we should probably avoid using it to denote or carry a workload identifier in the examples.

But I think a "workload" component as part of a complex subject is generic enough to apply it to many different use-cases.

[thomasdarimont]

Also I think this should target a SSF 1.1 version of the document. I think @mike-kiser-sp got some approval today to finally merge #310.

Once the 1.1 document exists I suggest to apply the change against that document.

[thomasdarimont]

I wonder if it also would make sense to have an additional "transaction" member in the ComplexSubject to allow folks to target a specific txn - whatever that means for the respective platform.

[appsdesh]

I wonder if it also would make sense to have an additional "transaction" member in the ComplexSubject to allow folks to target a specific txn - whatever that means for the respective platform.

I am not clear on which event you would be targeting with "transaction" as a subject.

[thomasdarimont]

I am not clear on which event you would be targeting with "transaction" as a subject.

I don't want to target an event, but a specific logical transaction; for example, some events might be raised during the execution of a workflow or a business transaction that spans multiple hops/services. This logical transaction might have an identifier, and I want to correlate all SSF events generated during this workflow.
We have the "txn" claim to associate a SET with a logical transaction. Still, the txn might be bound to a "local" transaction identifier instead of a "global" logical transaction/workflow identifier. Hence, I think we could use a complex subject with a "transaction" member to target events that occurred within the bounds of that transaction/workflow across multiple hops. The "session" member might be too coarse-grained for this, as there might be multiple logical transactions / workflow executions within the bounds of a particular session. And agent/workload might cover a section of the workflow / logical transaction but not the full journey.