rfc8935xml2.original.xml   rfc8935.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 <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
fc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-secevent-http-push-14" ipr="trust200902"
>
<front>
<title abbrev="draft-ietf-secevent-http-push">Push-Based Security Event
Token (SET) Delivery Using HTTP</title>
<author fullname="Annabelle Backman" initials="A." surname="Backman" rol
e="editor">
<organization abbrev="Amazon">Amazon</organization>
<address>
<email>richanna@amazon.com</email>
</address>
</author>
<author fullname="Michael B. Jones" initials="M." surname="Jones" role="
editor">
<organization abbrev="Microsoft">Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
<uri>https://self-issued.info/</uri>
</address>
</author>
<author fullname="Marius Scurtescu" initials="M.S." surname="Scurtescu">
<organization abbrev="Coinbase">Coinbase</organization>
<address>
<email>marius.scurtescu@coinbase.com</email>
</address>
</author>
<author fullname="Morteza Ansari" initials="M." surname="Ansari">
<organization abbrev="Cisco">Cisco</organization>
<address>
<email>morteza.ansari@cisco.com</email>
</address>
</author>
<author fullname="Anthony Nadalin" initials="A." surname="Nadalin">
<organization abbrev="Microsoft">Microsoft</organization>
<address>
<email>tonynad@microsoft.com</email>
</address>
</author>
<date year="2020" month="June" day="26" /> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
docName="draft-ietf-secevent-http-push-14" ipr="trust200902" obsoletes=""
updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
tocDepth="3" symRefs="true" sortRefs="true" version="3" consensus="yes"
number="8935">
<area>Security</area> <front>
<workgroup>Security Events Working Group</workgroup> <title abbrev="Push-Based SET Using HTTP">Push-Based Security Event Token (S
<keyword>Internet-Draft</keyword> ET) Delivery Using HTTP</title>
<seriesInfo name="RFC" value="8935"/>
<author fullname="Annabelle Backman" initials="A." surname="Backman" role="e
ditor">
<organization>Amazon</organization>
<address>
<email>richanna@amazon.com</email>
</address>
</author>
<author fullname="Michael B. Jones" initials="M." surname="Jones" role="edit
or">
<organization>Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
<uri>https://self-issued.info/</uri>
</address>
</author>
<author fullname="Marius Scurtescu" initials="M." surname="Scurtescu">
<organization>Coinbase</organization>
<address>
<email>marius.scurtescu@coinbase.com</email>
</address>
</author>
<author fullname="Morteza Ansari" initials="M." surname="Ansari">
<organization>Independent</organization>
<address>
<email>morteza@sharppics.com</email>
</address>
</author>
<author fullname="Anthony Nadalin" initials="A." surname="Nadalin">
<organization>Independent</organization>
<address>
<email>nadalin@prodigy.net</email>
</address>
</author>
<date year="2020" month="November"/>
<area>Security</area>
<workgroup>Security Events Working Group</workgroup>
<abstract> <keyword>JSON Web Token</keyword>
<t> <keyword>JWT</keyword>
This specification defines how a Security Event Token (SET) <keyword>Security Event Token</keyword>
can be delivered to an intended recipient using HTTP POST over T <keyword>SET</keyword>
LS. <keyword>Delivery</keyword>
The SET is transmitted in the body of an HTTP POST request to an <keyword>JavaScript Object Notation</keyword>
endpoint operated by the recipient, and the recipient indicates <keyword>JSON</keyword>
successful or failed transmission via the HTTP response.
</t>
</abstract>
</front>
<middle> <abstract>
<section anchor="intro" title="Introduction and Overview" toc="default"> <t>
This specification defines how a Security Event Token (SET) can be
delivered to an intended recipient using HTTP POST over TLS. The SET
is transmitted in the body of an HTTP POST request to an endpoint
operated by the recipient, and the recipient indicates successful or
failed transmission via the HTTP response.
</t>
</abstract>
</front>
<middle>
<t> <section anchor="intro" toc="default" numbered="true">
<name>Introduction and Overview</name>
<t>
This specification defines a mechanism by which a transmitter of a This specification defines a mechanism by which a transmitter of a
<xref target="RFC8417">Security Event Token (SET)</xref> can del <xref target="RFC8417" format="default">Security Event Token (SE
iver T)</xref> can deliver
the SET to an intended SET Recipient via <xref target="RFC7231"> the SET to an intended SET Recipient via <xref target="RFC7231"
HTTP POST</xref> format="default">HTTP POST</xref>
over TLS. over TLS.
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-poll"/>. <xref target="RFC8936" format="default"/>.
</t> </t>
<t> <t>
Push-based SET delivery over HTTP POST is intended for scenarios where all of Push-based SET delivery over HTTP POST is intended for scenarios where all of
the following apply: the following apply:
<list style="symbols"> </t>
<t>The transmitter of the SET is capable of making outbound <ul spacing="normal">
HTTP requests.</t> <li>The transmitter of the SET is capable of making outbound HTTP reques
<t> ts.</li>
<li>
The recipient is capable of hosting a TLS-enabled HTTP e ndpoint that is accessible The recipient is capable of hosting a TLS-enabled HTTP e ndpoint that is accessible
to the transmitter. to the transmitter.
</t> </li>
<t> <li>
The transmitter and recipient are willing to exchange data with one another. The transmitter and recipient are willing to exchange data with one another.
</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 endpoi nt URLs, A mechanism for exchanging configuration metadata such as endpoi nt URLs,
cryptographic keys, cryptographic keys,
and possible implementation constraints such as buffer size limit ations and possible implementation constraints such as buffer size limit ations
between the transmitter and recipient is between the transmitter and recipient is
out of scope for this specification. How SETs are defined and th e process out of scope for this specification. How SETs are defined and th e process
by which security events are identified for SET Recipients are s pecified by which security events are identified for SET Recipients are s pecified
in <xref target="RFC8417"/>. in <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>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDE "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
D", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
described in BCP 14 <xref target="RFC2119"/> <xref target="R to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
FC8174"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals,
when, and only when, they appear in all capitals, as shown h as shown here.
ere. </t>
</t> <t>
Throughout this document, all figures may contain spaces and extra
<t> line wrapping for readability and due to space limitations.
Throughout this document, all figures may contain spaces and ex </t>
tra </section>
line wrapping for readability and due to space limitations. <section anchor="defs" toc="default" numbered="true">
</t> <name>Definitions</name>
</section> <t>
This specification utilizes the following terms defined in <
<section anchor="defs" title="Definitions" toc="default"> xref target="RFC8417" format="default"/>:
<t>
This specification utilizes the following terms defined in <
xref target="RFC8417"/>:
"Security Event Token (SET)", "SET Issuer", "SET Recipient", and "Event Payload", "Security Event Token (SET)", "SET Issuer", "SET Recipient", and "Event Payload",
as well as the term defined below: as well as the term defined below:
</t> </t>
<t>
<list style="hanging">
<t hangText="SET Transmitter">
An entity that delivers SETs in its possession to on
e or more SET
Recipients.
</t>
</list>
</t>
</section>
</section>
<section anchor="Delivery" title="SET Delivery"> <dl newline="false" spacing="normal">
<t> <dt>SET Transmitter:</dt>
<dd>
An entity that delivers SETs in its possession to one or more SET
Recipients.
</dd>
</dl>
</section>
</section>
<section anchor="Delivery" numbered="true" toc="default">
<name>SET Delivery</name>
<t>
To deliver a SET to a given SET Recipient, the SET Transmitter To deliver a SET to a given SET Recipient, the SET Transmitter
makes a SET transmission request to the SET Recipient, with the SET makes a SET Transmission Request to the SET Recipient, with the SET
itself contained within the request. The SET Recipient replies t o itself contained within the request. The SET Recipient replies t o
this request with a response either acknowledging successful this request with a response either acknowledging successful
transmission of the SET or indicating that an error occurred transmission of the SET or indicating that an error occurred
while receiving, parsing, and/or validating the SET. while receiving, parsing, and/or validating the SET.
</t> </t>
<t> <t>
Upon receipt of a SET, the SET Recipient SHALL validate that all Upon receipt of a SET, the SET Recipient <bcp14>SHALL</bcp14> va
of lidate that all of
the following are true: the following are true:
<list style="symbols"> </t>
<t>The SET Recipient can parse the SET.</t> <ul spacing="normal">
<t> <li>The SET Recipient can parse the SET.</li>
<li>
The SET is authentic (i.e., it was issued by the issuer The SET is authentic (i.e., it was issued by the issuer
specified within the SET, specified within the SET,
and if signed, was signed by a key belonging to the issue r). and if signed, was signed by a key belonging to the issue r).
</t> </li>
<t> <li>
The SET Recipient is identified as an intended audience of The SET Recipient is identified as an intended audience of
the SET. the SET.
</t> </li>
<t> <li>
The SET Issuer is recognized as an issuer that the SET R ecipient The SET Issuer is recognized as an issuer that the SET R ecipient
is willing to receive SETs from (e.g., the issuer is lis ted as allowed is willing to receive SETs from (e.g., the issuer is lis ted as allowed
by the SET Recipient). by the SET Recipient).
</t> </li>
<t> <li>
The SET Recipient is willing to accept this SET from this S ET Transmitter The SET Recipient is willing to accept this SET from this S ET Transmitter
(e.g., the SET Transmitter is expected to send SETs (e.g., the SET Transmitter is expected to send SETs
with the issuer and subject of the SET in question). with the issuer and subject of the SET in question).
</t> </li>
</list> </ul>
</t>
<t> <t>
The mechanisms by which the SET Recipient performs this validati on The mechanisms by which the SET Recipient performs this validati on
are out of scope for this document. SET parsing, issuer identifi cation, are out of scope for this document. SET parsing, issuer identifi cation,
and audience identification are defined in <xref target="RFC8417" />. and audience identification are defined in <xref target="RFC8417" format="default"/>.
The mechanism for validating the authenticity of a SET is deploy ment The mechanism for validating the authenticity of a SET is deploy ment
specific, and may vary depending on the authentication mechanism specific and may vary depending on the authentication mechanisms
s in in
use, and whether the SET is signed and/or encrypted (See <xref t use and whether the SET is signed and/or encrypted (See <xref ta
arget="aa"/>). rget="aa" format="default"/>).
</t> </t>
<t> <t>
SET Transmitters MAY transmit SETs issued by another entity. The SET Transmitters <bcp14>MAY</bcp14> transmit SETs issued by anot
SET her entity. The SET
Recipient may accept or reject (i.e., return an error response s uch as Recipient may accept or reject (i.e., return an error response s uch as
<spanx style="verb">access_denied</spanx>) a SET at its own disc <tt>access_denied</tt>) a SET at its own discretion.
retion. </t>
</t> <t>
<t>
The SET Recipient persists the SET in a way that The SET Recipient persists the SET in a way that
is sufficient to meet the SET Recipient's own reliability requir ements. is sufficient to meet the SET Recipient's own reliability requir ements.
The level and method of retention of SETs The level and method of retention of SETs
by SET Recipients is out of scope of this specification. by SET Recipients is out of scope of this specification.
Once the SET has been validated and persisted, the SET Recipient SHOULD Once the SET has been validated and persisted, the SET Recipient <bcp14>SHOULD</bcp14>
immediately return a response indicating that the SET was succes sfully immediately return a response indicating that the SET was succes sfully
delivered. The SET Recipient SHOULD NOT perform further processi ng of the SET delivered. The SET Recipient <bcp14>SHOULD NOT</bcp14> perform f urther processing of the SET
beyond the required validation steps prior to sending this respon se. beyond the required validation steps prior to sending this respon se.
Any additional steps SHOULD be executed asynchronously from deli very Any additional steps <bcp14>SHOULD</bcp14> be executed asynchron ously from delivery
to minimize the time the SET Transmitter is waiting for a respons e. to minimize the time the SET Transmitter is waiting for a respons e.
</t> </t>
<t> <t>
The SET Transmitter MAY transmit the same SET to the SET Recipie The SET Transmitter <bcp14>MAY</bcp14> transmit the same SET to
nt multiple the SET Recipient multiple
times, regardless of the response from the SET Recipient. The SE T Recipient times, regardless of the response from the SET Recipient. The SE T Recipient
MUST respond as it would if the SET had not been previously rece <bcp14>MUST</bcp14> respond as it would if the SET had not been
ived by the previously received by the
SET Recipient. The SET Recipient MUST NOT expect or depend on a SET Recipient. The SET Recipient <bcp14>MUST NOT</bcp14> expect
SET Transmitter or depend on a SET Transmitter
to re-transmit a SET or otherwise make a SET available to the SE to retransmit a SET or otherwise make a SET available to the SET
T Recipient Recipient
once the SET Recipient acknowledges that it was received success fully. once the SET Recipient acknowledges that it was received success fully.
</t> </t>
<t> <t>
The SET Transmitter should not re-transmit a SET unless the SET The SET Transmitter should not retransmit a SET unless the SET T
Transmitter ransmitter
suspects that previous transmissions may have failed due to pote ntially suspects that previous transmissions may have failed due to pote ntially
recoverable errors (such as network outage or temporary service interruption at recoverable errors (such as network outage or temporary service interruption at
either the SET Transmitter or SET Recipient). In all other cases , the SET either the SET Transmitter or SET Recipient). In all other cases , the SET
Transmitter SHOULD NOT re-transmit a SET. The SET Transmitter <bcp14>SHOULD NOT</bcp14> retransmit a SET. The SET
Transmitter SHOULD delay retransmission for an appropriate amoun Transmitter <bcp14>SHOULD</bcp14> delay retransmission for an ap
t of time propriate amount of time
to avoid overwhelming the SET Recipient (see <xref target="relia to avoid overwhelming the SET Recipient (see <xref target="relia
bility"/>). bility" format="default"/>).
</t> </t>
<section anchor="httpPost" numbered="true" toc="default">
<section anchor="httpPost" title="Transmitting a SET"> <name>Transmitting a SET</name>
<t>
<t>
To transmit a SET to a SET Recipient, the SET Transmitter ma kes To transmit a SET to a SET Recipient, the SET Transmitter ma kes
an HTTP POST request to a TLS-enabled HTTP endpoint provided by the SET Recipient. The an HTTP POST request to a TLS-enabled HTTP endpoint provided by the SET Recipient. The
<spanx style="verb">Content-Type</spanx> header field of thi <tt>Content-Type</tt> header field of this request <bcp14>MU
s request MUST ST</bcp14>
be <spanx style="verb">application/secevent+jwt</spanx> as d be <tt>application/secevent+jwt</tt> as defined in
efined in Sections <xref target="RFC8417"
Sections 2.3 and 7.2 of <xref target="RFC8417"/>, and the sectionFormat="bare" section="2.3"/> and <xref target="RFC841
<spanx style="verb">Accept</spanx> header field MUST be <spa 7"
nx style="verb">application/json</spanx>. The sectionFormat="bare" section="7.2"/> of <xref target="RFC8417
request body MUST consist of the SET itself, represented as "
a sectionFormat="bare"/>, and the
<xref target="RFC7519">JWT</xref>. <tt>Accept</tt> header field <bcp14>MUST</bcp14> be <tt>appl
</t> ication/json</tt>. The
<t> request body <bcp14>MUST</bcp14> consist of the SET itself,
The SET Transmitter MAY include in the request an <spanx sty represented as a
le="verb">Accept-Language</spanx> <xref target="RFC7519" format="default">JSON Web Token (JWT)
</xref>.
</t>
<t>
The SET Transmitter <bcp14>MAY</bcp14> include in the reques
t an <tt>Accept-Language</tt>
header field to indicate to the SET Recipient the preferred language(s) in which to header field to indicate to the SET Recipient the preferred language(s) in which to
receive error messages. receive error messages.
</t> </t>
<t> <t>
The mechanisms by which the SET Transmitter determines the H TTP endpoint to The mechanisms by which the SET Transmitter determines the H TTP endpoint to
use when transmitting a SET to a given SET Recipient are not defined by this use when transmitting a SET to a given SET Recipient are not defined by this
specification and are deployment specific. specification and are deployment specific.
</t> </t>
<figure align="left" anchor="postSet" title="Example SET Transmi <t keepWithNext="true">
ssion Request"> The following is a non-normative example of a SET Transm
<preamble> ission Request:
The following is a non-normative example of a SET transm </t>
ission request: <figure anchor="postSet">
</preamble> <name>Example SET Transmission Request</name>
<artwork><![CDATA[
<sourcecode name="" type="http-message"><![CDATA[
POST /Events HTTP/1.1 POST /Events HTTP/1.1
Host: notify.rp.example.com Host: notify.rp.example.com
Accept: application/json Accept: application/json
Accept-Language: en-US, en;q=0.5 Accept-Language: en-US, en;q=0.5
Content-Type: application/secevent+jwt Content-Type: application/secevent+jwt
eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJIUzI1NiJ9Cg eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJIUzI1NiJ9Cg
. .
eyJpc3MiOiJodHRwczovL2lkcC5leGFtcGxlLmNvbS8iLCJqdGkiOiI3NTZFNjk eyJpc3MiOiJodHRwczovL2lkcC5leGFtcGxlLmNvbS8iLCJqdGkiOiI3NTZFNjk
3MTc1NjUyMDY5NjQ2NTZFNzQ2OTY2Njk2NTcyIiwiaWF0IjoxNTA4MTg0ODQ1LC 3MTc1NjUyMDY5NjQ2NTZFNzQ2OTY2Njk2NTcyIiwiaWF0IjoxNTA4MTg0ODQ1LC
JhdWQiOiI2MzZDNjk2NTZFNzQ1RjY5NjQiLCJldmVudHMiOnsiaHR0cHM6Ly9zY JhdWQiOiI2MzZDNjk2NTZFNzQ1RjY5NjQiLCJldmVudHMiOnsiaHR0cHM6Ly9zY
2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL2FjY291 2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL2FjY291
bnQtZGlzYWJsZWQiOnsic3ViamVjdCI6eyJzdWJqZWN0X3R5cGUiOiJpc3Mtc3V bnQtZGlzYWJsZWQiOnsic3ViamVjdCI6eyJzdWJqZWN0X3R5cGUiOiJpc3Mtc3V
iIiwiaXNzIjoiaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vIiwic3ViIjoiNzM3NT iIiwiaXNzIjoiaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vIiwic3ViIjoiNzM3NT
YyNkE2NTYzNzQifSwicmVhc29uIjoiaGlqYWNraW5nIn19fQ YyNkE2NTYzNzQifSwicmVhc29uIjoiaGlqYWNraW5nIn19fQ
. .
Y4rXxMD406P2edv00cr9Wf3_XwNtLjB9n-jTqN1_lLc Y4rXxMD406P2edv00cr9Wf3_XwNtLjB9n-jTqN1_lLc
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="successResponse" numbered="true" toc="default">
<section anchor="successResponse" title="Success Response"> <name>Success Response</name>
<t>If the SET is determined to be valid, the SET Recipient SHALL <t>If the SET is determined to be valid, the SET Recipient <bcp14>SHALL<
/bcp14>
acknowledge successful transmission by responding with HTTP acknowledge successful transmission by responding with HTTP
Response Status Code 202 (Accepted) (see Section 6.3.3 of <x Response Status Code 202 (Accepted) (see <xref target="RFC72
ref target="RFC7231"/>). 31" sectionFormat="of" section="6.3.3"/>).
The body of the response MUST be empty. The body of the response <bcp14>MUST</bcp14> be empty.
</t> </t>
<t keepWithNext="true">The following is a non-normative example of a suc
<figure anchor="goodPostResponse" title="Example Successful Deli cessful
very Response"> receipt of a SET.</t>
<preamble>The following is a non-normative example of a succ <figure anchor="goodPostResponse">
essful <name>Example Successful Delivery Response</name>
receipt of a SET.</preamble> <sourcecode name="" type="http-message"><![CDATA[
<artwork><![CDATA[
HTTP/1.1 202 Accepted HTTP/1.1 202 Accepted
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="failureResponse" numbered="true" toc="default">
<section anchor="failureResponse" title="Failure Response"> <name>Failure Response</name>
<t>In the event of a general HTTP error condition, the SET Recip <t>In the event of a general HTTP error condition, the SET Recipient
ient
responds with the applicable HTTP Status Code, as defined in responds with the applicable HTTP Status Code, as defined in
Section 6 of <xref target="RFC7231"/>.</t> <xref target="RFC7231" sectionFormat="of" section="6"/>.</t>
<t> <t>
When the SET Recipient detects an error parsing, validating, When the SET Recipient detects an error parsing,
or authenticating validating, or authenticating a SET transmitted in a SET
a SET transmitted in a SET Transmission Request, the SET Rec Transmission Request, the SET Recipient
ipient SHALL respond <bcp14>SHALL</bcp14> respond with an HTTP Response Status
with an HTTP Response Status Code of 400 (Bad Request). The Code of 400 (Bad Request). The <tt>Content-Type</tt>
<spanx style="verb">Content-Type</spanx> header field of thi header field of this response <bcp14>MUST</bcp14> be
s response MUST be <tt>application/json</tt>, and the body <bcp14>MUST</bcp14>
"application/json", and the body MUST be a UTF-8 encoded <xr be a
ef target="RFC8259">JSON</xref> UTF-8 encoded <xref target="RFC8259"
object containing the following name/value pairs: format="default">JSON</xref> object containing the
<list style="hanging"> following name/value pairs:
<t hangText="err"> </t>
A Security Event Token Error Code (see <xref target= <dl newline="false" spacing="normal">
"error_codes"/>). <dt>err:</dt>
</t> <dd>
<t hangText="description"> A Security Event Token Error Code (see <xref target=
"error_codes" format="default"/>).
</dd>
<dt>description:</dt>
<dd>
A UTF-8 string containing a human-readable descripti on of the error A UTF-8 string containing a human-readable descripti on of the error
that may provide additional diagnostic information. The exact content that may provide additional diagnostic information. The exact content
of this field is implementation specific. of this field is implementation specific.
</t> </dd>
</list> </dl>
</t> <t>
The response <bcp14>MUST</bcp14> include a
<t> <tt>Content-Language</tt> header field whose value
The response MUST include a <spanx style="verb">Content-Lang indicates the language of the error descriptions included
uage</spanx> header field, whose in the response body. If the SET Recipient can provide
value indicates the language of the error descriptions inclu error descriptions in multiple languages, they
ded in the response body. If <bcp14>SHOULD</bcp14> choose the language to use according
the SET Recipient can provide error descriptions in multiple to the value of the <tt>Accept-Language</tt> header field
languages, they SHOULD choose sent by the SET Transmitter in the transmission request,
the language to use according to the value of the <spanx sty as described in <xref target="RFC7231" sectionFormat="of"
le="verb">Accept-Language</spanx> section="5.3.5"/>. If the SET Transmitter did not send an
header field sent by the SET Transmitter in the transmission <tt>Accept-Language</tt> header field, or if the SET
request, as described in Section 5.3.5 Recipient does not support any of the languages included
of <xref target="RFC7231"/>. If the SET Transmitter did not in the header field, the SET Recipient <bcp14>MUST</bcp14>
send an respond with messages that are understandable by an
<spanx style="verb">Accept-Language</spanx> header field, or English-speaking person, as described in <xref
if the SET Recipient does not support any target="RFC2277" sectionFormat="of" section="4.5"/>.
of the languages included in the header field, the SET Recip </t>
ient MUST respond with messages that are <t keepWithNext="true">The following is a non-normative example error re
understandable by an English-speaking person, as described i sponse indicating
n Section 4.5 of <xref target="RFC2277"/>. that the key used to encrypt the SET has been revoked.</
</t> t>
<figure anchor="errorResponseInvalidKey">
<figure anchor="errorResponseInvalidKey" title="Example Error Re <name>Example Error Response (invalid_key)</name>
sponse (invalid_key)"> <sourcecode name="http-message" type=""><![CDATA[
<preamble>The following is a non-normative example error res
ponse indicating
that the key used to encrypt the SET has been revoked.</
preamble>
<artwork><![CDATA[
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Content-Language: en-US Content-Language: en-US
Content-Type: application/json Content-Type: application/json
{ {
"err": "invalid_key", "err": "invalid_key",
"description": "Key ID 12345 has been revoked." "description": "Key ID 12345 has been revoked."
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t keepWithNext="true">The following is a non-normative example error re
<figure anchor="errorResponseExpiredToken" title="Example Error sponse indicating
Response (authentication_failed)"> that the access token included in the request is expired
<preamble>The following is a non-normative example error res .</t>
ponse indicating <figure anchor="errorResponseExpiredToken">
that the access token included in the request is expired <name>Example Error Response (authentication_failed)</name>
.</preamble> <sourcecode name="" type="http-message"><![CDATA[
<artwork><![CDATA[
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Content-Language: en-US Content-Language: en-US
Content-Type: application/json Content-Type: application/json
{ {
"err": "authentication_failed", "err": "authentication_failed",
"description": "Access token has expired." "description": "Access token has expired."
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t keepWithNext="true">The following is a non-normative example error re
<figure anchor="errorResponseBadIssuer" title="Example Error Res sponse indicating
ponse (access_denied)">
<preamble>The following is a non-normative example error res
ponse indicating
that the SET Receiver is not willing to accept SETs issu ed by the specified that the SET Receiver is not willing to accept SETs issu ed by the specified
issuer from this particular SET Transmitter.</preamble> issuer from this particular SET Transmitter.</t>
<artwork><![CDATA[ <figure anchor="errorResponseBadIssuer">
HTTP/1.1 400 Bad Request <name>Example Error Response (access_denied)</name>
Content-Language: en-US
Content-Type: application/json
{ <sourcecode name="" type="http-message"><![CDATA[
"err": "invalid_issuer", HTTP/1.1 400 Bad Request
"description": "Not authorized for issuer https://iss.example.com/." Content-Language: en-US
} Content-Type: application/json
]]></artwork>
</figure>
</section>
<section anchor="error_codes" title="Security Event Token Delivery E {
rror Codes"> "err": "invalid_issuer",
<t>Security Event Token Delivery Error Codes are strings that id "description": "Not authorized for issuer https://iss.example.com/"
entify a }
]]></sourcecode>
</figure>
</section>
<section anchor="error_codes" numbered="true" toc="default">
<name>Security Event Token Error Codes</name>
<t>Security Event Token Error Codes are strings that identify a
specific category of error that may occur when parsing or va lidating a SET. specific category of error that may occur when parsing or va lidating a SET.
Every Security Event Token Delivery Error Code MUST have a u
nique name
registered in the IANA "Security Event Token Delivery Error
Codes"
registry established by <xref target="iana_set_errors"/>.</t
>
<t>The following table presents the initial set of Error Codes t Every Security Event Token Error Code <bcp14>MUST</bcp14> ha
hat are registered ve a unique name
in the IANA "Security Event Token Delivery Error Codes" regi registered in the IANA "Security Event Token Error Codes"
stry:</t> registry established by <xref target="iana_set_errors" forma
<texttable anchor="reqErrors" title="SET Delivery Error Codes"> t="default"/>.</t>
<ttcol>Error Code</ttcol><ttcol>Description</ttcol>
<c>invalid_request</c><c>The request body cannot be parsed a <t>The following table presents the initial set of Error Codes that are
s a SET, or the registered
Event Payload within the SET does not conform to the eve in the IANA "Security Event Token Error Codes" registry:</t>
nt's definition.</c> <table anchor="reqErrors" align="center">
<c>invalid_key</c><c>One or more keys used to encrypt or sig <name>SET Error Codes</name>
n the SET is <thead>
<tr>
<th align="left">Error Code</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">invalid_request</td>
<td align="left">The request body cannot be parsed as a SET, or th
e
Event Payload within the SET does not conform to the eve
nt's definition.</td>
</tr>
<tr>
<td align="left">invalid_key</td>
<td align="left">One or more keys used to encrypt or sign the SET
is
invalid or otherwise unacceptable to the SET Recipient ( expired, invalid or otherwise unacceptable to the SET Recipient ( expired,
revoked, failed certificate validation, etc.).</c> revoked, failed certificate validation, etc.).</td>
<c>invalid_issuer</c><c>The SET issuer is invalid for the SE </tr>
T Recipient.</c> <tr>
<c>invalid_audience</c><c>The SET audience does not correspo <td align="left">invalid_issuer</td>
nd to the SET Recipient.</c> <td align="left">The SET Issuer is invalid for the SET Recipient.<
<c>authentication_failed</c><c>The SET Recipient could not a /td>
uthenticate the </tr>
SET Transmitter.</c> <tr>
<c>access_denied</c><c>The SET Transmitter is not authorized <td align="left">invalid_audience</td>
to transmit the <td align="left">The SET Audience does not correspond to the SET R
SET to the SET Recipient.</c> ecipient.</td>
</texttable> </tr>
<t> <tr>
<td align="left">authentication_failed</td>
<td align="left">The SET Recipient could not authenticate the
SET Transmitter.</td>
</tr>
<tr>
<td align="left">access_denied</td>
<td align="left">The SET Transmitter is not authorized to transmit
the
SET to the SET Recipient.</td>
</tr>
</tbody>
</table>
<t>
Other Error Codes may also be received, Other Error Codes may also be received,
as the set of Error Codes is extensible as the set of Error Codes is extensible
via the IANA "Security Event Token Delivery Error Codes" regist via the IANA "Security Event Token Error Codes" registry
ry established in <xref target="iana_set_errors" format="default"/
established in <xref target="iana_set_errors"/>. >.
</t> </t>
</section> </section>
</section> </section>
<section anchor="aa" title="Authentication and Authorization" toc="defau
lt">
<t>The SET delivery method described in this specification is
based upon HTTP over TLS <xref target="RFC2818"/> and standard
HTTP authentication and authorization schemes, as per
<xref target="RFC7235" />.
The TLS server certificate MUST be validated using DNS-ID <xref t
arget="RFC6125"/>
and/or DANE <xref target="RFC6698"/>.
</t>
<t> <section anchor="aa" toc="default" numbered="true">
<name>Authentication and Authorization</name>
<t>The SET delivery method described in this specification is based upon
HTTP over TLS <xref target="RFC2818" format="default"/> and standard
HTTP authentication and authorization schemes, as per <xref
target="RFC7235" format="default"/>. The TLS server certificate
<bcp14>MUST</bcp14> be validated using DNS-ID <xref target="RFC6125"
format="default"/> and/or DNS-Based Authentication of Named Entities
(DANE) <xref target="RFC6698" format="default"/>.
</t>
<t>
Authorization for the eligibility to provide actionable SETs can be determined by Authorization for the eligibility to provide actionable SETs can be determined by
using the identity of the SET Issuer, using the identity of the SET Issuer,
the identity of the SET Transmitter, perhaps using mutual TLS, the identity of the SET Transmitter, perhaps using mutual TLS,
or via other employed authentication methods. or via other employed authentication methods.
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. are not of interest.
</t> </t>
</section> </section>
<section anchor="reliability" title="Delivery Reliability" toc="default" <section anchor="reliability" toc="default" numbered="true">
> <name>Delivery Reliability</name>
<t> <t>
Delivery reliability requirements may vary depending upon the us e cases. Delivery reliability requirements may vary depending upon the us e cases.
This specification defines the response from the SET This specification defines the response from the SET
Recipient in such a way as to provide the SET Transmitter with t he Recipient in such a way as to provide the SET Transmitter with t he
information necessary to determine what further action is requir ed, information necessary to determine what further action is requir ed,
if any, in order to meet their requirements. SET Transmitters w ith if any, in order to meet their requirements. SET Transmitters w ith
high reliability requirements may be tempted to always retry fai led high reliability requirements may be tempted to always retry fai led
transmissions. However, it should be noted that for many types o f SET transmissions. However, it should be noted that for many types o f SET
delivery errors, a retry is extremely unlikely to be successful. For delivery errors, a retry is extremely unlikely to be successful. For
example, <spanx style="verb">invalid_request</spanx> indicates a structural example, <tt>invalid_request</tt> indicates a structural
error in the content of the request body that is likely to remai n when error in the content of the request body that is likely to remai n when
re-transmitting the same SET. Others such as <spanx style="verb retransmitting the same SET. Others such as <tt>access_denied</
">access_denied</spanx> tt>
may be transient, for example if the SET Transmitter refreshes e may be transient, for example, if the SET Transmitter refreshes
xpired expired
credentials prior to re-transmission. credentials prior to retransmission.
</t> </t>
<t> <t>
The SET Transmitter may be unaware of whether or not a SET has b een delivered The SET Transmitter may be unaware of whether or not a SET has b een delivered
to a SET Recipient. For example, a network interruption could pr event the to a SET Recipient. For example, a network interruption could pr event the
SET Transmitter from receiving the success response, or a servic e outage could SET Transmitter from receiving the success response, or a servic e outage could
prevent the SET Transmitter from recording the fact that the SET was delivered. prevent the SET Transmitter from recording the fact that the SET was delivered.
It is left to the implementer to decide how to handle such cases , based on It is left to the implementer to decide how to handle such cases , based on
their requirements. For example, it may be appropriate for the S ET Transmitter to their requirements. For example, it may be appropriate for the S ET Transmitter to
re-transmit the SET to the SET Recipient, erring on the side of guaranteeing delivery, retransmit the SET to the SET Recipient, erring on the side of g uaranteeing delivery,
or it may be appropriate to assume delivery was successful, erri ng on the side of or it may be appropriate to assume delivery was successful, erri ng on the side of
not spending resources re-transmitting previously delivered SETs . Other options, not spending resources retransmitting previously delivered SETs. Other options,
such as sending the SET to a "dead letter queue" for manual exam ination may also such as sending the SET to a "dead letter queue" for manual exam ination may also
be appropriate. be appropriate.
</t> </t>
<t> <t>
Implementers SHOULD evaluate the reliability requirements of the Implementers <bcp14>SHOULD</bcp14> evaluate the reliability requ
ir use cases and the irements of their use cases and the
impact of various retry mechanisms and re-transmission policies impact of various retry mechanisms and retransmission policies o
on the performance n the performance
of their systems to determine an appropriate strategy for handli ng various error of their systems to determine an appropriate strategy for handli ng various error
conditions. conditions.
</t> </t>
</section> </section>
<section anchor="Security" title="Security Considerations" toc="default" <section anchor="Security" toc="default" numbered="true">
> <name>Security Considerations</name>
<section anchor="payloadAuthentication" numbered="true" toc="default">
<section anchor="payloadAuthentication" title="Authentication Using <name>Authentication Using Signed SETs</name>
Signed SETs"> <t>
<t>
JWS signed SETs can be JWS signed SETs can be
used (see <xref target="RFC7515"/> and Section 5 of <xref targe used (see <xref target="RFC7515" format="default"/> and
t="RFC8417"/>) <xref target="RFC8417" sectionFormat="of" section="5"/>)
to enable the SET Recipient to enable the SET Recipient
to validate that the SET Issuer is authorized to provide action able SETs. to validate that the SET Issuer is authorized to provide action able SETs.
</t> </t>
</section> </section>
<section anchor="HTTP" numbered="true" toc="default">
<section anchor="HTTP" title="HTTP Considerations"> <name>HTTP Considerations</name>
<t>SET delivery depends on the use of Hypertext Transfer Protocol a <t>SET delivery depends on the use of Hypertext Transfer Protocol and
nd is thus is thus subject to the security considerations of HTTP (<xref
subject to the security considerations of HTTP Section 9 of <xref target="RFC7230" sectionFormat="of" section="9"/>) and its related
target="RFC7230"/> and its related specifications.</t> specifications.</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 Id SETs may contain sensitive information, including Personally
entifiable Information (PII), Identifiable Information (PII), or be distributed through
or be distributed through third parties. third parties. In such cases, SET Transmitters and SET
In such cases, SET Transmitters and Recipients <bcp14>MUST</bcp14> protect the confidentiality
SET Recipients MUST protect the confidentiality of the SET c of the SET contents. TLS <bcp14>MUST</bcp14> be used to
ontents. secure the transmitted SETs. In some use cases, encrypting
TLS MUST be used to secure the transmitted SETs. the SET as described in <xref target="RFC7516"
In some use cases, format="default">JWE</xref> will also be required. The
encrypting the SET as described in <xref target="RFC7516">JWE Event delivery endpoint <bcp14>MUST</bcp14> support at least
</xref> will also be required. TLS version 1.2 <xref target="RFC5246" format="default"/>
The Event delivery endpoint MUST support at least TLS and <bcp14>SHOULD</bcp14> support the newest version of TLS
version 1.2 <xref target="RFC5246"/> and SHOULD support the that meets its security requirements, which as of the time
newest version of this publication is TLS 1.3 <xref target="RFC8446"
of TLS that meets its security requirements, format="default"/>. The client <bcp14>MUST</bcp14> perform
which as of the time of this publication is TLS 1.3 <xref tar a TLS/SSL server certificate check using DNS-ID <xref
get="RFC8446"/>. target="RFC6125" format="default"/> and/or DANE <xref
The client MUST target="RFC6698" format="default"/>. How a SET Transmitter
perform a TLS/SSL server certificate check using DNS-ID <xre determines the expected service identity to match the SET
f target="RFC6125"/> Recipient's server certificate against is out of scope for
and/or DANE <xref target="RFC6698"/>. this document. The implementation security considerations
How a SET Transmitter determines the expected service identi for TLS in "Recommendations for Secure Use of Transport
ty to match the SET Layer Security (TLS) and Datagram Transport Layer Security
Recipient's server certificate against is out of scope for t (DTLS)" <xref target="RFC7525" format="default"/>
his document. <bcp14>MUST</bcp14> be followed.
The implementation security considerations for TLS in </t>
"Recommendations for Secure Use of TLS and DTLS" <xref target </section>
="RFC7525"/> <section anchor="DoS" numbered="true" toc="default">
MUST be followed. <name>Denial of Service</name>
</t> <t>
</section>
<section anchor="DoS" title="Denial of Service">
<t>
The SET Recipient may be vulnerable to a denial-of-service a ttack where a The SET Recipient may be vulnerable to a denial-of-service a ttack where a
malicious party makes a high volume of requests containing i nvalid SETs, malicious party makes a high volume of requests containing i nvalid SETs,
causing the endpoint to expend significant resources on cryp tographic causing the endpoint to expend significant resources on cryp tographic
operations that are bound to fail. This may be mitigated by authenticating operations that are bound to fail. This may be mitigated by authenticating
SET Transmitters with a mechanism such as mutual TLS. SET Transmitters with a mechanism such as mutual TLS.
Rate-limiting problematic transmitters is also a possible mea ns of mitigation. Rate-limiting problematic transmitters is also a possible mea ns of mitigation.
</t> </t>
</section> </section>
<section anchor="Persisted" numbered="true" toc="default">
<section anchor="Persisted" title="Authenticating Persisted SETs"> <name>Authenticating Persisted SETs</name>
<t> <t>
At the time of receipt, the SET Recipient can rely upon TLS At the time of receipt, the SET Recipient can rely upon TLS
mechanisms, HTTP authentication methods, and/or other contex t from the mechanisms, HTTP authentication methods, and/or other contex t from the
transmission request to authenticate the SET Transmitter and validate the transmission request to authenticate the SET Transmitter and validate the
authenticity of the SET. However, this context is typically unavailable to authenticity of the SET. However, this context is typically unavailable to
systems to which the SET Recipient forwards the SET, or to s ystems that systems to which the SET Recipient forwards the SET, or to s ystems that
retrieve the SET from storage. If the SET Recipient require s the ability to retrieve the SET from storage. If the SET Recipient require s the ability to
validate SET authenticity outside of the context of the tran smission request, validate SET authenticity outside of the context of the tran smission request,
then the SET Recipient SHOULD ensure that such SETs have bee then the SET Recipient <bcp14>SHOULD</bcp14> ensure that suc
n signed in h SETs have been signed in
accordance with <xref target="RFC7515"/>. accordance with <xref target="RFC7515" format="default"/>.
Needed context could also be stored with the SET and retrieve d with it. Needed context could also be stored with the SET and retrieve d with it.
</t> </t>
</section> </section>
</section> </section>
<section anchor="Privacy" numbered="true" toc="default">
<section anchor="Privacy" title="Privacy Considerations"> <name>Privacy Considerations</name>
<t> <t>
SET Transmitters should attempt to deliver SETs that are targete d to the specific SET Transmitters should attempt to deliver SETs that are targete d to the specific
business and protocol needs of subscribers. business and protocol needs of subscribers.
</t> </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 agre ements Transmitters and Recipients <bcp14>MUST</bcp14> have the appropr iate 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 e ncrypted, Furthermore, data that needs confidentiality protection <bcp14>MU ST</bcp14> be encrypted,
at least with TLS at least with TLS
and sometimes also using JSON Web Encryption (JWE) <xref target=" and sometimes also using JSON Web Encryption (JWE) <xref target="
RFC7516"/>. RFC7516" format="default"/>.
</t> </t>
<t>
<t>
In some cases, subject identifiers themselves may be considered sen sitive In some cases, subject identifiers themselves may be considered sen sitive
information, such that their inclusion within a SET may be consider ed a violation information, such that their inclusion within a SET may be consider ed a violation
of privacy. SET Issuers and SET Transmitters should consider the r amifications of sharing a of privacy. SET Issuers and SET Transmitters should consider the r amifications of sharing a
particular subject identifier with a SET Recipient (e.g., whether d oing so could particular subject identifier with a SET Recipient (e.g., whether d oing so could
enable correlation and/or de-anonymization of data) and choose appr opriate enable correlation and/or de-anonymization of data) and choose appr opriate
subject identifiers for their use cases. subject identifiers for their use cases.
</t> </t>
</section>
</section> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations"> <section anchor="iana_set_errors" numbered="true" toc="default">
<section anchor="iana_set_errors" title="Security Event Token Delive <name>Security Event Token Error Codes</name>
ry Error Codes"> <t>
<t> This document defines Security Event Token Error
This document defines Security Event Token Delivery Error Co Codes, for which IANA has created and now maintains a
des, for which IANA new registry titled "Security Event Token Error
is asked to create and maintain a new registry titled "Secur Codes". Initial values for the "Security Event Token
ity Event Token Error Codes" registry are defined in <xref
Delivery Error Codes". Initial values for the Security Even target="reqErrors" format="default"/> and registered
t Token Delivery below. Future assignments are to be made through the
Error Codes registry are defined in <xref target="reqErrors" Specification Required registration policy <xref
/> and registered below. Future assignments target="RFC8126" format="default"/> and shall follow the
are to be made through the Specification Required registrati template below.
on policy (<xref target="RFC8126"/>) </t>
and shall follow the template below. <t>
</t> Error Codes are intended to be interpreted by automated
<t> systems; therefore, they <bcp14>SHOULD</bcp14> identify
Error Codes are intended to be interpreted by automated syst classes of errors to which an automated system could
ems, and therefore SHOULD respond in a meaningfully distinct way (e.g., by
identify classes of errors to which an automated system coul refreshing authentication credentials and retrying the
d respond in a meaningfully request).
distinct way (e.g., by refreshing authentication credentials </t>
and retrying the request). <t>
</t>
<t>
Error Code names are case sensitive. Error Code names are case sensitive.
Names may not match other registered names in a case-insensitiv e manner Names may not match other registered names in a case-insensitiv e manner
unless the Designated Experts state that there is a compelling reason unless the Designated Experts state that there is a compelling reason
to allow an exception. to allow an exception.
</t> </t>
<t> <t>
Criteria that should be applied by the Designated Experts inclu des Criteria that should be applied by the Designated Experts inclu des
determining whether the proposed registration duplicates existi ng functionality, determining whether the proposed registration duplicates existi ng functionality,
whether it is likely to be of general applicability whether it is likely to be of general applicability
or whether it is useful only for a single application, or whether it is useful only for a single application,
and whether the registration description is clear. and whether the registration description is clear.
</t> </t>
<t>
It is suggested that multiple Designated Experts be appointed w
ho are able to
represent the perspectives of different applications using this
specification,
in order to enable broadly informed review of registration deci
sions.
In cases where a registration decision could be perceived as
creating a conflict of interest for a particular Expert,
that Expert should defer to the judgment of the other Experts.
</t>
<section anchor="iana_set_errors_template" title="Registration T <t>
emplate"> It is suggested that multiple Designated Experts be
<t> appointed who are able to represent the perspectives of
<list style="hanging"> different applications using this specification in order to
<t hangText="Error Code"> enable broadly informed review of registration decisions.
<vspace/> In cases where a registration decision could be perceived as
The name of the Security Event Token Delivery Er creating a conflict of interest for a particular expert,
ror Code, as described that expert should defer to the judgment of the other
in <xref target="error_codes"/>. The name MUST b experts.
e a case-sensitive ASCII </t>
string consisting only of letters, digits, and u <section anchor="iana_set_errors_template" numbered="true" toc="default"
nderscore; these are the >
characters whose codes fall within the inclusive <name>Registration Template</name>
ranges 0x30-39, 0x41-5A, <dl newline="true" spacing="normal">
0x5F and 0x61-7A. <dt>Error Code</dt>
</t> <dd>
<t hangText="Description"> The name of the Security Event Token
<vspace/> Error Code, as described in <xref
A brief human-readable description of the Securi target="error_codes" format="default"/>. The
ty Event Token Delivery name <bcp14>MUST</bcp14> be a case-sensitive
ASCII string consisting only of letters,
digits, and underscore; these are the
characters whose codes fall within the
inclusive ranges 0x30-39, 0x41-5A, 0x5F, and
0x61-7A.
</dd>
<dt>Description</dt>
<dd>
A brief human-readable description of the Securi
ty Event Token
Error Code. Error Code.
</t> </dd>
<t hangText="Change Controller"> <dt>Change Controller</dt>
<vspace/> <dd>
For error codes registered by the IETF or its wo rking groups, list "IETF". For error codes registered by the IETF or its wo rking groups, list "IETF".
For all other error codes, list the name of the For all other error codes, list the name of the
party responsible for the registration. Contact information such as party responsible for the registration. Contact information such as
mailing address, email address, or phone number may also be provided. mailing address, email address, or phone number may also be provided.
</t> </dd>
<t hangText="Defining Document(s)"> <dt>Reference</dt>
<vspace/> <dd>
A reference to the document or documents that de fine the Security Event A reference to the document or documents that de fine the Security Event
Token Delivery Error Code. The definition MUST s pecify the name and Token Error Code. The definition <bcp14>MUST</bc p14> specify the name and
description of the error code and explain under what circumstances the description of the error code and explain under what circumstances the
error code may be used. URIs that can be used to retrieve copies of each error code may be used. URIs that can be used to retrieve copies of each
document at no cost SHOULD be included. document at no cost <bcp14>SHOULD</bcp14> be inc
</t> luded.
</list> </dd>
</t> </dl>
</section> </section>
<section anchor="InitialContents" numbered="true" toc="default">
<name>Initial Registry Contents</name>
<dl newline="false" spacing="compact">
<dt>Error Code:</dt><dd>invalid_request</dd>
<section anchor="InitialContents" title="Initial Registry Conten <dt>Description:</dt><dd>The request body cannot be parsed as a SET
ts"> or the Event
<t> Payload within the SET does not conform to the event's
<?rfc subcompact="yes"?> definition.</dd>
<list style="hanging">
<t>Error Code: invalid_request</t> <dt>Change Controller:</dt><dd>IETF</dd>
<t>Description: The request body cannot be parsed as a SET
or the event <dt>Reference:</dt><dd>
payload within the SET does not conform to the event's <xref target="error_codes" format="default"/> of RFC 8935
definition.</t> </dd>
<t>Change Controller: IETF</t> </dl>
<t>Defining Document(s):
<xref target="error_codes"/> of [[ this specification ]] <dl newline="false" spacing="compact">
</t> <dt>Error Code:</dt><dd>invalid_key</dd>
</list> <dt>Description:</dt><dd>One or more keys used to encrypt or sign th
</t> e SET is invalid
<t>
<list style="hanging">
<t>Error Code: invalid_key</t>
<t>Description: One or more keys used to encrypt or sign t
he SET is invalid
or otherwise unacceptable to the SET Recipient (expire d, revoked, or otherwise unacceptable to the SET Recipient (expire d, revoked,
failed certificate validation, etc.).</t> failed certificate validation, etc.).</dd>
<t>Change Controller: IETF</t> <dt>Change Controller:</dt><dd>IETF</dd>
<t>Defining Document(s): <dt>Reference:</dt><dd>
<xref target="error_codes"/> of [[ this specification ]] <xref target="error_codes" format="default"/> of RFC 8935
</t> </dd>
</list> </dl>
</t>
<t> <dl newline="false" spacing="compact">
<list style="hanging"> <dt>Error Code:</dt><dd>invalid_issuer</dd>
<t>Error Code: invalid_issuer</t> <dt>Description:</dt><dd>The SET Issuer is invalid for the SET Recip
<t>Description: The SET issuer is invalid for the SET Reci ient.</dd>
pient.</t> <dt>Change Controller:</dt><dd>IETF</dd>
<t>Change Controller: IETF</t> <dt>Reference:</dt><dd>
<t>Defining Document(s): <xref target="error_codes" format="default"/> of RFC 8935
<xref target="error_codes"/> of [[ this specification ]] </dd>
</t> </dl>
</list>
</t> <dl newline="false" spacing="compact">
<t> <dt>Error Code:</dt><dd>invalid_audience</dd>
<list style="hanging"> <dt>Description:</dt><dd>The SET Audience does not correspond to the
<t>Error Code: invalid_audience</t> SET Recipient.</dd>
<t>Description: The SET audience does not correspond to th <dt>Change Controller:</dt><dd>IETF</dd>
e SET Recipient.</t> <dt>Reference:</dt><dd>
<t>Change Controller: IETF</t> <xref target="error_codes" format="default"/> of RFC 8935
<t>Defining Document(s): </dd>
<xref target="error_codes"/> of [[ this specification ]] </dl>
</t>
</list> <dl newline="false" spacing="compact">
</t> <dt>Error Code:</dt><dd>authentication_failed</dd>
<t> <dt>Description:</dt><dd>The SET Recipient could not authenticate th
<list style="hanging"> e SET Transmitter.</dd>
<t>Error Code: authentication_failed</t> <dt>Change Controller:</dt><dd>IETF</dd>
<t>Description: The SET Recipient could not authenticate t <dt>Reference:</dt><dd>
he SET Transmitter.</t> <xref target="error_codes" format="default"/> of RFC 8935
<t>Change Controller: IETF</t> </dd>
<t>Defining Document(s): </dl>
<xref target="error_codes"/> of [[ this specification ]] <dl newline="false" spacing="compact">
</t> <dt>Error Code:</dt><dd>access_denied</dd>
</list> <dt>Description:</dt><dd>The SET Transmitter is not authorized to tr
</t> ansmit the
<t> SET to the SET Recipient.</dd>
<list style="hanging"> <dt>Change Controller:</dt><dd>IETF</dd>
<t>Error Code: access_denied</t> <dt>Reference:</dt><dd>
<t>Description: The SET Transmitter is not authorized to t <xref target="error_codes" format="default"/> of RFC 8935
ransmit the </dd>
SET to the SET Recipient.</t> </dl>
<t>Change Controller: IETF</t>
<t>Defining Document(s):
<xref target="error_codes"/> of [[ this specification ]]
</t>
</list>
</t>
</section>
<?rfc subcompact="no"?>
</section>
</section> </section>
</middle> </section>
</section>
</middle>
<back>
<back> <references>
<references title="Normative References"> <name>References</name>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <references>
ence.RFC.2119.xml' ?> <name>Normative References</name>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.2277.xml'?><!-- IETF Language Policy --> FC.2119.xml"/>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ence.RFC.2818.xml' ?><!-- HTTP over TLS --> FC.2277.xml"/>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5246.xml' ?><!-- TLS 1.2 -->
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
ence.RFC.6125.xml' ?><!-- TLS Certs --> ce.RFC.2818.xml"/>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6698.xml' ?><!-- DANE -->
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
nce.RFC.7230.xml' ?><!-- HTTP Msg --> ce.RFC.5246.xml"/>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7231.xml' ?><!-- HTTP Semantics -->
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7515.xml' ?><!-- JWS -->
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7516.xml' ?><!-- JWE -->
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7519.xml' ?><!-- JWT -->
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7525.xml' ?><!-- TLS Recos -->
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
ence.RFC.8126.xml' ?> ce.RFC.6125.xml"/>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8259.xml' ?><!-- JSON -->
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8417.xml'?><!-- SET -->
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8446.xml' ?><!-- TLS 1.3 -->
</references>
<references title="Informative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/referen ce.RFC.6698.xml"/>
ce.I-D.draft-ietf-secevent-http-poll-12.xml" ?>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referenc
e.RFC.7230.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
ce.RFC.7231.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
ce.RFC.7515.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
ce.RFC.7516.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
ce.RFC.7519.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
ce.RFC.7525.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
ce.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
ce.RFC.8259.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen
ce.RFC.8417.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referenc
e.RFC.8446.xml"/>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.7235.xml' ?><!-- HTTP Auth -->
</references> </references>
<references>
<name>Informative References</name>
<section anchor="Unencrypted" title="Unencrypted Transport Considerations <reference anchor="RFC8936" target="https://www.rfc-editor.org/info/rfc8936">
">
<t> <front>
<title>Poll-Based Security Event Token (SET) Delivery Using HTTP</title>
<author initials='A' surname='Backman' fullname='Annabelle Backman' role='editor
'>
<organization />
</author>
<author initials='M' surname='Jones' fullname='Michael Jones'>
<organization />
</author>
<author initials='M' surname='Scurtescu' fullname='Marius Scurtescu'>
<organization />
</author>
<author initials='M' surname='Ansari' fullname='Morteza Ansari'>
<organization />
</author>
<author initials='A' surname='Nadalin' fullname='Anthony Nadalin'>
<organization />
</author>
<date month='October' year='2020' />
</front>
<seriesInfo name="RFC" value="8936"/>
<seriesInfo name="DOI" value="10.17487/RFC8936"/>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7235.xml"/>
</references>
</references>
<section anchor="Unencrypted" numbered="true" toc="default">
<name>Unencrypted Transport Considerations</name>
<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 this non-normative appendix. in this non-normative appendix.
</t> </t>
<t> <t>
SETs may contain sensitive information that is considered SETs may contain sensitive information that is considered
Personally Identifiable Information (PII). Personally Identifiable Information (PII).
In such cases, SET Transmitters and In such cases, SET Transmitters and
SET Recipients MUST protect the confidentiality of the SET contents. SET Recipients <bcp14>MUST</bcp14> protect the confidentiality of the
When TLS is not used, this means that the SET MUST be encrypted SET contents.
as described in <xref target="RFC7516">JWE</xref>. When TLS is not used, this means that the SET <bcp14>MUST</bcp14> be
</t> encrypted
<t> as described in <xref target="RFC7516" format="default">JWE</xref>.
</t>
<t>
If SETs were allowed to be transmitted over unencrypted channels, som e privacy-sensitive If SETs were allowed to be transmitted over unencrypted channels, som e privacy-sensitive
information about them might leak, even though the SETs themselves ar e encrypted. information about them might leak, even though the SETs themselves ar e encrypted.
For instance, an attacker may be able to determine whether or not a S ET was accepted and the reason for its rejection For instance, an attacker may be able to determine whether or not a S ET was accepted and the reason for its rejection
or may be able to derive information from being able to observe the s ize of the encrypted SET. or may be able to derive information from being able to observe the s ize of the encrypted SET.
(Note that even when TLS is utilized, some information leakage is sti ll possible; (Note that even when TLS is utilized, some information leakage is sti ll possible;
message padding algorithms to prevent side channels remain an open re search topic.) message padding algorithms to prevent side channels remain an open re search topic.)
</t> </t>
</section> </section>
<section anchor="Others" title="Other Streaming Specifications">
<t>[[ NOTE TO THE RFC EDITOR: This section to be removed prior to pu
blication ]]</t>
<t>The following pub/sub, queuing, and streaming systems were review
ed
as possible solutions or as input to the current draft:</t>
<t>Poll-Based Security Event Token (SET) Delivery Using HTTP</t>
<t>In addition to this specification, the WG is defining a polling-b
ased
SET delivery protocol. That protocol <xref target="I-D.ietf-sece
vent-http-poll"/>
describes it as:</t>
<figure><artwork>This specification defines how a series of Security
Event Tokens
(SETs) can be delivered to an intended recipient using HTTP POST over
TLS initiated as a poll by the recipient. The specification also
defines how delivery can be assured, subject to the SET Recipient's
need for assurance.</artwork>
</figure>
<t>XMPP Events</t>
<t>The WG considered XMPP Events and their ability to provide a sing
le
messaging solution without the need for both polling and push mo
des.
The feeling was the size and methodology of XMPP was too far apa
rt from
the current capabilities of the SECEVENTs community, which focus
es in
on HTTP based service delivery and authorization.</t>
<t>Amazon Simple Notification Service</t>
<t>Simple Notification Service is a pub/sub messaging product from
AWS. SNS supports a variety of subscriber types: HTTP/HTTPS endp
oints,
AWS Lambda functions, email addresses (as JSON or plain text), p
hone
numbers (via SMS), and AWS SQS standard queues. It does not dire
ctly
support pull, but subscribers can get the pull model by creating
an
SQS queue and subscribing it to the topic. Note that this puts t
he
cost of pull support back onto the subscriber, just as it is in
the
push model. It is not clear that one way is strictly better than
the
other; larger, sophisticated developers may be happy to own mess
age
persistence so they can have their own internal delivery guarant
ees.
The long tail of OIDC clients may not care about that or may fai
l
to get it right. Regardless, I think we can learn something from
the
Delivery Policies supported by SNS, as well as the delivery cont
rols
that SQS offers (e.g., Visibility Timeout, Dead-Letter Queues).
I am
not suggesting that we need all of these things in the spec, but
they give an idea of what features people have found useful.</t>
<t>Other information:<list style="symbols">
<t>API Reference: http://docs.aws.amazon.com/AWSSimpleQueueServi
ce/latest/APIReference/Welcome.html</t>
<t>Visibility Timeouts: http://docs.aws.amazon.com/AWSSimpleQueu
eService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html</t>
</list></t>
<t>Apache Kafka</t>
<t>Apache Kafka is an Apache open source project based upon TCP for
distributed streaming. It prescribes some interesting general-pu
rpose
features that seem to extend far beyond the simpler
streaming model that SECEVENTs is after. A comment from MS has b
een that
Kafka does an acknowledge with poll combination event which seem
s
to be a performance advantage. See: https://kafka.apache.org/int
ro</t>
<t>Google Pub/Sub</t>
<t>The Google Pub Sub system favors a model whereby polling and ackn
owledgement
of events is done with separate endpoints and as separate functi
ons.</t>
<t>Information:<list style="symbols">
<t>Cloud Overview - https://cloud.google.com/pubsub/</t>
<t>Subscriber Overview - https://cloud.google.com/pubsub/docs/su
bscriber</t>
<t>Subscriber Pull(poll) - https://cloud.google.com/pubsub/docs/
pull</t>
</list></t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments"> <section anchor="Acknowledgments" numbered="false" toc="default">
<t> <name>Acknowledgments</name>
The editors would like to thank the members of the SCIM working group <t>
, which The editors would like to thank the members of the SCIM Working Group
, which
began discussions of provisioning events starting with draft-hunt-sci m-notify-00 in 2015. began discussions of provisioning events starting with draft-hunt-sci m-notify-00 in 2015.
We would like to thank Phil Hunt and the other authors of draft-ietf- secevent-delivery-02, We would like to thank <contact fullname="Phil Hunt"/> and the other authors of draft-ietf-secevent-delivery-02,
upon which this specification is based. upon which this specification is based.
We would like to thank the participants in the SecEvents We would like to thank the participants in the SecEvents
working group for their contributions to this specification. Working Group for their contributions to this specification.
</t> </t>
<t> <t>
Additionally, we would like to thank the following individuals for th eir reviews of the specification: Additionally, we would like to thank the following individuals for th eir reviews of the specification:
Joe Clarke, <contact fullname="Joe Clarke"/>,
Roman Danyliw, <contact fullname="Roman Danyliw"/>,
Vijay Gurbani, <contact fullname="Vijay Gurbani"/>,
Benjamin Kaduk, <contact fullname="Benjamin Kaduk"/>,
Erik Kline, <contact fullname="Erik Kline"/>,
Murray Kucherawy, <contact fullname="Murray Kucherawy"/>,
Barry Leiba, <contact fullname="Barry Leiba"/>,
Yaron Sheffer, <contact fullname="Yaron Sheffer"/>,
Robert Sparks, <contact fullname="Robert Sparks"/>,
Valery Smyslov, <contact fullname="Valery Smyslov"/>,
É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>[[ NOTE TO THE RFC EDITOR: This section to be removed prior to pu
blication ]]</t>
<t>Draft 00 - AB - Based on draft-ietf-secevent-delivery-02 with the </back>
following changes:<list style="symbols">
<t>Renamed to "Push-Based SET Token Delivery Using HTTP"</t>
<t>Removed references to the HTTP Polling delivery method.</t>
<t>Removed informative reference to RFC6202.</t>
</list></t>
<t>
Draft 01 - AB:
<list style="symbols">
<t>Fixed area and workgroup to match secevent.</t>
<t>Removed unused definitions and definitions already covere
d by SET.</t>
<t>Renamed Event Transmitter and Event Receiver to SET Trans
mitter and SET Receiver, respectively.</t>
<t>Added IANA registry for SET Delivery Error Codes.</t>
<t>Removed enumeration of HTTP authentication methods.</t>
<t>Removed generally applicable guidance for HTTP, authoriza
tion tokens, and bearer tokens.</t>
<t>Moved guidance for using authentication methods as DoS pr
otection to Security Considerations.</t>
<t>Removed redundant instruction to use WWW-Authenticate hea
der.</t>
<t>Removed further generally applicable guidance for authori
zation tokens.</t>
<t>Removed bearer token from example delivery request, and t
ext referencing it.</t>
<t>Broke delivery method description into separate request/r
esponse sections.</t>
<t>Added missing empty line between headers and body in exam
ple request.</t>
<t>Removed inapplicable notes about example formatting.</t>
<t>Removed text about SET creation and handling.</t>
<t>Removed duplication in protocol description.</t>
<t>Added "non-normative example" text to example transmissio
n request.</t>
<t>Fixed inconsistencies in use of Error Code term.</t>
</list>
</t>
<t>
Draft 02 - AB:
<list style="symbols">
<t>Rewrote abstract and introduction.</t>
<t>Rewrote definitions for SET Transmitter, SET Receiver.</t
>
<t>Renamed Event Delivery section to SET Delivery.</t>
<t>Readability edits to Success Response and Failure Respons
e sections.</t>
<t>Consolidated definition of error response under Failure R
esponse section.</t>
<t>Removed Event Delivery Process section and moved its cont
ent to parent section.</t>
<t>Readability edits to SET Delivery section and its subsect
ions.</t>
<t>Added callout that SET Receiver HTTP endpoint configurati
on is out-of-scope.</t>
<t>Added callout that SET verification mechanisms are out-of
-scope.</t>
<t>Added retry guidance, notes regarding delivery reliabilit
y requirements.</t>
<t>Added guidance around using JWS and/or JWE to authenticat
e persisted SETs.</t>
</list>
</t>
<t>
Draft 03 - mbj:
<list style="symbols">
<t>
Addressed problems identified in my 18-Jul-18 review message ti
tled
"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
Receiver.
</t>
<t>
Applied editorial and minor normative corrections.
</t>
<t>
Updated Marius' contact information.
</t>
</list>
</t>
<t>
Draft 04 - AB:
<list style="symbols">
<t>Replaced Error Codes with smaller set of meaningfully dif
ferentiated codes.</t>
<t>Added more error response examples.</t>
<t>Removed un-referenced normative references.</t>
<t>Added normative reference to JSON in error response defin
ition.</t>
<t>
Added text clarifying that the value of the <spanx style
="verb">description</spanx>
attribute in error responses is implementation specific.
</t>
<t>Added requirement that error descriptions and responses a
re UTF-8 encoded.</t>
<t>
Added error description language preferences and specifi
cation via <spanx style="verb">Accept-Language</spanx>
and <spanx style="verb">Content-Language</spanx> headers
.
</t>
<t>Added "recognized issuer" validation requirement in secti
on 2.</t>
<t>Added timeouts as an acceptable reason to resend a SET in
section 2.</t>
<t>Edited text in section 1 to clarify that configuration is
out of scope.</t>
<t>Made minor editorial corrections.</t>
</list>
</t>
<t>
Draft 05 - AB:
<list style="symbols">
<t>Made minor editorial corrections.</t>
<t>Updated example request with a correct SET header and sig
nature.</t>
<t>Revised TLS guidance to allow implementers to provide con
fidentiality protection via JWE.</t>
<t>Revised TLS guidance to require *at least* TLS 1.2.</t>
<t>Revised TLS guidance to recommend supporting the newest v
ersion of TLS that meets security requirements.</t>
<t>Revised SET Delivery Error Code format to allow the same
set of characters as is allowed in error codes in RFC6749.</t>
<t>Added mention of HTTP Poll spec to list of other streamin
g specs in appendix.</t>
<t>Added validation step requiring SET Recipient to verify t
hat the SET is one which the SET Transmitter is expected to send to the SET Reci
pient.</t>
<t>Changed responding to errors with an appropriate HTTP sta
tus code from optional to recommended.</t>
<t>Changed Error Codes registry change policy from Expert Re
view to First Come First Served; added guidance that error codes are meant to be
consumed by automated systems.</t>
<t>Added text making clear that it is up to SET Recipients w
hether or not they will accept SETs where the SET Issuer is different from the S
ET Transmitter.</t>
<t>Reworded guidance around signing and/or encrypting SETs f
or integrity protection.</t>
<t>Renamed TLS "Support Considerations" section to "Confiden
tiality of SETs".</t>
<t>Reworded guidance around subject identifier selection and
privacy concerns.</t>
</list>
</t>
<t>
Draft 06 - mbj, MS:
<list style="symbols">
<t>Made minor editorial corrections.</t>
<t>Updated to indicate that failure response should be retur
ned if errors occur in authenticating the SET.</t>
<t>Updated reference for JSON from RFC 7159 to RFC 8259.</t>
<t>Fixed Authentication Using Signed SETs to indicate the SE
T Transmitter must be authorized to deliver the SET, not the SET Issuer.</t>
<t>Fixed Authenticating Persisted SETs to put the responsibi
lity for ensuring the SET is signed on the SET Recipient.</t>
<t>Fixed error code format definition to match error codes d
efined in doc.</t>
</list>
</t>
<t>
Draft 07 - AB:
<list style="symbols">
<t>Made minor editorial corrections.</t>
<t>Removed "SET Recipient" definition and added explicit lis
t of terms used from RFC8417.</t>
</list>
</t>
<t>
Draft 08 - mbj
<list style="symbols">
<t>
Addressed area director review comments by Benjamin Kaduk.
</t>
</list>
</t>
<t>
Draft 09 - mbj + AB
<list style="symbols">
<t>
Corrected editorial nits.
</t>
</list>
</t>
<t>
Draft 10 - AB
<list style="symbols">
<t>
Addressed area director review comments by Benjamin Kadu
k:
<list style="symbols">
<t>Added reference to 8417 as definition document fo
r SETs.</t>
<t>
Added text clarifying that determining the SET R
ecipient's service identity
is out of scope.
</t>
<t>
Added normative recommendation for transmitters
to target SETs to specific
business needs of subscribers.
</t>
<t>Minor editorial corrections.</t>
</list>
</t>
</list>
</t>
<t>
Draft 11 - mbj
<list style="symbols">
<t>
Addressed SecDir review comments by Valery Smyslov.
</t>
<t>
Addressed OpsDir review comments by Joe Clarke.
</t>
<t>
Addressed GenArt review comments by Vijay Gurbani.
</t>
</list>
</t>
<t>
Draft 12 - mbj
<list style="symbols">
<t>
Revised to unambiguously require the use of TLS,
while preserving descriptions of precautions needed for non-TLS
use in an appendix.
</t>
</list>
</t>
<t>
Draft 13 - mbj
<list style="symbols">
<t>
Addressed IESG comments.
</t>
</list>
</t>
<t>
Draft 14 - AB
<list style="symbols">
<t>
Revised normative requirements for SET re-transmission t
o clarify "at least once"
delivery expectiations.
</t>
<t>
Added non-normative text to Section 4 - Delivery Reliabi
lity describing conditions
where re-transmission of successfully delivered SETs may
occur.
</t>
</list>
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 95 change blocks. 
1061 lines changed or deleted 749 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/