Category: OpenID Page 4 of 10

The Security Event Token (SET) specification is now RFC 8417. The abstract describes the specification as:

This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.

SETs are already in use to represent OpenID Connect Back-Channel Logout tokens and to represent Risk and Incident Sharing and Coordination (RISC) events. Thanks to my co-editors, members of the IETF ID Events mailing list, and members of the IETF Security Events working group for making this standard a reality!

The Security Event Token (SET) specification has been updated to simplify the definitions and usage of the “iat” (issued at) and “toe” (time of event) claims. The full set of changes made was:

• Simplified the definitions of the “iat” and “toe” claims in ways suggested by Annabelle Backman.
• Added privacy considerations text suggested by Annabelle Backman.
• Updated the RISC event example, courtesy of Marius Scurtescu.
• Reordered the claim definitions to place the required claims first.
• Changed to using the RFC 8174 boilerplate instead of the RFC 2119 boilerplate.

Thanks to Annabelle Backman, Marius Scurtescu, Phil Hunt, and Dick Hardt for the discussions that led to these simplifications.

The specification is available at:

• https://tools.ietf.org/html/draft-ietf-secevent-token-05

An HTML-formatted version is also available at:

• https://self-issued.info/docs/draft-ietf-secevent-token-05.html

A new version of the Security Event Token (SET) specification has been published that incorporates clarifications suggested by working group members in discussions since IETF 100. Changes were:

• Clarified that all “events” values must represent aspects of the same state change that occurred to the subject — not an aggregation of unrelated events about the subject.
• Removed ambiguities about the roles of multiple “events” values and the responsibilities of profiling specifications for defining how and when they are used.
• Corrected places where the term JWT was used when what was actually being discussed was the JWT Claims Set.
• Addressed terminology inconsistencies. In particular, standardized on using the term “issuer” to align with JWT terminology and the “iss” claim. Previously the term “transmitter” was sometimes used and “issuer” was sometimes used. Likewise, standardized on using the term “recipient” instead of “receiver” for the same reasons.
• Added a RISC event example, courtesy of Marius Scurtescu.
• Applied wording clarifications suggested by Annabelle Backman and Yaron Sheffer.
• Applied numerous grammar, syntax, and formatting corrections.

No changes to the semantics of the specification were made.

The specification is available at:

• https://tools.ietf.org/html/draft-ietf-secevent-token-04

An HTML-formatted version is also available at:

• https://self-issued.info/docs/draft-ietf-secevent-token-04.html