idnits 2.17.1 draft-hunt-idevent-token-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 18, 2016) is 2780 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7517' is defined on line 620, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hunt, Ed. 3 Internet-Draft Oracle 4 Intended status: Standards Track W. Denniss 5 Expires: February 19, 2017 Google 6 M. Ansari 7 Cisco 8 M. Jones 9 Microsoft 10 August 18, 2016 12 Security Event Token (SET) 13 draft-hunt-idevent-token-03 15 Abstract 17 This specification defines the Security Event token, which may be 18 distributed via a protocol such as HTTP. The Security Event Token 19 (SET) specification profiles the JSON Web Token (JWT) and may be 20 optionally signed and/or encrypted. A SET describes a statement of 21 fact that may be shared by an event publisher with event subscribers. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 19, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 58 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 59 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. The Security Event Token (SET) . . . . . . . . . . . . . . . 5 61 2.1. Core SET Attributes . . . . . . . . . . . . . . . . . . . 8 62 2.2. Security Event Token Construction . . . . . . . . . . . . 9 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 5.1. JSON Web Token Claims Registration . . . . . . . . . . . 13 67 5.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 13 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 70 6.2. Informative References . . . . . . . . . . . . . . . . . 14 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 72 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction and Overview 77 This specification defines an extensible Security Event Token (SET) 78 format which may be exchanged using protocols such as HTTP. The 79 specification builds on the JSON Web Token (JWT) format [RFC7519] in 80 order to provide a self-contained token that can be optionally signed 81 using JSON Web Signature (JWS) [RFC7515] and/or encrypted using JSON 82 Web Encryption (JWE) [RFC7516]. 84 For the purpose of this specification, an event is a statement of 85 fact by a publisher (also known as the event issuer) that the state 86 of a security subject (e.g., a web resource, token, IP address) it 87 controls or is aware of, has changed in some way (explicitly or 88 implicitly). A security subject may be permanent (e.g., a user 89 account) or temporary (e.g., a login session) in nature. A state 90 change may include direct changes of entity state, implicit changes 91 to state or other higher-level security statements such as: 93 o The creation, modification, removal of a resource. 95 o The resetting or suspension of an account. 97 o The revocation of a security token prior to its expiry. 99 o The logout of a user session. Or, 101 o A cumulative conclusion such as to indicate that a user has taken 102 over an email identifier that may have been used in the past by 103 another user. 105 Based on some agreed upon criteria for an event Feed, the publisher 106 distributes events to the appropriate subscribers. While an event 107 may be delivered via synchronous means (e.g., HTTP POST), the 108 distribution of the event often happens asynchronously to the change 109 of state which generated the security event. As an example, an 110 OAuth2 Authorization Server [RFC6749], having received a token 111 revocation request [RFC7009], may issue a token revocation event to 112 downstream web resource providers. Having been informed of a token 113 revocation, the OAuth2 web resource service provider may add the 114 token identifier to its local revocation list assuming the token has 115 not already expired. 117 A subscriber having received an event, validates and interprets the 118 event and takes its own independent action, if any. For example, 119 having been informed of a personal identifier now being associated 120 with a different security subject (i.e., is being used by someone 121 else), the subscriber may choose to ensure that the new user is not 122 granted access to resources associated with the previous user. Or it 123 may not have any relationship with the subject, and no action is 124 taken. 126 While subscribers will often take actions upon receiving one or more 127 events, events MUST NOT be assumed to be commands or requests. To do 128 so requires complex bi-directional signals and error recovery 129 mechanisms that fall outside the scope of this specification. The 130 intent of this specification is to define a way of exchanging 131 statements of fact that subscribers may interpret for their own 132 purposes. Since events are typically historical statements by a 133 publisher and are not commands, idempotency or lack thereof, does not 134 apply. 136 Unless otherwise specified, this specification uses example events 137 intended as non-normative examples showing how an event may be used. 138 It is expected that other specifications will use this specification 139 to define normative events. 141 This specification is scoped to security and identity related events. 142 While event tokens may be used for other purposes, the specification 143 only considers security and privacy concerns relevant to identity and 144 personal information. 146 1.1. Notational Conventions 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. These 151 keywords are capitalized when used to unambiguously specify 152 requirements of the protocol or application features and behavior 153 that affect the inter-operability and security of implementations. 154 When these words are not capitalized, they are meant in their 155 natural-language sense. 157 For purposes of readability, examples are not URL encoded. 158 Implementers MUST percent encode URLs as described in Section 2.1 of 159 [RFC3986]. 161 Throughout this document, all figures MAY contain spaces and extra 162 line-wrapping for readability and space limitations. Similarly, some 163 URIs contained within examples have been shortened for space and 164 readability reasons. 166 1.2. Definitions 168 The following definitions are used with SETs: 170 Feed Publisher 171 The Feed Publisher creates SETs to be distributed to registered 172 subscribers. In JWT terminology, the Feed Publisher is also known 173 as the issuer ("iss"). 175 Security Event Token (SET) 176 An SET is a JWT that is to be distributed to one or more 177 registered subscribers. A SET MAY be signed or encrypted using 178 JWS and/or JWE for authentication and confidentiality reasons. 180 Feed 181 A Feed is a logical grouping of SETs or a context under which SETs 182 may be issued. A Subscriber registers with the Feed Publisher to 183 subscribe to SETs associated with a Feed. How a Feed is defined 184 or the method for subscription is out-of-scope of this 185 specification. 187 Subscriber 188 A Subscriber registers to receive SETs from a Feed Publisher using 189 a protocol such as HTTP. The method of registration and delivery 190 is out-of-scope of this specification. 192 Security Subject 193 A Security Subject is the entity to which a SET refers. A 194 Security Subject may be a principle (e.g., Section 4.1.2 195 [RFC7519]), a web resource, or other thing such as an IP address 196 that a SET might reference. 198 2. The Security Event Token (SET) 200 A SET conveys a statement (in the form of a JWT [RFC7519]) about a 201 single security event in relation to a Security Subject that may be 202 of interest to a Subscriber or set of Subscribers receiving SETs from 203 a Feed Publisher. 205 The schema and structure of a SET follows the JWT [RFC7519] 206 specification. A SET has the following characteristics: 208 o An outer JSON structure that acts as the event envelope. The 209 envelope contains a set of attributes common to every SET. The 210 attributes are used to validate the event and determine the event 211 data included. The envelope includes an "events" attribute 212 describing the type of event, and 214 o JSON [RFC7159] sub-objects, that act as event payload, that 215 contain attributes associated with the event URIs values provided 216 in the envelope "events" attribute. 218 o While a SET may have more than one URI value for "events", the 219 intent is that the additional URIs are to provide additional 220 attributes related to the same event in the form of extensions to 221 the primary event. 223 SET payload objects are added to the envelope by adding an attribute 224 to the top-level JSON object (the envelope) whose name corresponds to 225 a value from "events". The payload object contains the attributes 226 relevant to the specified event URI. For example, SET event payloads 227 may include "iss" attribute to distinguish between the issuer of the 228 event and the issuer of a Security Subject or "sub". 230 The following is a non-normative example showing a hypothetical SCIM 231 password reset SET. The example also shows an example where the 232 issuer has provided an extension ("https://example.com/scim/event/ 233 passwordResetExt") that is used to convey additional information such 234 as the current count of reset attempts: 236 { 237 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", 238 "events":[ 239 "urn:ietf:params:scim:event:passwordReset", 240 "https://example.com/scim/event/passwordResetExt" 241 ], 242 "iat": 1458496025, 243 "iss": "https://scim.example.com", 244 "aud":[ 245 "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", 246 "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" 247 ], 248 "urn:ietf:params:scim:event:passwordReset":{ 249 "iss":"https://scim.example.com", 250 "id":"44f6142df96bd6ab61e7521d9", 251 "sub":"/Users/44f6142df96bd6ab61e7521d9" 252 }, 253 "https://example.com/scim/event/passwordResetExt":{ 254 "resetAttempts":5 255 } 256 } 258 Figure 1: Example SCIM Password Reset Event 260 The event in the figure above expresses hypothetical password reset 261 event for SCIM [RFC7644]. The JWT consists of: 263 o An _events_ attribute specifying the hypothetical SCIM urn 264 ("urn:ietf:params:scim:event:passwordReset") for a password reset, 265 and a custom extension, "https://example.com/scim/event/ 266 passwordResetExt", that is used to provide additional event 267 information presumably specified by the location URI provided. 269 o An "iss" attribute, denotes the event publisher in the envelope 270 while the "iss" in the event payload specifies the SCIM service 271 provider for the account that was reset. 273 o The "aud" attribute specifies the intended audience for the event. 274 In practical terms, this MAY be the URI for the event Feed that a 275 client has subscribed to. 277 Additional extensions to an event may be added by adding more values 278 to the "events" attribute. For each event URI value specified, there 279 MAY be a corresponding attribute that has a JSON object that contains 280 the attributes associated with that event (e.g., 281 "https://example.com/scim/event/passwordResetExt"). In this example, 282 the SCIM event indicates that a password has been updated and the 283 current password reset count is 5. Notice that the value for 284 "resetAttempts" is actually part of its own JSON object 285 "https://example.com/scim/event/passwordResetExt". 287 Here is another example event token, this one for a Logout Token: 289 { 290 "iss": "https://server.example.com", 291 "aud": "https://rp.example.com", 292 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", 293 "iat": 1458668180, 294 "exp": 1458668580, 295 "events": [ 296 "https://specs.openid.net/logout" 297 ], 298 "https://specs.openid.net/logout": { 299 "iss": "https://token.example.com", 300 "sub": "248289761001", 301 "jti": "08a5019c-17e1-4977-8f42-65a12843ea02" 302 } 303 } 305 Figure 2: Example OpenID Logout Event 307 In the above example, the event has its own issuer, 308 "https://server.example.com" while the event is about the logging out 309 of a user session identified in the event extension by "jti" that was 310 issued by "https://token.example.com". 312 In the following example, a fictional medical service collects 313 consent for medical actions and notifies other parties. The 314 individual for whom consent is identified was originally 315 authenticated via OpenID Connect. In this case, the issuer of the 316 SET event is an application rather than the OpenID provider: 318 { 319 "jti": "fb4e75b5411e4e19b6c0fe87950f7749", 320 "events":[ 321 "https://openid.net/heart/consent.html" 322 ], 323 "iat": 1458496025, 324 "iss": "https://my.examplemed.com", 325 "aud":[ 326 "https://rp.example.com" 327 ], 328 "https://openid.net/heart/consent":{ 329 "iss": "https://token.example.com", 330 "sub": "248289761001", 331 "consentUri":[ 332 "https://terms.examplemed.com/labdisclosure.html#Agree" 333 ] 334 } 335 } 337 Figure 3: Example Consent Event 339 In the above example "iss" and "sub" contained within the attribute 340 "https://openid.net/heart/consent", refer to the subject and issuer 341 of the original OpendID Provider. They are distinct from the top 342 level value of "iss" which always refers to the issuer of the event - 343 a medical consent service that is a relying party to the OpenID 344 Provider. 346 2.1. Core SET Attributes 348 The following are attributes that are based on [RFC7519] claim 349 definitions and are profiled for use in an event token: 351 jti 352 As defined by Section 4.1.7 [RFC7519] contains a unique identifier 353 for an event. The identifier SHOULD be unique within a particular 354 event Feed and MAY be used by clients to track whether a 355 particular event has already been received. This attribute is 356 REQUIRED. 358 iss 359 A single valued String containing the URI of the service provider 360 publishing the SET (the issuer). This attribute is REQUIRED. 362 aud 363 A multi-valued String containing the URIs representing the 364 audience of the event. Values are typically URLs of the Feeds the 365 event is associated with. When an event has multiple audiences 366 that go to the same subscriber, the publisher is not obligated to 367 deliver repeated events to the same subscriber. This attribute is 368 RECOMMENDED. 370 iat 371 As defined by Section 4.1.6 [RFC7519], a value containing a 372 NumericDate, which represents when the event was issued. Unless 373 otherwise specified, the value SHOULD be interpreted by the 374 subscriber as equivalent to the actual time of the event. This 375 attribute is REQUIRED. 377 nbf 378 As defined by Section 4.1.5 [RFC7519], a value containing a 379 NumericDate, which represents a future date when the event will 380 occur. This attribute is OPTIONAL. 382 The following is a new attribute defined by this specification: 384 events 385 A multi-valued String that contains one or more URIs representing 386 the type of event being expressed and the attributes that MAY be 387 available within the JWT. Each value in this attribute indicates 388 what other JSON sub-objects MAY present within the parent JSON SET 389 structure. Each JSON sub-object is denoted by an attribute that 390 matches a value in "events". This attribute is REQUIRED. 392 2.2. Security Event Token Construction 394 A SET is a JWT [RFC7519] that is constructed by building a JSON 395 structure that constitutes an event object and which is then used as 396 the body of a JWT. 398 While this specification uses JWT to convey a SET, implementers SHALL 399 NOT use SETs to convey authentication or authorization assertions. 401 The following is an example event token (which has been formatted for 402 readability): 404 { 405 "jti": "4d3559ec67504aaba65d40b0363faad8", 406 "iat": 1458496404, 407 "iss": "https://scim.example.com", 408 "aud":[ 409 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", 410 "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" 411 ], 413 "events":[ 414 "urn:ietf:params:scim:event:create" 415 ], 416 "urn:ietf:params:scim:event:create":{ 417 "ref": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", 418 "attributes":["id", "name", "userName", "password", "emails"], 419 "values":{ 420 "emails":[ 421 {"type":"work", "value":"jdoe@example.com"} 422 ], 423 "password":"not4u2no", 424 "userName":"jdoe", 425 "id":"44f6142df96bd6ab61e7521d9", 426 "name":{ 427 "givenName":"John", 428 "familyName":"Doe" 429 } 430 } 431 } 432 } 434 Figure 4: Example Event JSON Data 436 When transmitted, the above JSON body must be converted into a JWT as 437 per [RFC7519]. In this example, because the event contains attribute 438 values, the token MUST be encrypted per JWE (see [RFC7516]) before 439 transmission. 441 The following is an example of a SCIM Event expressed as an unsecured 442 JWT. The JWT header of: 444 {"alg":"none"} 445 Base64url encoding of the octets of the UTF-8 representation of the 446 header yields: 448 eyJhbGciOiJub25lIn0 450 The example JSON Event Data is encoded as follows: 452 eyAgCiAgImp0aSI6ICI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsCiAg 453 ImlhdCI6IDE0NTg0OTY0MDQsCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5j 454 b20iLCAgCiAgImF1ZCI6WwogICAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRz 455 Lzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLAogICAiaHR0cHM6Ly9zY2ltLmV4YW1w 456 bGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciCiAgXSwgIAogIAog 457 ICJldmVudHMiOlsKICAgICJ1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpjcmVhdGUi 458 CiAgXSwKICAidXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6Y3JlYXRlIjp7CiAgICAi 459 cmVmIjogImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9Vc2Vycy80NGY2MTQyZGY5NmJk 460 NmFiNjFlNzUyMWQ5IiwKICAgICJhdHRyaWJ1dGVzIjpbImlkIiwibmFtZSIsInVzZXJO 461 YW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiXSwKICAgICJ2YWx1ZXMiOnsKICAgICAgImVt 462 YWlscyI6WwogICAgICAgeyJ0eXBlIjoid29yayIsInZhbHVlIjoiamRvZUBleGFtcGxl 463 LmNvbSJ9CiAgICAgIF0sCiAgICAgICJwYXNzd29yZCI6Im5vdDR1Mm5vIiwKICAgICAg 464 InVzZXJOYW1lIjoiamRvZSIsCiAgICAgICJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3 465 NTIxZDkiLAogICAgICAibmFtZSI6ewogICAgICAgICJnaXZlbk5hbWUiOiJKb2huIiwK 466 ICAgICAgICAiZmFtaWx5TmFtZSI6IkRvZSIKICAgICAgfQogICAgfSAgCiAgfQp9 468 The encoded JWS signature is the empty string. Concatenating the 469 parts yields: 471 eyJhbGciOiJub25lIn0 472 . 473 eyAgCiAgImp0aSI6ICI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsCiAg 474 ImlhdCI6IDE0NTg0OTY0MDQsCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5j 475 b20iLCAgCiAgImF1ZCI6WwogICAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRz 476 Lzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLAogICAiaHR0cHM6Ly9zY2ltLmV4YW1w 477 bGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciCiAgXSwgIAogIAog 478 ICJldmVudHMiOlsKICAgICJ1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpjcmVhdGUi 479 CiAgXSwKICAidXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6Y3JlYXRlIjp7CiAgICAi 480 cmVmIjogImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9Vc2Vycy80NGY2MTQyZGY5NmJk 481 NmFiNjFlNzUyMWQ5IiwKICAgICJhdHRyaWJ1dGVzIjpbImlkIiwibmFtZSIsInVzZXJO 482 YW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiXSwKICAgICJ2YWx1ZXMiOnsKICAgICAgImVt 483 YWlscyI6WwogICAgICAgeyJ0eXBlIjoid29yayIsInZhbHVlIjoiamRvZUBleGFtcGxl 484 LmNvbSJ9CiAgICAgIF0sCiAgICAgICJwYXNzd29yZCI6Im5vdDR1Mm5vIiwKICAgICAg 485 InVzZXJOYW1lIjoiamRvZSIsCiAgICAgICJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3 486 NTIxZDkiLAogICAgICAibmFtZSI6ewogICAgICAgICJnaXZlbk5hbWUiOiJKb2huIiwK 487 ICAgICAgICAiZmFtaWx5TmFtZSI6IkRvZSIKICAgICAgfQogICAgfSAgCiAgfQp9 488 . 490 Figure 5: Example Unsecured Event Token 492 To create and or validate a signed or encrypted SET, follow the 493 instructions in section 7 of [RFC7519]. 495 3. Security Considerations 497 SETs may often contain sensitive information. Therefore, methods for 498 distribution of events SHOULD require the use of a transport-layer 499 security mechanism when distributing events. Parties MUST support 500 TLS 1.2 [RFC5246] and MAY support additional transport-layer 501 mechanisms meeting its security requirements. When using TLS, the 502 client MUST perform a TLS/SSL server certificate check, per 503 [RFC6125]. Implementation security considerations for TLS can be 504 found in "Recommendations for Secure Use of TLS and DTLS" [RFC7525]. 506 Security Events distributed through third-parties or that carry 507 personally identifiable information, SHOULD be encrypted using JWE 508 [RFC7516] or secured for confidentiality by other means. 510 Security Events distributed without authentication over the channel, 511 such as via TLS ([RFC5246] and [RFC6125]), and/or OAuth2 [RFC6749], 512 or Basic Authentication [RFC7617], MUST be signed using JWS [RFC7515] 513 so that individual events MAY be authenticated and validated by the 514 subscriber. 516 4. Privacy Considerations 518 If a SET needs to be retained for audit purposes, JWS MAY be used to 519 provide verification of its authenticity. 521 Event Publishers SHOULD attempt to specialize Feeds so that the 522 content is targeted to the specific business and protocol needs of 523 subscribers. 525 When sharing personally identifiable information or information that 526 is otherwise considered confidential to affected users, the 527 publishers and subscribers MUST have the appropriate legal agreements 528 and user consent in place. 530 The propagation of subject identifiers can be perceived as personally 531 identifiable information. Where possible, publishers and subscribers 532 should devise approaches that prevent propagation -- for example, the 533 passing of a hash value that requires the subscriber to already know 534 the subject. 536 5. IANA Considerations 538 5.1. JSON Web Token Claims Registration 540 This specification registers the "events" claim in the IANA "JSON Web 541 Token Claims" registry [IANA.JWT.Claims] established by [RFC7519]. 543 5.1.1. Registry Contents 545 o Claim Name: "events" 546 o Claim Description: Security Events 547 o Change Controller: IESG 548 o Specification Document(s): Section 2 of [[ this specification ]] 550 6. References 552 6.1. Normative References 554 [IANA.JWT.Claims] 555 IANA, "JSON Web Token Claims", 556 . 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, 560 DOI 10.17487/RFC2119, March 1997, 561 . 563 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 564 Resource Identifier (URI): Generic Syntax", STD 66, 565 RFC 3986, DOI 10.17487/RFC3986, January 2005, 566 . 568 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 569 (TLS) Protocol Version 1.2", RFC 5246, 570 DOI 10.17487/RFC5246, August 2008, 571 . 573 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 574 Verification of Domain-Based Application Service Identity 575 within Internet Public Key Infrastructure Using X.509 576 (PKIX) Certificates in the Context of Transport Layer 577 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 578 2011, . 580 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 581 RFC 6749, DOI 10.17487/RFC6749, October 2012, 582 . 584 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 585 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 586 2014, . 588 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 589 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 590 . 592 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 593 "Recommendations for Secure Use of Transport Layer 594 Security (TLS) and Datagram Transport Layer Security 595 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 596 2015, . 598 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 599 RFC 7617, DOI 10.17487/RFC7617, September 2015, 600 . 602 6.2. Informative References 604 [idevent-scim] 605 Oracle Corporation, "SCIM Event Extensions (work in 606 progress)", . 608 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 609 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, 610 August 2013, . 612 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 613 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 614 2015, . 616 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 617 RFC 7516, DOI 10.17487/RFC7516, May 2015, 618 . 620 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 621 DOI 10.17487/RFC7517, May 2015, 622 . 624 [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., 625 and C. Mortimore, "System for Cross-domain Identity 626 Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, 627 September 2015, . 629 Appendix A. Acknowledgments 631 The editors would like to thank the participants in the IETF id-event 632 mailing list and related working groups for their support of this 633 specification. 635 Appendix B. Change Log 637 Draft 01 - PH - Renamed eventUris to events 639 Draft 00 - PH - First Draft 641 Draft 01 - PH - Fixed some alignment issues with JWT. Remove event 642 type attribute. 644 Draft 02 - PH - Renamed to Security Events, Removed questions, 645 clarified examples and intro text, and added security and privacy 646 section. 648 Draft 03 - PH 650 General edit corrections from Sarah Squire 651 Changed "event" term to "SET" 652 Corrected author organization for William Dennis to Google 653 Changed definition of SET to be 2 parts, an envelope and 1 or more 654 payloads. 655 Clarified that the intent is to express a single event with 656 optional extensions only. 658 Draft 03 - mbj - Registered "events" claim. Applied proofreading 659 corrections. 661 Authors' Addresses 663 Phil Hunt (editor) 664 Oracle Corporation 666 Email: phil.hunt@yahoo.com 668 William Denniss 669 Google 671 Email: wdenniss@google.com 672 Morteza Ansari 673 Cisco 675 Email: morteza.ansari@cisco.com 677 Michael B. Jones 678 Microsoft 680 Email: mbj@microsoft.com 681 URI: http://self-issued.info/