We discussed adding device information to device compliance signal use case in today's (01/20/26) WG meeting but this is likely to apply to other event types.
Background:
Slack discussion: https://oidf.slack.com/archives/C02Q0762E83/p1767896644198309
Previous issue: #221
Meeting notes: https://hackmd.io/@oidf-wg-sse/SycZESaBbl
Use case:
When sending device compliance signal, there is a use case to add additional data about the device (OS type, serial #, configuration) or compliance details. Similarly, a session revoking signal may want to add additional data about the user, etc.
Summary:
In the meeting, we concluded that the best place to add such additional data is in the event payload (and not in the sub_id). The type of additional data to add is broad and it while some of it can potentially be standardized, it is unlikely that we can provide a comprehensive definition of all desired data. What we can do is define a standard location and format for the data.
The previous similar issue (#221) propose the addition of an optional "event_data" field to the event payload that will include all such additional information.
More discussion is likely needed if we want to define a more structured format.
We discussed adding device information to device compliance signal use case in today's (01/20/26) WG meeting but this is likely to apply to other event types.
Background:
Slack discussion: https://oidf.slack.com/archives/C02Q0762E83/p1767896644198309
Previous issue: #221
Meeting notes: https://hackmd.io/@oidf-wg-sse/SycZESaBbl
Use case:
When sending device compliance signal, there is a use case to add additional data about the device (OS type, serial #, configuration) or compliance details. Similarly, a session revoking signal may want to add additional data about the user, etc.
Summary:
In the meeting, we concluded that the best place to add such additional data is in the event payload (and not in the sub_id). The type of additional data to add is broad and it while some of it can potentially be standardized, it is unlikely that we can provide a comprehensive definition of all desired data. What we can do is define a standard location and format for the data.
The previous similar issue (#221) propose the addition of an optional "event_data" field to the event payload that will include all such additional information.
More discussion is likely needed if we want to define a more structured format.