[Id-event] Late comment on experience with draft-ietf-secevent-subject-identifiers-12

[Phillip Hunt <[e-mail]>]

Apologies for this late feedback. I felt it important to share my recent (right now) after recent review of interop with the OpenID Shared Signals draft and the new SCIM WG SCIM Events Profile draft (draft-ietf-scim-events-00 <https://datatracker.ietf.org/doc/draft-ietf-scim-events/>).

It appears there is potential for interop concerns or mistakes arising because the examples in this draft suggests profilers to embed subject identifiers inside of the events claim that may suggest multiple events about different subjects are possible (contrary to RFC8417).  A best practice would be to use the “sub_id” to hold such claims.  It should be noted that the use of subject identifiers in event “payloads” should be supplemental to sub_id.  A SET that contains multiple events about the same transaction must be about the same top-level identifier “sub_id” (per section 2.0 of RFC8417).  

For example in SCIM Events, a SET could be issued that contains both a provisioning  event (urn:ietf:params:event:SCIM:prov:patch) AND a signal (urn:ietf:params:event:SCIM:sig:authMethod).  In the current draft the “sub” claim ties the events together to indicate the event occurs from the same transaction about the same subject.

In contrast, the OpenID RISC Profile embeds subjects in events:
https://openid.net/specs/openid-risc-profile-specification-1_0-01.html

The interop concern is:
* Subject information located in differing places (top level sub_id claim or embedded in event payloads)
* A possible impression a SET can contain multiple events with per event identifiers about different subjects contrary to section 2 RFC8417

I would like the authors to consider adjusting the draft to more strongly recommend “sub_id” as the main claim and that subject objects in event payloads SHOULD be specific to that event type (ie. as a supplemental context).

From an inter-op perspective it is much easier to write code to look for sub_id and recognize it as a standard json object.

I ran into this problem recently implementing SET for SCIM Events and testing interop with the implementation described at SharedSignals.guide.  In this implementation, events are only accepted if subject is embedded in the event “payload” rather than as a top-level claim (“sub-id”).

Further I have been asked if SCIM Events could adopt support this draft.   If SCIM were to support it, we would use the ’sub_id’ claim. Off the top, this would make SCIM incompatible with the implementation of sharedsignals.guide which implements SSEF (https://openid.net/specs/openid-sse-framework-1_0-ID1.html).

Phillip Hunt
@independentid
[e-mail]