Get updates to your emailSubscribe
Today, RFC 8417 "Security Event Token (SET)" was published. Here's the RFC's abstract:
"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."
The Security Event Token (SET) "specification is scoped to security- and identity-related events. While SETs may be used for other purposes, the specification only considers security and privacy concerns relevant to identity and personal information.
Security events are not commands issued between parties. A SET describes statements of fact from the perspective of an issuer about a subject (e.g., a web resource, token, IP address, the issuer itself). These statements of fact represent a logical 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. A security subject may be permanent (e.g., a user account) or temporary (e.g., an HTTP session) in nature. A state change could describe a direct change of entity state, an implicit change of state, or other higher-level security statements such as:
- The creation, modification, removal of a resource.
- The resetting or suspension of an account.
- The revocation of a security token prior to its expiry.
- The logout of a user session.
- An indication that a user has been given control of an email identifier that was previously controlled by another user.
While subject state changes are often triggered by a user agent or security subsystem, the issuance and transmission of an event may occur asynchronously and in a back channel to the action that caused the change that generated the security event. Subsequently, a SET recipient, having received a SET, validates and interprets the received SET and takes its own independent actions, if any. For example, having been informed of a personal identifier being associated with a different security subject (e.g., an email address is being used by someone else), the SET recipient may choose to ensure that the new user is not granted access to resources associated with the previous user. Or, the SET recipient may not have any relationship with the subject, and no action is taken.
While SET recipients will often take actions upon receiving SETs, security events cannot be assumed to be commands or requests. The intent of this specification is to define a syntax for statements of fact that SET recipients may interpret for their own purposes."
An expert in protocol design and structured data, Erik Wilde consults with organizations to help them get the most out of APIs and microservices. Erik has been involved in the development of innovative technologies since the advent of the Web and is active in the IETF and W3C communities. He obtained his PhD from ETH Zurich and served as Associate Adjunct Professor at Berkeley before working at EMC, Siemens and now CA Technologies.