draft-ietf-secevent-token-11.txt   draft-ietf-secevent-token-12.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: November 8, 2018 Microsoft Expires: November 10, 2018 Microsoft
W. Denniss W. Denniss
Google Google
M. Ansari M. Ansari
Cisco Cisco
May 7, 2018 May 9, 2018
Security Event Token (SET) Security Event Token (SET)
draft-ietf-secevent-token-11 draft-ietf-secevent-token-12
Abstract Abstract
This specification defines the Security Event Token (SET) data This specification defines the Security Event Token (SET) data
structure. A SET describes statements of fact from the perspective structure. A SET describes statements of fact from the perspective
of an issuer about a subject. These statements of fact represent an of an issuer about a subject. These statements of fact represent an
event that occurred directly to or about a security subject, for event that occurred directly to or about a security subject, for
example, a statement about the issuance or revocation of a token on example, a statement about the issuance or revocation of a token on
behalf of a subject. This specification is intended to enable behalf of a subject. This specification is intended to enable
representing security- and identity-related events. A SET is a JSON representing security- and identity-related events. A SET is a JSON
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 November 8, 2018. This Internet-Draft will expire on November 10, 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 46 skipping to change at page 2, line 46
5.2. Delivery . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Delivery . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Sequencing . . . . . . . . . . . . . . . . . . . . . . . 18 5.3. Sequencing . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Timing Issues . . . . . . . . . . . . . . . . . . . . . . 19 5.4. Timing Issues . . . . . . . . . . . . . . . . . . . . . . 19
5.5. Preventing Confusion . . . . . . . . . . . . . . . . . . 19 5.5. Preventing Confusion . . . . . . . . . . . . . . . . . . 19
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. JSON Web Token Claims Registration . . . . . . . . . . . 20 7.1. JSON Web Token Claims Registration . . . . . . . . . . . 20
7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 20 7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 20
7.2. Structured Syntax Suffix Registration . . . . . . . . . . 21 7.2. Structured Syntax Suffix Registration . . . . . . . . . . 21
7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 21 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 21
7.3. Media Type Registration . . . . . . . . . . . . . . . . . 21 7.3. Media Type Registration . . . . . . . . . . . . . . . . . 22
7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 21 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 25
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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
skipping to change at page 13, line 39 skipping to change at page 13, line 39
Figure 5: Example Event Claims Figure 5: Example Event Claims
The JSON Claims Set is encoded per [RFC7519]. The JSON Claims Set is encoded per [RFC7519].
In this example, the SCIM SET claims are encoded in an unsecured JWT. In this example, the SCIM SET claims are encoded in an unsecured JWT.
The JOSE Header for this example is: The JOSE Header for this example is:
{"typ":"secevent+jwt","alg":"none"} {"typ":"secevent+jwt","alg":"none"}
Base64url encoding of the octets of the UTF-8 representation of the Base64url encoding (see Section 2 of [RFC7515]) of the octets of the
JOSE Header yields: UTF-8 [RFC3629] representation of the JOSE Header yields:
eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJub25lIn0 eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJub25lIn0
The above example JWT Claims Set is encoded as follows: The above example JWT Claims Set is encoded as follows:
eyJqdGkiOiI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsImlhdCI6MTQ1 eyJqdGkiOiI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsImlhdCI6MTQ1
ODQ5NjQwNCwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwiYXVkIjpbImh0 ODQ5NjQwNCwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwiYXVkIjpbImh0
dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3 dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3
NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4 NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4
NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50 NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybjppZXRmOnBhcmFtczpzY2ltOmV2ZW50
OmNyZWF0ZSI6eyJyZWYiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRm OmNyZWF0ZSI6eyJyZWYiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRm
skipping to change at page 17, line 24 skipping to change at page 17, line 24
This is particularly useful if the same endpoint may receive both This is particularly useful if the same endpoint may receive both
types of tokens. types of tokens.
o Employ explicit typing, as described in Section 2.3, and modify o Employ explicit typing, as described in Section 2.3, and modify
access token validation systems to use the "typ" header parameter access token validation systems to use the "typ" header parameter
value. value.
4.3. Distinguishing SETs from other kinds of JWTs 4.3. Distinguishing SETs from other kinds of JWTs
JWTs are now being used in application areas beyond the identity JWTs are now being used in application areas beyond the identity
applications in which they first appeared. For instance, the Session applications in which they first appeared. For instance, the
Initiation Protocol (SIP) Via Header Field [RFC8055] and Personal "Session Initiation Protocol (SIP) Via Header Field Parameter to
Assertion Token (PASSporT) [RFC8225] specifications both define JWT Indicate Received Realm" [RFC8055] and "Personal Assertion Token
profiles that use mostly or completely different sets of claims than (PASSporT)" [RFC8225] specifications both define JWT profiles that
are used by ID Tokens. If it would otherwise be possible for an use mostly or completely different sets of claims than are used by ID
attacker to substitute a SET for one of these (or other) kinds of Tokens. If it would otherwise be possible for an attacker to
JWTs, then the SET profile must be defined in such a way that any substitute a SET for one of these (or other) kinds of JWTs, then the
substituted SET will result in its rejection when validated as the SET profile must be defined in such a way that any substituted SET
intended kind of JWT. will result in its rejection when validated as the intended kind of
JWT.
The most direct way to prevent confusion is to employ explicit The most direct way to prevent confusion is to employ explicit
typing, as described in Section 2.3, and modify applicable token typing, as described in Section 2.3, and modify applicable token
validation systems to use the "typ" header parameter value. This validation systems to use the "typ" header parameter value. This
approach can be employed for new systems but may not be applicable to approach can be employed for new systems but may not be applicable to
existing systems. existing systems.
Another way to ensure that a SET is not confused with another kind of 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 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 "events" claim unless the JWT is intended to be a SET. This approach
skipping to change at page 18, line 26 skipping to change at page 18, line 29
SETs may contain sensitive information. Therefore, methods for SETs may contain sensitive information. Therefore, methods for
distribution of events SHOULD require the use of a transport-layer distribution of events SHOULD require the use of a transport-layer
security mechanism when distributing events. Parties MUST support security mechanism when distributing events. Parties MUST support
TLS 1.2 [RFC5246] or a higher version and MAY support additional TLS 1.2 [RFC5246] or a higher version and MAY support additional
transport-layer mechanisms meeting its security requirements. When transport-layer mechanisms meeting its security requirements. When
using TLS, the client MUST perform a TLS server certificate check, using TLS, the client MUST perform a TLS server certificate check,
per [RFC6125]. Implementation security considerations for TLS can be per [RFC6125]. Implementation security considerations for TLS can be
found in "Recommendations for Secure Use of TLS and DTLS" [RFC7525]. found in "Recommendations for Secure Use of TLS and DTLS" [RFC7525].
Security events distributed through third parties or that carry Security events distributed through third parties or that carry
personally identifiable information SHOULD be encrypted using JWE personally identifiable information MUST be encrypted using JWE
[RFC7516] or secured for confidentiality by other means. [RFC7516] or secured for confidentiality by other means.
Unless integrity of the JWT is ensured by other means, it MUST be 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 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 use case so that the SET can be authenticated and validated by
the SET recipient. the SET recipient.
5.2. Delivery 5.2. Delivery
This specification does not define a delivery mechanism for SETs. In This specification does not define a delivery mechanism for SETs. In
addition to confidentiality and integrity (discussed above), addition to confidentiality and integrity (discussed above),
implementers and profiling specifications MUST consider the implementers and profiling specifications must consider the
consequences of delivery mechanisms that are not secure and/or not consequences of delivery mechanisms that are not secure and/or not
assured. For example, while a SET may be end-to-end secured using assured. For example, while a SET may be end-to-end secured using
JWE encrypted SETs, without (mutual) TLS, there is no assurance that JWE encrypted SETs, without (mutual) TLS, there is no assurance that
the correct endpoint received the SET and that it could be the correct endpoint received the SET and that it could be
successfully processed. successfully processed.
5.3. Sequencing 5.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
skipping to change at page 23, line 10 skipping to change at page 23, line 15
[IANA.StructuredSuffix] [IANA.StructuredSuffix]
IANA, "Structured Syntax Suffix", IANA, "Structured Syntax Suffix",
<https://www.iana.org/assignments/ <https://www.iana.org/assignments/
media-type-structured-suffix/>. media-type-structured-suffix/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
skipping to change at page 23, line 31 skipping to change at page 23, line 40
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <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>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.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-01 (work in Current Practices", draft-ietf-oauth-jwt-bcp-03 (work in
progress), March 2018. progress), May 2018.
[OpenID.BackChannel] [OpenID.BackChannel]
Jones, M. and J. Bradley, "OpenID Connect Back-Channel Jones, M. and J. Bradley, "OpenID Connect Back-Channel
Logout 1.0", January 2017, <http://openid.net/specs/ Logout 1.0", January 2017, <http://openid.net/specs/
openid-connect-backchannel-1_0.html>. openid-connect-backchannel-1_0.html>.
[OpenID.Core] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", November 2014, C. Mortimore, "OpenID Connect Core 1.0", November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
skipping to change at page 24, line 25 skipping to change at page 24, line 42
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>. <https://www.rfc-editor.org/info/rfc2046>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
August 2013, <https://www.rfc-editor.org/info/rfc7009>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
and C. Mortimore, "System for Cross-domain Identity and C. Mortimore, "System for Cross-domain Identity
Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
September 2015, <https://www.rfc-editor.org/info/rfc7644>. September 2015, <https://www.rfc-editor.org/info/rfc7644>.
[RFC8055] Holmberg, C. and Y. Jiang, "Session Initiation Protocol [RFC8055] Holmberg, C. and Y. Jiang, "Session Initiation Protocol
(SIP) Via Header Field Parameter to Indicate Received (SIP) Via Header Field Parameter to Indicate Received
Realm", RFC 8055, DOI 10.17487/RFC8055, January 2017, Realm", RFC 8055, DOI 10.17487/RFC8055, January 2017,
<https://www.rfc-editor.org/info/rfc8055>. <https://www.rfc-editor.org/info/rfc8055>.
skipping to change at page 25, line 22 skipping to change at page 25, line 22
Appendix A. Acknowledgments Appendix A. Acknowledgments
The editors would like to thank the members of the IETF SCIM working The editors would like to thank the members of the IETF SCIM working
group, which began discussions of provisioning events starting with group, which began discussions of provisioning events starting with
draft-hunt-scim-notify-00 in 2015. The editors would like to thank draft-hunt-scim-notify-00 in 2015. The editors would like to thank
the participants in the IETF id-event mailing list, the Security the participants in the IETF id-event mailing list, the Security
Events working group, and related working groups for their Events working group, and related working groups for their
contributions to this specification. The specification incorporates contributions to this specification. The specification incorporates
suggestions made by many people, including Annabelle Backman, John suggestions made by many people, including Annabelle Backman, John
Bradley, Ned Freed, Dick Hardt, Russ Housley, Benjamin Kaduk, Mark Bradley, Alissa Cooper, Ned Freed, Dick Hardt, Russ Housley, Benjamin
Lizar, Andrew Nash, Eric Rescorla, Justin Richer, Nat Sakimura, Kaduk, Mark Lizar, Alexey Melnikov, Andrew Nash, Eric Rescorla, Adam
Marius Scurtescu, and Yaron Sheffer. Roach, Justin Richer, Nat Sakimura, Marius Scurtescu, and Yaron
Sheffer.
Appendix B. Change Log Appendix B. Change Log
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
From the original draft-hunt-idevent-token: From the original draft-hunt-idevent-token:
Draft 01 - PH - Renamed eventUris to events Draft 01 - PH - Renamed eventUris to events
Draft 00 - PH - First Draft Draft 00 - PH - First Draft
skipping to change at page 30, line 22 skipping to change at page 30, line 22
suffix registrations. suffix registrations.
o Changed the encodings of the media type and media type suffix o Changed the encodings of the media type and media type suffix
registrations to binary (since no line breaks are allowed). registrations to binary (since no line breaks are allowed).
o Replaced a "TBD" in the media type registration with descriptive o Replaced a "TBD" in the media type registration with descriptive
text. text.
o Acknowledged Eric Rescorla and Ned Freed. o Acknowledged Eric Rescorla and Ned Freed.
Draft 12 - pjh/mbj - Incorporated feedback from Adam Roach, Alexey
Melnikov, and Alissa Cooper.
o Removed unused references to RFC 7009 and RFC 7517.
o Corrected name of RFC 8055 in Section 4.3 to "Session Initiation
Protocol (SIP) Via Header Field Parameter to Indicate Received
Realm".
o Added normative references for base64url and UTF-8.
o Section 5.1 - Changed SHOULD to MUST in "personally identifiable
information MUST be encrypted using JWE [RFC7516] or ...".
o Section 5.2 - Changed "MUST consider" to "must consider".
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. 16 change blocks. 
41 lines changed or deleted 55 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/