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 |