summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8417.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8417.txt')
-rw-r--r--doc/rfc/rfc8417.txt1571
1 files changed, 1571 insertions, 0 deletions
diff --git a/doc/rfc/rfc8417.txt b/doc/rfc/rfc8417.txt
new file mode 100644
index 0000000..ae36ea3
--- /dev/null
+++ b/doc/rfc/rfc8417.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) P. Hunt, Ed.
+Request for Comments: 8417 Oracle
+Category: Standards Track M. Jones
+ISSN: 2070-1721 Microsoft
+ W. Denniss
+ Google
+ M. Ansari
+ Cisco
+ July 2018
+
+
+ Security Event Token (SET)
+
+Abstract
+
+ This specification defines the Security Event Token (SET) data
+ structure. A SET describes statements of fact from the perspective
+ of an issuer about a subject. These statements of fact represent an
+ event that occurred directly to or about a security subject, for
+ example, a statement about the issuance or revocation of a token on
+ behalf of a subject. This specification is intended to enable
+ representing security- and identity-related events. A SET is a JSON
+ Web Token (JWT), which can be optionally signed and/or encrypted.
+ SETs can be distributed via protocols such as HTTP.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8417.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 1]
+
+RFC 8417 SET July 2018
+
+
+Copyright Notice
+
+ Copyright (c) 2018 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 2]
+
+RFC 8417 SET July 2018
+
+
+Table of Contents
+
+ 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 4
+ 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 5
+ 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2. The Security Event Token (SET) . . . . . . . . . . . . . . . 6
+ 2.1. Illustrative Examples . . . . . . . . . . . . . . . . . . 7
+ 2.1.1. SCIM Example . . . . . . . . . . . . . . . . . . . . 7
+ 2.1.2. Logout Example . . . . . . . . . . . . . . . . . . . 9
+ 2.1.3. Consent Example . . . . . . . . . . . . . . . . . . . 10
+ 2.1.4. RISC Example . . . . . . . . . . . . . . . . . . . . 11
+ 2.2. Core SET Claims . . . . . . . . . . . . . . . . . . . . . 11
+ 2.3. Explicit Typing of SETs . . . . . . . . . . . . . . . . . 13
+ 2.4. Security Event Token Construction . . . . . . . . . . . . 14
+ 3. Requirements for SET Profiles . . . . . . . . . . . . . . . . 16
+ 4. Preventing Confusion between SETs and Other JWTs . . . . . . 17
+ 4.1. Distinguishing SETs from ID Tokens . . . . . . . . . . . 17
+ 4.2. Distinguishing SETs from Access Tokens . . . . . . . . . 18
+ 4.3. Distinguishing SETs from Other Kinds of JWTs . . . . . . 18
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
+ 5.1. Confidentiality and Integrity . . . . . . . . . . . . . . 19
+ 5.2. Delivery . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 5.3. Sequencing . . . . . . . . . . . . . . . . . . . . . . . 20
+ 5.4. Timing Issues . . . . . . . . . . . . . . . . . . . . . . 20
+ 5.5. Preventing Confusion . . . . . . . . . . . . . . . . . . 21
+ 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
+ 7.1. JSON Web Token Claims Registration . . . . . . . . . . . 22
+ 7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 22
+ 7.2. Structured Syntax Suffix Registration . . . . . . . . . . 22
+ 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 23
+ 7.3. Media Type Registration . . . . . . . . . . . . . . . . . 24
+ 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 24
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 25
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 26
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 3]
+
+RFC 8417 SET July 2018
+
+
+1. Introduction and Overview
+
+ This specification defines an extensible Security Event Token (SET)
+ data structure, which can be exchanged using protocols such as HTTP.
+ The specification builds on the JSON Web Token (JWT) format [RFC7519]
+ in order to provide a self-contained token that can be optionally
+ signed using JSON Web Signature (JWS) [RFC7515] and/or encrypted
+ using JSON Web Encryption (JWE) [RFC7516].
+
+ This specification profiles the use of JWT for the purpose of issuing
+ SETs. This specification defines a base format used by profiling
+ specifications to define actual events and their meanings. This
+ specification uses non-normative example events to demonstrate how
+ events can be constructed.
+
+ This specification is scoped to security- and identity-related
+ events. While SETs may be used for other purposes, the specification
+ only considers security and privacy concerns relevant to identity and
+ personal information.
+
+ Security events are not commands issued between parties. A SET
+ describes statements of fact from the perspective of an issuer about
+ a subject (e.g., a web resource, token, IP address, the issuer
+ itself). These statements of fact represent a logical event that
+ occurred directly to or about a security subject, for example, a
+ statement about the issuance or revocation of a token on behalf of a
+ subject. A security subject may be permanent (e.g., a user account)
+ or temporary (e.g., an HTTP session) in nature. A state change could
+ describe a direct change of entity state, an implicit change of
+ state, or other higher-level security statements such as:
+
+ o The creation, modification, removal of a resource.
+
+ o The resetting or suspension of an account.
+
+ o The revocation of a security token prior to its expiry.
+
+ o The logout of a user session.
+
+ o An indication that a user has been given control of an email
+ identifier that was previously controlled by another user.
+
+ While subject state changes are often triggered by a user agent or
+ security subsystem, the issuance and transmission of an event may
+ occur asynchronously and in a back channel to the action that caused
+ the change that generated the security event. Subsequently, a SET
+ recipient, having received a SET, validates and interprets the
+ received SET and takes its own independent actions, if any. For
+
+
+
+Hunt, et al. Standards Track [Page 4]
+
+RFC 8417 SET July 2018
+
+
+ example, having been informed of a personal identifier being
+ associated with a different security subject (e.g., an email address
+ is being used by someone else), the SET recipient may choose to
+ ensure that the new user is not granted access to resources
+ associated with the previous user. Or, the SET recipient may not
+ have any relationship with the subject, and no action is taken.
+
+ While SET recipients will often take actions upon receiving SETs,
+ security events cannot be assumed to be commands or requests. The
+ intent of this specification is to define a syntax for statements of
+ fact that SET recipients may interpret for their own purposes.
+
+1.1. Notational Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+ For purposes of readability, examples are not URL encoded.
+ Implementers MUST percent-encode URLs as described in Section 2.1 of
+ [RFC3986].
+
+ Throughout this document, all figures may contain spaces and extra
+ line-wrapping for readability and space limitations. Similarly, some
+ URIs contained within examples have been shortened for space and
+ readability reasons.
+
+1.2. Definitions
+
+ The following definitions are used with SETs:
+
+ Security Event Token (SET)
+ A SET is a JWT [RFC7519] conforming to this specification.
+
+ SET Issuer
+ A service provider that creates SETs to be sent to other service
+ providers known as SET recipients.
+
+ SET Recipient
+ A SET recipient is an entity that receives SETs through some
+ distribution method. A SET recipient is the same entity referred
+ as a "recipient" in [RFC7519] or "receiver" in related
+ specifications.
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 5]
+
+RFC 8417 SET July 2018
+
+
+ Subject
+ A SET describes an event or state change that has occurred to a
+ subject. A subject might, for instance, be a principal (e.g.,
+ Section 4.1.2 of [RFC7519]), a web resource, an entity such as an
+ IP address, or the issuer of the SET.
+
+ Event Identifier
+ A member name for an element of the JSON object that is the value
+ of the "events" claim in a SET. This member name MUST be a URI.
+
+ Event Payload
+ A member value for an element of the JSON object that is the value
+ of the "events" claim in a SET. This member value MUST be a JSON
+ object.
+
+ Profiling Specification
+ A specification that profiles the SET data structure to define one
+ or more specific event types and their associated claims and
+ processing rules.
+
+2. The Security Event Token (SET)
+
+ A SET is a JWT [RFC7519] data structure that represents one or more
+ related aspects of a security event that occurred to a subject. The
+ JWT Claims Set in a SET has the following structure:
+
+ o The top-level claims in the JWT Claims Set are called the SET
+ "envelope". Some of these claims are present in every SET; others
+ will be specific to particular SET profiles or profile families.
+ Claims in the envelope SHOULD be registered in the "JSON Web Token
+ Claims" registry [IANA.JWT.Claims] or be Public Claims or Private
+ Claims, as defined in [RFC7519].
+
+ o Envelope claims that are profiled and defined in this
+ specification are used to validate the SET and provide information
+ about the event data included in the SET. The "events" claim
+ contains the event identifiers and event-specific data expressed
+ about the security subject. The envelope MAY include event-
+ specific or profile-specific data. The "events" claim value MUST
+ be a JSON object that contains at least one member.
+
+ o Each member of the "events" JSON object is a name/value pair. The
+ JSON member name is a URI string value, which is the event
+ identifier, and the corresponding value is a JSON object known as
+ the event "payload". The payload JSON object contains claims that
+ pertain to that event identifier and need not be registered as JWT
+
+
+
+
+
+Hunt, et al. Standards Track [Page 6]
+
+RFC 8417 SET July 2018
+
+
+ claims. These claims are defined by the profiling specification
+ that defines the event. An event with no payload claims SHALL be
+ represented as the empty JSON object ("{}").
+
+ o When multiple event identifiers are contained in a SET, they
+ represent multiple aspects of the same state transition that
+ occurred to the security subject. They are not intended to be
+ used to aggregate distinct events about the same subject. Beyond
+ this, the interpretation of SETs containing multiple event
+ identifiers is out of scope for this specification; profiling
+ specifications MAY define their own rules regarding their use of
+ SETs containing multiple event identifiers, as described in
+ Section 3. Possible uses of multiple values include, but are not
+ limited to:
+
+ * Values to provide classification information (e.g., threat type
+ or level).
+
+ * Additions to existing event representations.
+
+ * Values used to link potential series of events.
+
+ * Specific-purpose event URIs used between particular SET issuers
+ and SET recipients.
+
+2.1. Illustrative Examples
+
+ This section illustrates several possible uses of SETs through non-
+ normative examples.
+
+2.1.1. SCIM Example
+
+ The following example shows the JWT Claims Set for a hypothetical
+ System for Cross-domain Identity Management (SCIM) [RFC7644] password
+ reset SET. Such a SET might be used by a receiver as a trigger to
+ reset active user-agent sessions related to the identified user.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 7]
+
+RFC 8417 SET July 2018
+
+
+ {
+ "iss": "https://scim.example.com",
+ "iat": 1458496025,
+ "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
+ "aud": [
+ "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
+ "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
+ ],
+ "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
+ "events": {
+ "urn:ietf:params:scim:event:passwordReset": {
+ "id": "44f6142df96bd6ab61e7521d9"
+ },
+ "https://example.com/scim/event/passwordResetExt": {
+ "resetAttempts": 5
+ }
+ }
+ }
+
+ Figure 1: Example SCIM Password Reset Event
+
+ The JWT Claims Set usage consists of:
+
+ o The "events" claim specifying the hypothetical SCIM URN
+ ("urn:ietf:params:scim:event:passwordReset") for a password reset,
+ and a second value, "https://example.com/scim/event/
+ passwordResetExt", that is used to provide additional event
+ information such as the current count of resets.
+
+ o The "iss" claim, denoting the SET issuer.
+
+ o The "sub" claim, specifying the SCIM resource URI that was
+ affected.
+
+ o The "aud" claim, specifying the intended audiences for the event.
+ (The syntax of the "aud" claim is defined in Section 4.1.3 of
+ [RFC7519].)
+
+ The SET contains two event payloads:
+
+ o The "id" claim represents SCIM's unique identifier for a subject.
+
+ o The second payload identified by "https://example.com/scim/event/
+ passwordResetExt" and the payload claim "resetAttempts" conveys
+ the current count of reset attempts. In this example, while the
+ count is a simple factual statement for the issuer, the meaning of
+ the value (a count) is up to the receiver. As an example, such a
+ value might be used by the receiver to infer increasing risk.
+
+
+
+Hunt, et al. Standards Track [Page 8]
+
+RFC 8417 SET July 2018
+
+
+ In this example, the SCIM event indicates that a password has been
+ updated and the current password reset count is 5. Notice that the
+ value for "resetAttempts" is in the event payload of an event used to
+ convey this information.
+
+2.1.2. Logout Example
+
+ Here is another example JWT Claims Set for a security event token,
+ this one for a Logout Token:
+
+ {
+ "iss": "https://server.example.com",
+ "sub": "248289761001",
+ "aud": "s6BhdRkqt3",
+ "iat": 1471566154,
+ "jti": "bWJq",
+ "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
+ "events": {
+ "http://schemas.openid.net/event/backchannel-logout": {}
+ }
+ }
+
+ Figure 2: Example OpenID Back-Channel Logout Event
+
+ Note that the above SET has an empty JSON object and uses the JWT
+ claims "sub" and "sid" to identify the subject that was logged out.
+ At the time of this writing, this example corresponds to the logout
+ token defined in the OpenID Connect Back-Channel Logout 1.0
+ [OpenID.BackChannel] specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 9]
+
+RFC 8417 SET July 2018
+
+
+2.1.3. Consent Example
+
+ In the following example JWT Claims Set, a fictional medical service
+ collects consent for medical actions and notifies other parties. The
+ individual for whom consent is identified was originally
+ authenticated via OpenID Connect. In this case, the issuer of the
+ security event is an application rather than the OpenID provider:
+
+ {
+ "iss": "https://my.med.example.org",
+ "iat": 1458496025,
+ "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
+ "aud": [
+ "https://rp.example.com"
+ ],
+ "events": {
+ "https://openid.net/heart/specs/consent.html": {
+ "iss": "https://connect.example.com",
+ "sub": "248289761001",
+ "consentUri": [
+ "https://terms.med.example.org/labdisclosure.html#Agree"
+ ]
+ }
+ }
+ }
+
+ Figure 3: Example Consent Event
+
+ In the above example, the attribute "iss" contained within the
+ payload for the event "https://openid.net/heart/specs/consent.html"
+ refers to the issuer of the security subject ("sub") rather than the
+ SET issuer "https://my.med.example.org". They are distinct from the
+ top-level value of "iss", which always refers to the issuer of the
+ event -- a medical consent service that is a relying party to the
+ OpenID Provider.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 10]
+
+RFC 8417 SET July 2018
+
+
+2.1.4. RISC Example
+
+ The following example JWT Claims Set is for an account disabled
+ event. At the time of this writing, this example corresponds to the
+ account disabled event defined in the OpenID RISC Event Types 1.0
+ [OpenID.RISC.Events] specification.
+
+ {
+ "iss": "https://idp.example.com/",
+ "jti": "756E69717565206964656E746966696572",
+ "iat": 1508184845,
+ "aud": "636C69656E745F6964",
+ "events": {
+ "https://schemas.openid.net/secevent/risc/event-type/account-disabled"
+ : {
+ "subject": {
+ "subject_type": "iss-sub",
+ "iss": "https://idp.example.com/",
+ "sub": "7375626A656374"
+ },
+ "reason": "hijacking"
+ }
+ }
+ }
+
+ Figure 4: Example RISC Event
+
+ Notice that parameters to the event are included in the event
+ payload, in this case, the "reason" and "cause-time" values. The
+ subject of the event is identified using the "subject" payload value,
+ which itself is a JSON object.
+
+2.2. Core SET Claims
+
+ The following claims from [RFC7519] are profiled for use in SETs:
+
+ "iss" (Issuer) Claim
+ As defined by Section 4.1.1 of [RFC7519], this claim contains a
+ string identifying the service provider publishing the SET (the
+ issuer). In some cases, the issuer of the SET will not be the
+ issuer associated with the security subject of the SET.
+ Therefore, implementers cannot assume that the issuers are the
+ same unless the profiling specification specifies that they are
+ for SETs conforming to that profile. This claim is REQUIRED.
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 11]
+
+RFC 8417 SET July 2018
+
+
+ "iat" (Issued At) Claim
+ As defined by Section 4.1.6 of [RFC7519], this claim contains a
+ value representing when the SET was issued. This claim is
+ REQUIRED.
+
+ "jti" (JWT ID) Claim
+ As defined by Section 4.1.7 of [RFC7519], this claim contains a
+ unique identifier for the SET. The identifier MUST be unique
+ within a particular event feed and MAY be used by clients to track
+ whether a particular SET has already been received. This claim is
+ REQUIRED.
+
+ "aud" (Audience) Claim
+ As defined by Section 4.1.3 of [RFC7519], this claim contains one
+ or more audience identifiers for the SET. This claim is
+ RECOMMENDED.
+
+ "sub" (Subject) Claim
+ As defined by Section 4.1.2 of [RFC7519], this claim contains a
+ StringOrURI value representing the principal that is the subject
+ of the SET. This is usually the entity whose "state" was changed.
+ For example:
+
+ * an IP Address was added to a blacklist;
+
+ * a URI representing a user resource that was modified; or,
+
+ * a token identifier (e.g. "jti") for a revoked token.
+
+ If used, the profiling specification MUST define the content and
+ format semantics for the value. This claim is OPTIONAL, as the
+ principal for any given profile may already be identified without
+ the inclusion of a subject claim. Note that some SET profiles MAY
+ choose to convey event subject information in the event payload
+ (either using the "sub" member name or another name), particularly
+ if the subject information is relative to issuer information that
+ is also conveyed in the event payload, which may be the case for
+ some identity SET profiles.
+
+ "exp" (Expiration Time) Claim
+ As defined by Section 4.1.4 of [RFC7519], this claim is the time
+ after which the JWT MUST NOT be accepted for processing. In the
+ context of a SET, however, this notion does not typically apply,
+ since a SET represents something that has already occurred and is
+ historical in nature. Therefore, its use is NOT RECOMMENDED.
+ (Also, see Section 4.1 for additional reasons not to use the "exp"
+ claim in some SET use cases.)
+
+
+
+
+Hunt, et al. Standards Track [Page 12]
+
+RFC 8417 SET July 2018
+
+
+ The following new claims are defined by this specification:
+
+ "events" (Security Events) Claim
+ This claim contains a set of event statements that each provide
+ information describing a single logical event that has occurred
+ about a security subject (e.g., a state change to the subject).
+ Multiple event identifiers with the same value MUST NOT be used.
+ The "events" claim MUST NOT be used to express multiple
+ independent logical events.
+
+ The value of the "events" claim is a JSON object whose members are
+ name/value pairs whose names are URIs identifying the event
+ statements being expressed. Event identifiers SHOULD be stable
+ values (e.g., a permanent URL for an event specification). For
+ each name present, the corresponding value MUST be a JSON object.
+ The JSON object MAY be an empty object ("{}"), or it MAY be a JSON
+ object containing data described by the profiling specification.
+
+ "txn" (Transaction Identifier) Claim
+ An OPTIONAL string value that represents a unique transaction
+ identifier. In cases in which multiple related JWTs are issued,
+ the transaction identifier claim can be used to correlate these
+ related JWTs. Note that this claim can be used in JWTs that are
+ SETs and also in JWTs using non-SET profiles.
+
+ "toe" (Time of Event) Claim
+ A value that represents the date and time at which the event
+ occurred. This value is a NumericDate (see Section 2 of
+ [RFC7519]). By omitting this claim, the issuer indicates that
+ they are not sharing an event time with the recipient. (Note that
+ in some use cases, the represented time might be approximate;
+ statements about the accuracy of this field MAY be made by
+ profiling specifications.) This claim is OPTIONAL.
+
+2.3. Explicit Typing of SETs
+
+ This specification registers the "application/secevent+jwt" media
+ type, which can be used to indicate that the content is a SET. SETs
+ MAY include this media type in the "typ" header parameter of the JWT
+ representing the SET to explicitly declare that the JWT is a SET.
+ This MUST be included if the SET could be used in an application
+ context in which it could be confused with other kinds of JWTs.
+
+ Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is
+ RECOMMENDED that the "application/" prefix be omitted. Therefore,
+ the "typ" value used SHOULD be "secevent+jwt".
+
+
+
+
+
+Hunt, et al. Standards Track [Page 13]
+
+RFC 8417 SET July 2018
+
+
+2.4. Security Event Token Construction
+
+ This section describes how to construct a SET.
+
+ The following is an example JWT Claims Set for a hypothetical SCIM
+ SET:
+
+ {
+ "iss": "https://scim.example.com",
+ "iat": 1458496404,
+ "jti": "4d3559ec67504aaba65d40b0363faad8",
+ "aud": [
+ "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
+ "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
+ ],
+ "events": {
+ "urn:ietf:params:scim:event:create": {
+ "ref":
+ "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
+ "attributes": ["id", "name", "userName", "password", "emails"]
+ }
+ }
+ }
+
+ Figure 5: Example Event Claims
+
+ The JSON Claims Set is encoded per [RFC7519].
+
+ In this example, the SCIM SET claims are encoded in an unsecured JWT.
+ The JOSE Header for this example is:
+
+ {"typ":"secevent+jwt","alg":"none"}
+
+ Base64url encoding (as defined by Section 2 of [RFC7515], including
+ the omission of all trailing '=' characters) of the octets of the
+ UTF-8 [RFC3629] representation of the JOSE Header yields:
+
+ eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJub25lIn0
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 14]
+
+RFC 8417 SET July 2018
+
+
+ The above example JWT Claims Set (with insignificant whitespace
+ removed) is encoded as follows (with line breaks for display purposes
+ only):
+
+ eyJpc3MiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJpYXQiOjE0NTg0OTY0M
+ DQsImp0aSI6IjRkMzU1OWVjNjc1MDRhYWJhNjVkNDBiMDM2M2ZhYWQ4IiwiYXVkIj
+ pbImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg
+ 3OTU5M2I3NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYw
+ NDUxNmIxZDA4NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybjppZXRmOnBhcmFtc
+ zpzY2ltOmV2ZW50OmNyZWF0ZSI6eyJyZWYiOiJodHRwczovL3NjaW0uZXhhbXBsZS
+ 5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsImF0dHJpYnV0ZXM
+ iOlsiaWQiLCJuYW1lIiwidXNlck5hbWUiLCJwYXNzd29yZCIsImVtYWlscyJdfX19
+
+ The encoded JWS signature is the empty string.
+
+ Concatenating the three encoded parts (JOSE Header, JWT Claims Set,
+ and JWS signature) in order with period ('.') characters between the
+ parts yields this complete SET (with line breaks for display purposes
+ only):
+
+ eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJub25lIn0
+ .
+ eyJpc3MiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJpYXQiOjE0NTg0OTY0M
+ DQsImp0aSI6IjRkMzU1OWVjNjc1MDRhYWJhNjVkNDBiMDM2M2ZhYWQ4IiwiYXVkIj
+ pbImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg
+ 3OTU5M2I3NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYw
+ NDUxNmIxZDA4NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybjppZXRmOnBhcmFtc
+ zpzY2ltOmV2ZW50OmNyZWF0ZSI6eyJyZWYiOiJodHRwczovL3NjaW0uZXhhbXBsZS
+ 5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsImF0dHJpYnV0ZXM
+ iOlsiaWQiLCJuYW1lIiwidXNlck5hbWUiLCJwYXNzd29yZCIsImVtYWlscyJdfX19
+ .
+
+ Figure 6: Example Unsecured Security Event Token
+
+ For the purpose of having a simpler example in Figure 6, an unsecured
+ token is shown. When SETs are not signed or encrypted, other
+ mechanisms such as TLS MUST be employed to provide integrity
+ protection, confidentiality, and issuer authenticity, as needed by
+ the application.
+
+ When validation (i.e., auditing) or additional transmission security
+ is required, JWS signing and/or JWE encryption MAY be used. To
+ create and or validate a signed and/or encrypted SET, follow the
+ instructions in Section 7 of [RFC7519].
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 15]
+
+RFC 8417 SET July 2018
+
+
+3. Requirements for SET Profiles
+
+ Profiling specifications of this specification define actual SETs to
+ be used in particular use cases. These profiling specifications
+ define the syntax and semantics of SETs conforming to that SET
+ profile and rules for validating those SETs. Profiling
+ specifications SHOULD define syntax, semantics, subject
+ identification, and validation.
+
+ Syntax
+ The syntax of the SETs defined, including:
+
+ Top-Level Claims
+ Claims and values in the JWT Claims Set. Examples are claims
+ defined by the JWT specification [RFC7519], this specification,
+ and by the profiling specification.
+
+ Event Payload
+ The JSON data structure contents and format, containing event-
+ specific information, if any (see Section 1.2).
+
+ Semantics
+ Defining the semantics of the SET contents for SETs utilizing the
+ profile is equally important. Possibly most important is defining
+ the procedures used to validate the SET issuer and to obtain the
+ keys controlled by the issuer that were used for cryptographic
+ operations used in the JWT representing the SET. For instance,
+ some profiles may define an algorithm for retrieving the SET
+ issuer's keys that uses the "iss" claim value as its input.
+ Likewise, if the profile allows (or requires) that the JWT be
+ unsecured, the means by which the integrity of the JWT is ensured
+ MUST be specified.
+
+ Subject Identification
+ Profiling specifications MUST define how the event subject is
+ identified in the SET, as well as how to differentiate between the
+ event subject's issuer and the SET issuer, if applicable. It is
+ NOT RECOMMENDED for profiling specifications to use the "sub"
+ claim in cases in which the subject is not globally unique and has
+ a different issuer from the SET itself.
+
+ Validation
+ Profiling specifications MUST clearly specify the steps that a
+ recipient of a SET utilizing that profile MUST perform to validate
+ that the SET is both syntactically and semantically valid.
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 16]
+
+RFC 8417 SET July 2018
+
+
+ Among the syntax and semantics of SETs that a profiling
+ specification may define is whether the value of the "events"
+ claim may contain multiple members, and what processing
+ instructions are employed in the single- and multiple-valued cases
+ for SETs conforming to that profile. Many valid choices are
+ possible. For instance, some profiles might allow multiple event
+ identifiers to be present and specify that any that are not
+ understood by recipients be ignored, thus enabling extensibility.
+ Other profiles might allow multiple event identifiers to be
+ present but require that all be understood if the SET is to be
+ accepted. Some profiles might require that only a single value be
+ present. All such choices are within the scope of profiling
+ specifications to define.
+
+4. Preventing Confusion between SETs and Other JWTs
+
+ Because [RFC7519] states that "all claims that are not understood by
+ implementations MUST be ignored", there is a consideration that a SET
+ might be confused with another kind of JWT from the same issuer.
+ Unless this confusion is prevented, this might enable an attacker who
+ possesses a SET to use it in a context in which another kind of JWT
+ is expected, or vice versa. This section presents concrete
+ techniques for preventing confusion between SETs and several other
+ specific kinds of JWTs, as well as generic techniques for preventing
+ possible confusion between SETs and other kinds of JWTs.
+
+4.1. Distinguishing SETs from ID Tokens
+
+ A SET might be confused with an ID Token [OpenID.Core] if a SET is
+ mistakenly or maliciously used in a context requiring an ID Token.
+ If a SET could otherwise be interpreted as a valid ID Token (because
+ it includes the required claims for an ID Token and valid issuer and
+ audience claim values for an ID Token), then that SET profile MUST
+ require that the "exp" claim not be present in the SET. Because
+ "exp" is a required claim in ID Tokens, valid ID Token
+ implementations will reject such a SET if presented as if it were an
+ ID Token.
+
+ Excluding "exp" from SETs that could otherwise be confused with ID
+ Tokens is actually defense in depth. In any OpenID Connect contexts
+ in which an attacker could attempt to substitute a SET for an ID
+ Token, the SET would actually already be rejected as an ID Token
+ because it would not contain the correct "nonce" claim value for the
+ ID Token to be accepted in contexts for which substitution is
+ possible.
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 17]
+
+RFC 8417 SET July 2018
+
+
+ Note that the use of explicit typing, as described in Section 2.3,
+ will not achieve disambiguation between ID Tokens and SETs, as the ID
+ Token validation rules do not use the "typ" header parameter value.
+
+4.2. Distinguishing SETs from Access Tokens
+
+ OAuth 2.0 [RFC6749] defines access tokens as being opaque.
+ Nonetheless, some implementations implement access tokens as JWTs.
+ Because the structure of these JWTs is implementation specific,
+ ensuring that a SET cannot be confused with such an access token is,
+ therefore, also implementation specific, generally. Nonetheless, it
+ is recommended that SET profiles employ the following strategies to
+ prevent possible substitutions of SETs for access tokens in contexts
+ in which that might be possible:
+
+ o Prohibit use of the "exp" claim, as is done to prevent ID Token
+ confusion.
+
+ o Where possible, use a separate "aud" claim value to distinguish
+ between the SET recipient and the protected resource that is the
+ audience of an access token.
+
+ o Modify access token validation systems to check for the presence
+ of the "events" claim as a means to detect security event tokens.
+ This is particularly useful if the same endpoint may receive both
+ types of tokens.
+
+ o Employ explicit typing, as described in Section 2.3, and modify
+ access token validation systems to use the "typ" header parameter
+ value.
+
+4.3. Distinguishing SETs from Other Kinds of JWTs
+
+ JWTs are now being used in application areas beyond the identity
+ applications in which they first appeared. For instance, the
+ "Session Initiation Protocol (SIP) Via Header Field Parameter to
+ Indicate Received Realm" [RFC8055] and "PASSporT: Personal Assertion
+ Token" [RFC8225] specifications both define JWT profiles that use
+ mostly or completely different sets of claims than are used by ID
+ Tokens. If it would otherwise be possible for an attacker to
+ substitute a SET for one of these (or other) kinds of JWTs, then the
+ SET profile must be defined in such a way that any substituted SET
+ will result in its rejection when validated as the intended kind of
+ JWT.
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 18]
+
+RFC 8417 SET July 2018
+
+
+ The most direct way to prevent confusion is to employ explicit
+ typing, as described in Section 2.3, and modify applicable token
+ validation systems to use the "typ" header parameter value. This
+ approach can be employed for new systems but may not be applicable to
+ existing systems.
+
+ Another way to ensure that a SET is not confused with another kind of
+ JWT is to have the JWT validation logic reject JWTs containing an
+ "events" claim unless the JWT is intended to be a SET. This approach
+ can be employed for new systems but may not be applicable to existing
+ systems. Validating that the JWT has an "events" claim will be
+ effective in preventing attackers from passing other kinds of JWTs
+ off as SETs.
+
+ For many use cases, the simplest way to prevent substitution is
+ requiring that the SET not include claims that are required for the
+ kind of JWT that might be the target of an attack. For example, for
+ [RFC8055], the "sip_callid" claim could be omitted and for [RFC8225],
+ the "orig" claim could be omitted.
+
+ In many contexts, simple measures such as these will accomplish the
+ task, should confusion otherwise even be possible. Note that this
+ topic is being explored in a more general fashion in "JSON Web Token
+ Best Current Practices" [JWT-BCP]. The proposed best practices in
+ that document may also be applicable for particular SET profiles and
+ use cases.
+
+5. Security Considerations
+
+5.1. Confidentiality and Integrity
+
+ SETs may contain sensitive information. Therefore, methods for
+ distribution of events SHOULD require the use of a transport-layer
+ security mechanism when distributing events. Parties MUST support
+ TLS 1.2 [RFC5246] or a higher version and MAY support additional
+ transport-layer mechanisms meeting its security requirements. When
+ using TLS, the client MUST perform a TLS server certificate check,
+ per [RFC6125]. Implementation security considerations for TLS can be
+ found in "Recommendations for Secure Use of Transport Layer Security
+ (TLS) and Datagram Transport Layer Security (DTLS)" [RFC7525].
+
+ Security events distributed through third parties or that carry
+ personally identifiable information MUST be encrypted using JWE
+ [RFC7516] or secured for confidentiality by other means.
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 19]
+
+RFC 8417 SET July 2018
+
+
+ Unless integrity of the JWT is ensured by other means, it MUST be
+ signed using JWS [RFC7515] by an issuer that is trusted to do so for
+ the use case so that the SET can be authenticated and validated by
+ the SET recipient.
+
+5.2. Delivery
+
+ This specification does not define a delivery mechanism for SETs. In
+ addition to confidentiality and integrity (discussed above),
+ implementers and profiling specifications must consider the
+ consequences of delivery mechanisms that are not secure and/or not
+ assured. For example, while a SET may be end-to-end secured using
+ JWE encrypted SETs, without (mutual) TLS, there is no assurance that
+ the correct endpoint received the SET and that it could be
+ successfully processed.
+
+5.3. Sequencing
+
+ This specification defines no means of ordering multiple SETs in a
+ sequence. Depending on the type and nature of the events represented
+ by SETs, order may or may not matter. For example, in provisioning,
+ event order is critical -- an object cannot be modified before it is
+ created. In other SET types, such as a token revocation, the order
+ of SETs for revoked tokens does not matter. If, however, the event
+ conveys a logged in or logged out status for a user subject, then
+ order becomes important.
+
+ Profiling specifications and implementers SHOULD take caution when
+ using timestamps such as "iat" to define order. Distributed systems
+ will have some amount of clock skew. Thus, time by itself will not
+ guarantee order.
+
+ Specifications profiling SET SHOULD define a mechanism for detecting
+ order or sequence of events when the order matters. For example, the
+ "txn" claim could contain an ordered value (e.g., a counter) that the
+ issuer includes, although just as for timestamps, ensuring such
+ ordering can be difficult in distributed systems.
+
+5.4. Timing Issues
+
+ When SETs are delivered asynchronously and/or out-of-band with
+ respect to the original action that incurred the security event, it
+ is important to consider that a SET might be delivered to a SET
+ recipient in advance of or behind the process that caused the event.
+ For example, a user having been required to log out and then log back
+ in again, may cause a "token revoked" SET to be issued, typically
+ causing the receiver to reset all active sessions at the receiver
+ that are related to that user. If a revocation SET arrives at the
+
+
+
+Hunt, et al. Standards Track [Page 20]
+
+RFC 8417 SET July 2018
+
+
+ same time as the user agent re-logs in, timing could cause problems
+ by erroneously treating the new user session as logged out.
+ Profiling specifications SHOULD be careful to consider both SET
+ expression and timing issues. For example, it might be more
+ appropriate to revoke a specific session or ID Token rather than a
+ general logout statement about a "user". Alternatively, profiling
+ specifications could use timestamps that allow new sessions to be
+ started immediately after a stated logout event time.
+
+5.5. Preventing Confusion
+
+ Also, see Section 4 above for both additional security considerations
+ and normative text on preventing SETs from being confused with other
+ kinds of JWTs.
+
+6. Privacy Considerations
+
+ If a SET needs to be retained for audit purposes, the signature can
+ be used to provide verification of its authenticity.
+
+ SET issuers SHOULD attempt to specialize SETs so that their content
+ is targeted to the specific business and protocol needs of the
+ intended SET recipients.
+
+ When sharing personally identifiable information or information that
+ is otherwise considered confidential to affected users, SET issuers
+ and recipients should have the appropriate legal agreements and user
+ consent and/or terms of service in place.
+
+ The propagation of subject identifiers can be perceived as personally
+ identifiable information. Where possible, SET issuers and recipients
+ SHOULD devise approaches that prevent propagation -- for example, the
+ passing of a salted hash value that requires the SET recipient to
+ know the subject.
+
+ In some cases, it may be possible for a SET recipient to correlate
+ different events and thereby gain information about a subject that
+ the SET issuer did not intend to share. For example, a SET recipient
+ might be able to use "iat" values or highly precise "toe" values to
+ determine that two otherwise un-relatable events actually relate to
+ the same real-world event. The union of information from both events
+ could allow a SET recipient to de-anonymize data or recognize that
+ unrelated identifiers relate to the same individual. SET issuers
+ SHOULD take steps to minimize the chance of event correlation, when
+ such correlation would constitute a privacy violation. For instance,
+ they could use approximate values for the "toe" claim or arbitrarily
+ delay SET issuance, where such delay can be tolerated.
+
+
+
+
+Hunt, et al. Standards Track [Page 21]
+
+RFC 8417 SET July 2018
+
+
+7. IANA Considerations
+
+7.1. JSON Web Token Claims Registration
+
+ IANA has registered the "events", "toe", and "txn" claims in the IANA
+ "JSON Web Token Claims" registry [IANA.JWT.Claims] established by
+ [RFC7519].
+
+7.1.1. Registry Contents
+
+ o Claim Name: "events"
+ o Claim Description: Security Events
+ o Change Controller: IESG
+ o Specification Document(s): Section 2.2 of [RFC8417]
+
+ o Claim Name: "toe"
+ o Claim Description: Time of Event
+ o Change Controller: IESG
+ o Specification Document(s): Section 2.2 of [RFC8417]
+
+ o Claim Name: "txn"
+ o Claim Description: Transaction Identifier
+ o Change Controller: IESG
+ o Specification Document(s): Section 2.2 of [RFC8417]
+
+7.2. Structured Syntax Suffix Registration
+
+ IANA has registered the "+jwt" structured syntax suffix [RFC6838] in
+ the "Structured Syntax Suffix" registry [IANA.StructuredSuffix] in
+ the manner described in [RFC6838], which can be used to indicate that
+ the media type is encoded as a JWT.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 22]
+
+RFC 8417 SET July 2018
+
+
+7.2.1. Registry Contents
+
+ o Name: JSON Web Token (JWT)
+ o +suffix: +jwt
+ o References: Section 3 of [RFC7519], Section 7.2 of [RFC8417]
+ o Encoding Considerations: binary; JWT values are encoded as a
+ series of base64url-encoded values (with trailing '=' characters
+ removed), some of which may be the empty string, separated by
+ period ('.') characters.
+ o Interoperability Considerations: N/A
+ o Fragment Identifier Considerations:
+ The syntax and semantics of fragment identifiers specified for
+ +jwt SHOULD be as specified for "application/jwt". (At
+ publication of this document, there is no fragment identification
+ syntax defined for "application/jwt".)
+
+ The syntax and semantics for fragment identifiers for a specific
+ "xxx/yyy+jwt" SHOULD be processed as follows:
+
+ For cases defined in +jwt where the fragment identifier resolves
+ per the +jwt rules, process as specified in +jwt.
+
+ For cases defined in +jwt where the fragment identifier does not
+ resolve per the +jwt rules, process as specified in "xxx/yyy+jwt".
+
+ For cases not defined in +jwt, process as specified in "xxx/
+ yyy+jwt".
+ o Security Considerations: See Section 11 of [RFC7519].
+ o Contact:
+ Michael B. Jones, mbj@microsoft.com
+ o Author/Change Controller:
+ Security Events Working Group.
+ The IESG has change control over this registration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 23]
+
+RFC 8417 SET July 2018
+
+
+7.3. Media Type Registration
+
+7.3.1. Registry Contents
+
+ This section registers the "application/secevent+jwt" media type
+ [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the
+ manner described in [RFC6838], which can be used to indicate that the
+ content is a SET.
+
+ o Type name: application
+ o Subtype name: secevent+jwt
+ o Required parameters: N/A
+ o Optional parameters: N/A
+ o Encoding considerations: binary; A SET is a JWT; JWT values are
+ encoded as a series of base64url-encoded values (with trailing '='
+ characters removed), some of which may be the empty string,
+ separated by period ('.') characters.
+ o Security considerations: See Section 5 of [RFC8417]
+ o Interoperability considerations: N/A
+ o Published specification: Section 2.3 of [RFC8417]
+ o Applications that use this media type: Applications that exchange
+ SETs
+ o Fragment identifier considerations: N/A
+ o Additional information:
+
+ Magic number(s): N/A
+ File extension(s): N/A
+ Macintosh file type code(s): N/A
+
+ o Person & email address to contact for further information:
+ Michael B. Jones, mbj@microsoft.com
+ o Intended usage: COMMON
+ o Restrictions on usage: none
+ o Author: Michael B. Jones, mbj@microsoft.com
+ o Change controller: IESG
+ o Provisional registration? No
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 24]
+
+RFC 8417 SET July 2018
+
+
+8. References
+
+8.1. Normative References
+
+ [IANA.JWT.Claims]
+ IANA, "JSON Web Token Claims",
+ <http://www.iana.org/assignments/jwt>.
+
+ [IANA.MediaTypes]
+ IANA, "Media Types",
+ <http://www.iana.org/assignments/media-types>.
+
+ [IANA.StructuredSuffix]
+ IANA, "Structured Syntax Suffix",
+ <https://www.iana.org/assignments/
+ media-type-structured-suffix/>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
+ 2003, <https://www.rfc-editor.org/info/rfc3629>.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, DOI 10.17487/RFC3986, January 2005,
+ <https://www.rfc-editor.org/info/rfc3986>.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246,
+ DOI 10.17487/RFC5246, August 2008,
+ <https://www.rfc-editor.org/info/rfc5246>.
+
+ [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
+ Verification of Domain-Based Application Service Identity
+ within Internet Public Key Infrastructure Using X.509
+ (PKIX) Certificates in the Context of Transport Layer
+ Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
+ 2011, <https://www.rfc-editor.org/info/rfc6125>.
+
+ [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>.
+
+
+
+
+
+Hunt, et al. Standards Track [Page 25]
+
+RFC 8417 SET July 2018
+
+
+ [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
+ Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
+ 2015, <https://www.rfc-editor.org/info/rfc7515>.
+
+ [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
+ RFC 7516, DOI 10.17487/RFC7516, May 2015,
+ <https://www.rfc-editor.org/info/rfc7516>.
+
+ [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
+ (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
+ <https://www.rfc-editor.org/info/rfc7519>.
+
+ [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
+ "Recommendations for Secure Use of Transport Layer
+ Security (TLS) and Datagram Transport Layer Security
+ (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
+ 2015, <https://www.rfc-editor.org/info/rfc7525>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+8.2. Informative References
+
+ [JWT-BCP] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
+ Current Practices", Work in Progress,
+ draft-ietf-oauth-jwt-bcp-03, May 2018.
+
+ [OpenID.BackChannel]
+ Jones, M. and J. Bradley, "OpenID Connect Back-Channel
+ Logout 1.0", January 2017, <http://openid.net/specs/
+ openid-connect-backchannel-1_0.html>.
+
+ [OpenID.Core]
+ Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
+ C. Mortimore, "OpenID Connect Core 1.0", November 2014,
+ <http://openid.net/specs/openid-connect-core-1_0.html>.
+
+ [OpenID.RISC.Events]
+ Scurtescu, M., Backman, A., Hunt, P., and J. Bradley,
+ "OpenID RISC Event Types 1.0", April 2018,
+ <http://openid.net/specs/
+ openid-risc-event-types-1_0.html>.
+
+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046,
+ DOI 10.17487/RFC2046, November 1996,
+ <https://www.rfc-editor.org/info/rfc2046>.
+
+
+
+Hunt, et al. Standards Track [Page 26]
+
+RFC 8417 SET July 2018
+
+
+ [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
+ Specifications and Registration Procedures", BCP 13,
+ RFC 6838, DOI 10.17487/RFC6838, January 2013,
+ <https://www.rfc-editor.org/info/rfc6838>.
+
+ [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
+ and C. Mortimore, "System for Cross-domain Identity
+ Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
+ September 2015, <https://www.rfc-editor.org/info/rfc7644>.
+
+ [RFC8055] Holmberg, C. and Y. Jiang, "Session Initiation Protocol
+ (SIP) Via Header Field Parameter to Indicate Received
+ Realm", RFC 8055, DOI 10.17487/RFC8055, January 2017,
+ <https://www.rfc-editor.org/info/rfc8055>.
+
+ [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
+ Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
+ <https://www.rfc-editor.org/info/rfc8225>.
+
+Acknowledgments
+
+ The editors would like to thank the members of the IETF SCIM working
+ group, which began discussions of provisioning events starting with
+ draft-hunt-scim-notify-00 in 2015. The editors would like to thank
+ the participants in the IETF id-event mailing list, the Security
+ Events working group, and related working groups for their
+ contributions to this specification. The specification incorporates
+ suggestions made by many people, including Annabelle Backman, John
+ Bradley, Alissa Cooper, Ned Freed, Dick Hardt, Russ Housley, Benjamin
+ Kaduk, Mirja Kuehlewind, Mark Lizar, Alexey Melnikov, Andrew Nash,
+ Eric Rescorla, Adam Roach, Justin Richer, Nat Sakimura, Marius
+ Scurtescu, Yaron Sheffer, and Martin Vigoureux.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 27]
+
+RFC 8417 SET July 2018
+
+
+Authors' Addresses
+
+ Phil Hunt (editor)
+ Oracle Corporation
+
+ Email: phil.hunt@yahoo.com
+
+
+ Michael B. Jones
+ Microsoft
+
+ Email: mbj@microsoft.com
+ URI: http://self-issued.info/
+
+
+ William Denniss
+ Google
+
+ Email: rfc8417@wdenniss.com
+ URI: https://wdenniss.com/SET
+
+
+ Morteza Ansari
+ Cisco
+
+ Email: morteza.ansari@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hunt, et al. Standards Track [Page 28]
+