Difference between revisions of "Security Event Token"
(→Problems) |
(→Context) |
||
| Line 6: | Line 6: | ||
Security Event Token (SET) RFC 8417 | Security Event Token (SET) RFC 8417 | ||
| − | + | <blockquote>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.</blockquote> | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
This standard was create by the Security Events Working Group of the IETF: https://datatracker.ietf.org/wg/secevent/about/ | This standard was create by the Security Events Working Group of the IETF: https://datatracker.ietf.org/wg/secevent/about/ | ||
Revision as of 09:42, 2 October 2018
Full Title or Meme
Security Event Token (SET) RFC 8417
Context
Security Event Token (SET) RFC 8417
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.
This standard was create by the Security Events Working Group of the IETF: https://datatracker.ietf.org/wg/secevent/about/ who have not determined if they need to do any more or not.
Problems
Examples are systems that leverage user-agent session cookies (RFC 6265), and OAuth2 (RFC 6749). In order to prevent or mitigate security risks, or to provide out-of-band information as necessary, these systems need to share security event messages. For example, an OAuth authorization server, having received a token revocation request (RFC 7009) may need to inform affected resource servers; a cloud provider may wish to inform another cloud provider of suspected fraudulent use of identity information; an identity provider may wish to signal a session logout to a relying party and does not wish to rely solely upon clearing a session cookie.
Solutions
Yet another data structure defined by the IETF.
