Difference between revisions of "Security Event Token"

From MgmtWiki
Jump to: navigation, search
(Solutions)
(Problems)
Line 21: Line 21:
 
==Problems==
 
==Problems==
 
Examples are systems that leverage user-agent session cookies
 
Examples are systems that leverage user-agent session cookies
(RFC6265), and OAuth2 (RFC6749). In order to prevent or mitigate
+
(RFC 6265), and OAuth2 (RFC 6749). In order to prevent or mitigate
 
security risks, or to provide out-of-band information as  
 
security risks, or to provide out-of-band information as  
 
necessary, these systems need to share security event messages.  
 
necessary, these systems need to share security event messages.  
 
For example, an OAuth authorization server, having received a  
 
For example, an OAuth authorization server, having received a  
token revocation request (RFC7009) may need to inform affected
+
token revocation request (RFC 7009) may need to inform affected
 
resource servers; a cloud provider may wish to inform another  
 
resource servers; a cloud provider may wish to inform another  
 
cloud provider of suspected fraudulent use of identity  
 
cloud provider of suspected fraudulent use of identity  

Revision as of 15:07, 10 August 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.

References