Diff: rfc8936xml2.original.xml

	rfc8936xml2.original.xml	rfc8936.xml

	<?xml version="1.0" encoding="utf-8"?>	<?xml version='1.0' encoding='utf-8'?>
	<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/r
	fc2629.xslt' ?>	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
	<?rfc toc="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
	<?rfc tocompact="yes"?>	docName="draft-ietf-secevent-http-poll-12" ipr="trust200902" obsoletes=""
	<?rfc tocdepth="3"?>	updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
	<?rfc tocindent="yes"?>	tocDepth="3" symRefs="true" sortRefs="true" consensus="yes" number="8936"
	<?rfc symrefs="yes"?>	version="3">
	<?rfc sortrefs="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc category="std" docName="draft-ietf-secevent-http-poll-12"
	ipr="trust200902">
	<front>
	<title abbrev="draft-ietf-secevent-http-poll">
	Poll-Based Security Event Token (SET) Delivery Using HTTP
	</title>


		<front>
		<title abbrev="Poll-Based SET Delivery Using HTTP">Poll-Based Security Event
		Token (SET) Delivery Using HTTP</title>
		<seriesInfo name="RFC" value="8936"/>
	<author fullname="Annabelle Backman" initials="A." surname="Backman" role="e ditor">	<author fullname="Annabelle Backman" initials="A." surname="Backman" role="e ditor">

	<organization abbrev="Amazon">Amazon</organization>	<organization>Amazon</organization>
	<address>	<address>
	<email>richanna@amazon.com</email>	<email>richanna@amazon.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Michael B. Jones" initials="M." surname="Jones" role="edit or">	<author fullname="Michael B. Jones" initials="M." surname="Jones" role="edit or">

	<organization abbrev="Microsoft">Microsoft</organization>	<organization>Microsoft</organization>
	<address>	<address>
	<email>mbj@microsoft.com</email>	<email>mbj@microsoft.com</email>
	<uri>https://self-issued.info/</uri>	<uri>https://self-issued.info/</uri>
	</address>	</address>
	</author>	</author>

		<author fullname="Marius Scurtescu" initials="M." surname="Scurtescu">
	<author fullname="Marius Scurtescu" initials="M.S." surname="Scurtescu">	<organization>Coinbase</organization>
	<organization abbrev="Coinbase">Coinbase</organization>

	<address>	<address>
	<email>marius.scurtescu@coinbase.com</email>	<email>marius.scurtescu@coinbase.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Morteza Ansari" initials="M." surname="Ansari">	<author fullname="Morteza Ansari" initials="M." surname="Ansari">

	<organization abbrev="Cisco">Cisco</organization>	<organization>Independent</organization>

	<address>	<address>

	<email>morteza.ansari@cisco.com</email>	<email>morteza@sharppics.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Anthony Nadalin" initials="A." surname="Nadalin">	<author fullname="Anthony Nadalin" initials="A." surname="Nadalin">

	<organization abbrev="Microsoft">Microsoft</organization>	<organization>Independent</organization>

	<address>	<address>

	<email>tonynad@microsoft.com</email>	<email>nadalin@prodigy.net</email>
	</address>	</address>
	</author>	</author>

		<date year="2020" month="November"/>
	<date year="2020" month="June" day="24" />

	<area>Security</area>	<area>Security</area>
	<workgroup>Security Events Working Group</workgroup>	<workgroup>Security Events Working Group</workgroup>


	<keyword>Internet-Draft</keyword>	<keyword>JSON Web Token</keyword>
		<keyword>JWT</keyword>
		<keyword>Security Event Token</keyword>
		<keyword>SET</keyword>
		<keyword>Delivery</keyword>
		<keyword>JavaScript Object Notation</keyword>
		<keyword>JSON</keyword>

	<abstract>	<abstract>
	<t>	<t>
	This specification defines how a series of Security Event Tokens	This specification defines how a series of Security Event Tokens
	(SETs) can be delivered to an intended recipient	(SETs) can be delivered to an intended recipient
	using HTTP POST over TLS initiated as a poll by the recipient. The	using HTTP POST over TLS initiated as a poll by the recipient. The
	specification also defines how delivery can be assured, subject to	specification also defines how delivery can be assured, subject to
	the SET Recipient's need for assurance.	the SET Recipient's need for assurance.

	</t>	</t>
	</abstract>	</abstract>
	</front>	</front>


	<middle>	<middle>

	<section anchor="intro" title="Introduction and Overview" toc="default">


		<section anchor="intro" toc="default" numbered="true">
		<name>Introduction and Overview</name>
	<t>	<t>
	This specification defines how a stream of	This specification defines how a stream of

	Security Event Tokens (SETs) <xref target="RFC8417"/>	Security Event Tokens (SETs) <xref target="RFC8417" format="default"/>
	can be transmitted to an intended	can be transmitted to an intended

	SET Recipient using HTTP <xref target="RFC7231"/>	SET Recipient using HTTP <xref target="RFC7231" format="default"/>
	over TLS. The specification defines a method to poll for SETs	over TLS. The specification defines a method to poll for SETs
	using HTTP POST.	using HTTP POST.
	This is an alternative SET delivery method to the one defined in	This is an alternative SET delivery method to the one defined in

	<xref target="I-D.ietf-secevent-http-push"/>.	<xref target="RFC8935" format="default"/>.
	</t>	</t>
	<t>	<t>
	Poll-based SET delivery is intended for scenarios where all of	Poll-based SET delivery is intended for scenarios where all of
	the following apply:	the following apply:

	<list style="symbols">	</t>
	<t>The recipient of the SET is capable of making outbound HTTP requests	<ul spacing="normal">
	.</t>	<li>The recipient of the SET is capable of making outbound HTTP requests
	<t>	.</li>
		<li>
	The transmitter is capable of hosting a TLS-enabled HTTP endpoint tha t is accessible	The transmitter is capable of hosting a TLS-enabled HTTP endpoint tha t is accessible
	to the recipient.	to the recipient.

	</t>	</li>
	<t>	<li>
	The transmitter and recipient are willing to exchange data with one a nother.	The transmitter and recipient are willing to exchange data with one a nother.

	</t>	</li>
	</list>	</ul>
		<t>
	In some scenarios, either push-based or poll-based delivery could be used ,	In some scenarios, either push-based or poll-based delivery could be used ,
	and in others, only one of them would be applicable.	and in others, only one of them would be applicable.
	</t>	</t>
	<t>	<t>
	A mechanism for exchanging configuration metadata such as endpoint URLs,	A mechanism for exchanging configuration metadata such as endpoint URLs,
	cryptographic keys,	cryptographic keys,
	and possible implementation constraints such as buffer size limitations	and possible implementation constraints such as buffer size limitations
	between the transmitter and recipient is	between the transmitter and recipient is
	out of scope for this specification. How SETs are defined and the proce ss	out of scope for this specification. How SETs are defined and the proce ss
	by which security events are identified for SET Recipients are specified in	by which security events are identified for SET Recipients are specified in

	<xref target="RFC8417"/>.	<xref target="RFC8417" format="default"/>.
	</t>	</t>

		<section anchor="notat" toc="default" numbered="true">
	<section anchor="notat" title="Notational Conventions" toc="default">	<name>Notational Conventions</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	<t>
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	"MAY", and "OPTIONAL" in this document are to be interpreted as	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	when, and only when, they appear in all capitals, as shown here.	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	</t>	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
		to be interpreted as described in BCP 14 <xref target="RFC2119"/>
	<t>	<xref target="RFC8174"/> when, and only when, they appear in all capitals,
		as shown here.
		</t>
		<t>
	Throughout this document, all figures may contain spaces and extra	Throughout this document, all figures may contain spaces and extra
	line wrapping for readability and due to space limitations.	line wrapping for readability and due to space limitations.

	</t>	</t>
	</section>	</section>

		<section anchor="defs" toc="default" numbered="true">
	<section anchor="defs" title="Definitions" toc="default">	<name>Definitions</name>
	<t>	<t>
	This specification utilizes terminology defined in <xref target="RFC	This specification utilizes terminology defined in <xref target="RFC
	8417"/>	8417" format="default"/>
	and <xref target="I-D.ietf-secevent-http-push"/>.	and <xref target="RFC8935" format="default"/>.
	</t>	</t>
	</section>	</section>
	</section>	</section>

		<section anchor="Delivery" numbered="true" toc="default">
	<section anchor="Delivery" title="SET Delivery">	<name>SET Delivery</name>
	<t>	<t>
	When a SET is available for a SET Recipient, the SET Transmitter	When a SET is available for a SET Recipient, the SET Transmitter
	queues the SET in a buffer so that	queues the SET in a buffer so that
	a SET Recipient can poll for SETs using HTTP POST.	a SET Recipient can poll for SETs using HTTP POST.
	</t>	</t>


	<t>	<t>
	In poll-based SET delivery using HTTP over TLS, zero or more SETs are	In poll-based SET delivery using HTTP over TLS, zero or more SETs are

	delivered in a JSON <xref target="RFC8259"/> document	delivered in a JSON <xref target="RFC8259" format="default"/> document
	to a SET Recipient in response to an HTTP POST request to the	to a SET Recipient in response to an HTTP POST request to the
	SET Transmitter. Then in a following request, the SET Recipient	SET Transmitter. Then in a following request, the SET Recipient
	acknowledges received SETs and can poll for more. All requests and	acknowledges received SETs and can poll for more. All requests and
	responses are JSON documents and use a	responses are JSON documents and use a

	<spanx style="verb">Content-Type</spanx> of	<tt>Content-Type</tt> of
	<spanx style="verb">application/json</spanx>, as described in	<tt>application/json</tt>, as described in
	<xref target="httpPoll"/>.	<xref target="pollReq" format="default"/>.
	</t>	</t>

	<t>After successful (acknowledged) SET delivery, SET	<t>After successful (acknowledged) SET delivery, SET
	Transmitters are not required to retain or record SETs for	Transmitters are not required to retain or record SETs for

	retransmission. Once a SET is acknowledged, the SET Recipient SHALL be	retransmission. Once a SET is acknowledged, the SET Recipient <bcp14>SHALL </bcp14> be
	responsible for retention, if needed.	responsible for retention, if needed.
	Transmitters may also discard undelivered SETs under deployment-specific c onditions,	Transmitters may also discard undelivered SETs under deployment-specific c onditions,
	such as if they have not been polled for over too long a period of time	such as if they have not been polled for over too long a period of time
	or if an excessive amount of storage is needed to retain them.	or if an excessive amount of storage is needed to retain them.
	</t>	</t>
	<t>	<t>
	Upon receiving a SET, the SET Recipient reads the SET and validates	Upon receiving a SET, the SET Recipient reads the SET and validates

	it in the manner described in Section 2 of <xref target="I-D.ietf-seceven	it in the manner described in <xref
	t-http-push"/>.	target="RFC8935" sectionFormat="of" section="2"/>.
	The SET Recipient MUST acknowledge receipt to the SET Transmitter,	The SET Recipient <bcp14>MUST</bcp14> acknowledge receipt to the SET Tran
	and SHOULD do so in a timely fashion, as described in <xref target="pollR	smitter,
	equest"/>.	and <bcp14>SHOULD</bcp14> do so in a timely fashion, as described in <xre
	The SET Recipient SHALL NOT use the event acknowledgement mechanism	f target="pollRequest" format="default"/>.
		The SET Recipient <bcp14>SHALL NOT</bcp14> use the event acknowledgement
		mechanism
	to report event errors other than those relating to the parsing and	to report event errors other than those relating to the parsing and
	validation of the SET.	validation of the SET.
	</t>	</t>

		<section anchor="httpPoll" numbered="true" toc="default">
	<section anchor="httpPoll" title="Polling Delivery using HTTP">	<name>Polling Delivery using HTTP</name>
		<t>This method allows a SET Recipient to use HTTP POST
	<t>This method allows a SET Recipient to use HTTP POST	(<xref target="RFC7231" sectionFormat="of" section="4.3.3"/>) to acknowle
	(Section 4.3.3 of <xref target="RFC7231"/>) to acknowledge	dge
	SETs and to check for and receive zero or more SETs. Requests	SETs and to check for and receive zero or more SETs. Requests

	MAY be made at a periodic interval (short polling) or requests	<bcp14>MAY</bcp14> be made at a periodic interval (short polling) or requ
	MAY wait, pending availability of new SETs using long polling,	ests
	per Section 2 of <xref target="RFC6202"/>.	<bcp14>MAY</bcp14> wait, pending availability of new SETs using long poll
		ing,
		per <xref target="RFC6202" sectionFormat="of" section="2"/>.
	Note that short polling will result in retrieving zero or more SETs	Note that short polling will result in retrieving zero or more SETs
	whereas long polling will typically result in retrieving one or more SETs	whereas long polling will typically result in retrieving one or more SETs
	unless a timeout occurs.	unless a timeout occurs.

	</t>	</t>
		<t>The delivery of SETs in this method is facilitated by HTTP
	<t>The delivery of SETs in this method is facilitated by HTTP	POST requests initiated by the SET Recipient in which:</t>
	POST requests initiated by the SET Recipient in which:<list style="symbol	<ul spacing="normal">
	s">	<li>The SET Recipient makes a request for available SETs
	<t>The SET Recipient makes a request for available SETs
	using an HTTP POST to a pre-arranged endpoint provided by the SET	using an HTTP POST to a pre-arranged endpoint provided by the SET

	Transmitter or,</t>	Transmitter, or</li>
	<t>after validating previously received SETs, the SET Recipient	<li>after validating previously received SETs, the SET Recipient
	initiates another poll request using HTTP POST that includes	initiates another poll request using HTTP POST that includes
	acknowledgement of previous SETs and requests the next batch	acknowledgement of previous SETs and requests the next batch

	of SETs.</t>	of SETs.</li>
	</list></t>	</ul>
		<t>The purpose of the acknowledgement is to inform the
	<t>The purpose of the acknowledgement is to inform the
	SET Transmitter that delivery has succeeded and	SET Transmitter that delivery has succeeded and
	redelivery is no longer required.	redelivery is no longer required.
	Before acknowledgement, SET Recipients validate the received SETs	Before acknowledgement, SET Recipients validate the received SETs
	and retain them in a manner appropriate to the recipient's	and retain them in a manner appropriate to the recipient's
	requirements. The level and method of retention of SETs	requirements. The level and method of retention of SETs
	by SET Recipients is out of scope of this specification.</t>	by SET Recipients is out of scope of this specification.</t>
	</section>	</section>

		<section anchor="pollReq" numbered="true" toc="default">
	<section anchor="pollReq" title="Polling HTTP Request">	<name>Polling HTTP Request</name>
		<t>When initiating a poll request, the SET Recipient constructs
	<t>When initiating a poll request, the SET Recipient constructs
	a JSON document that consists of polling request parameters	a JSON document that consists of polling request parameters
	and SET acknowledgement parameters in the form of JSON objects.	and SET acknowledgement parameters in the form of JSON objects.

	</t>	</t>
		<t>When making a request, the HTTP <tt>Content-Type</tt> header field
	<t>When making a request, the HTTP <spanx style="verb">Content-Type</span	is set to <tt>application/json</tt>.</t>
	x> header field	<t>The following JSON object members are used in a polling request:
	is set to <spanx style="verb">application/json</spanx>.</t>	</t>
		<dl newline="true" spacing="normal">
	<t>The following JSON object members are used in a polling request:	<dt>Request Processing Parameters</dt>
	<list style="hanging">	<dd>
		<dl newline="true" spacing="normal">
	<t hangText="Request Processing Parameters"><list style="hanging">	<dt>maxEvents</dt>
		<dd>An <bcp14>OPTIONAL</bcp14> integer value
	<t hangText="maxEvents"><vspace/>An OPTIONAL integer value
	indicating the maximum number of unacknowledged SETs to be returned.	indicating the maximum number of unacknowledged SETs to be returned.

	The SET Transmitter SHOULD NOT send more SETs than the specified maxi mum.	The SET Transmitter <bcp14>SHOULD NOT</bcp14> send more SETs than the specified maximum.
	If more than the maximum number of SETs	If more than the maximum number of SETs
	are available, the SET Transmitter determines which to return first;	are available, the SET Transmitter determines which to return first;

	the oldest SETs available MAY returned first,	the oldest SETs available <bcp14>MAY</bcp14> be returned first,
	or another selection algorithm MAY be used,	or another selection algorithm <bcp14>MAY</bcp14> be used,
	such as prioritizing SETs in some manner that makes sense for the use case.	such as prioritizing SETs in some manner that makes sense for the use case.

	first. A value of <spanx style="verb">0</spanx> MAY be used by	A value of <tt>0</tt> <bcp14>MAY</bcp14> be used by
	SET Recipients that would like to perform an acknowledge-only	SET Recipients that would like to perform an acknowledge-only
	request. This enables the Recipient to use separate HTTP requests	request. This enables the Recipient to use separate HTTP requests
	for acknowledgement and reception of SETs.	for acknowledgement and reception of SETs.
	If this parameter is omitted, no limit is placed on	If this parameter is omitted, no limit is placed on
	the number of SETs to be returned.	the number of SETs to be returned.

	</t>	</dd>
		<dt>returnImmediately</dt>
	<t hangText="returnImmediately"><vspace/>An OPTIONAL JSON	<dd>An <bcp14>OPTIONAL</bcp14> JSON
	boolean value that indicates the SET Transmitter SHOULD return	boolean value that indicates the SET Transmitter <bcp14>SHOULD</bcp14
		> return
	an immediate response even if no results are available	an immediate response even if no results are available

	(short polling). The default value is <spanx style="verb">false</span	(short polling). The default value is <tt>false</tt>,
	x>,	which indicates the request is to be treated as an HTTP long poll,
	which indicates the request is to be treated as an HTTP Long Poll,	per <xref target="RFC6202" sectionFormat="of" section="2"/>. The time
	per Section 2 of <xref target="RFC6202"/>. The timeout for the	out for the
	request is part of the configuration between the participants, which is out of	request is part of the configuration between the participants, which is out of

	scope of this specification.</t>	scope of this specification.</dd>
		</dl>
	</list></t>	</dd> </dl>
		<dl newline="true" spacing="normal">
	<t hangText="SET Acknowledgment Parameters"><list style="hanging">	<dt>SET Acknowledgment Parameters</dt><dd>
		<dl newline="true" spacing="normal">
	<t hangText="ack">	<dt>ack</dt>
	<vspace/>	<dd>
	A JSON array of strings whose values	A JSON array of strings whose values are the <tt>jti</tt> <xref
	are the <spanx style="verb">jti</spanx> <xref target="RFC7519"/> val	target="RFC7519" format="default"/> values of successfully
	ues of	received SETs that are being acknowledged. If there are no
	successfully received SETs that are being acknowledged.	outstanding SETs to acknowledge, this member is omitted or
	If there are no outstanding SETs to acknowledge, this member is omit	contains an empty array. Once a SET has been acknowledged, the
	ted	SET Transmitter is released from any obligation to retain the
	or contains an empty array.	SET.
	Once a SET has been acknowledged, the SET Transmitter is released fr	</dd>
	om	<dt>setErrs</dt>
	any obligation to retain the SET.	<dd>
	</t>

	<t hangText="setErrs">
	<vspace/>
	A JSON object with one or more members whose keys	A JSON object with one or more members whose keys

	are the <spanx style="verb">jti</spanx> values of	are the <tt>jti</tt> values of
	invalid SETs received.	invalid SETs received.
	The values of these objects are themselves JSON objects that	The values of these objects are themselves JSON objects that
	describe the errors detected using the	describe the errors detected using the

	<spanx style="verb">err</spanx> and	<tt>err</tt> and
	<spanx style="verb">description</spanx> values	<tt>description</tt> values
	specified in <xref target="errorResponse"/>.	specified in <xref target="errorResponse" format="default"/>.
	If there are no outstanding SETs with errors to report, this member is omitted	If there are no outstanding SETs with errors to report, this member is omitted
	or contains an empty JSON object.	or contains an empty JSON object.

	</t>	</dd>
		</dl>
	</list></t>	</dd> </dl>
		</section>
	</list>	<section anchor="pollResp" numbered="true" toc="default">
	</t>	<name>Polling HTTP Response</name>
	</section>	<t>In response to a poll request, the SET Transmitter checks for

	<section anchor="pollResp" title="Polling HTTP Response">

	<t>In response to a poll request, the SET Transmitter checks for
	available SETs and responds with a JSON document containing	available SETs and responds with a JSON document containing
	the following JSON object members:	the following JSON object members:

	<list style="hanging">	</t>
		<dl newline="true" spacing="normal">
	<t hangText="sets"><vspace/>A JSON object containing zero or more SETs	<dt>sets</dt>
	being returned.	<dd>A JSON object containing zero or more SETs being returned.
	Each member name	Each member name

	is the <spanx style="verb">jti</spanx> of a SET to	is the <tt>jti</tt> of a SET to
	be delivered and its value is a JSON string representing the	be delivered, and its value is a JSON string representing the
	corresponding SET. If there are no	corresponding SET. If there are no

	outstanding SETs to be transmitted, the JSON object SHALL be	outstanding SETs to be transmitted, the JSON object <bcp14>SHALL</bcp14 > be
	empty.	empty.
	Note that both SETs being transmitted for the first time and	Note that both SETs being transmitted for the first time and

	SETs that are being re-transmitted after not having been acknowledged	SETs that are being retransmitted after not having been acknowledged
	are communicated here.	are communicated here.

	</t>	</dd>
		<dt>moreAvailable</dt>
	<t hangText="moreAvailable"><vspace/>A JSON boolean value that	<dd>A JSON boolean value that
	indicates if more unacknowledged SETs are available to be returned.	indicates if more unacknowledged SETs are available to be returned.

	This member MAY be omitted, with the meaning being the same as	This member <bcp14>MAY</bcp14> be omitted, with the meaning being the s
	including it with the boolean value <spanx style="verb">false</spanx>.	ame as
	</t>	including it with the boolean value <tt>false</tt>.
	</list>	</dd>
	</t>	</dl>
		<t>When making a response, the HTTP <tt>Content-Type</tt> header field
	<t>When making a response, the HTTP <spanx style="verb">Content-Type</spa	is set to <tt>application/json</tt>.</t>
	nx> header field
	is set to <spanx style="verb">application/json</spanx>.</t>
	</section>	</section>

		<section anchor="pollRequest" numbered="true" toc="default">
	<section anchor="pollRequest" title="Poll Request">	<name>Poll Request</name>
		<t>The SET Recipient performs an HTTP POST (see
	<t>The SET Recipient performs an HTTP POST (see	<xref target="RFC7231" sectionFormat="of" section="4.3.4"/>) to a pre-arr
	Section 4.3.4 of <xref target="RFC7231"/>) to a pre-arranged	anged
	polling endpoint URI to check for SETs that are available.	polling endpoint URI to check for SETs that are available.
	Because the SET Recipient has no prior SETs to	Because the SET Recipient has no prior SETs to

	acknowledge, the <spanx style="verb">ack</spanx> and	acknowledge, the <tt>ack</tt> and
	<spanx style="verb">setErrs</spanx> request parameters are omitted.</t>	<tt>setErrs</tt> request parameters are omitted.</t>
		<t>
	<t>
	After a period of time configured in an out-of-band manner between the SET	After a period of time configured in an out-of-band manner between the SET

	Transmitter and Recipient, a SET Transmitter MAY redeliver SETs	Transmitter and Recipient, a SET Transmitter <bcp14>MAY</bcp14> redeliver
	it has previously delivered. The SET Recipient SHOULD accept	SETs
		it has previously delivered. The SET Recipient <bcp14>SHOULD</bcp14> acce
		pt
	repeat SETs and acknowledge the SETs regardless of whether the	repeat SETs and acknowledge the SETs regardless of whether the
	Recipient believes it has already acknowledged the SETs previously.	Recipient believes it has already acknowledged the SETs previously.

	A SET Transmitter MAY limit the number of times it attempts to	A SET Transmitter <bcp14>MAY</bcp14> limit the number of times it attempt s to
	deliver a SET.	deliver a SET.

	</t>	</t>

	<t>If the SET Recipient has received SETs from the	<t>If the SET Recipient has received SETs from the
	SET Transmitter, the SET Recipient parses and validates that	SET Transmitter, the SET Recipient parses and validates that

	received SETs meet its own requirements and SHOULD acknowledge	received SETs meet its own requirements and <bcp14>SHOULD</bcp14> acknow ledge
	receipt in a timely fashion (e.g., seconds or minutes) so that the SET	receipt in a timely fashion (e.g., seconds or minutes) so that the SET

	Transmitter can mark the SETs as received. SET Recipients SHOULD	Transmitter can mark the SETs as received. SET Recipients <bcp14>SHOULD< /bcp14>
	acknowledge receipt before taking any local actions based on	acknowledge receipt before taking any local actions based on
	the SETs to avoid unnecessary delay in acknowledgement, where	the SETs to avoid unnecessary delay in acknowledgement, where
	possible.</t>	possible.</t>

		<dl newline="true"><dt>Poll requests have three variations:</dt>


	<t>Poll requests have three variations:	<dd>
	<list style="hanging">	<dl newline="true" spacing="normal">
	<t hangText="Poll-Only"><vspace/>In which a SET Recipient
		<dt>Poll-Only</dt>
		<dd>In this scenario, a SET Recipient
	asks for the next set of events where no previous SET deliveries	asks for the next set of events where no previous SET deliveries

	are acknowledged (such as in the initial poll request).</t>	are acknowledged (such as in the initial poll request).</dd>
	<t hangText="Acknowledge-Only"><vspace/>In which a SET	<dt>Acknowledge-Only</dt>
	Recipient sets the <spanx style="verb">maxEvents</spanx>	<dd>In this scenario, a SET
	value to <spanx style="verb">0</spanx> along with	Recipient sets the <tt>maxEvents</tt>
	<spanx style="verb">ack</spanx> and	value to <tt>0</tt> along with
	<spanx style="verb">setErrs</spanx> members indicating the	<tt>ack</tt> and
		<tt>setErrs</tt> members indicating the
	SET Recipient is acknowledging previously received SETs and	SET Recipient is acknowledging previously received SETs and
	does not want to receive any new SETs in response to the	does not want to receive any new SETs in response to the

	request. </t>	request. </dd>
	<t hangText="Combined Acknowledge and Poll"><vspace/>In	<dt>Combined Acknowledge and Poll</dt>
	which a SET Recipient is both acknowledging previously	<dd>In this scenario, a SET Recipient is both acknowledging previously
	received SETs using the <spanx style="verb">ack</spanx> and	received SETs using the <tt>ack</tt> and <tt>setErrs</tt> members
	<spanx style="verb">setErrs</spanx> members
	and will wait for the next group of SETs in the SET Transmitters	and will wait for the next group of SETs in the SET Transmitters

	response.</t>	response.</dd>
	</list></t>	</dl></dd></dl>
		<section anchor="PollOnlyRequest" numbered="true" toc="default">
	<section anchor="PollOnlyRequest" title="Poll-Only Request">	<name>Poll-Only Request</name>
	<t>In the case where no SETs were received in a previous poll (see	<t>In the case where no SETs were received in a previous poll (see
	<xref target="emptyPollResponse"/>), the SET Recipient simply	<xref target="emptyPollResponse" format="default"/>), the SET Recipient
	polls without acknowledgement parameters (<spanx style="verb">ack</span	simply
	x>	polls without acknowledgement parameters (<tt>ack</tt>
	and <spanx style="verb">setErrs</spanx>).</t>	and <tt>setErrs</tt>).</t>
		<t keepWithNext="true">
	<figure anchor="pollInitRequest" title="Example Initial Poll Request">
	<preamble>
	The following is a non-normative example request made by a SET Reci pient	The following is a non-normative example request made by a SET Reci pient
	that has no outstanding SETs to acknowledge and is polling	that has no outstanding SETs to acknowledge and is polling
	for available SETs at the endpoint	for available SETs at the endpoint

	<spanx style="verb">https://notify.idp.example.com/Events</spanx>:	<tt>https://notify.idp.example.com/Events</tt>:
	</preamble>	</t>
	<artwork><![CDATA[	<figure anchor="pollInitRequest">
		<name>Example Initial Poll Request</name>

		<sourcecode type="http-message" name=""><![CDATA[
	POST /Events HTTP/1.1	POST /Events HTTP/1.1
	Host: notify.idp.example.com	Host: notify.idp.example.com
	Content-Type: application/json	Content-Type: application/json

	{	{
	"returnImmediately": true	"returnImmediately": true
	}	}

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
		<t>A SET Recipient can poll using default parameter values by passing
	<t>A SET Recipient can poll using default parameter values by passing
	an empty JSON object.</t>	an empty JSON object.</t>

		<t keepWithNext="true">The following is a non-normative example defaul
	<figure anchor="pollDefaultRequest" title="Example Default Poll Request	t poll request to the
	">	endpoint <tt>https://notify.idp.example.com/Events</tt>:</t>
	<preamble>The following is a non-normative example default poll reque	<figure anchor="pollDefaultRequest">
	st to the	<name>Example Default Poll Request</name>
	endpoint <spanx style="verb">https://notify.idp.example.com/Events</s	<sourcecode name="" type="http-message"><![CDATA[
	panx>:</preamble>
	<artwork><![CDATA[
	POST /Events HTTP/1.1	POST /Events HTTP/1.1
	Host: notify.idp.example.com	Host: notify.idp.example.com
	Content-Type: application/json	Content-Type: application/json

	{}	{}

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
		<section anchor="AckOnlyRequest" numbered="true" toc="default">
	<section anchor="AckOnlyRequest" title="Acknowledge-Only Request">	<name>Acknowledge-Only Request</name>
	<t>In this variation, the SET Recipient acknowledges previously	<t>In this variation, the SET Recipient acknowledges previously
	received SETs and indicates it does not want to receive SETs in	received SETs and indicates it does not want to receive SETs in

	response by setting the <spanx style="verb">maxEvents</spanx>	response by setting the <tt>maxEvents</tt>
	value to <spanx style="verb">0</spanx>.	value to <tt>0</tt>.
	This variation might be used, for instance, when a SET Recipient needs to	This variation might be used, for instance, when a SET Recipient needs to
	acknowledge received SETs independently (e.g., on separate threads)	acknowledge received SETs independently (e.g., on separate threads)
	from the process of receiving SETs.	from the process of receiving SETs.

	</t>	</t>
	<t>	<t>
	If the poll needs to return immediately, then <spanx style="verb">ret	If the poll needs to return immediately, then <tt>returnImmediately</
	urnImmediately</spanx>	tt>
	MUST also be present with the value <spanx style="verb">true</spanx>.	<bcp14>MUST</bcp14> also be present with the value <tt>true</tt>.
	If it is <spanx style="verb">false</spanx>, then a long poll will sti	If it is <tt>false</tt>, then a long poll will still occur
	ll occur
	until an event is ready to be returned, even though no events will be returned.	until an event is ready to be returned, even though no events will be returned.

	</t>	</t>
		<t keepWithNext="true">The following is a non-normative example poll r
	<figure anchor="pollAckOnly" title="Example Acknowledge-Only Request">	equest with acknowledgement
	<preamble>The following is a non-normative example poll request with	of SETs received (for example, as shown in
	acknowledgement	<xref target="pollResponse" format="default"/>):</t>
	of SETs received (for example as shown in	<figure anchor="pollAckOnly">
	<xref target="pollResponse"/>):</preamble>	<name>Example Acknowledge-Only Request</name>
	<artwork><![CDATA[	<sourcecode name="" type="http-message"><![CDATA[
	POST /Events HTTP/1.1	POST /Events HTTP/1.1
	Host: notify.idp.example.com	Host: notify.idp.example.com
	Content-Type: application/json	Content-Type: application/json

	{	{
	"ack": [	"ack": [
	"4d3559ec67504aaba65d40b0363faad8",	"4d3559ec67504aaba65d40b0363faad8",
	"3d0c3cf797584bd193bd0fb1bd4e7d30"	"3d0c3cf797584bd193bd0fb1bd4e7d30"
	],	],
	"maxEvents": 0,	"maxEvents": 0,
	"returnImmediately": true	"returnImmediately": true
	}	}

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
		<section anchor="pollAck" numbered="true" toc="default">
	<section anchor="pollAck" title="Poll with Acknowledgement">	<name>Poll with Acknowledgement</name>
		<t>This variation allows a recipient thread to simultaneously
	<t>This variation allows a recipient thread to simultaneously
	acknowledge previously received SETs and wait for the next	acknowledge previously received SETs and wait for the next
	group of SETs in a single request.</t>	group of SETs in a single request.</t>

		<t keepWithNext="true">The following is a non-normative example poll w
	<figure anchor="pollGoodResponse" title="Example Poll with Acknowledgem	ith acknowledgement
	ent and No Errors">	of the SETs received in <xref target="pollResponse" format="default"/
	<preamble>The following is a non-normative example poll with acknowle	>:</t>
	dgement	<figure anchor="pollGoodResponse">
	of the SETs received in <xref target="pollResponse"/>:</preamble>	<name>Example Poll with Acknowledgement and No Errors</name>
	<artwork><![CDATA[	<sourcecode name="" type="http-message"><![CDATA[
	POST /Events HTTP/1.1	POST /Events HTTP/1.1
	Host: notify.idp.example.com	Host: notify.idp.example.com
	Content-Type: application/json	Content-Type: application/json

	{	{
	"ack": [	"ack": [
	"4d3559ec67504aaba65d40b0363faad8",	"4d3559ec67504aaba65d40b0363faad8",
	"3d0c3cf797584bd193bd0fb1bd4e7d30"	"3d0c3cf797584bd193bd0fb1bd4e7d30"
	],	],
	"returnImmediately": false	"returnImmediately": false
	}	}

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
		<t>In the above acknowledgement, the SET Recipient has acknowledged
	<t>In the above acknowledgement, the SET Recipient has acknowledged
	receipt of two SETs and has indicated it wants to wait until	receipt of two SETs and has indicated it wants to wait until
	the next SET is available.</t>	the next SET is available.</t>

	</section>	</section>
		<section anchor="pollAckErr" numbered="true" toc="default">
	<section anchor="pollAckErr" title="Poll with Acknowledgement and Errors"	<name>Poll with Acknowledgement and Errors</name>
	>	<t>In the case where errors were detected in previously
	<t>In the case where errors were detected in previously	delivered SETs, the SET Recipient <bcp14>MAY</bcp14> use the
	delivered SETs, the SET Recipient MAY use the	<tt>setErrs</tt> member to communicate the errors
	<spanx style="verb">setErrs</spanx> member to communicate the errors
	in the following poll request.	in the following poll request.

	</t>	</t>
		<t keepWithNext="true">The following is a non-normative example of a r
	<figure anchor="pollErrorResponse"	esponse
	title="Example Poll Acknowledgement with Error">
	<preamble>The following is a non-normative example of a response
	acknowledging one successfully received SET and one SET with an error	acknowledging one successfully received SET and one SET with an error

	from the two SETs received in <xref target="pollResponse"/>:</preambl	from the two SETs received in <xref target="pollResponse" format="def
	e>	ault"/>:</t>
	<artwork><![CDATA[	<figure anchor="pollErrorResponse">
		<name>Example Poll Acknowledgement with Error</name>
		<sourcecode name="" type="http-message"><![CDATA[
	POST /Events HTTP/1.1	POST /Events HTTP/1.1
	Host: notify.idp.example.com	Host: notify.idp.example.com
	Content-Language: en-US	Content-Language: en-US
	Content-Type: application/json	Content-Type: application/json

	{	{
	"ack": ["3d0c3cf797584bd193bd0fb1bd4e7d30"],	"ack": ["3d0c3cf797584bd193bd0fb1bd4e7d30"],
	"setErrs": {	"setErrs": {
	"4d3559ec67504aaba65d40b0363faad8": {	"4d3559ec67504aaba65d40b0363faad8": {

	"err": "authentication_failed",	"err": "authentication_failed",
	"description": "The SET could not be authenticated"	"description": "The SET could not be authenticated"
	}	}
	},	},
	"returnImmediately": true	"returnImmediately": true
	}	}

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
		</section>
	</section>
	</section>	</section>

		<section anchor="pollGetAck" numbered="true" toc="default">
	<section anchor="pollGetAck"	<name>Poll Response</name>
	title="Poll Response">	<t>In response to a valid poll request, the service provider <bcp14>MAY<
		/bcp14>
	<t>In response to a valid poll request, the service provider MAY
	respond immediately if SETs are available to be delivered.	respond immediately if SETs are available to be delivered.
	If no SETs are available at the time of the request, the	If no SETs are available at the time of the request, the

	SET Transmitter SHALL delay responding until a SET is	SET Transmitter <bcp14>SHALL</bcp14> delay responding until a SET is
	available or the timeout interval has elapsed unless the poll request par ameter	available or the timeout interval has elapsed unless the poll request par ameter

	<spanx style="verb">returnImmediately</spanx> is present with the value <	<tt>returnImmediately</tt> is present with the value <tt>true</tt>.
	spanx style="verb">true</spanx>.	</t>
	</t>	<t>As described in <xref target="pollResp" format="default"/>, a JSON do
		cument
	<t>As described in <xref target="pollResp"/>, a JSON document
	is returned containing members including	is returned containing members including

	<spanx style="verb">sets</spanx>, which SHALL contain zero or more	<tt>sets</tt>, which <bcp14>SHALL</bcp14> contain zero or more
	SETs.</t>	SETs.</t>

	<figure anchor="pollResponse" title="Example Poll Response">	<t keepWithNext="true">The following is a non-normative example response
	<preamble>The following is a non-normative example response to	to
	the request shown in <xref target="pollRequest"/>. This example	the request shown in <xref target="pollRequest" format="default"/>. Thi
	shows two SETs being returned:</preamble>	s example
	<artwork><![CDATA[	shows two SETs being returned:</t>
	HTTP/1.1 200 OK	<figure anchor="pollResponse">
	Content-Type: application/json	<name>Example Poll Response</name>

		<sourcecode name="" type="http-message"><![CDATA[
		HTTP/1.1 200 OK
		Content-Type: application/json


		{
		"sets":
	{	{

	"sets": {	"4d3559ec67504aaba65d40b0363faad8":
	"4d3559ec67504aaba65d40b0363faad8":	"eyJhbGciOiJub25lIn0.
	"eyJhbGciOiJub25lIn0.	eyJqdGkiOiI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsImlhdC
	eyJqdGkiOiI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsImlhdCI6MTQ	I6MTQ1ODQ5NjQwNCwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwi
	1ODQ5NjQwNCwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwiYXVkIjpbIm	YXVkIjpbImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MW
	h0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M	ZhNWJiYzg3OTU5M2I3NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0Zl
	2I3NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIx	ZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybj
	ZDA4NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybjppZXRmOnBhcmFtczpzY2ltOmV	ppZXRmOnBhcmFtczpzY2ltOmV2ZW50OmNyZWF0ZSI6eyJyZWYiOiJodHRwczov
	2ZW50OmNyZWF0ZSI6eyJyZWYiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcn	L3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1Mj
	MvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsImF0dHJpYnV0ZXMiOlsiaWQiLCJuY	FkOSIsImF0dHJpYnV0ZXMiOlsiaWQiLCJuYW1lIiwidXNlck5hbWUiLCJwYXNz
	W1lIiwidXNlck5hbWUiLCJwYXNzd29yZCIsImVtYWlscyJdfX19.",	d29yZCIsImVtYWlscyJdfX19.",
	"3d0c3cf797584bd193bd0fb1bd4e7d30":	"3d0c3cf797584bd193bd0fb1bd4e7d30":
	"eyJhbGciOiJub25lIn0.	"eyJhbGciOiJub25lIn0.
	eyJqdGkiOiIzZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIsImlhdCI6MTQ	eyJqdGkiOiIzZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIsImlhdC
	1ODQ5NjAyNSwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwiYXVkIjpbIm	I6MTQ1ODQ5NjAyNSwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwi
	h0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M	YXVkIjpbImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MW
	2I3NzU0IiwiaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIx	ZhNWJiYzg3OTU5M2I3NzU0IiwiaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0Zl
	ZDA4NjQxZDc2NzZlZTciXSwic3ViIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL1V	ZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciXSwic3ViIjoiaHR0cHM6Ly
	zZXJzLzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJldmVudHMiOnsidXJuOmlldG	9zY2ltLmV4YW1wbGUuY29tL1VzZXJzLzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIx
	Y6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldCI6eyJpZCI6IjQ0ZjYxNDJkZ	ZDkiLCJldmVudHMiOnsidXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3
	jk2YmQ2YWI2MWU3NTIxZDkifSwiaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50	dvcmRSZXNldCI6eyJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkifSwi
	L3Bhc3N3b3JkUmVzZXRFeHQiOnsicmVzZXRBdHRlbXB0cyI6NX19fQ."	aHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50L3Bhc3N3b3JkUmVzZXRFeH
	}	QiOnsicmVzZXRBdHRlbXB0cyI6NX19fQ."
	}	}

	]]></artwork>	}
	</figure>	]]></sourcecode>
	<t>In the above example, two SETs whose <spanx style="verb">jti</spanx> v	</figure>
	alues	<t>In the above example, two SETs whose <tt>jti</tt> values
	are <spanx style="verb">4d3559ec67504aaba65d40b0363faad8</spanx>	are <tt>4d3559ec67504aaba65d40b0363faad8</tt>
	and <spanx style="verb">3d0c3cf797584bd193bd0fb1bd4e7d30</spanx>	and <tt>3d0c3cf797584bd193bd0fb1bd4e7d30</tt>
	are delivered.</t>	are delivered.</t>

		<t keepWithNext="true">The following is a non-normative example response
	<figure anchor="emptyPollResponse" title="Example No SETs Poll Response">	to
	<preamble>The following is a non-normative example response to	the request shown in <xref target="PollOnlyRequest" format="default"/>,
	the request shown in <xref target="PollOnlyRequest"/>, which indicates	which indicates that no new
	that no new	SETs or unacknowledged SETs are available:</t>
	SETs or unacknowledged SETs are available:</preamble>	<figure anchor="emptyPollResponse">
	<artwork><![CDATA[	<name>Example No SETs Poll Response</name>
		<sourcecode name="" type="http-message"><![CDATA[
	HTTP/1.1 200 OK	HTTP/1.1 200 OK
	Content-Type: application/json	Content-Type: application/json

	{	{
	"sets": {}	"sets": {}
	}	}

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
		<t>Upon receiving the JSON document (e.g., as shown in <xref
	<t>Upon receiving the JSON document (e.g., as shown in	target="pollResponse" format="default"/>), the SET Recipient parses
	<xref target="pollResponse"/>), the SET Recipient parses	and verifies the received SETs and notifies the SET Transmitter of
	and verifies the received SETs and notifies the SET Transmitter	successfully received SETs and SETs with errors via the next poll
	of successfully received SETs and SETs with errors	request to the SET Transmitter, as described in Sections <xref
	via the next poll request to the SET Transmitter, as described in	target="pollAck" format="counter"/> and <xref target="pollAckErr"
	<xref target="pollAck"/> or <xref target="pollAckErr"/>.</t>	format="counter"/>.</t>
		<section anchor="PollErrorResponse" numbered="true" toc="default">
	<section anchor="PollErrorResponse" title="Poll Error Response">	<name>Poll Error Response</name>
	<t>In the event of a general HTTP error condition in the context of	<t>In the event of a general HTTP error condition in the context of
	processing a poll request, the service provider responds with	processing a poll request, the service provider responds with

	the applicable HTTP Response Status Code, as defined in Section	the applicable HTTP response status code, as defined in <xref ta
	6 of	rget="RFC7231" sectionFormat="of" section="6"/>.</t>
	<xref target="RFC7231" />.</t>


	<t>Service providers MAY respond to any invalid poll request with an	<t>Service providers <bcp14>MAY</bcp14> respond to any invalid poll re
	HTTP Response	quest with an HTTP response
	Status Code of 400 (Bad Request) even when a more specific code	status code of 400 (Bad Request) even when a more specific code
	might apply, for	might apply, for
	example if the service provider deemed that a more specific code	example, if the service provider deemed that a more specific cod
	presented an	e presented an
	information disclosure risk. When no more specific code might ap ply, the service	information disclosure risk. When no more specific code might ap ply, the service

	provider SHALL respond to an invalid poll request with an HTTP S	provider <bcp14>SHALL</bcp14> respond to an invalid poll
	tatus Code of 400.</t>	request with an HTTP status code of 400.</t>
		<t>
	<t>
	The response body for responses to invalid poll requests is left un defined,	The response body for responses to invalid poll requests is left un defined,

	and its contents SHOULD be ignored.	and its contents <bcp14>SHOULD</bcp14> be ignored.
	</t>	</t>
		<t keepWithNext="true">
	<figure title="Example Poll Error Response">
	<preamble>
	The following is a non-normative example of a response to an invalid poll request:	The following is a non-normative example of a response to an invalid poll request:

	</preamble>	</t>
	<artwork><![CDATA[	<figure>
		<name>Example Poll Error Response</name>
		<sourcecode name="" type="http-message"><![CDATA[
	HTTP/1.1 400 Bad Request	HTTP/1.1 400 Bad Request

	]]></artwork>	]]></sourcecode>
	</figure>	</figure>
	</section>	</section>
	</section>	</section>

		<section anchor="errorResponse" numbered="true" toc="default">
	<section anchor="errorResponse" title="Error Response Handling">	<name>Error Response Handling</name>
	<t>	<t>
	If a SET is invalid,	If a SET is invalid,

	error codes from the IANA "Security Event Token Delivery Error Codes"	error codes from the IANA "Security Event Token Error Codes"
	registry established by <xref target="I-D.ietf-secevent-http-push"/>	registry established by <xref target="RFC8935" format="default"/>
	are used in error responses.	are used in error responses.

	As described in Section 2.3 of <xref target="I-D.ietf-secevent-http-pus
	h"/>,	As described in <xref target="RFC8935"
	an error response is a JSON object providing details about the error	sectionFormat="of" section="2.3"/>, an error response is a JSON
	that includes the following name/value pairs:	object providing details about the error that includes the following
	</t>	name/value pairs:
	<t>	</t>
	<list style="hanging">	<dl newline="false" spacing="normal">
	<t hangText="err"><vspace />	<dt>err:</dt>
		<dd>
	A value from the	A value from the

	IANA "Security Event Token Delivery Error Codes" registry	IANA "Security Event Token Error Codes" registry
	that identifies the error.	that identifies the error.

	</t>	</dd>
	<t hangText="description"><vspace />	<dt>description:</dt>
		<dd>
	A human-readable string that provides	A human-readable string that provides
	additional diagnostic information.	additional diagnostic information.

	</t>	</dd>
	</list>	</dl>
	</t>	<t>
	<t>
	When included as part of a batch of SETs, the above JSON is included	When included as part of a batch of SETs, the above JSON is included

	as part of the <spanx style="verb">setErrs</spanx> member, as	as part of the <tt>setErrs</tt> member, as
	defined in <xref target="pollReq"/> and <xref target="pollAckErr"/>.	defined in Sections <xref target="pollReq" format="counter"/> and
	</t>	<xref target="pollAckErr" format="counter"/>.
		</t>
	<t>	<t>
	When the SET Recipient includes one or more error responses in a req uest to	When the SET Recipient includes one or more error responses in a req uest to
	the SET Transmitter, it must also include in the request a	the SET Transmitter, it must also include in the request a

	<spanx style="verb">Content-Language</spanx> header field whose valu e indicates the	<tt>Content-Language</tt> header field whose value indicates the
	language of the error descriptions included in the request. The met hod of	language of the error descriptions included in the request. The met hod of
	language selection in the case when the SET Recipient can provide er ror messages	language selection in the case when the SET Recipient can provide er ror messages
	in multiple languages is out of scope for this specification.	in multiple languages is out of scope for this specification.
	</t>	</t>
	</section>	</section>


	</section>	</section>

		<section anchor="aa" toc="default" numbered="true">
	<section anchor="aa" title="Authentication and Authorization" toc="default">	<name>Authentication and Authorization</name>
	<t>The SET delivery method described in this specification is	<t>The SET delivery method described in this specification is

	based upon HTTP over TLS <xref target="RFC2818"/> and standard	based upon HTTP over TLS <xref target="RFC2818" format="default"/> and sta ndard
	HTTP authentication and authorization schemes, as per	HTTP authentication and authorization schemes, as per

	<xref target="RFC7235" />.	<xref target="RFC7235" format="default"/>.
	The TLS server certificate MUST be validated using DNS-ID <xref target="RF	The TLS server certificate <bcp14>MUST</bcp14> be validated using DNS-ID <
	C6125"/>	xref target="RFC6125" format="default"/>
	and/or DANE <xref target="RFC6698"/>.	and/or DNS-Based Authentication of Named Entities (DANE) <xref target="RFC
	As per Section 4.1 of <xref target="RFC7235"/>, a SET	6698" format="default"/>.
	delivery endpoint SHALL indicate supported HTTP authentication	As per <xref target="RFC7235" sectionFormat="of" section="4.1"/>, a SET
	schemes via the <spanx style="verb">WWW-Authenticate</spanx> header field	delivery endpoint <bcp14>SHALL</bcp14> indicate supported HTTP authenticat
		ion
		schemes via the <tt>WWW-Authenticate</tt> header field
	when using HTTP authentication.	when using HTTP authentication.
	</t>	</t>


	<t>	<t>
	Authorization for the eligibility to provide actionable SETs can be deter mined by	Authorization for the eligibility to provide actionable SETs can be deter mined by
	using the identity of the SET Issuer,	using the identity of the SET Issuer,
	validating the identity of the SET Transmitter,	validating the identity of the SET Transmitter,
	or via other employed authentication methods.	or via other employed authentication methods.
	Likewise, the SET Transmitter may choose to validate the identity of the SET Recipient,	Likewise, the SET Transmitter may choose to validate the identity of the SET Recipient,
	perhaps using mutual TLS.	perhaps using mutual TLS.
	Because SETs are	Because SETs are
	not commands, SET Recipients are free to ignore SETs that	not commands, SET Recipients are free to ignore SETs that
	are not of interest after acknowledging their receipt.</t>	are not of interest after acknowledging their receipt.</t>

	skipping to change at line 670 ¶	skipping to change at line 655 ¶
	<t>	<t>
	Authorization for the eligibility to provide actionable SETs can be deter mined by	Authorization for the eligibility to provide actionable SETs can be deter mined by
	using the identity of the SET Issuer,	using the identity of the SET Issuer,
	validating the identity of the SET Transmitter,	validating the identity of the SET Transmitter,
	or via other employed authentication methods.	or via other employed authentication methods.
	Likewise, the SET Transmitter may choose to validate the identity of the SET Recipient,	Likewise, the SET Transmitter may choose to validate the identity of the SET Recipient,
	perhaps using mutual TLS.	perhaps using mutual TLS.
	Because SETs are	Because SETs are
	not commands, SET Recipients are free to ignore SETs that	not commands, SET Recipients are free to ignore SETs that
	are not of interest after acknowledging their receipt.</t>	are not of interest after acknowledging their receipt.</t>


	</section>	</section>

		<section anchor="Security" toc="default" numbered="true">
	<section anchor="Security" title="Security Considerations" toc="default">	<name>Security Considerations</name>
		<section anchor="payloadAuthentication" numbered="true" toc="default">
	<section anchor="payloadAuthentication" title="Authentication Using Signed	<name>Authentication Using Signed SETs</name>
	SETs">	<t>
	<t>
	JWS signed SETs can be	JWS signed SETs can be

	used (see <xref target="RFC7515"/> and Section 5 of <xref target="RFC84 17"/>)	used (see <xref target="RFC7515" format="default"/> and <xref target="R FC8417" sectionFormat="of" section="5"/>)
	to enable the SET Recipient	to enable the SET Recipient
	to validate that the SET Issuer is authorized to provide actionable SET s.	to validate that the SET Issuer is authorized to provide actionable SET s.

	</t>	</t>
	</section>	</section>


	<section anchor="HTTP" title="HTTP Considerations">	<section anchor="HTTP" numbered="true" toc="default">
	<t>SET delivery depends on the use of Hypertext Transfer Protocol and is	<name>HTTP Considerations</name>
	thus	<t>SET delivery depends on the use of the Hypertext Transfer Protocol an
	subject to the security considerations of HTTP Section 9 of <xref	d is thus
	target="RFC7230"/> and its related specifications.</t>	subject to the security considerations of HTTP (<xref
		target="RFC7230" sectionFormat="of" section="9"/>) and its related specif
		ications.</t>
	</section>	</section>

		<section anchor="Confidentiality" numbered="true" toc="default">
	<section anchor="Confidentiality" title="Confidentiality of SETs">	<name>Confidentiality of SETs</name>
	<t>	<t>

	SETs may contain sensitive information, including Personally Identifiab	SETs may contain sensitive information, including Personally
	le Information (PII),	Identifiable Information (PII), or be distributed through third
	or be distributed through third parties.	parties. In such cases, SET Transmitters and SET Recipients
	In such cases, SET Transmitters and	<bcp14>MUST</bcp14> protect the confidentiality of the SET contents.
	SET Recipients MUST protect the confidentiality of the SET contents.	In some use cases, using TLS to secure the transmitted SETs will be
	In some use cases, using TLS to secure the transmitted SETs will be suf	sufficient. In other use cases, encrypting the SET as described in
	ficient.	JSON Web Encryption (JWE) <xref target="RFC7516" format="default"/> wil
	In other use cases,	l also be required.
	encrypting the SET as described in JWE <xref target="RFC7516"/> will al	The Event delivery endpoint <bcp14>MUST</bcp14> support at least TLS
	so be required.	version 1.2 <xref target="RFC5246" format="default"/> and
	The Event delivery endpoint MUST support at least TLS	<bcp14>SHOULD</bcp14> support the newest version of TLS that meets
	version 1.2 <xref target="RFC5246"/> and SHOULD support the newest vers	its security requirements, which as of the time of this publication
	ion	is TLS 1.3 <xref target="RFC8446" format="default"/>. The client
	of TLS that meets its security requirements,	<bcp14>MUST</bcp14> perform a TLS/SSL server certificate check using
	which as of the time of this publication is TLS 1.3 <xref target="RFC84	DNS-ID <xref target="RFC6125" format="default"/> and/or DANE <xref
	46"/>.	target="RFC6698" format="default"/>. How a SET Recipient determines
	The client MUST	the expected service identity to match the SET Transmitter's server
	perform a TLS/SSL server certificate check using DNS-ID <xref target="R	certificate against is out of scope for this document. The
	FC6125"/>	implementation security considerations for TLS in "Recommendations
	and/or DANE <xref target="RFC6698"/>.	for Secure Use of Transport Layer Security (TLS) and Datagram
	How a SET Recipient determines the expected service identity to match	Transport Layer Security (DTLS)" <xref target="RFC7525"
	the SET	format="default"/> <bcp14>MUST</bcp14> be followed.
	Transmitter's server certificate against is out of scope for this docu	</t>
	ment.
	The implementation security considerations for TLS in
	"Recommendations for Secure Use of TLS and DTLS" <xref target="RFC7525"
	/>
	MUST be followed.
	</t>
	</section>	</section>

		<section anchor="AT" numbered="true" toc="default">
	<section anchor="AT" title="Access Token Considerations">	<name>Access Token Considerations</name>
	<t>	<t>

	If HTTP Authentication is performed using OAuth access tokens <xref tar	If HTTP Authentication is performed using OAuth access tokens <xref tar
	get="RFC6749"/>,	get="RFC6749" format="default"/>,
	implementers MUST take into account the threats	implementers <bcp14>MUST</bcp14> take into account the threats
	and countermeasures documented in Section 8 of <xref	and countermeasures documented in <xref target="RFC7521"
	target="RFC7521"/>.</t>	sectionFormat="of" section="8"/>.</t>
		<section anchor="bearerConsiderations" numbered="true" toc="default">
	<section anchor="bearerConsiderations"	<name>Bearer Token Considerations</name>
	title="Bearer Token Considerations">
	<t>
	Transmitting Bearer tokens <xref target="RFC6750"/> using TLS helps p
	revent their interception.
	</t>


	<t>Bearer tokens SHOULD have a limited lifetime that can be determined	<t>
		Transmitting bearer tokens <xref target="RFC6750" format="default"/>
		using TLS helps prevent their interception.
		</t>
		<t>Bearer tokens <bcp14>SHOULD</bcp14> have a limited lifetime that ca
		n be determined
	directly or indirectly (e.g., by checking with a validation service)	directly or indirectly (e.g., by checking with a validation service)
	by the service provider. By expiring tokens, clients are forced to	by the service provider. By expiring tokens, clients are forced to
	obtain a new token (which usually involves re-authentication) for	obtain a new token (which usually involves re-authentication) for

	continued authorized access. For example, in OAuth 2.0, a client MAY us e	continued authorized access. For example, in OAuth 2.0, a client <bcp14 >MAY</bcp14> use
	an OAuth refresh token to obtain a new bearer token after authenticatin g	an OAuth refresh token to obtain a new bearer token after authenticatin g

	to an authorization server, per Section 6 of <xref	to an authorization server, per <xref target="RFC6749" sectionFormat="o
	target="RFC6749"/>.</t>	f" section="6"/>.</t>
		<t>Implementations supporting OAuth bearer tokens need to factor in
	<t>Implementations supporting OAuth bearer tokens need to factor in	security considerations of this authorization method <xref target="RFC7
	security considerations of this authorization method <xref	521" format="default"/>. Since security is only as good
	target="RFC7521"/>. Since security is only as good
	as the weakest link, implementers also need to consider authentication	as the weakest link, implementers also need to consider authentication
	choices coupled with OAuth bearer tokens. The security considerations	choices coupled with OAuth bearer tokens. The security considerations
	of the default authentication method for OAuth bearer tokens, HTTP	of the default authentication method for OAuth bearer tokens, HTTP

	Basic, are well documented in <xref	Basic, are well documented in <xref target="RFC7617" format="default"/>
	target="RFC7617"/>, therefore implementers	; therefore, implementers
	are encouraged to prefer stronger authentication methods.	are encouraged to prefer stronger authentication methods.

	</t>	</t>
	</section>	</section>
	</section>	</section>


	</section>	</section>

		<section anchor="Privacy" numbered="true" toc="default">
	<section anchor="Privacy" title="Privacy Considerations">	<name>Privacy Considerations</name>

	<t>SET Transmitters should attempt to deliver SETs that are	<t>SET Transmitters should attempt to deliver SETs that are
	targeted to the specific business and	targeted to the specific business and
	protocol needs of subscribers.</t>	protocol needs of subscribers.</t>


	<t>When sharing personally identifiable information or information	<t>When sharing personally identifiable information or information
	that is otherwise considered confidential to affected users, SET	that is otherwise considered confidential to affected users, SET

	Transmitters and Recipients MUST have the appropriate legal agreements	Transmitters and Recipients <bcp14>MUST</bcp14> have the appropriate legal agreements
	and user consent or terms of service in place.	and user consent or terms of service in place.

	Furthermore, data that needs confidentiality protection MUST be encrypted,	Furthermore, data that needs confidentiality protection <bcp14>MUST</bcp14 > be encrypted,
	at least with TLS	at least with TLS

	and sometimes also using JSON Web Encryption (JWE) <xref target="RFC7516"/ >.	and sometimes also using JSON Web Encryption (JWE) <xref target="RFC7516" format="default"/>.
	</t>	</t>


	<t>	<t>
	In some cases, subject identifiers themselves may be considered sensitive	In some cases, subject identifiers themselves may be considered sensitive
	information, such that their inclusion within a SET may be considered a v iolation	information, such that their inclusion within a SET may be considered a v iolation
	of privacy. SET Issuers and SET Transmitters should consider the ramific ations of sharing a	of privacy. SET Issuers and SET Transmitters should consider the ramific ations of sharing a
	particular subject identifier with a SET Recipient (e.g., whether doing s o could	particular subject identifier with a SET Recipient (e.g., whether doing s o could
	enable correlation and/or de-anonymization of data) and choose appropriat e	enable correlation and/or de-anonymization of data) and choose appropriat e
	subject identifiers for their use cases.	subject identifiers for their use cases.
	</t>	</t>


	</section>	</section>

		<section anchor="IANA" numbered="true" toc="default">
	<section anchor="IANA" title="IANA Considerations">	<name>IANA Considerations</name>

	<t>	<t>

	This specification requires no IANA actions.	This document has no IANA actions.
	</t>	</t>


	</section>	</section>
	</middle>	</middle>


	<back>	<back>

	<references title="Normative References">
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.2119.xml' ?>
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.2818.xml' ?><!-- HTTP over TLS -->
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.5246.xml' ?><!-- TLS 1.2 -->
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.6125.xml' ?><!-- TLS Certs -->
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.6698.xml' ?><!-- DANE -->
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.7231.xml' ?><!-- HTTP Semantics -->


	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<references>
	FC.7515.xml' ?><!-- JWS -->	<name>References</name>
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.7516.xml' ?><!-- JWE -->
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.7519.xml' ?><!-- JWT -->
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.7521.xml' ?><!-- Client Auth Assertions -->


	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<references>
	FC.7525.xml' ?><!-- TLS Recos -->
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.8174.xml' ?><!-- RFC 2119 bis -->
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.8259.xml' ?><!-- JSON -->
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.8417.xml' ?><!-- SET -->
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.8446.xml' ?><!-- TLS 1.3 -->


	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.	<name>Normative References</name>
	I-D.draft-ietf-secevent-http-push-12.xml" ?>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</references>	FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2818.xml"/>


	<references title="Informative References">	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	.5246.xml"/>
	FC.6202.xml' ?><!-- HTTP Long Polling -->


	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	FC.6749.xml' ?><!-- OAuth -->	.6125.xml"/>
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.6750.xml' ?><!-- OAuth Bearer -->


	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	FC.7230.xml' ?><!-- HTTP Msg -->	.6698.xml"/>
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
	FC.7235.xml' ?><!-- HTTP Auth -->


	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R FC.7617.xml' ?><!-- Basic Auth Update -->	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .7231.xml"/>


	</references>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .7515.xml"/>


	<section anchor="Unencrypted" title="Unencrypted Transport Considerations">	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.7516.xml"/>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.7519.xml"/>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.7521.xml"/>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.7525.xml"/>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.8174.xml"/>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.8259.xml"/>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.8417.xml"/>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.8446.xml"/>

		<reference anchor="RFC8935" target="https://www.rfc-editor.org/info/rfc8935">
		<front>
		<title>Push-Based Security Event Token (SET) Delivery Using HTTP</title>

		<author initials='A' surname='Backman' fullname='Annabelle Backman' role='editor
		'>
		</author>

		<author initials='M' surname='Jones' fullname='Michael Jones'>
		</author>

		<author initials='M' surname='Scurtescu' fullname='Marius Scurtescu'>
		</author>

		<author initials='M' surname='Ansari' fullname='Morteza Ansari'>
		</author>

		<author initials='A' surname='Nadalin' fullname='Anthony Nadalin'>
		</author>

		<date month='October' year='2020' />

		</front>

		<seriesInfo name="RFC" value="8935"/>
		<seriesInfo name="DOI" value="10.17487/RFC8935"/>
		</reference>

		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6202.xml"/>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.6749.xml"/>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.6750.xml"/>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.7230.xml"/>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.7235.xml"/>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
		.7617.xml"/>

		</references>
		</references>
		<section anchor="Unencrypted" numbered="true" toc="default">
		<name>Unencrypted Transport Considerations</name>
	<t>	<t>
	Earlier versions of this specification made the use of TLS optional	Earlier versions of this specification made the use of TLS optional
	and described security and privacy considerations resulting from use	and described security and privacy considerations resulting from use
	of unencrypted HTTP as the underlying transport.	of unencrypted HTTP as the underlying transport.

	When the working group decided to mandate usage HTTP over TLS,	When the working group decided to mandate usage of HTTP over TLS,
	it also decided to preserve the description of these considerations	it also decided to preserve the description of these considerations
	in a non-normative manner.	in a non-normative manner.
	</t>	</t>
	<t>	<t>
	The considerations for using unencrypted HTTP with this protocol	The considerations for using unencrypted HTTP with this protocol

	are the same as those described in Appendix A of <xref target="I-D.ietf-s	are the same as those described in <xref
	ecevent-http-push"/>,	target="RFC8935" sectionFormat="of"
	and are therefore not repeated here.	section="A"/>,
	</t>
	</section>

	<section anchor="Others" title="Other Streaming Specifications">
	<t>[[ NOTE TO THE RFC EDITOR: This section to be removed prior to publicat
	ion ]]</t>
	<t>
	A number of pub/sub, queuing, and streaming systems were reviewed
	as possible solutions or as input to the current draft.
	These are listed in Appendix B of <xref target="I-D.ietf-secevent-http-pu
	sh"/>,
	and are therefore not repeated here.	and are therefore not repeated here.
	</t>	</t>
	</section>	</section>


	<section anchor="Acknowledgments" title="Acknowledgments">	<section anchor="Acknowledgments" numbered="false" toc="default">
		<name>Acknowledgments</name>
	<t>	<t>

	The editors would like to thank the members of the SCIM working group, wh	The editors would like to thank the members of the SCIM Working Group,
	ich	which began discussions of provisioning events starting with
	began discussions of provisioning events starting with draft-hunt-scim-no	draft-hunt-scim-notify-00 in 2015. We would like to thank <contact
	tify-00 in 2015.	fullname="Phil Hunt"/> and the other authors of
	We would like to thank Phil Hunt and the other the authors of draft-ietf-	draft-ietf-secevent-delivery-02, upon which this specification is
	secevent-delivery-02,	based. We would like to thank the participants in the SecEvents
	upon which this specification is based.	Working Group for their contributions to this specification.
	We would like to thank the participants in the SecEvents
	working group for their contributions to this specification.
	</t>	</t>
	<t>	<t>

	Additionally, we would like to thank the following individuals for their	Additionally, we would like to thank the following individuals for their
	reviews of the specification:	reviews of this specification:
	Roman Danyliw,	<contact fullname="Roman Danyliw"/>,
	Martin Duke,	<contact fullname="Martin Duke"/>,
	Benjamin Kaduk,	<contact fullname="Benjamin Kaduk"/>,
	Erik Kline,	<contact fullname="Erik Kline"/>,
	Murray Kucherawy,	<contact fullname="Murray Kucherawy"/>,
	Warren Kumari,	<contact fullname="Warren Kumari"/>,
	Barry Leiba,	<contact fullname="Barry Leiba"/>,
	Mark Nottingham,	<contact fullname="Mark Nottingham"/>,
	Alvaro Retana,	<contact fullname="Alvaro Retana"/>,
	Yaron Sheffer,	<contact fullname="Yaron Sheffer"/>,
	Valery Smyslov,	<contact fullname="Valery Smyslov"/>,
	Robert Sparks,	<contact fullname="Robert Sparks"/>,
	Éric Vyncke,	<contact fullname="Éric Vyncke"/>,
	and	and

	Robert Wilton.	<contact fullname="Robert Wilton"/>.
	</t>	</t>
	</section>	</section>


	<section anchor="History" title="Change Log">

	<t>[[ to be removed by the RFC Editor before publication as an RFC ]]</t>

	<t>
	Draft 00 - AB - Based on draft-ietf-secevent-delivery-02 with the
	following additions:
	<list style="symbols">
	<t>Renamed to "Poll-Based SET Token Delivery Using HTTP"</t>
	<t>Removed references to the HTTP Push delivery method.</t>
	</list>
	</t>
	<t>
	Draft 01 - mbj:
	<list style="symbols">
	<t>
	Addressed problems identified in my 18-Jul-18 review message titled
	"Issues for both the Push and Poll Specs".
	</t>
	<t>
	Changes to align terminology with RFC 8417, for instance,
	by using the already defined term SET Recipient rather than SET Recei
	ver.
	</t>
	<t>
	Applied editorial and minor normative corrections.
	</t>
	<t>
	Updated Marius' contact information.
	</t>
	<t>
	Begun eliminating redundancies between this specification and
	"Push-Based Security Event Token (SET) Delivery Using HTTP"
	<xref target="I-D.ietf-secevent-http-push"/>,
	referencing, rather that duplicating common normative text.
	</t>
	</list>
	</t>
	<t>
	Draft 02 - mbj:
	<list style="symbols">
	<t>
	Removed vestigial language remaining from when the push and poll
	delivery methods were defined in a common specification.
	</t>
	<t>
	Replaced remaining uses of the terms Event Transmitter and Event Reci
	pient
	with the correct terms SET Transmitter and SET Recipient.
	</t>
	<t>
	Removed uses of the unnecessary term "Event Stream".
	</t>
	<t>
	Removed dependencies between the semantics of
	<spanx style="verb">maxEvents</spanx> and <spanx style="verb">returnI
	mmediately</spanx>.
	</t>
	<t>
	Said that PII in SETs is to be encrypted with TLS, JWE, or both.
	</t>
	<t>
	Corrected grammar and spelling errors.
	</t>
	</list>
	</t>
	<t>
	Draft 03 - mbj:
	<list style="symbols">
	<t>
	Corrected uses of "attribute" to "member" when describing JSON object
	s.
	</t>
	<t>
	Further alignment with the push draft.
	</t>
	</list>
	</t>
	<t>
	Draft 04 - AB + mbj
	<list style="symbols">
	<t>
	Referenced SET Transmitter definition in http-push.
	</t>
	<t>
	Removed incorrect normative text regarding SET construction.
	</t>
	<t>
	Consolidated general out-of-scope items under Introduction.
	</t>
	<t>
	Removed unnecessary HTTP headers in examples and added Content-Type.
	</t>
	<t>
	Added Content-Language requirement for error descriptions, aligning
	with http-push.
	</t>
	<t>
	Stated that bearer tokens SHOULD have a limited lifetime.
	</t>
	<t>
	Minor editorial fixes.
	</t>
	</list>
	</t>
	<t>
	Draft 05 - AB + mbj
	<list style="symbols">
	<t>
	Added normative text defining how to respond to invalid poll request
	s.
	</t>
	<t>
	Addressed shepherd comments by Yaron Sheffer.
	</t>
	</list>
	</t>
	<t>
	Draft 06 - mbj
	<list style="symbols">
	<t>
	Addressed nits identified by the idnits tool.
	</t>
	</list>
	</t>
	<t>
	Draft 07 - mbj
	<list style="symbols">
	<t>
	Addressed area director review comments by Benjamin Kaduk.
	</t>
	</list>
	</t>
	<t>
	Draft 08 - mbj + AB
	<list style="symbols">
	<t>
	Corrected editorial nits.
	</t>
	</list>
	</t>
	<t>
	Draft 09 - AB
	<list style="symbols">
	<t>
	Addressed area director review comments by Benjamin Kaduk:
	<list style="symbols">
	<t>Added text clarifying that determining the SET Recipient's serv
	ice identity is out of scope.</t>
	<t>Removed unelaborated reference to use of authentication to prev
	ent DoS attacks.</t>
	</list>
	</t>
	</list>
	</t>
	<t>
	Draft 10 - mbj
	<list style="symbols">
	<t>
	Addressed SecDir review comments by Valery Smyslov
	on draft-ietf-secevent-http-push-10 that also applied here.
	</t>
	<t>
	Addressed IETF last call comments by Mark Nottingham.
	</t>
	<t>
	Addressed GenArt review comments by Robert Sparks.
	</t>
	</list>
	</t>
	<t>
	Draft 11 - mbj
	<list style="symbols">
	<t>
	Revised to unambiguously require the use of TLS,
	while preserving descriptions of precautions needed for non-TLS use i
	n an appendix.
	</t>
	</list>
	</t>
	<t>
	Draft 12 - mbj
	<list style="symbols">
	<t>
	Addressed IESG comments.
	</t>
	</list>
	</t>
	</section>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 155 change blocks.
	803 lines changed or deleted	618 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/