draft-ietf-secevent-http-push-03.txt   draft-ietf-secevent-http-push-04.txt 
Security Events Working Group A. Backman, Ed. Security Events Working Group A. Backman, Ed.
Internet-Draft Amazon Internet-Draft Amazon
Intended status: Standards Track M. Jones, Ed. Intended status: Standards Track M. Jones, Ed.
Expires: April 21, 2019 Microsoft Expires: July 27, 2019 Microsoft
M. Scurtescu M. Scurtescu
Coinbase Coinbase
M. Ansari M. Ansari
Cisco Cisco
A. Nadalin A. Nadalin
Microsoft Microsoft
October 18, 2018 January 23, 2019
Push-Based Security Event Token (SET) Delivery Using HTTP Push-Based Security Event Token (SET) Delivery Using HTTP
draft-ietf-secevent-http-push-03 draft-ietf-secevent-http-push-04
Abstract Abstract
This specification defines how a Security Event Token (SET) may be This specification defines how a Security Event Token (SET) may be
delivered to an intended recipient using HTTP POST. The SET is delivered to an intended recipient using HTTP POST. The SET is
transmitted in the body of an HTTP POST reqest to an endpoint transmitted in the body of an HTTP POST request to an endpoint
operated by the recipient, and the recipient indicates successful or operated by the recipient, and the recipient indicates successful or
failed transmission via the HTTP response. failed transmission via the HTTP response.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2019. This Internet-Draft will expire on July 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. SET Delivery . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SET Delivery . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Transmitting a SET . . . . . . . . . . . . . . . . . . . 4 2.1. Transmitting a SET . . . . . . . . . . . . . . . . . . . 4
2.2. Success Response . . . . . . . . . . . . . . . . . . . . 5 2.2. Success Response . . . . . . . . . . . . . . . . . . . . 5
2.3. Failure Response . . . . . . . . . . . . . . . . . . . . 6 2.3. Failure Response . . . . . . . . . . . . . . . . . . . . 6
2.4. Security Event Token Delivery Error Codes . . . . . . . . 6 2.4. Security Event Token Delivery Error Codes . . . . . . . . 7
3. Authentication and Authorization . . . . . . . . . . . . . . 7 3. Authentication and Authorization . . . . . . . . . . . . . . 8
4. Delivery Reliability . . . . . . . . . . . . . . . . . . . . 7 4. Delivery Reliability . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Authentication Using Signed SETs . . . . . . . . . . . . 8 5.1. Authentication Using Signed SETs . . . . . . . . . . . . 9
5.2. TLS Support Considerations . . . . . . . . . . . . . . . 8 5.2. TLS Support Considerations . . . . . . . . . . . . . . . 9
5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 8 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 9
5.4. Authenticating Persisted SETs . . . . . . . . . . . . . . 8 5.4. Authenticating Persisted SETs . . . . . . . . . . . . . . 10
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Security Event Token Delivery Error Codes . . . . . . . . 9 7.1. Security Event Token Delivery Error Codes . . . . . . . . 10
7.1.1. Registration Template . . . . . . . . . . . . . . . . 9 7.1.1. Registration Template . . . . . . . . . . . . . . . . 10
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 10 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Other Streaming Specifications . . . . . . . . . . . 13 Appendix A. Other Streaming Specifications . . . . . . . . . . . 13
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 15 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 15
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 15 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction and Overview 1. Introduction and Overview
This specification defines a mechanism by which a transmitter of a This specification defines a mechanism by which a transmitter of a
Security Event Token (SET) [RFC8417] may deliver the SET to an Security Event Token (SET) [RFC8417] may deliver the SET to an
intended recipient via HTTP POST [RFC7231]. intended recipient via HTTP POST [RFC7231].
Push-Based SET Delivery over HTTP POST is intended for scenarios Push-Based SET Delivery over HTTP POST is intended for scenarios
where all of the following apply: where all of the following apply:
o The transmitter of the SET is capable of making outbound HTTP o The transmitter of the SET is capable of making outbound HTTP
requests. requests.
o The recipient is capable of hosting an HTTP endpoint that is o The recipient is capable of hosting an HTTP endpoint that is
accessible to the transmitter. accessible to the transmitter.
o The transmitter and recipient are known to one another. o The transmitter and recipient are known to one another.
o The transmitter and recipient have an out-of-band mechanism for A mechanism for exchanging configuration metadata such as endpoint
exchanging configuration metadata such as endpoint URLs and URLs and cryptographic key parameters between the transmitter and
cryptographic key parameters. receipt is out of scope for this specifications.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Throughout this documents all figures may contain spaces and extra Throughout this documents all figures may contain spaces and extra
line-wrapping for readability and due to space limitations. line-wrapping for readability and due to space limitations.
1.2. Definitions 1.2. Definitions
This specification utilizes terminology defined in [RFC8417], as well This specification utilizes terminology defined in [RFC8417], as well
as the terms defined below: as the terms defined below:
SET Transmitter SET Transmitter
An entity that delivers SETs in its possession to one or more SET An entity that delivers SETs in its possession to one or more SET
Recipients. Recipients, as defined in [RFC8417].
SET Recipient
An entity that receives SETs through some distribution method, as
defined in [RFC8417].
2. SET Delivery 2. SET Delivery
To deliver a SET to a given SET Recipient, the SET Transmitter makes To deliver a SET to a given SET Recipient, the SET Transmitter makes
a SET Transmission Request to the SET Recipient, with the SET itself a SET Transmission Request to the SET Recipient, with the SET itself
contained within the request. The SET Recipient replies to this contained within the request. The SET Recipient replies to this
request with a response either acknowledging successful transmission request with a response either acknowledging successful transmission
of the SET, or indicating that an error occurred while receiving, of the SET, or indicating that an error occurred while receiving,
parsing, and/or validating the SET. parsing, and/or validating the SET.
skipping to change at page 4, line 8 skipping to change at page 4, line 13
the following are true: the following are true:
o The SET Recipient can parse the SET. o The SET Recipient can parse the SET.
o The SET is authentic (i.e., it was issued by the issuer specified o The SET is authentic (i.e., it was issued by the issuer specified
within the SET). within the SET).
o The SET Recipient is identified as an intended audience of the o The SET Recipient is identified as an intended audience of the
SET. SET.
o The SET issuer is recognized as an issuer that the SET Recipient
is willing to receive SETs from (e.g., the issuer is whitelisted
by the SET Recipient).
The mechanisms by which the SET Recipient performs this validation The mechanisms by which the SET Recipient performs this validation
are out of scope for this document. SET parsing and issuer and are out of scope for this document. SET parsing and issuer and
audience identification are defined in [RFC8417]. The mechanism for audience identification are defined in [RFC8417]. The mechanism for
validating the authenticity of a SET is implementation specific, and validating the authenticity of a SET is implementation specific, and
may vary depending on the authentication mechanisms in use, and may vary depending on the authentication mechanisms in use, and
whether the SET is signed and/or encrypted (See Section 3). whether the SET is signed and/or encrypted (See Section 3).
The SET Recipient SHOULD ensure that the SET is persisted in a way The SET Recipient SHOULD ensure that the SET is persisted in a way
that is sufficient to meet the SET Recipient's own reliability that is sufficient to meet the SET Recipient's own reliability
requirements, and MUST NOT expect or depend on a SET Transmitter to requirements, and MUST NOT expect or depend on a SET Transmitter to
skipping to change at page 4, line 30 skipping to change at page 4, line 39
successfully. successfully.
Once the SET has been validated and persisted, the SET Recipient Once the SET has been validated and persisted, the SET Recipient
SHOULD immediately return a response indicating that the SET was SHOULD immediately return a response indicating that the SET was
successfully delivered. The SET Recipient SHOULD NOT perform successfully delivered. The SET Recipient SHOULD NOT perform
extensive business logic that processes the event expressed by the extensive business logic that processes the event expressed by the
SET prior to sending this response. Such logic SHOULD be executed SET prior to sending this response. Such logic SHOULD be executed
asynchronously from delivery, in order to minimize the expense and asynchronously from delivery, in order to minimize the expense and
impact of SET delivery on the SET Transmitter. impact of SET delivery on the SET Transmitter.
The SET Transmitter SHOULD NOT re-transmit a SET, unless the response The SET Transmitter MAY re-transmit a SET if the responses from
from the SET Recipient in previous transmissions indicated a previous transmissions timed out or indicated potentially recoverable
potentially recoverable error (such as server unavailability that may error (such as server unavailability that may be transient, or a
be transient, or a decryption failure that may be due to decryption failure that may be due to misconfigured keys on the SET
misconfigured keys on the SET Recipient's side). In the latter case, Recipient's side). In all other cases, the SET Transmitter SHOULD
the SET Transmitter MAY re-transmit a SET, after an appropriate delay NOT re-transmit a SET. The SET Transmitter SHOULD delay
to avoid overwhelming the SET Recipient (see Section 4). retransmission for an appropriate amount of time to avoid
overwhelming the SET Recipient (see Section 4).
2.1. Transmitting a SET 2.1. Transmitting a SET
To transmit a SET to a SET Recipient, the SET Transmitter makes an To transmit a SET to a SET Recipient, the SET Transmitter makes an
HTTP POST request to an HTTP endpoint provided by the SET Recipient. HTTP POST request to an HTTP endpoint provided by the SET Recipient.
The "Content-Type" header of this request MUST be "application/ The "Content-Type" header of this request MUST be "application/
secevent+jwt" as defined in Sections 2.2 and 6.2 of [RFC8417], and secevent+jwt" as defined in Sections 2.2 and 6.2 of [RFC8417], and
the "Accept" header MUST be "application/json". The request body the "Accept" header MUST be "application/json". The request body
MUST consist of the SET itself, represented as a JWT [RFC7519]. MUST consist of the SET itself, represented as a JWT [RFC7519].
The SET Transmitter MAY include in the request an "Accept-Language"
header to indicate to the SET Recipient the preferred language(s) in
which to receive error messages.
The mechanisms by which the SET Transmitter determines the HTTP The mechanisms by which the SET Transmitter determines the HTTP
endpoint to use when transmitting a SET to a given SET Recipient are endpoint to use when transmitting a SET to a given SET Recipient are
not defined by this specification and may be implementation-specific. not defined by this specification and may be implementation-specific.
The following is a non-normative example of a SET transmission The following is a non-normative example of a SET transmission
request: request:
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
Content-Type: application/secevent+jwt Content-Type: application/secevent+jwt
eyJhbGciOiJub25lIn0 eyJhbGciOiJub25lIn0
. .
eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6 WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ 1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
. .
c2lnbmF0dXJl
Figure 1: Example SET Transmission Request Figure 1: Example SET Transmission Request
2.2. Success Response 2.2. Success Response
If the SET is determined to be valid, the SET Recipient SHALL If the SET is determined to be valid, the SET Recipient SHALL
"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 [RFC7231]). Response Status Code 202 (Accepted) (see Section 6.3.3 of [RFC7231]).
The body of the response MUST be empty. The body of the response MUST be empty.
skipping to change at page 6, line 15 skipping to change at page 6, line 31
2.3. Failure Response 2.3. Failure Response
In the event of a general HTTP error condition, the SET Recipient MAY In the event of a general HTTP error condition, the SET Recipient MAY
respond with an appropriate HTTP Status Code as defined in Section 6 respond with an appropriate HTTP Status Code as defined in Section 6
of [RFC7231]. of [RFC7231].
When the SET Recipient detects an error parsing or validating a SET When the SET Recipient detects an error parsing or validating a SET
transmitted in a SET Transmission Request, the SET Recipient SHALL transmitted in a SET Transmission Request, the SET Recipient SHALL
respond with an HTTP Response Status Code of 400 (Bad Request). The respond with an HTTP Response Status Code of 400 (Bad Request). The
"Content-Type" header of this response MUST be "application/json", "Content-Type" header of this response MUST be "application/json",
and the body MUST be a JSON object containing the following name/ and the body MUST be a UTF-8 encoded JSON [RFC7159] object containing
value pairs: the following name/value pairs:
err A Security Event Token Error Code (see Section 2.4). err A Security Event Token Error Code (see Section 2.4).
description Human-readable text that describes the error and MAY description A UTF-8 string containing a human-readable description
contain additional diagnostic information. of the error that MAY provide additional diagnostic information.
The exact content of this field is implementation-specific.
The following is an example non-normative error response. The response MUST include a "Content-Language" header, whose value
indicates the language of the error descriptions included in the
response body. If the SET Recipient can provide error descriptions
in multiple languages, they SHOULD choose the language to use
according to the value of the "Accept-Language" header sent by the
SET Transmitter in the transmission request, as described in
Section 5.3.5 of [RFC7231]. If the SET Transmitter did not send an
"Accept-Language" header, or if the SET Recipient does not support
any of the languages included in the header, the SET Recipient MUST
respond with messages that are understandable by an English-speaking
person, as described in Section 4.5 of [RFC2277].
The following is an example non-normative error response indicating
that the key used to encrypt the SET has been revoked.
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Content-Language: en-US
Content-Type: application/json Content-Type: application/json
{ {
"err":"dup", "err": "invalid_key",
"description":"SET already received. Ignored." "description": "Key ID 12345 has been revoked."
}
Figure 3: Example Error Response (invalid_key)
The following is an example non-normative error response indicating
that the access token included in the request is expired.
HTTP/1.1 400 Bad Request
Content-Language: en-US
Content-Type: application/json
{
"err": "authentication_failed",
"description": "Access token is expired."
} }
Figure 3: Example Error Response Figure 4: Example Error Response (authentication_failed)
The following is an example non-normative error response indicating
that the SET Transmitter is not permitted to transmit SETs issued by
the issuer specified in the SET.
HTTP/1.1 400 Bad Request
Content-Language: en-US
Content-Type: application/json
{
"err": "access_denied",
"description": "Not authorized for issuer http://iss.example.com/."
}
Figure 5: Example Error Response (access_denied)
2.4. Security Event Token Delivery Error Codes 2.4. Security Event Token Delivery Error Codes
Security Event Token Delivery Error Codes are strings that identify a Security Event Token Delivery Error Codes are strings that identify a
specific type of error that may occur when parsing or validating a specific category of error that may occur when parsing or validating
SET. Every Security Event Token Delivery Error Code MUST have a a SET. Every Security Event Token Delivery Error Code MUST have a
unique name registered in the IANA "Security Event Token Delivery unique name registered in the IANA "Security Event Token Delivery
Error Codes" registry established by Section 7.1. Error Codes" registry established by Section 7.1.
The following table presents the initial set of Error Codes that are The following table presents the initial set of Error Codes that are
registered in the IANA "Security Event Token Delivery Error Codes" registered in the IANA "Security Event Token Delivery Error Codes"
registry: registry:
+-----------+-------------------------------------------------------+ +-----------------------+-------------------------------------------+
| Error | Description | | Error Code | Description |
| Code | | +-----------------------+-------------------------------------------+
+-----------+-------------------------------------------------------+ | invalid_request | The request body cannot be parsed as a |
| json | Invalid JSON object. | | | SET, or the event payload within the SET |
| jwtParse | Invalid or unparsable JWT or JSON structure. | | | does not conform to the event's |
| jwtHdr | An invalid JWT header was detected. | | | definition. |
| jwtCrypto | Unable to parse due to unsupported algorithm. | | invalid_key | One or more keys used to encrypt or sign |
| jws | Signature was not validated. | | | the SET is invalid or otherwise |
| jwe | Unable to decrypt JWE encoded data. | | | unacceptable to the SET Recipient. (e.g., |
| jwtAud | Invalid audience value. | | | expired, revoked, failed certificate |
| jwtIss | Issuer not recognized. | | | validation, etc.) |
| setType | An unexpected Event type was received. | | authentication_failed | The SET Recipient could not authenticate |
| setParse | Invalid structure was encountered such as an | | | the SET Transmitter from the contents of |
| | inability to parse or an incomplete set of Event | | | the request. |
| | claims. | | access_denied | The SET Transmitter is not authorized to |
| setData | SET claims incomplete or invalid. | | | transmit the provided SET to the SET |
| dup | A duplicate SET was received and has been ignored. | | | Recipient. |
+-----------+-------------------------------------------------------+ +-----------------------+-------------------------------------------+
Table 1: SET Delivery Error Codes Table 1: SET Delivery Error Codes
3. Authentication and Authorization 3. Authentication and Authorization
The SET delivery method described in this specification is based upon The SET delivery method described in this specification is based upon
HTTP and depends on the use of TLS and/or standard HTTP HTTP and depends on the use of TLS and/or standard HTTP
authentication and authorization schemes as per [RFC7235]. authentication and authorization schemes as per [RFC7235].
Because SET Delivery describes a simple function, authorization for Because SET Delivery describes a simple function, authorization for
skipping to change at page 7, line 49 skipping to change at page 9, line 7
4. Delivery Reliability 4. Delivery Reliability
Delivery reliability requirements may vary from implementation to Delivery reliability requirements may vary from implementation to
implementation. This specification defines the response from the SET implementation. This specification defines the response from the SET
Recipient in such a way as to provide the SET Transmitter with the Recipient in such a way as to provide the SET Transmitter with the
information necessary to determine what further action is required, information necessary to determine what further action is required,
if any, in order to meet their requirements. SET Transmitters with if any, in order to meet their requirements. SET Transmitters with
high reliability requirements may be tempted to always retry failed high reliability requirements may be tempted to always retry failed
transmissions, however it should be noted that for many types of SET transmissions, however it should be noted that for many types of SET
delivery errors, a retry is extremely unlikely to be successful. For delivery errors, a retry is extremely unlikely to be successful. For
example, "json", "jwtParse", and "setParse" all indicate structural example, "invalid_request" indicates a structural error in the
errors in the content of the SET that are likely to remain when re- content of the request body that is likely to remain when re-
transmitting the same SET. Others such as "jws" or "jwe" may be transmitting the same SET. Others such as "access_denied" may be
transient, for example if cryptographic material has not been transient, for example if the SET Transmitter refreshes expired
properly distributed to the SET Recipient's systems. credentials prior to re-transmission.
Implementers SHOULD evaluate their reliability requirements and the Implementers SHOULD evaluate their reliability requirements and the
impact of various retry mechanisms on the performance of their impact of various retry mechanisms on the performance of their
systems to determine the correct strategy for various error systems to determine the correct strategy for various error
conditions. conditions.
5. Security Considerations 5. Security Considerations
5.1. Authentication Using Signed SETs 5.1. Authentication Using Signed SETs
skipping to change at page 10, line 16 skipping to change at page 11, line 25
Defining Document(s) Defining Document(s)
A reference to the document or documents that define the Security A reference to the document or documents that define the Security
Event Token Delivery Error Code. The definition MUST specify the Event Token Delivery Error Code. The definition MUST specify the
name and description of the error code, and explain under what name and description of the error code, and explain under what
circumstances the error code may be used. URIs that can be used circumstances the error code may be used. URIs that can be used
to retrieve copies of each document at no cost SHOULD be included. to retrieve copies of each document at no cost SHOULD be included.
7.1.2. Initial Registry Contents 7.1.2. Initial Registry Contents
Error Code: json Error Code: invalid_request
Description: Invalid JSON object Description: The request body cannot be parsed as a SET, or the
Change Controller: IETF Secevent Working Group event payload within the SET does not conform to the event's
Defining Document(s): Section 2.4 of this document definition.
Error Code: jwtParse
Description: Invalid or unparsable JWT or JSON structure
Change Controller: IETF Secevent Working Group
Defining Document(s): Section 2.4 of this document
Error Code: jwtHdr
Description: An invalid JWT header was detected
Change Controller: IETF Secevent Working Group
Defining Document(s): Section 2.4 of this document
Error Code: jwtCrypto
Description: Unable to parse due to unsupported algorithm
Change Controller: IETF Secevent Working Group
Defining Document(s): Section 2.4 of this document
Error Code: jws
Description: Signature was not validated
Change Controller: IETF Secevent Working Group
Defining Document(s): Section 2.4 of this document
Error Code: jwe
Description: Unable to decrypt JWE encoded data
Change Controller: IETF Secevent Working Group
Defining Document(s): Section 2.4 of this document
Error Code: jwtAud
Description: Invalid audience value
Change Controller: IETF Secevent Working Group
Defining Document(s): Section 2.4 of this document
Error Code: jwtIss
Description: Issuer not recognized
Change Controller:
Defining Document(s): Section 2.4 of this document
Error Code: setType
Description: An unexpected Event type was received
Change Controller: IETF Secevent Working Group Change Controller: IETF Secevent Working Group
Defining Document(s): Section 2.4 of this document Defining Document(s): Section 2.4 of this document
Error Code: setParse Error Code: invalid_key
Description: Invalid structure was encountered such as an Description: One or more keys used to encrypt or sign the SET is
inability to parse or an incomplete set of Event claims. invalid or otherwise unacceptable to the SET Recipient. (e.g.,
expired, revoked, failed certificate validation, etc.)
Change Controller: IETF Secevent Working Group Change Controller: IETF Secevent Working Group
Defining Document(s): Section 2.4 of this document Defining Document(s): Section 2.4 of this document
Error Code: setData Error Code: authentication_failed
Description: SET claims incomplete or invalid Description: The SET Recipient could not authenticate the SET
Transmitter from the contents of the request.
Change Controller: IETF Secevent Working Group Change Controller: IETF Secevent Working Group
Defining Document(s): Section 2.4 of this document Defining Document(s): Section 2.4 of this document
Error Code: dup Error Code: access_denied
Description: A duplicate SET was received and has been ignored. Description: The SET Transmitter is not authorized to transmit the
provided SET to the SET Recipient.
Change Controller: IETF Secevent Working Group Change Controller: IETF Secevent Working Group
Defining Document(s): Section 2.4 of this document Defining Document(s): Section 2.4 of this document
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Resource Identifier (URI): Generic Syntax", STD 66, Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
RFC 3986, DOI 10.17487/RFC3986, January 2005, January 1998, <https://www.rfc-editor.org/info/rfc2277>.
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010,
<https://www.rfc-editor.org/info/rfc5988>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
skipping to change at page 12, line 29 skipping to change at page 12, line 47
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015, RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>. <https://www.rfc-editor.org/info/rfc7516>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
skipping to change at page 13, line 12 skipping to change at page 13, line 27
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari,
"Security Event Token (SET)", RFC 8417, "Security Event Token (SET)", RFC 8417,
DOI 10.17487/RFC8417, July 2018, DOI 10.17487/RFC8417, July 2018,
<https://www.rfc-editor.org/info/rfc8417>. <https://www.rfc-editor.org/info/rfc8417>.
8.2. Informative References 8.2. Informative References
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/info/rfc6750>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>. <https://www.rfc-editor.org/info/rfc7235>.
[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0 Client Authentication
and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,
May 2015, <https://www.rfc-editor.org/info/rfc7521>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>.
Appendix A. Other Streaming Specifications Appendix A. Other Streaming Specifications
[[EDITORS NOTE: This section to be removed prior to publication]] [[EDITORS NOTE: This section to be removed prior to publication]]
The following pub/sub, queuing, streaming systems were reviewed as The following pub/sub, queuing, streaming systems were reviewed as
possible solutions or as input to the current draft: possible solutions or as input to the current draft:
XMPP Events XMPP Events
The WG considered the XMPP events ands its ability to provide a The WG considered the XMPP events ands its ability to provide a
single messaging solution without the need for both polling and push single messaging solution without the need for both polling and push
modes. The feeling was the size and methodology of XMPP was to far modes. The feeling was the size and methodology of XMPP was to far
apart from the current capabilities of the SECEVENTs community which apart from the current capabilities of the SECEVENTs community which
focuses in on HTTP based service delivery and authorization. focuses in on HTTP based service delivery and authorization.
Amazon Simple Notification Service Amazon Simple Notification Service
Simple Notification Service, is a pub/sub messaging product from AWS. Simple Notification Service, is a pub/sub messaging product from AWS.
SNS supports a variety of subscriber types: HTTP/HTTPS endpoints, AWS SNS supports a variety of subscriber types: HTTP/HTTPS endpoints, AWS
skipping to change at page 17, line 30 skipping to change at page 17, line 20
o Addressed problems identified in my 18-Jul-18 review message o Addressed problems identified in my 18-Jul-18 review message
titled "Issues for both the Push and Poll Specs". titled "Issues for both the Push and Poll Specs".
o Changes to align terminology with RFC 8417, for instance, by using o Changes to align terminology with RFC 8417, for instance, by using
the already defined term SET Recipient rather than SET Receiver. the already defined term SET Recipient rather than SET Receiver.
o Applied editorial and minor normative corrections. o Applied editorial and minor normative corrections.
o Updated Marius' contact information. o Updated Marius' contact information.
Draft 04 - AB:
o Replaced Error Codes with smaller set of meaningfully
differentiated codes.
o Added more error response examples.
o Removed un-referenced normative references.
o Added normative reference to JSON in error response definition.
o Added text clarifying that the value of the "description"
attribute in error responses is implementation specific.
o Added requirement that error descriptions and responses are UTF-8
encoded.
o Added error description language preferences and specification via
"Accept-Language" and "Content-Language" headers.
o Added "recognized issuer" validation requirement in section 2.
o Added time outs as an acceptable reason to resend a SET in section
2.
o Edited text in section 1 to clarify that configuration is out of
scope.
o Made minor editorial corrections.
Authors' Addresses Authors' Addresses
Annabelle Backman (editor) Annabelle Backman (editor)
Amazon Amazon
Email: richanna@amazon.com Email: richanna@amazon.com
Michael B. Jones (editor) Michael B. Jones (editor)
Microsoft Microsoft
 End of changes. 36 change blocks. 
155 lines changed or deleted 173 lines changed or added

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