{"id":1620,"date":"2016-11-23T19:54:40","date_gmt":"2016-11-24T03:54:40","guid":{"rendered":"https:\/\/self-issued.info\/?p=1620"},"modified":"2016-11-23T19:54:40","modified_gmt":"2016-11-24T03:54:40","slug":"security-event-token-set-specification-and-ietf-security-events-working-group","status":"publish","type":"post","link":"https:\/\/self-issued.info\/?p=1620","title":{"rendered":"Security Event Token (SET) Specification and IETF Security Events Working Group"},"content":{"rendered":"

\"IETF<\/span>As those of you who have been following the id-event@ietf.org mailing list or attended the inaugural meeting of the new IETF Security Events<\/a> working group know, Phil Hunt and co-authors (including myself) have been working on a Security Event Token (SET) specification. A SET is a JSON Web Token (JWT) with an “events<\/code>” claim that contains one or more event identifiers (which are URIs) that say what event the SET describes.<\/p>\n

This work isn’t being done in isolation. Among others, the OpenID Risk and Incident Sharing and Coordination (RISC) working group<\/a>, the OpenID Back-Channel Logout<\/a> specification, and the SCIM Provisioning Events work intend to use the Security Event Token format.<\/p>\n

To make this concrete, the claims in an example OpenID Connect Back-Channel Logout token (which is a SET) are:
\n
\n{
\n  \"iss\": \"https:\/\/server.example.com\",
\n  \"sub\": \"248289761001\",
\n  \"aud\": \"s6BhdRkqt3\",
\n  \"iat\": 1471566154,
\n  \"jti\": \"bWJq\",
\n  \"sid\": \"08a5019c-17e1-4977-8f42-65a12843ea02\",
\n  \"events\": {
\n    \"http:\/\/schemas.openid.net\/event\/backchannel-logout\": {}
\n  }
\n}
\n<\/code>
\nYou’ll see that this a normal JWT, with the issuer, subject, and session ID identifying the target of the logout, and the “events” value identifying the JWT as a logout SET.<\/p>\n

Today, we published an updated SET spec based on discussions at IETF 97<\/a>, which simplifies the SET parsing. Thanks to Phil Hunt or Oracle, William Denniss of Google, Morteza Ansari of Cisco, and the numerous other contributors who’ve gotten us to this point. We now believe that this specification is ready for adoption by the Security Events working group.<\/p>\n

The specification is available at:<\/p>\n