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
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.
本规范定义了安全事件令牌（SET）数据结构。集合从发行人的角度描述关于主题的事实陈述。这些事实陈述表示直接发生于安全主体或与之相关的事件，例如，关于代表主体发行或撤销令牌的陈述。本规范旨在表示与安全和身份相关的事件。一个集合是JSON Web令牌（JWT），可以选择对其进行签名和/或加密。可以通过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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8417.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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].
该规范定义了一个可扩展的安全事件令牌（SET）数据结构，可以使用HTTP等协议进行交换。该规范建立在JSON Web令牌（JWT）格式[RFC7519]的基础上，以提供一个自包含的令牌，该令牌可以选择使用JSON Web签名（JWS）[RFC7515]进行签名和/或使用JSON Web加密（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.
本规范概述了JWT用于发布集合的用途。本规范定义了分析规范用来定义实际事件及其含义的基本格式。本规范使用非规范性示例事件来演示如何构造事件。
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:
安全事件不是双方之间发出的命令。集合从发行人的角度描述关于主题（例如，web资源、令牌、IP地址、发行人本身）的事实陈述。这些事实陈述表示直接发生于安全主体或关于安全主体的逻辑事件，例如，关于代表主体发行或撤销令牌的陈述。安全主题可以是永久性的（例如，用户帐户）或临时性的（例如，HTTP会话）。状态更改可以描述实体状态的直接更改、状态的隐式更改或其他更高级别的安全声明，例如：
o The creation, modification, removal of a resource.
o 资源的创建、修改、删除。
o The resetting or suspension of an account.
o 账户的重置或暂停。
o The revocation of a security token prior to its expiry.
o 在安全令牌到期之前对其进行的撤销。
o The logout of a user session.
o 用户会话的注销。
o An indication that a user has been given control of an email identifier that was previously controlled by another user.
o 一种指示，表明一个用户已被授予对以前由另一个用户控制的电子邮件标识符的控制权。
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
虽然主体状态更改通常由用户代理或安全子系统触发，但事件的发布和传输可能会异步发生，并在导致生成安全事件的更改的操作的反向通道中发生。随后，集合接收者在收到集合后，验证并解释接收到的集合，并采取自己的独立操作（如果有的话）。对于
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.
虽然集合接收者通常会在接收集合时采取操作，但不能将安全事件假定为命令或请求。本规范的目的是为事实陈述定义一种语法，集合接收者可以出于自己的目的对其进行解释。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
For purposes of readability, examples are not URL encoded. Implementers MUST percent-encode URLs as described in Section 2.1 of [RFC3986].
为了便于阅读，示例不是URL编码的。实施者必须按照[RFC3986]第2.1节所述对URL进行百分比编码。
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.
在本文件中，所有图形可能包含空格和额外的换行符，以确保可读性和空间限制。同样，出于空间和可读性的原因，示例中包含的一些URI也被缩短了。
The following definitions are used with SETs:
以下定义用于集合：
Security Event Token (SET) A SET is a JWT [RFC7519] conforming to this specification.
安全事件令牌（集合）集合是符合本规范的JWT[RFC7519]。
SET Issuer A service provider that creates SETs to be sent to other service providers known as SET recipients.
SET Issuer创建要发送给其他服务提供商（称为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.
集合收件人集合收件人是通过某种分发方法接收集合的实体。集合接收者是指[RFC7519]中称为“接收者”或相关规范中称为“接收者”的同一实体。
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.
主题集合描述主题发生的事件或状态更改。例如，主题可以是主体（例如，[RFC7519]第4.1.2节）、web资源、实体（如IP地址）或集合的颁发者。
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.
事件标识符JSON对象元素的成员名称，该元素是集合中“事件”声明的值。此成员名称必须是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.
事件负载JSON对象元素的成员值，该值是集合中“事件”声明的值。此成员值必须是JSON对象。
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.
分析规范分析集合数据结构以定义一个或多个特定事件类型及其关联的声明和处理规则的规范。
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:
集合是一种JWT[RFC7519]数据结构，表示主体发生的安全事件的一个或多个相关方面。集合中的JWT声明集合具有以下结构：
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 JWT索赔集合中的顶级索赔称为集合“信封”。每一套中都有一些这样的主张；其他选项将特定于特定的设定纵断面或纵断面族。信封中的声明应在“JSON Web令牌声明”注册表[IANA.JWT.Claims]中注册，或者是[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 本规范中描述和定义的信封声明用于验证集合并提供集合中包含的事件数据的相关信息。“events”声明包含事件标识符和表示有关安全主题的事件特定数据。信封可以包括特定于事件或特定于概要文件的数据。“events”声明值必须是至少包含一个成员的JSON对象。
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
o “events”JSON对象的每个成员都是一个名称/值对。JSON成员名称是一个URI字符串值，它是事件标识符，对应的值是一个JSON对象，称为事件“负载”。payload JSON对象包含与该事件标识符相关的声明，不需要注册为JWT
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 ("{}").
声称。这些声明由定义事件的分析规范定义。没有有效负载声明的事件应表示为空JSON对象（“{}”）。
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:
o 当一个集合中包含多个事件标识符时，它们表示安全主体发生的同一状态转换的多个方面。它们不用于聚合关于同一主题的不同事件。除此之外，对包含多个事件标识符的集合的解释超出了本规范的范围；如第3节所述，分析规范可以定义其自己关于使用包含多个事件标识符的集合的规则。多个值的可能用途包括但不限于：
* 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.
* 特定集合颁发者和集合接收者之间使用的特定用途事件URI。
This section illustrates several possible uses of SETs through non-normative examples.
本节通过非规范性示例说明集合的几种可能用途。
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.
以下示例显示了用于跨域身份管理（SCIM）[RFC7644]密码重置集的假设系统的JWT声明集。接收器可以使用这样的集合作为触发器来重置与所识别的用户相关的活动用户代理会话。
{
"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
}
}
}
{
"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
图1：SCIM密码重置事件示例
The JWT Claims Set usage consists of:
JWT索赔集的用途包括：
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 “events”声明指定假设的SCIM URN（“URN:ietf:params:SCIM:event:passwordReset”）用于密码重置，以及第二个值https://example.com/scim/event/ passwordResetExt”，用于提供其他事件信息，如当前重置计数。
o The "iss" claim, denoting the SET issuer.
o “iss”声明，表示集合颁发者。
o The "sub" claim, specifying the SCIM resource URI that was affected.
o “sub”声明，指定受影响的SCIM资源URI。
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].)
o “aud”声明，指定活动的预期受众。（在[RFC7519]第4.1.3节中定义了“aud”索赔的语法。）
The SET contains two event payloads:
该集合包含两个事件有效载荷：
o The "id" claim represents SCIM's unique identifier for a subject.
o “id”声明表示SCIM对受试者的唯一标识符。
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.
o 由“”标识的第二个有效载荷https://example.com/scim/event/ passwordResetExt”和有效负载声明“resetAttempts”传递重置尝试的当前计数。在本例中，虽然计数对发行人来说是一个简单的事实陈述，但值（计数）的含义由接收人决定。例如，接收者可以使用这样的值来推断增加的风险。
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.
在此示例中，SCIM事件表示密码已更新，当前密码重置计数为5。请注意，“resetAttempts”的值位于用于传递此信息的事件的事件负载中。
Here is another example JWT Claims Set for a security event token, this one for a Logout Token:
下面是为安全事件令牌设置的另一个JWT声明示例，该声明用于注销令牌：
{
"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": {}
}
}
{
"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
图2:OpenID返回通道注销事件示例
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.
注意，上面的集合有一个空的JSON对象，并使用JWT声明的“sub”和“sid”来标识注销的主题。在撰写本文时，此示例对应于OpenID Connect Back Channel logout 1.0[OpenID.BackChannel]规范中定义的注销令牌。
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:
在下面的JWT索赔集示例中，虚构的医疗服务收集医疗行为的同意书并通知其他方。确认同意的个人最初通过OpenID Connect进行身份验证。在这种情况下，安全事件的颁发者是应用程序，而不是OpenID提供程序：
{
"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"
]
}
}
}
{
"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
图3：同意事件示例
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.
在上面的示例中，事件的有效负载中包含的属性“iss”https://openid.net/heart/specs/consent.html“指证券主体（“子”）的发行人，而非集合发行人”https://my.med.example.org". 它们不同于“iss”的顶级值，iss总是指事件的发布者——一个作为OpenID提供者的依赖方的医疗同意服务。
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.
以下示例JWT声明集用于帐户禁用事件。在撰写本文时，此示例对应于OpenID RISC事件类型1.0[OpenID.RISC.Events]规范中定义的帐户禁用事件。
{
"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"
}
}
}
{
"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
图4：RISC事件示例
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.
请注意，事件的参数包括在事件负载中，在本例中是“原因”和“原因时间”值。事件的主题使用“subject”有效负载值标识，该值本身是一个JSON对象。
The following claims from [RFC7519] are profiled for use in SETs:
[RFC7519]中的以下声明是成套使用的：
"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.
[RFC7519]第4.1.1节定义的“iss”（发卡机构）声明，该声明包含一个字符串，标识发布该集合的服务提供商（发卡机构）。在某些情况下，集合的发行人将不是与集合的安全主体相关联的发行人。因此，实现者不能假设发布者是相同的，除非分析规范指定它们用于符合该分析的集合。这项索赔是必需的。
"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.
[RFC7519]第4.1.6节定义的“iat”（发布于）索赔，该索赔包含一个值，该值表示该集合发布的时间。这项索赔是必需的。
"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.
[RFC7519]第4.1.7节定义的“jti”（JWT ID）声明，该声明包含集合的唯一标识符。标识符在特定的事件提要中必须是唯一的，客户端可以使用该标识符跟踪是否已接收到特定的集合。这项索赔是必需的。
"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.
[RFC7519]第4.1.3节定义的“aud”（观众）声明，该声明包含该集合的一个或多个观众标识符。建议提出这项索赔。
"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:
[RFC7519]第4.1.2节定义的“子”（主体）权利要求，该权利要求包含一个StringOrURI值，表示作为集合主体的主体。这通常是其“状态”已更改的实体。例如：
* an IP Address was added to a blacklist;
* 一个IP地址被添加到黑名单中；
* a URI representing a user resource that was modified; or,
* 表示已修改的用户资源的URI；或
* a token identifier (e.g. "jti") for a revoked token.
* 已撤销令牌的令牌标识符（如“jti”）。
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.)
[RFC7519]第4.1.4节定义的“exp”（到期时间）索赔，该索赔是不得接受JWT处理的时间。然而，在集合的上下文中，这一概念通常不适用，因为集合表示已经发生的事物，并且在本质上是历史的。因此，不建议使用它。（另外，关于在某些特定用例中不使用“exp”声明的其他原因，请参见第4.1节。）
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.
“事件”（Security 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.
“events”声明的值是一个JSON对象，其成员是名称/值对，其名称是标识所表达事件语句的URI。事件标识符应为稳定值（例如，事件规范的永久URL）。对于存在的每个名称，相应的值必须是JSON对象。JSON对象可以是空对象（“{}”），也可以是包含分析规范所描述数据的JSON对象。
"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.
“txn”（事务标识符）声明表示唯一事务标识符的可选字符串值。在发出多个相关JWT的情况下，事务标识符声明可用于关联这些相关JWT。请注意，此声明可用于作为集合的JWT，也可用于使用非集合配置文件的JWT。
"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.
“toe”（事件发生时间）声明一个值，该值表示事件发生的日期和时间。该值为数字日期（见[RFC7519]第2节）。通过省略此声明，发卡机构表示他们没有与收件人共享事件时间。（注意，在某些用例中，表示的时间可能是近似值；关于此字段的准确性的声明可以通过分析规范进行。）此声明是可选的。
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.
本规范注册了“application/secevent+jwt”媒体类型，可用于指示内容是一组。集合可以在表示集合的JWT的“typ”头参数中包括该媒体类型，以明确声明JWT是集合。如果集合可以在可能与其他类型的JWT混淆的应用程序上下文中使用，则必须包括该集合。
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".
根据[RFC7515]第4.1.9节中“类型”的定义，建议省略“application/”前缀。因此，使用的“类型”值应为“secevent+jwt”。
This section describes how to construct a SET.
本节介绍如何构造集合。
The following is an example JWT Claims Set for a hypothetical SCIM SET:
以下是假设SCIM集合的JWT索赔集合示例：
{
"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"]
}
}
}
{
"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
图5：事件索赔示例
The JSON Claims Set is encoded per [RFC7519].
JSON声明集按照[RFC7519]进行编码。
In this example, the SCIM SET claims are encoded in an unsecured JWT. The JOSE Header for this example is:
在本例中，SCIM集合声明以不安全的JWT编码。本例的JOSE标头为：
{"typ":"secevent+jwt","alg":"none"}
{"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:
JOSE标头的UTF-8[RFC3629]表示的八位字节的Base64url编码（如[RFC7515]第2节所定义，包括省略所有尾随“=”字符）产生：
eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJub25lIn0
eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJub25lIn0
The above example JWT Claims Set (with insignificant whitespace removed) is encoded as follows (with line breaks for display purposes only):
上述示例JWT声明集（删除了不重要的空白）编码如下（换行符仅用于显示目的）：
eyJpc3MiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJpYXQiOjE0NTg0OTY0M
DQsImp0aSI6IjRkMzU1OWVjNjc1MDRhYWJhNjVkNDBiMDM2M2ZhYWQ4IiwiYXVkIj
pbImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg
3OTU5M2I3NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYw
NDUxNmIxZDA4NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybjppZXRmOnBhcmFtc
zpzY2ltOmV2ZW50OmNyZWF0ZSI6eyJyZWYiOiJodHRwczovL3NjaW0uZXhhbXBsZS
5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsImF0dHJpYnV0ZXM
iOlsiaWQiLCJuYW1lIiwidXNlck5hbWUiLCJwYXNzd29yZCIsImVtYWlscyJdfX19
eyJpc3MiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJpYXQiOjE0NTg0OTY0M
DQsImp0aSI6IjRkMzU1OWVjNjc1MDRhYWJhNjVkNDBiMDM2M2ZhYWQ4IiwiYXVkIj
pbImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg
3OTU5M2I3NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYw
NDUxNmIxZDA4NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybjppZXRmOnBhcmFtc
zpzY2ltOmV2ZW50OmNyZWF0ZSI6eyJyZWYiOiJodHRwczovL3NjaW0uZXhhbXBsZS
5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsImF0dHJpYnV0ZXM
iOlsiaWQiLCJuYW1lIiwidXNlck5hbWUiLCJwYXNzd29yZCIsImVtYWlscyJdfX19
The encoded JWS signature is the empty string.
编码的JWS签名是空字符串。
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):
将三个编码部分（JOSE Header、JWT Claims Set和JWS signature）按顺序与部分之间的句点（'.'）字符连接在一起，就得到了这个完整的部分集（换行符仅用于显示）：
eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJub25lIn0 . eyJpc3MiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJpYXQiOjE0NTg0OTY0M DQsImp0aSI6IjRkMzU1OWVjNjc1MDRhYWJhNjVkNDBiMDM2M2ZhYWQ4IiwiYXVkIj pbImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg 3OTU5M2I3NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYw NDUxNmIxZDA4NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybjppZXRmOnBhcmFtc zpzY2ltOmV2ZW50OmNyZWF0ZSI6eyJyZWYiOiJodHRwczovL3NjaW0uZXhhbXBsZS 5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsImF0dHJpYnV0ZXM iOlsiaWQiLCJuYW1lIiwidXNlck5hbWUiLCJwYXNzd29yZCIsImVtYWlscyJdfX19 .
EYJ0EXAIIJZWNLDMVUDCTQD3QICHbGCIOIJUb25Lin0。EYJPC3mioIjHrWcZOvZOvZOvJ2ZHyWQ4iIyxHbZ5JB20IlCjPyxQiOj0NtG0NtG0Nt0Nt0NdJJj1OwJj1DdJHjWnjVkNdDm2M2ZHyWwQ4iIyxVkij PBiWc2Nc2Nc2Nc2Nb2Nb2Nb2Nb2Nb2Nb2Nb9Nb9GzWgWkCc8Nc8Nc8NgWc8Nc8Nc8Nc8Nc8Nv8Nc8Nc8Nc8Nc8NgWc8Nc8Nc8Nc8Nc8Nc8Nc8Nc8Nc8NgWc8Nc8Nc8Nc8Nc8NgzZZPZY2LTOMV2ZW50OMNYZWF0ZSI6EYJYZWYIOIJHRWCZOVL3NJAW0UZXHHBXBSZ 5JB20VVVXNLCNMVNDRMNJE0MMRMOTZZYJYXZTC1MJFKOSIMF0DHJPYNZV0ZXM IOLSIAWYIWYIWYLJ5HBWYLJWYXNZD29YZDCYDCYFX19。
Figure 6: Example Unsecured Security Event Token
图6：示例不安全安全事件令牌
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.
为了在图6中有一个更简单的示例，显示了一个不安全的令牌。如果未对集合进行签名或加密，则必须根据应用程序的需要使用TLS等其他机制来提供完整性保护、机密性和颁发者真实性。
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].
当需要验证（即审计）或额外的传输安全性时，可以使用JWS签名和/或JWE加密。要创建和/或验证签名和/或加密集，请按照[RFC7519]第7节中的说明进行操作。
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.
JWT声明集中的顶级声明和值。例如，JWT规范[RFC7519]、本规范和评测规范定义的声明。
Event Payload The JSON data structure contents and format, containing event-specific information, if any (see Section 1.2).
事件有效负载JSON数据结构内容和格式，包含特定于事件的信息（如有）（参见第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.
语义为使用概要文件的集合定义集合内容的语义同样重要。可能最重要的是定义用于验证集合颁发者和获取由颁发者控制的密钥的过程，这些密钥用于表示集合的JWT中使用的加密操作。例如，一些概要文件可能会定义一种算法，用于检索集合颁发者的密钥，该算法使用“iss”声明值作为其输入。同样，如果配置文件允许（或要求）JWT不安全，则必须指定确保JWT完整性的方法。
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.
主题识别分析规范必须定义如何在集合中识别事件主题，以及如何区分事件主题的发布者和集合发布者（如果适用）。如果主题不是全局唯一的，并且具有与集本身不同的颁发者，则不建议评测规范使用“sub”声明。
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.
验证配置规范必须明确指定使用该配置文件的集合的接收者必须执行的步骤，以验证集合在语法和语义上是否有效。
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.
在分析规范可能定义的集合的语法和语义中，包括“事件”声明的值是否包含多个成员，以及在符合该分析规范的集合的单值和多值情况下使用了哪些处理指令。许多有效的选择是可能的。例如，某些概要文件可能允许存在多个事件标识符，并指定忽略收件人不理解的任何事件标识符，从而实现可扩展性。其他配置文件可能允许存在多个事件标识符，但如果要接受该集合，则需要理解所有事件标识符。某些配置文件可能要求仅存在一个值。所有这些选择都在要定义的分析规范的范围内。
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.
因为[RFC7519]声明“所有未被实现理解的声明都必须忽略”，所以需要考虑的是，集合可能会与来自同一发行人的另一种JWT混淆。除非防止这种混淆，否则这可能使拥有集合的攻击者能够在预期使用另一种JWT的上下文中使用该集合，反之亦然。本节介绍了防止集合与其他几种特定类型JWT之间混淆的具体技术，以及防止集合与其他类型JWT之间可能混淆的通用技术。
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.
如果在需要ID令牌的上下文中错误或恶意使用集合，则集合可能与ID令牌[OpenID.Core]混淆。如果集合可以被解释为有效的ID令牌（因为它包括ID令牌所需的声明以及ID令牌的有效颁发者和受众声明值），则集合配置文件必须要求集合中不存在“exp”声明。因为“exp”是ID令牌中的一个必需声明，所以有效的ID令牌实现将拒绝这样一个集合，如果它是一个ID令牌。
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.
从可能与ID标记混淆的集合中排除“exp”实际上是一种深度防御。在任何OpenID Connect上下文中，如果攻击者试图用一个集合替换ID令牌，该集合实际上已经作为ID令牌被拒绝，因为它不包含在可能替换的上下文中要接受的ID令牌的正确“nonce”声明值。
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.
请注意，如第2.3节所述，使用显式键入不会消除ID标记和集合之间的歧义，因为ID标记验证规则不使用“typ”头参数值。
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:
OAuth 2.0[RFC6749]将访问令牌定义为不透明的。尽管如此，有些实现将访问令牌实现为JWT。由于这些JWT的结构是特定于实现的，因此确保集合不会与这样的访问令牌混淆通常也是特定于实现的。尽管如此，建议集合配置文件采用以下策略，以防止在可能的上下文中为访问令牌替换集合：
o Prohibit use of the "exp" claim, as is done to prevent ID Token confusion.
o 禁止使用“exp”声明，这样做是为了防止ID令牌混淆。
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 在可能的情况下，使用单独的“aud”声明值来区分设置的收件人和作为访问令牌的访问群体的受保护资源。
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 修改访问令牌验证系统，以检查是否存在“事件”声明，以此作为检测安全事件令牌的手段。如果同一端点可能同时接收两种类型的令牌，则这一点特别有用。
o Employ explicit typing, as described in Section 2.3, and modify access token validation systems to use the "typ" header parameter value.
o 如第2.3节所述，使用显式键入，并修改访问令牌验证系统以使用“typ”头参数值。
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.
JWT现在正在应用领域中使用，而不仅仅是它们最初出现的身份应用领域。例如，“会话初始化协议（SIP）Via Header Field Parameter to Indication Received Realm”[RFC8055]和“PASSporT:Personal Assertion Token”[RFC8225]规范都定义了JWT配置文件，它们使用的声明集与ID令牌使用的声明集大部分或完全不同。如果攻击者有可能用一个集合替换这些（或其他）类型的JWT之一，则必须以这样的方式定义集合配置文件，即任何替换的集合在验证为预期类型的JWT时都会被拒绝。
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.
防止混淆的最直接方法是使用显式键入，如第2.3节所述，并修改适用的令牌验证系统以使用“typ”头参数值。此方法可用于新系统，但可能不适用于现有系统。
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.
确保集合不会与另一种JWT混淆的另一种方法是让JWT验证逻辑拒绝包含“事件”声明的JWT，除非JWT打算成为集合。此方法可用于新系统，但可能不适用于现有系统。验证JWT是否具有“事件”声明将有效防止攻击者将其他类型的JWT作为集合传递出去。
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.
对于许多用例，防止替换的最简单方法是要求集合中不包含可能成为攻击目标的JWT类型所需的声明。例如，对于[RFC8055]，可以省略“sip_callid”权利要求，对于[RFC8225]，可以省略“orig”权利要求。
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.
在许多情况下，简单的措施，如这些将完成任务，否则甚至可能出现混乱。请注意，在“JSON Web令牌最佳当前实践”[JWT-BCP]中，将以更一般的方式探讨此主题。该文件中提出的最佳实践也可能适用于特定的集合概要和用例。
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].
集合可能包含敏感信息。因此，分发事件的方法应该要求在分发事件时使用传输层安全机制。各方必须支持TLS 1.2[RFC5246]或更高版本，并可能支持满足其安全要求的其他传输层机制。使用TLS时，客户端必须按照[RFC6125]执行TLS服务器证书检查。TLS的实施安全注意事项可在“安全使用传输层安全性（TLS）和数据报传输层安全性（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.
通过第三方分发或携带个人识别信息的安全事件必须使用JWE[RFC7516]进行加密或通过其他方式进行保密。
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.
除非通过其他方式确保JWT的完整性，否则必须由受信任的发卡机构使用JWS[RFC7515]对其进行签名，以便集合接收方可以对集合进行身份验证和验证。
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.
本规范未定义集合的传递机制。除了机密性和完整性（上文讨论）之外，实现者和分析规范必须考虑不安全和/或不保证的传递机制的后果。例如，虽然可以使用JWE加密集对一个集进行端到端的安全保护，但没有（相互）TLS，无法保证正确的端点接收到该集并且可以成功处理该集。
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.
当使用诸如“iat”之类的时间戳来定义顺序时，分析规范和实现人员应该小心。分布式系统会有一定程度的时钟偏差。因此，时间本身并不能保证秩序。
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.
规范分析集应该定义一种机制，用于在顺序重要时检测事件的顺序或序列。例如，“txn”声明可以包含发卡机构包括的有序值（例如计数器），尽管与时间戳一样，在分布式系统中确保这种有序可能很困难。
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
当集合相对于发生安全事件的原始动作异步和/或带外传递时，重要的是要考虑在发生事件的过程之前或之后将一个集合递送到集合接收方。例如，已被要求注销然后再次登录的用户可导致发出“令牌撤销”集，通常导致接收器重置接收器处与该用户相关的所有活动会话。如果撤销集到达
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.
在用户代理重新登录的同时，计时可能会由于错误地将新用户会话视为注销而导致问题。分析规范应仔细考虑集合表达式和时序问题。例如，撤销特定会话或ID令牌可能比撤销关于“用户”的一般注销声明更合适。或者，分析规范可以使用时间戳，允许在声明的注销事件时间之后立即启动新会话。
Also, see Section 4 above for both additional security considerations and normative text on preventing SETs from being confused with other kinds of JWTs.
此外，有关防止SET与其他类型JWT混淆的其他安全注意事项和规范性文本，请参见上文第4节。
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.
当共享个人识别信息或对受影响用户保密的信息时，SET发行人和接收人应具有适当的法律协议、用户同意和/或服务条款。
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.
主体标识符的传播可被视为个人可识别信息。在可能的情况下，SET发行者和接收者应该设计防止传播的方法——例如，传递一个要求SET接收者知道主题的附加散列值。
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.
在某些情况下，集合接收者可能会关联不同的事件，从而获得集合发行人不打算共享的主题信息。例如，集合接收者可能能够使用“iat”值或高度精确的“toe”值来确定两个本来不相关的事件实际上与同一真实世界事件相关。来自这两个事件的信息的联合可以允许集合接收者取消数据的匿名性，或者识别与同一个人相关的不相关标识符。SET发行人应采取措施将事件关联的可能性降至最低，因为此类关联将构成隐私侵犯。例如，他们可以使用“toe”声明的近似值或任意延迟集发布，在这种延迟可以容忍的情况下。
IANA has registered the "events", "toe", and "txn" claims in the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims] established by [RFC7519].
IANA已在[RFC7519]建立的IANA“JSON Web令牌声明”注册表[IANA.JWT.claims]中注册了“事件”、“toe”和“txn”声明。
o Claim Name: "events" o Claim Description: Security Events o Change Controller: IESG o Specification Document(s): Section 2.2 of [RFC8417]
o 索赔名称：“事件”o索赔描述：安全事件o变更控制器：IESG o规范文件：[RFC8417]第2.2节
o Claim Name: "toe" o Claim Description: Time of Event o Change Controller: IESG o Specification Document(s): Section 2.2 of [RFC8417]
o 索赔名称：“toe”o索赔描述：事件发生时间o变更控制器：IESG o规范文件：[RFC8417]第2.2节
o Claim Name: "txn" o Claim Description: Transaction Identifier o Change Controller: IESG o Specification Document(s): Section 2.2 of [RFC8417]
o 索赔名称：“txn”o索赔描述：交易标识符o变更控制器：IESG o规范文件：[RFC8417]第2.2节
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.
IANA已按照[RFC6838]中所述的方式在“结构化语法后缀”注册表[IANA.StructuredSuffix]中注册了“+jwt”结构化语法后缀[RFC6838]，可用于指示媒体类型编码为jwt。
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".)
o 名称：JSON Web令牌（JWT）o+后缀：+JWT o引用：第3节[RFC7519]，第7.2节[RFC8417]o编码注意事项：二进制；JWT值被编码为一系列base64url编码值（删除尾随“=”字符），其中一些可能是空字符串，由句点（“.”）字符分隔。o互操作性注意事项：不适用o片段标识符注意事项：为+jwt指定的片段标识符的语法和语义应与为“应用程序/jwt”指定的相同。（在本文档发布时，没有为“application/jwt”定义片段标识语法。）
The syntax and semantics for fragment identifiers for a specific "xxx/yyy+jwt" SHOULD be processed as follows:
特定“xxx/yyy+jwt”的片段标识符的语法和语义应按如下方式处理：
For cases defined in +jwt where the fragment identifier resolves per the +jwt rules, process as specified in +jwt.
对于+jwt中定义的片段标识符按照+jwt规则解析的情况，请按照+jwt中的规定进行处理。
For cases defined in +jwt where the fragment identifier does not resolve per the +jwt rules, process as specified in "xxx/yyy+jwt".
对于+jwt中定义的片段标识符未按照+jwt规则解析的情况，请按照“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.
对于+jwt中未定义的情况，按照“xxx/yyy+jwt”中的规定进行处理。o安全注意事项：见[RFC7519]第11节。o联系人：Michael B.Jones，mbj@microsoft.como作者/变更控制者：安全事件工作组。IESG对此注册具有变更控制权。
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.
本节以[RFC6838]中描述的方式在“媒体类型”注册表[IANA.MediaTypes]中注册“application/secevent+jwt”媒体类型[RFC2046]，可用于指示内容是一组。
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:
o 类型名称：应用程序o子类型名称：secevent+jwt o必需参数：N/A o可选参数：N/A o编码注意事项：二进制；集合是JWT；JWT值被编码为一系列base64url编码值（删除尾随“=”字符），其中一些可能是空字符串，由句点（“.”）字符分隔。o安全注意事项：请参阅[RFC8417]第5节o互操作性注意事项：不适用o已发布规范：第2.3节[RFC8417]o使用此媒体类型的应用程序：交换集的应用程序o片段标识符注意事项：不适用o其他信息：
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
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
o 联系人和电子邮件地址，以获取更多信息：Michael B.Jones，mbj@microsoft.como预期用途：常见o使用限制：无o作者：Michael B.Jones，mbj@microsoft.como变更控制员：IESG o临时注册？不
[IANA.JWT.Claims] IANA, "JSON Web Token Claims", <http://www.iana.org/assignments/jwt>.
[IANA.JWT.Claims]IANA，“JSON Web令牌声明”<http://www.iana.org/assignments/jwt>.
[IANA.MediaTypes] IANA, "Media Types", <http://www.iana.org/assignments/media-types>.
[IANA.MediaTypes]IANA，“媒体类型”<http://www.iana.org/assignments/media-types>.
[IANA.StructuredSuffix] IANA, "Structured Syntax Suffix", <https://www.iana.org/assignments/ media-type-structured-suffix/>.
[IANA.StructuredSuffix]IANA，“结构化语法后缀”<https://www.iana.org/assignments/ 媒体类型结构化后缀/>。
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<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>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<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>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<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>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<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>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，DOI 10.17487/RFC6749，2012年10月<https://www.rfc-editor.org/info/rfc6749>.
[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>.
[RFC7515]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<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>.
[RFC7516]Jones，M.和J.Hildebrand，“JSON Web加密（JWE）”，RFC 7516，DOI 10.17487/RFC7516，2015年5月<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>.
[RFC7519]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络令牌（JWT）”，RFC 7519，DOI 10.17487/RFC7519，2015年5月<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>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<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>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[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.
[JWT-BCP]Sheffer，Y.，Hardt，D.，和M.Jones，“JSON Web令牌最佳当前实践”，正在进行的工作，草稿-ietf-oauth-JWT-BCP-03，2018年5月。
[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.BackChannel]Jones，M.和J.Bradley，“OpenID连接反向通道注销1.0”，2017年1月<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.Core]北樱村、J.布拉德利、M.琼斯、B.德梅德罗斯和C.莫蒂莫尔，“OpenID连接核心1.0”，2014年11月<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>.
[OpenID.RISC.Events]Scurtescu，M.，Backman，A.，Hunt，P.，和J.Bradley，“OpenID RISC事件类型1.0”，2018年4月<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>.
[RFC2046]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，DOI 10.17487/RFC2046，1996年11月<https://www.rfc-editor.org/info/rfc2046>.
[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>.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<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>.
[RFC7644]Hunt，P.，Ed.，Grizzle，K.，Ansari，M.，Wahlstroem，E.，和C.Mortimore，“跨域身份管理系统：协议”，RFC 7644，DOI 10.17487/RFC76442015年9月<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>.
[RFC8055]Holmberg，C.和Y.Jiang，“通过头字段参数指示接收域的会话启动协议（SIP）”，RFC 8055，DOI 10.17487/RFC8055，2017年1月<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>.
[RFC8225]Wendt，C.和J.Peterson，“护照：个人主张令牌”，RFC 8225，DOI 10.17487/RFC82252018年2月<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.
编辑们要感谢IETF SCIM工作组的成员，该工作组从2015年的draft-hunt-SCIM-notify-00开始讨论资源调配事件。编辑们要感谢IETF id事件邮件列表的参与者、安全事件工作组和相关工作组对本规范的贡献。该规范包含了许多人提出的建议，包括安娜贝尔·贝克曼、约翰·布拉德利、艾莉莎·库珀、内德·弗里德、迪克·哈特、罗斯·霍斯利、本杰明·卡杜克、米佳·库勒温德、马克·利泽、阿列克谢·梅尔尼科夫、安德鲁·纳什、埃里克·雷斯科拉、亚当·罗奇、贾斯汀·里希、纳特·樱村、马吕斯·斯克鲁特斯库、亚龙·谢弗和马丁·维古鲁。
Authors' Addresses
作者地址
Phil Hunt (editor) Oracle Corporation
菲尔·亨特（编辑）甲骨文公司
Email: phil.hunt@yahoo.com
Email: phil.hunt@yahoo.com
Michael B. Jones Microsoft
迈克尔·琼斯微软公司
Email: mbj@microsoft.com
URI: http://self-issued.info/
Email: mbj@microsoft.com
URI: http://self-issued.info/
William Denniss Google
威廉·丹尼斯谷歌
Email: rfc8417@wdenniss.com
URI: https://wdenniss.com/SET
Email: rfc8417@wdenniss.com
URI: https://wdenniss.com/SET
Morteza Ansari Cisco
莫特扎·安萨里·思科
Email: morteza.ansari@cisco.com
Email: morteza.ansari@cisco.com