draft-ietf-secevent-delivery-01.txt   draft-ietf-secevent-delivery-02.txt 
Network Working Group P. Hunt, Ed. Network Working Group P. Hunt, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track M. Scurtescu Intended status: Standards Track M. Scurtescu
Expires: May 1, 2018 Google Expires: September 5, 2018 Google
M. Ansari M. Ansari
Cisco Cisco
A. Nadalin A. Nadalin
Microsoft Microsoft
A. Backman A. Backman
Amazon Amazon
October 28, 2017 March 4, 2018
SET Token Delivery Using HTTP SET Token Delivery Using HTTP
draft-ietf-secevent-delivery-01 draft-ietf-secevent-delivery-02
Abstract Abstract
This specification defines how a series of security event tokens This specification defines how a series of security event tokens
(SETs) may be delivered to a previously registered receiver using (SETs) may be delivered to a previously registered receiver using
HTTP POST over TLS initiated as a push to the receiver, or as a poll HTTP POST over TLS initiated as a push to the receiver, or as a poll
by the receiver. The specification also defines how delivery can be by the receiver. The specification also defines how delivery can be
assured subject to the SET Token Receiver's need for assurance. assured subject to the SET Token Receiver's need for assurance.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 1, 2018. This Internet-Draft will expire on September 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. SET Event Stream Protocol . . . . . . . . . . . . . . . . . . 5 2. SET Event Stream Protocol . . . . . . . . . . . . . . . . . . 4
2.1. Event Delivery Process . . . . . . . . . . . . . . . . . 5 2.1. Event Delivery Process . . . . . . . . . . . . . . . . . 4
2.2. Push Delivery using HTTP . . . . . . . . . . . . . . . . 6 2.2. Push Delivery using HTTP . . . . . . . . . . . . . . . . 6
2.3. Polling Delivery using HTTP . . . . . . . . . . . . . . . 8 2.3. Polling Delivery using HTTP . . . . . . . . . . . . . . . 8
2.3.1. Polling HTTP Request Attributes . . . . . . . . . . . 9 2.3.1. Polling HTTP Request Attributes . . . . . . . . . . . 8
2.3.2. Polling HTTP Response Attributes . . . . . . . . . . 10 2.3.2. Polling HTTP Response Attributes . . . . . . . . . . 10
2.3.3. Poll Request . . . . . . . . . . . . . . . . . . . . 10 2.3.3. Poll Request . . . . . . . . . . . . . . . . . . . . 10
2.3.4. Poll Response . . . . . . . . . . . . . . . . . . . . 14 2.3.4. Poll Response . . . . . . . . . . . . . . . . . . . . 14
2.4. Error Response Handling . . . . . . . . . . . . . . . . . 16 2.4. Error Response Handling . . . . . . . . . . . . . . . . . 16
3. Authentication and Authorization . . . . . . . . . . . . . . 17 3. Authentication and Authorization . . . . . . . . . . . . . . 17
3.1. Use of Tokens as Authorizations . . . . . . . . . . . . . 18 3.1. Use of Tokens as Authorizations . . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
4.1. Authentication Using Signed SETs . . . . . . . . . . . . 18 4.1. Authentication Using Signed SETs . . . . . . . . . . . . 18
4.2. HTTP Considerations . . . . . . . . . . . . . . . . . . . 19 4.2. HTTP Considerations . . . . . . . . . . . . . . . . . . . 19
4.3. TLS Support Considerations . . . . . . . . . . . . . . . 19 4.3. TLS Support Considerations . . . . . . . . . . . . . . . 19
4.4. Authorization Token Considerations . . . . . . . . . . . 19 4.4. Authorization Token Considerations . . . . . . . . . . . 19
4.4.1. Bearer Token Considerations . . . . . . . . . . . . . 19 4.4.1. Bearer Token Considerations . . . . . . . . . . . . . 19
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Other Streaming Specifications . . . . . . . . . . . 23 Appendix A. Other Streaming Specifications . . . . . . . . . . . 23
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 24 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 24
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 24 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction and Overview 1. Introduction and Overview
This specification defines how a stream of SETs (see This specification defines how a stream of SETs (see
[I-D.ietf-secevent-token]) can be transmitted to a previously [I-D.ietf-secevent-token]) can be transmitted to a previously
registered Event Receiver using HTTP [RFC7231] over TLS. The registered Event Receiver using HTTP [RFC7231] over TLS. The
specification defines a method to push SETs via HTTP POST and to poll specification defines a method to push SETs via HTTP POST and another
for SETs using HTTP POST. method to poll for SETs using HTTP POST.
This specification defines to methods of SET delivery in what is This specification defines two methods of SET delivery in what is
known as Event Streams. The specification includes a verification known as Event Streams.
process which tests and validates Event Stream configuration.
This specification does not define the method by which Event Streams This specification does not define the method by which Event Streams
are defined, provisioned, managed, monitored, and configured and is are defined, provisioned, managed, monitored, and configured and is
out of scope of this specification. out of scope of this specification.
[[This work is TBD by the SECEVENTS WG]] [[This work is TBD by the SECEVENTS WG]]
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119] . These "OPTIONAL" in this document are to be interpreted as described in BCP
keywords are capitalized when used to unambiguously specify 14 [RFC2119] [RFC8174] when, and only when, they appear in all
requirements of the protocol or application features and behavior capitals, as shown here.
that affect the inter-operability and security of implementations.
When these words are not capitalized, they are meant in their
natural-language sense.
For purposes of readability examples are not URL encoded. For purposes of readability examples are not URL encoded.
Implementers MUST percent encode URLs as described in Section 2.1 of Implementers MUST percent encode URLs as described in Section 2.1 of
[RFC3986] . [RFC3986] .
Throughout this documents all figures MAY contain spaces and extra Throughout this documents all figures MAY contain spaces and extra
line-wrapping for readability and space limitations. Similarly, some line-wrapping for readability and space limitations. Similarly, some
URI's contained within examples, have been shortened for space and URI's contained within examples, have been shortened for space and
readability reasons. readability reasons.
1.2. Definitions 1.2. Definitions
This specification assumes terminology defined in the Security Event This specification assumes terminology defined in the Security Event
Token specification[I-D.ietf-secevent-token] . Token specification[I-D.ietf-secevent-token] .
The following definitions are defined for Security Event The following definitions are defined for Security Event
distribution: distribution:
Identity Provider
An Identity Provider is a service provider that issues
authentication assertions that may be used by Relying Party
service providers to establish login sessions with users.
Examples of Identity Providers are defined in: OpenID Connect
[openid-connect-core] and SAML2 [saml-core-2.0]. For the purpose
of this specification an Identity Provider also includes any
provider of services where the compromise of an account may open
up relying parties to attack. For example for the purposes of
security events, an email service provider could be considered an
"implicit" Identity Provider.
Relying Party
Relying Parties come in multiple forms generally classified as
"Explicit" or "Implicit". An Explicit Relying Party is a service
provider that accepts a standard security assertion (e.g. a JWT
access tokens [RFC7519]) from an Identity Provider to establish a
session or authorization. An Implicit Relying Party (implicit)
uses a personal identifier such as an email address or telephone
number from another provider to establish a Subject's identity.
Examples of Explicit Relying Parties are defined in: OpenID
Connect [openid-connect-core] and SAML2 [saml-core-2.0]. Implicit
relying parties are verified by a common channel associated with
the identifier. For example, an email or a text message is sent
with a unique link to establish ownership of the identifier by the
Subject.
Event Transmitter Event Transmitter
A service provider that delivers SETs to other providers known as A service provider that delivers SETs to other providers known as
Event Receivers. Some examples of Event Transmitters are Identity Event Receivers. An Event Transmitter is responsible for offering
Providers and Relying Parties. An Event Transmitter is a service that allows the Event Receiver to check the Event Stream
responsible for offering a service that allows the Event Receiver configuration and status known as the "Control Plane".
to check the Event Stream configuration and status known as the
"Control Plane".
Event Receiver Event Receiver
A service provider that registers to receive SETs from an Event A service provider that registers to receive SETs from an Event
Transmitter and provides an endpoint to receive SETs via HTTP POST Transmitter and provides an endpoint to receive SETs via HTTP
(known as the "Data Plane"). Some examples of Event Receivers are POST. Event Receivers can check current Event Stream
Identity Providers and Relying Parties. Event Receivers can check configuration and status by accessing the Event Transmitters
current Event Stream configuration and status by accessing the "Control Plane".
Event Transmitters "Control Plane".
Event Stream Event Stream
An Event Stream is a defined location, distribution method and An Event Stream is a defined location, distribution method and
whereby an Event Transmitter and Event Receiver exchange a pre- whereby an Event Transmitter and Event Receiver exchange a pre-
defined family of SETs. A Stream is assumed to have configuration defined family of SETs. A Stream is assumed to have configuration
data such as HTTP endpoints, timeouts, public key sets for signing data such as HTTP endpoints, timeouts, public key sets for signing
and encryption, and Event Families. and encryption, and Event Families.
Event Family
An Event Family is a URI that describes the set of Events types be
issued in an Event Stream.
Subject Subject
The security subject around which a security event has occurred. The security subject around which a security event has occurred.
For example, a security subject might per a user, a person, an For example, a security subject might per a user, a person, an
email address, a service provider entity, an IP address, an OAuth email address, a service provider entity, an IP address, an OAuth
Client, a mobile device, or any identifiable thing referenced in Client, a mobile device, or any identifiable thing referenced in
security and authorization systems. security and authorization systems.
Event Event
An Event is defined to be an event as represented by a security An Event is defined to be an event as represented by a security
event token (SET). See [I-D.ietf-secevent-token]. event token (SET). See [I-D.ietf-secevent-token].
skipping to change at page 5, line 25 skipping to change at page 4, line 37
than that non-integer values can be represented. See [RFC3339] than that non-integer values can be represented. See [RFC3339]
for details regarding date/times in general and UTC in particular. for details regarding date/times in general and UTC in particular.
2. SET Event Stream Protocol 2. SET Event Stream Protocol
An Event Stream represents the communication channel over which a An Event Stream represents the communication channel over which a
series of SETs are delivered to a configured Event Receiver. series of SETs are delivered to a configured Event Receiver.
2.1. Event Delivery Process 2.1. Event Delivery Process
When an Event occurs, the Feed Provider constructs a SET token When an Event occurs, the Event Transmitter constructs a SET token
[I-D.ietf-secevent-token] that describes the Event. The SET issuer [I-D.ietf-secevent-token] that describes the Event. The Event
determines the Event Streams over which the SET should be distributed Transmitter determines the Event Streams over which the SET should be
to. distributed to.
How SET Events are defined and the process by which Events are How SETs are defined and the process by which Events are identified
identified for Event Receivers is out-of-scope of this specification. for Event Receivers is out-of-scope of this specification.
When a SET is available for a Event Receiver, the Feed Transmitter When a SET is available for an Event Receiver, the Event Transmitter
attempts to deliver the SET based on the Event Receiver's registered attempts to deliver the SET based on the Event Receiver's registered
delivery mechanism: delivery mechanism:
o The Event Transmitter uses an HTTP/1.1 POST to the Event Receiver o The Event Transmitter uses an HTTP/1.1 POST to the Event Receiver
endpoint to deliver the SET; endpoint to deliver the SET;
o The Event Transmitter queues up the SET in a buffer so that an o The Event Transmitter queues up the SET in a buffer so that an
Event Receiver MAY poll for SETs using HTTP/1.1 POST. Event Receiver MAY poll for SETs using HTTP/1.1 POST.
o Or, the Feed Transmitter delivers the Event through a different o Or, the Event Transmitter delivers the Event through a different
method not defined by this specification. method not defined by this specification.
Delivery of SETs MAY be delivered using one of two modes: Delivery of SETs MAY be delivered using one of two modes:
PUSH PUSH
In which SETs are delivered one at a time using HTTP POST requests In which SETs are delivered one at a time using HTTP POST requests
by an Event Transmitter to an Event Receiver. The HTTP request by an Event Transmitter to an Event Receiver. The HTTP request
body is a JSON Web Token [RFC7519] with a "Content-Type" header of body is a JSON Web Token [RFC7519] with a "Content-Type" header of
"application/secevent+jwt" as defined in Section 2.2 and 6.2 of "application/secevent+jwt" as defined in Section 2.2 and 6.2 of
[I-D.ietf-secevent-token]. Upon receipt, the Event Receiver [I-D.ietf-secevent-token]. Upon receipt, the Event Receiver
acknowledges receipt with an HTTP response which is a JSON acknowledges receipt with a response with HTTP Status 202, as
document with a "Content-Type" header of "application/json" (see described below in Section 2.2.
Section 11 of [RFC7159]) as described below in Section 2.2.
POLLING Where multiple SETs are delivered in a JSON document POLLING Where multiple SETs are delivered in a JSON document
[RFC7159] to an Event Receiver in response to an HTTP POST request [RFC7159] to an Event Receiver in response to an HTTP POST request
to the Event Transmitter. Then in a following request, the Event to the Event Transmitter. Then in a following request, the Event
Receiver acknowledges received SETs and MAY poll for more. In Receiver acknowledges received SETs and MAY poll for more. In
POLLING mode, all requests and responses are JSON documents and POLLING mode, all requests and responses are JSON documents and
use a "Content-Type" of "application/json" as described in use a "Content-Type" of "application/json" as described in
Section 2.3. Section 2.3.
After successful (acknowledged) SET delivery, Event Transmitters After successful (acknowledged) SET delivery, Event Transmitters
skipping to change at page 6, line 30 skipping to change at page 5, line 42
a SET is acknowledged, the Event Receiver SHALL be responsible for a SET is acknowledged, the Event Receiver SHALL be responsible for
retention and recovery. retention and recovery.
Transmitted SETs SHOULD be self-validating (e.g. signed) if there is Transmitted SETs SHOULD be self-validating (e.g. signed) if there is
a requirement to verify they were issued by the Event Transmitter at a requirement to verify they were issued by the Event Transmitter at
a later date when de-coupled from the original delivery where a later date when de-coupled from the original delivery where
authenticity could be checked via the HTTP or TLS mutual authenticity could be checked via the HTTP or TLS mutual
authentication. authentication.
Upon receiving a SET, the Event Receiver reads the SET and validates Upon receiving a SET, the Event Receiver reads the SET and validates
it. The receiver MUST acknowledge receipt to the Event transmitter, it. The Event Receiver MUST acknowledge receipt to the Event
using the defined acknowledgement or error method depending on the Transmitter, using the defined acknowledgement or error method
method of transfer. depending on the method of transfer.
The Event Receiver SHALL NOT use the Event acknowledgement mechanism The Event Receiver SHALL NOT use the Event acknowledgement mechanism
to report Event errors other than relating to the parsing and to report Event errors other than relating to the parsing and
validation of the SET token. validation of the SET.
2.2. Push Delivery using HTTP 2.2. Push Delivery using HTTP
This method allows an Event Transmitter to use HTTP POST This method allows an Event Transmitter to use HTTP POST
(Section 4.3.3 [RFC7231]) to deliver SETs to a previously registered (Section 4.3.3 [RFC7231]) to deliver SETs to a previously registered
web callback URI supplied by the Event Receiver as part of an Event web callback URI supplied by the Event Receiver as part of an Event
Stream configuration process (not defined by this document). Stream configuration process (not defined by this document).
The SET to be delivered MAY be signed and/or encrypted as defined in The SET to be delivered MAY be signed and/or encrypted as defined in
[I-D.ietf-secevent-token]. [I-D.ietf-secevent-token].
The Event Stream configuration defines a URI the of an Event Receiver The Event Stream configuration defines a URI of an Event Receiver
provided endpoint which accepts HTTP POST requests (e.g. provided endpoint which accepts HTTP POST requests (e.g.
"https://notify.examplerp.com/Events"). "https://rp.example.com/Events").
The HTTP Content-Type (see Section 3.1.1.5 [RFC7231]) for the HTTP The HTTP Content-Type (see Section 3.1.1.5 [RFC7231]) for the HTTP
POST is "application/jwt" and SHALL consist of a single SET token POST is "application/secevent+jwt" and SHALL consist of a single SET
(see [I-D.ietf-secevent-token]). As per Section 5.3.2 [RFC7231], the (see [I-D.ietf-secevent-token]). As per Section 5.3.2 [RFC7231], the
expected media type ("Accept" header) response is "application/json". expected media type ("Accept" header) response is "application/json".
To deliver an Event, the Event Transmitter generates an event To deliver an Event, the Event Transmitter generates an event
delivery message and uses HTTP POST to the configured endpoint with delivery message and uses HTTP POST to the configured endpoint with
the appropriate "Accept" and "Content-Type" headers. the appropriate "Accept" and "Content-Type" headers.
POST /Events HTTP/1.1 POST /Events HTTP/1.1
Host: notify.examplerp.com Host: notify.examplerp.com
skipping to change at page 7, line 50 skipping to change at page 7, line 15
in Section 2 [I-D.ietf-secevent-token]. in Section 2 [I-D.ietf-secevent-token].
If the SET is determined to be valid, the Event Receiver SHALL If the SET is determined to be valid, the Event Receiver SHALL
"acknowledge" successful submission by responding with HTTP Status "acknowledge" successful submission by responding with HTTP Status
202 as "Accepted" (see Section 6.3.3 [RFC7231]). 202 as "Accepted" (see Section 6.3.3 [RFC7231]).
In order to maintain compatibility with other methods of In order to maintain compatibility with other methods of
transmission, the Event Receiver SHOULD NOT include an HTTP response transmission, the Event Receiver SHOULD NOT include an HTTP response
body representation of the submitted SET or what the SET's pending body representation of the submitted SET or what the SET's pending
status is when acknowledging success. In the case of an error (e.g. status is when acknowledging success. In the case of an error (e.g.
HTTP Status 400), purpose of the HTTP response body is to indicate HTTP Status 400), the purpose of the HTTP response body is to
any SET parsing, validation, or cryptographic errors. indicate any SET parsing, validation, or cryptographic errors.
The following is a non-normative example of a successful receipt of a The following is a non-normative example of a successful receipt of a
SET. SET.
HTTP/1.1 202 Accepted HTTP/1.1 202 Accepted
Figure 2: Example Successful Delivery Response Figure 2: Example Successful Delivery Response
Note that the purpose of the "acknowledgement" response is to let the Note that the purpose of the "acknowledgement" response is to let the
Event Transmitter know that a SET has been delivered and the Event Transmitter know that a SET has been delivered and the
information no longer needs to be retained by the Event Transmitter. information no longer needs to be retained by the Event Transmitter.
Before acknowledgement, Event Receivers SHOULD ensure they have Before acknowledgement, Event Receivers SHOULD ensure they have
validated received SETs and retained them in a manner appropriate to validated received SETs and retained them in a manner appropriate to
information retention requirements appropriate to the SET event types information retention requirements appropriate to the SET event types
signaled. The level of retention and method of SETs by Event signaled. The level and method of retention of SETs by Event
Receivers is out-of-scope of this specification. Receivers is out-of-scope of this specification.
In the Event of a general HTTP error condition, the Event Receiver In the Event of a general HTTP error condition, the Event Receiver
MAY respond with an appropriate HTTP Status code as defined in MAY respond with an appropriate HTTP Status code as defined in
Section 6 [RFC7231]. Section 6 [RFC7231].
When the Event Receiver detects an error parsing or validating a When the Event Receiver detects an error parsing or validating a
received SET (as defined by [I-D.ietf-secevent-token]), the Event received SET (as defined by [I-D.ietf-secevent-token]), the Event
Receiver SHALL indicate an HTTP Status 400 error with an error code Receiver SHALL indicate an HTTP Status 400 error with an error code
as described in Section 2.4. as described in Section 2.4.
skipping to change at page 9, line 5 skipping to change at page 8, line 29
This method allows an Event Receiver to use HTTP POST (Section 4.3.3 This method allows an Event Receiver to use HTTP POST (Section 4.3.3
[RFC7231]) to acknowledge SETs and to check for and receive zero or [RFC7231]) to acknowledge SETs and to check for and receive zero or
more SETs. Requests MAY be made at a periodic interval (short more SETs. Requests MAY be made at a periodic interval (short
polling) or requests MAY wait pending availability of new SETs using polling) or requests MAY wait pending availability of new SETs using
long polling (see Section 2 [RFC6202]). long polling (see Section 2 [RFC6202]).
The delivery of SETs in this method is facilitated by HTTP POST The delivery of SETs in this method is facilitated by HTTP POST
requests initiated by the Event Receiver in which: requests initiated by the Event Receiver in which:
o The Event Receiver makes an request for available SETs using an o The Event Receiver makes a request for available SETs using an
HTTP POST to a pre-arranged endpoint provided by the Event HTTP POST to a pre-arranged endpoint provided by the Event
Transmitter. Or, Transmitter. Or,
o After validating previously received SETs, the Event Receiver o After validating previously received SETs, the Event Receiver
initiates another poll request using HTTP POST that includes initiates another poll request using HTTP POST that includes
acknowledgement of previous SETs, and waits for the next batch of acknowledgement of previous SETs, and waits for the next batch of
SETs. SETs.
The purpose of the "acknowledgement" is to inform the Event The purpose of the "acknowledgement" is to inform the Event
Transmitter that has successfully been delivered and attempts to re- Transmitter that has successfully been delivered and attempts to re-
skipping to change at page 22, line 5 skipping to change at page 21, line 49
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 7.2. Informative References
[openid-connect-core] [openid-connect-core]
NRI, "OpenID Connect Core 1.0", Nov 2014. NRI, "OpenID Connect Core 1.0", Nov 2014.
[POSIX.1] Institute of Electrical and Electronics Engineers, "The [POSIX.1] Institute of Electrical and Electronics Engineers, "The
Open Group Base Specifications Issue 7", IEEE Std 1003.1, Open Group Base Specifications Issue 7", IEEE Std 1003.1,
2013 Edition, 2013. 2013 Edition, 2013.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
skipping to change at page 25, line 18 skipping to change at page 25, line 18
o Added general HTTP security considerations o Added general HTTP security considerations
o Added authentication and authorization o Added authentication and authorization
o Revised Verify Event to work with both types of delivery o Revised Verify Event to work with both types of delivery
Draft 01 - PH - Removed Verification section per feedback from Draft 01 - PH - Removed Verification section per feedback from
IETF99. IETF99.
Draft 02 - MS -
o Minor editorial improvements
o Removed Identity Provider / Relying Party Terminology
o Changed boilerplate language according to RFC8174
This draft was based on draft-hunt-secevent.distribution revision This draft was based on draft-hunt-secevent.distribution revision
history: history:
o Draft 00 - PH - First Draft based on reduced version of draft- o Draft 00 - PH - First Draft based on reduced version of draft-
hunt-idevent-distribution hunt-idevent-distribution
o Draft 01 - PH - o Draft 01 - PH -
* Reworked terminology to match new WG Transmitter/Receiver terms * Reworked terminology to match new WG Transmitter/Receiver terms
 End of changes. 31 change blocks. 
85 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/