draft-ietf-secevent-token-04.txt   draft-ietf-secevent-token-05.txt 
Security Events Working Group P. Hunt, Ed. Security Events Working Group P. Hunt, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track M. Jones Intended status: Standards Track M. Jones
Expires: July 24, 2018 Microsoft Expires: August 6, 2018 Microsoft
W. Denniss W. Denniss
Google Google
M. Ansari M. Ansari
Cisco Cisco
January 20, 2018 February 2, 2018
Security Event Token (SET) Security Event Token (SET)
draft-ietf-secevent-token-04 draft-ietf-secevent-token-05
Abstract Abstract
This specification defines the Security Event Token (SET) data This specification defines the Security Event Token (SET) data
structure. A SET describes a statement of fact from the perspective structure. A SET describes a statement of fact from the perspective
of an issuer, which is intended to be shared with one or more of an issuer, which is intended to be shared with one or more
recipients. A SET is a JSON Web Token (JWT), which can be optionally recipients. A SET is a JSON Web Token (JWT), which can be optionally
signed and/or encrypted. SETs can be distributed via protocols such signed and/or encrypted. SETs can be distributed via protocols such
as HTTP. as HTTP.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 24, 2018. This Internet-Draft will expire on August 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
4.2. Delivery . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Delivery . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Sequencing . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Sequencing . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Timing Issues . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Timing Issues . . . . . . . . . . . . . . . . . . . . . . 15
4.5. Distinguishing SETs from ID Tokens . . . . . . . . . . . 15 4.5. Distinguishing SETs from ID Tokens . . . . . . . . . . . 15
4.6. Distinguishing SETs from Access Tokens . . . . . . . . . 16 4.6. Distinguishing SETs from Access Tokens . . . . . . . . . 16
4.7. Distinguishing SETs from other kinds of JWTs . . . . . . 17 4.7. Distinguishing SETs from other kinds of JWTs . . . . . . 17
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. JSON Web Token Claims Registration . . . . . . . . . . . 18 6.1. JSON Web Token Claims Registration . . . . . . . . . . . 18
6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 18 6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 18
6.2. Media Type Registration . . . . . . . . . . . . . . . . . 18 6.2. Media Type Registration . . . . . . . . . . . . . . . . . 19
6.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 18 6.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction and Overview 1. Introduction and Overview
This specification defines an extensible Security Event Token (SET) This specification defines an extensible Security Event Token (SET)
data structure, which can be exchanged using protocols such as HTTP. data structure, which can be exchanged using protocols such as HTTP.
The specification builds on the JSON Web Token (JWT) format [RFC7519] The specification builds on the JSON Web Token (JWT) format [RFC7519]
in order to provide a self-contained token that can be optionally in order to provide a self-contained token that can be optionally
signed using JSON Web Signature (JWS) [RFC7515] and/or encrypted signed using JSON Web Signature (JWS) [RFC7515] and/or encrypted
using JSON Web Encryption (JWE) [RFC7516]. using JSON Web Encryption (JWE) [RFC7516].
skipping to change at page 4, line 16 skipping to change at page 4, line 16
security events cannot be assumed to be commands or requests. The security events cannot be assumed to be commands or requests. The
intent of this specification is to define a syntax for statements of intent of this specification is to define a syntax for statements of
fact that Event Recipients may interpret for their own purposes. As fact that Event Recipients may interpret for their own purposes. As
such, SETs have no capability for error signaling to ensure the such, SETs have no capability for error signaling to ensure the
validation of a received SET. validation of a received SET.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC2119]. These keywords are capitalized when used to unambiguously 14 [RFC2119] [RFC8174] when, and only when, they appear in all
specify requirements of the protocol or application features and capitals, as shown here.
behavior that affect the inter-operability and security of
implementations. When these words are not capitalized, they are
meant in their natural-language sense.
For purposes of readability, examples are not URL encoded. For purposes of readability, examples are not URL encoded.
Implementers MUST percent encode URLs as described in Section 2.1 of Implementers MUST percent encode URLs as described in Section 2.1 of
[RFC3986]. [RFC3986].
Throughout this document, all figures MAY contain spaces and extra Throughout this document, all figures MAY contain spaces and extra
line-wrapping for readability and space limitations. Similarly, some line-wrapping for readability and space limitations. Similarly, some
URIs contained within examples have been shortened for space and URIs contained within examples have been shortened for space and
readability reasons. readability reasons.
skipping to change at page 6, line 26 skipping to change at page 6, line 23
2.1.1. SCIM Example 2.1.1. SCIM Example
The following is a non-normative example showing the JWT Claims Set The following is a non-normative example showing the JWT Claims Set
for a hypothetical SCIM [RFC7644] password reset SET. This example for a hypothetical SCIM [RFC7644] password reset SET. This example
uses a second "events" value ("https://example.com/scim/event/ uses a second "events" value ("https://example.com/scim/event/
passwordResetExt") to convey additional information about the state passwordResetExt") to convey additional information about the state
change -- in this case, the current count of reset attempts: change -- in this case, the current count of reset attempts:
{ {
"jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
"iat": 1458496025,
"iss": "https://scim.example.com", "iss": "https://scim.example.com",
"iat": 1458496025,
"jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
"aud": [ "aud": [
"https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
], ],
"sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
"events": { "events": {
"urn:ietf:params:scim:event:passwordReset": "urn:ietf:params:scim:event:passwordReset":
{ "id": "44f6142df96bd6ab61e7521d9"}, { "id": "44f6142df96bd6ab61e7521d9"},
"https://example.com/scim/event/passwordResetExt": "https://example.com/scim/event/passwordResetExt":
{ "resetAttempts": 5} { "resetAttempts": 5}
skipping to change at page 8, line 11 skipping to change at page 8, line 11
logged out. logged out.
2.1.3. Consent Example 2.1.3. Consent Example
In the following example JWT Claims Set, a fictional medical service In the following example JWT Claims Set, a fictional medical service
collects consent for medical actions and notifies other parties. The collects consent for medical actions and notifies other parties. The
individual for whom consent is identified was originally individual for whom consent is identified was originally
authenticated via OpenID Connect. In this case, the issuer of the authenticated via OpenID Connect. In this case, the issuer of the
security event is an application rather than the OpenID provider: security event is an application rather than the OpenID provider:
{ {
"jti": "fb4e75b5411e4e19b6c0fe87950f7749", "iss": "https://my.med.example.org",
"iat": 1458496025, "iat": 1458496025,
"iss": "https://my.examplemed.com", "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
"aud": [ "aud": [
"https://rp.example.com" "https://rp.example.com"
], ],
"events": { "events": {
"https://openid.net/heart/specs/consent.html": { "https://openid.net/heart/specs/consent.html": {
"iss": "https://connect.example.com", "iss": "https://connect.example.com",
"sub": "248289761001", "sub": "248289761001",
"consentUri": [ "consentUri": [
"https://terms.examplemed.com/labdisclosure.html#Agree" "https://terms.med.example.org/labdisclosure.html#Agree"
] ]
} }
} }
} }
Figure 3: Example Consent Event Figure 3: Example Consent Event
In the above example, the attribute "iss" contained within the In the above example, the attribute "iss" contained within the
payload for the event "https://openid.net/heart/specs/consent.html" payload for the event "https://openid.net/heart/specs/consent.html"
refers to the issuer of the Security Subject ("sub") rather than the refers to the issuer of the Security Subject ("sub") rather than the
event issuer "https://my.examplemed.com". They are distinct from the event issuer "https://my.med.example.org". They are distinct from
top level value of "iss", which always refers to the issuer of the the top-level value of "iss", which always refers to the issuer of
event - a medical consent service that is a relying party to the the event -- a medical consent service that is a relying party to the
OpenID Provider. OpenID Provider.
2.1.4. RISC Example 2.1.4. RISC Example
The following example JWT Claims Set is for an account disabled The following example JWT Claims Set is for an account disabled
event. This example was taken from a working draft of the RISC event. This example was taken from a working draft of the RISC
events specification, where RISC is the OpenID RISC (Risk and events specification, where RISC is the OpenID RISC (Risk and
Incident Sharing and Coordination) working group [RISC]. The example Incident Sharing and Coordination) working group [RISC]. The example
is subject to change. is subject to change.
{ {
"iss": "https://idp.example.com/", "iss": "https://idp.example.com/",
"sub": "7375626A656374",
"jti": "756E69717565206964656E746966696572", "jti": "756E69717565206964656E746966696572",
"iat": 1508184845, "iat": 1508184845,
"aud": "636C69656E745F6964", "aud": "636C69656E745F6964",
"events": { "events": {
"http://schemas.openid.net/secevent/risc/event-type/\ "http://schemas.openid.net/secevent/risc/event-type/\
account-disabled": { account-disabled": {
"subject": {
"subject_type": "iss-sub",
"iss": "https://idp.example.com/",
"sub": "7375626A656374"
},
"reason": "hijacking", "reason": "hijacking",
"cause-time": 1508012752, "cause-time": 1508012752
} }
} }
} }
Figure 4: Example RISC Event Figure 4: Example RISC Event
Notice that parameters to the event are included in the event Notice that parameters to the event are included in the event
payload, in this case, the "reason" and "cause-time" values. The payload, in this case, the "reason" and "cause-time" values. The
account that is the subject of the event is identified using the subject of the event is identified using the "subject" payload value,
"iss" and "sub" values, in the same manner as OpenID Connect which itself is a JSON object.
[OpenID.Core] ID Tokens.
2.2. Core SET Claims 2.2. Core SET Claims
The following claims from [RFC7519] are profiled for use in SETs: The following claims from [RFC7519] are profiled for use in SETs:
jti
As defined by Section 4.1.7 of [RFC7519] contains a unique
identifier for an event. The identifier SHOULD be unique within a
particular event feed and MAY be used by clients to track whether
a particular event has already been received. This claim is
REQUIRED.
iss iss
A string identifying the service provider publishing the SET (the A string identifying the service provider publishing the SET (the
issuer). In some cases, the SET issuer is not the issuer of the issuer). In some cases, the SET issuer is not the issuer of the
Security Subject. Therefore, implementers cannot assume that the Security Subject. Therefore, implementers cannot assume that the
issuers are the same unless the Profiling Specification specifies issuers are the same unless the Profiling Specification specifies
that they are for SETs conforming to that profile. This claim is that they are for SETs conforming to that profile. This claim is
REQUIRED. REQUIRED.
iat
As defined by Section 4.1.6 of [RFC7519], a value representing
when the event was issued. This claim is REQUIRED.
jti
As defined by Section 4.1.7 of [RFC7519] contains a unique
identifier for an event. The identifier SHOULD be unique within a
particular event feed and MAY be used by clients to track whether
a particular event has already been received. This claim is
REQUIRED.
aud aud
The syntax of the claim is as defined in Section 4.1.3 of The syntax of the claim is as defined in Section 4.1.3 of
[RFC7519]. This claim contains one or more audience identifiers [RFC7519]. This claim contains one or more audience identifiers
for the SET. This claim is RECOMMENDED. for the SET. This claim is RECOMMENDED.
iat
As defined by Section 4.1.6 of [RFC7519], a value representing
when the event was issued. Unless otherwise specified, the value
SHOULD be interpreted as equivalent to the actual time of the
event. This claim is REQUIRED.
sub sub
As defined by Section 4.1.2 of [RFC7519], a String or URI value As defined by Section 4.1.2 of [RFC7519], a String or URI value
representing the principal or the subject of the SET. This is representing the principal or the subject of the SET. This is
usually the entity whose "state" was changed. For example, an IP usually the entity whose "state" was changed. For example, an IP
Address was added to a black list. A URI representing a user Address was added to a black list. A URI representing a user
resource that was modified. A token identifier for a revoked resource that was modified. A token identifier for a revoked
token. If used, the Profiling Specification SHOULD define the token. If used, the Profiling Specification SHOULD define the
content and format semantics for the value. This claim is content and format semantics for the value. This claim is
OPTIONAL, as the principal for any given profile may already be OPTIONAL, as the principal for any given profile may already be
identified without the inclusion of a subject claim. Note that identified without the inclusion of a subject claim. Note that
skipping to change at page 11, line 18 skipping to change at page 11, line 19
txn txn
An OPTIONAL string value that represents a unique transaction An OPTIONAL string value that represents a unique transaction
identifier. In cases in which multiple related JWTs are issued, identifier. In cases in which multiple related JWTs are issued,
the transaction identifier claim can be used to correlate these the transaction identifier claim can be used to correlate these
related JWTs. related JWTs.
toe toe
A value that represents the date and time at which the event A value that represents the date and time at which the event
occurred. This value is a NumericDate (see Section 2 of occurred. This value is a NumericDate (see Section 2 of
[RFC7519]). This claim is RECOMMENDED. Note that some profiles [RFC7519]). By omitting this claim, the issuer indicates that
may choose to omit "toe" and convey event time information with they are not sharing an event time with the recipient. (Note that
the "iat" claim or another claim. in some use cases, the represented time might be approximate.)
This claim is OPTIONAL.
2.3. Explicit Typing of SETs 2.3. Explicit Typing of SETs
This specification registers the "application/secevent+jwt" media This specification registers the "application/secevent+jwt" media
type, which can be used to indicate that the content is a SET. SETs 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 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. 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 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. context in which it could be confused with other kinds of JWTs.
skipping to change at page 12, line 9 skipping to change at page 12, line 9
the "typ" value used SHOULD be "secevent+jwt". the "typ" value used SHOULD be "secevent+jwt".
2.4. Security Event Token Construction 2.4. Security Event Token Construction
This section describes how to construct a SET. This section describes how to construct a SET.
The following is an example JWT Claims Set for a hypothetical SCIM The following is an example JWT Claims Set for a hypothetical SCIM
SET (which has been formatted for readability): SET (which has been formatted for readability):
{ {
"jti": "4d3559ec67504aaba65d40b0363faad8",
"iat": 1458496404,
"iss": "https://scim.example.com", "iss": "https://scim.example.com",
"iat": 1458496404,
"jti": "4d3559ec67504aaba65d40b0363faad8",
"aud": [ "aud": [
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
], ],
"events": { "events": {
"urn:ietf:params:scim:event:create": { "urn:ietf:params:scim:event:create": {
"ref": "ref":
"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
"attributes": ["id", "name", "userName", "password", "emails"] "attributes": ["id", "name", "userName", "password", "emails"]
skipping to change at page 15, line 14 skipping to change at page 15, line 14
correct endpoint received the SET and that it could be successfully correct endpoint received the SET and that it could be successfully
processed. processed.
4.3. Sequencing 4.3. Sequencing
This specification defines no means of ordering multiple SETs in a This specification defines no means of ordering multiple SETs in a
sequence. Depending on the type and nature of the events represented sequence. Depending on the type and nature of the events represented
by SETs, order may or may not matter. For example, in provisioning, by SETs, order may or may not matter. For example, in provisioning,
event order is critical -- an object cannot be modified before it is event order is critical -- an object cannot be modified before it is
created. In other SET types, such as a token revocation, the order created. In other SET types, such as a token revocation, the order
of SETs for revoked tokens does not matter. If however, the event 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 conveys a logged in or logged out status for a user subject, then
order becomes important. order becomes important.
Profiling Specifications and implementers SHOULD take caution when Profiling Specifications and implementers SHOULD take caution when
using timestamps such as "iat" to define order. Distributed systems using timestamps such as "iat" to define order. Distributed systems
will have some amount of clock skew. Thus, time by itself will not will have some amount of clock skew. Thus, time by itself will not
guarantee order. guarantee order.
Specifications profiling SET SHOULD define a mechanism for detecting Specifications profiling SET SHOULD define a mechanism for detecting
order or sequence of events when the order matters. For example, the order or sequence of events when the order matters. For example, the
skipping to change at page 18, line 16 skipping to change at page 18, line 16
is otherwise considered confidential to affected users, Event Issuers is otherwise considered confidential to affected users, Event Issuers
and Recipients MUST have the appropriate legal agreements and user and Recipients MUST have the appropriate legal agreements and user
consent and/or terms of service in place. consent and/or terms of service in place.
The propagation of subject identifiers can be perceived as personally The propagation of subject identifiers can be perceived as personally
identifiable information. Where possible, Event Issuers and identifiable information. Where possible, Event Issuers and
Recipients SHOULD devise approaches that prevent propagation -- for Recipients SHOULD devise approaches that prevent propagation -- for
example, the passing of a hash value that requires the Event example, the passing of a hash value that requires the Event
Recipient to know the subject. Recipient to know the subject.
In some cases, it may be possible for an Event Recipient to correlate
different events and thereby gain information about a subject that
the Event Issuer did not intend to share. For example, an Event
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 an Event Recipient to de-anonymize data or
recognize that unrelated identifiers relate to the same individual.
Event 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.
6. IANA Considerations 6. IANA Considerations
6.1. JSON Web Token Claims Registration 6.1. JSON Web Token Claims Registration
This specification registers the "events", "toe", and "txn" claims in This specification registers the "events", "toe", and "txn" claims in
the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims] the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims]
established by [RFC7519]. established by [RFC7519].
6.1.1. Registry Contents 6.1.1. Registry Contents
skipping to change at page 20, line 35 skipping to change at page 20, line 49
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015, RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>. <https://www.rfc-editor.org/info/rfc7617>.
[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>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-oauth-jwt-bcp] [I-D.ietf-oauth-jwt-bcp]
Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", draft-ietf-oauth-jwt-bcp-00 (work in Current Practices", draft-ietf-oauth-jwt-bcp-00 (work in
progress), July 2017. progress), July 2017.
[I-D.ietf-stir-passport] [I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Personal Assertion Token Wendt, C. and J. Peterson, "Personal Assertion Token
(PASSporT)", draft-ietf-stir-passport-11 (work in (PASSporT)", draft-ietf-stir-passport-11 (work in
skipping to change at page 24, line 36 skipping to change at page 24, line 47
SET conveys a single security event. SET conveys a single security event.
o mbj - Added a note explicitly acknowledging that some SET profiles o mbj - Added a note explicitly acknowledging that some SET profiles
may choose to convey event subject information in the event may choose to convey event subject information in the event
payload. payload.
o PH - Corrected encoded claim example on page 10. o PH - Corrected encoded claim example on page 10.
o mbj - Applied grammar corrections. o mbj - Applied grammar corrections.
Draft 03 - Changes As Follows: Draft 03 - Changes are as follows:
o pjh - Corrected old "subscriber" to "Event Receiver". Added o pjh - Corrected old "subscriber" to "Event Receiver". Added
clarification in definition that Event Receiver is the same as JWT clarification in definition that Event Receiver is the same as JWT
recipient. recipient.
o pjh - Added definition for "toe" (and IANA registration). o pjh - Added definition for "toe" (and IANA registration).
o pjh - Removed "nbf" claim. o pjh - Removed "nbf" claim.
o pjh - Figure 3, moved "sub" to the events payload next to "iss". o pjh - Figure 3, moved "sub" to the events payload next to "iss".
skipping to change at page 25, line 36 skipping to change at page 25, line 47
Likewise, standardized on using the term "recipient" instead of Likewise, standardized on using the term "recipient" instead of
"receiver" for the same reasons. "receiver" for the same reasons.
o Added a RISC event example, courtesy of Marius Scurtescu. o Added a RISC event example, courtesy of Marius Scurtescu.
o Applied wording clarifications suggested by Annabelle Backman and o Applied wording clarifications suggested by Annabelle Backman and
Yaron Sheffer. Yaron Sheffer.
o Applied numerous grammar, syntax, and formatting corrections. o Applied numerous grammar, syntax, and formatting corrections.
Draft 05 - mbj - Changes were as follows:
o Simplified the definitions of the "iat" and "toe" claims in ways
suggested by Annabelle Backman.
o Added privacy considerations text suggested by Annabelle Backman.
o Updated the RISC event example, courtesy of Marius Scurtescu.
o Reordered the claim definitions to place the required claims
first.
o Changed to using the RFC 8174 boilerplate instead of the RFC 2119
boilerplate.
Authors' Addresses Authors' Addresses
Phil Hunt (editor) Phil Hunt (editor)
Oracle Corporation Oracle Corporation
Email: phil.hunt@yahoo.com Email: phil.hunt@yahoo.com
Michael B. Jones Michael B. Jones
Microsoft Microsoft
 End of changes. 29 change blocks. 
47 lines changed or deleted 79 lines changed or added

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