Skip to main content

Concluded WG Security Events (secevent)

Note: The data for concluded WGs is occasionally incorrect.

WG Name Security Events
Acronym secevent
Area Security Area (sec)
State Concluded
Charter charter-ietf-secevent-01 Approved
Status update Show Changed 2018-07-19
Document dependencies
Additional resources Issue tracker, Wiki, Zulip Stream
Personnel Chairs Dick Hardt, Yaron Sheffer
Area Director Roman Danyliw
Mailing list Address id-event@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/id-event
Archive https://mailarchive.ietf.org/arch/browse/id-event/

Closing note for Working Group

https://mailarchive.ietf.org/arch/msg/id-event/ASlT-O5wmkP-kF1MVbRVE04kltA/ Hi SECEVENT WG! Congratulations on completion of the planned deliverables. Thank you for a job well done! Dick (Hardt) and Yaron (Sheffer), thank you for your many years of leadership of the WG. With the last of planned work item just approved, the WG is being closed. The mailing list (https://www.ietf.org/mailman/listinfo/id-event) will remain open for discussion of any errata or implementation issues that might arise; and the list archive will remain online. Additionally, the SECEVENT datatracker entry will also stay active (https://datatracker.ietf.org/wg/secevent/about/) Regards, Roman (Responsible AD for SECEVENT)

Final Charter for Working Group

Many HTTP web services and APIs depend on a web security infrastructure that:
* identifies security subjects and regulates their access to services
* and provides profile and rights information to applications.

Examples are systems that leverage user-agent session cookies
(RFC6265), and OAuth2 (RFC6749). 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 (RFC7009) 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.

It is expected that several identity and security working groups and
organizations will use Identity Event Tokens to describe area-specific
events such as: SCIM Provisioning Events, OpenID RISC Events, and
OpenID Connect Backchannel Logout, among others.

The Security Events working group will produce a standards-track Event
Token specification that includes:
- A JWT extension for expressing security events
- A syntax that enables event-specific data to be conveyed
This Event Token specification will be event transport independent.

The working group will also develop a simple standards-track Event
Delivery specification that includes:
- A mechanism for delivering events using HTTP POST (push)
- Metadata for describing event feeds
- Methods for subscribing to and managing event feeds
- Methods for validating event feed subscriptions

Milestones

Date Milestone Associated documents
Mar 2018 Recharter or Conclude

Done milestones

Date Milestone Associated documents
Done Event delivery draft to IESG as a Proposed Standard
Done WG last call of event delivery draft
Done Event token draft to IESG as a Proposed Standard
Done WG last call of event token draft
Done Initial adoption of event token and event delivery drafts