idnits 2.17.1 draft-hunt-idevent-token-02.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 11, 2016) is 2815 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: 'RFC7159' is defined on line 585, but no explicit reference was found in the text == Unused Reference: 'RFC7517' is defined on line 597, 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 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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 12, 2017 Google 6 M. Ansari 7 Cisco 8 August 11, 2016 10 Security Event Token (SET) 11 draft-hunt-idevent-token-02 13 Abstract 15 This specification defines the Security Event token which may be 16 distributed via a protocol such as HTTP. A Security Event Token 17 (SET) is based on the JSON Web Token and may be optionally signed 18 and/or encrypted. A SET describes a statement of fact that may be 19 shared by an event publisher with registered subscribers. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 12, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 56 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 57 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Core Event Attributes . . . . . . . . . . . . . . . . . . 8 60 2.2. Security Event Token Construction . . . . . . . . . . . . 9 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 62 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 66 6.2. Informative References . . . . . . . . . . . . . . . . . 14 67 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 14 68 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 14 69 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction and Overview 74 This specification defines an extensible security event token (SET) 75 format which may be exchanged using protocols such as HTTP. The 76 specification builds on the JSON Web Token format [RFC7519] in order 77 to provide a self-contained token that can be optionally signed using 78 JSON Web Signature [RFC7515] and/or encrypted using JSON Web 79 Encryption [RFC7516]. 81 For the purpose of this specification an event is a statement of fact 82 by a publisher (also known as the event issuer) that the state of a 83 security subject (e.g. a web resource, token, IP address) it controls 84 or is aware of, has changed in some way (explicitly or implicitly). 85 A security subject may be permanent (e.g. a User account) or 86 temporary (e.g. a login session) in nature. A state change may 87 include direct changes of entity state, implicit changes to state or 88 other higher-level security statements such as: 90 o The creation, modification, removal of a resource. 92 o The reseting or suspension of an account. 94 o The revoking of a security token prior to its expiry. 96 o The logout of a user session. Or, 97 o A cumulative conclusion such as to indicate that a user has taken 98 over an email identifier that may have been used in the past by 99 another user. 101 Based on some agreed upon criteria for an event feed, the publisher 102 distributes events to the appropriate subscribers. While an event 103 may be delivered via synchronous means (e.g. HTTP POST), the 104 distribution of the event often happens asynchronously to the change 105 of state which generated the security event. As an example, an 106 OAuth2 Authorization server [RFC6749], having received a token 107 revocation request [RFC7009], may issue a token revocation event to 108 downstream web resource providers. Having been informed of a token 109 revocation, the OAuth2 web resource service provider may add the 110 token identifier to its local revocation list assuming the token has 111 not already expired. 113 A subscriber having received an event, validates and interprets the 114 event and takes its own independent action, if any. For example, 115 having been informed of a personal identifier now being associated 116 with a different security subject (i.e. is being used by someone- 117 else), the subscriber may choose to ensure that the new user is not 118 granted access to resources associated with the previous user. Or it 119 may not have any relationship with the subject and no action is 120 taken. 122 While subscribers will often take actions upon receiving one or more 123 events, events MUST NOT be assumed to be commands or requests. To do 124 so requires complex bi-directional signals and error recovery 125 mechanisms which fall outside the scope of this specification. The 126 intent of this specification is to define a way of exchanging 127 statements of fact that subscribers may interpret for their own 128 purposes. Since events are typically historical statements by a 129 publisher and are not commands, idempotency or lack there of, does 130 not apply. 132 Unless otherwise specified, this specification uses example events 133 intended as non-normative examples showing how an event may be used. 134 It is expected that other specifications will use this specification 135 to define normative events. 137 This specification is scoped to security and identity related events. 138 While event tokens may be used for other purposes, the specification 139 only considers security and privacy concerns relevant to identity and 140 personal information. 142 1.1. Notational Conventions 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. These 147 keywords are capitalized when used to unambiguously specify 148 requirements of the protocol or application features and behavior 149 that affect the inter-operability and security of implementations. 150 When these words are not capitalized, they are meant in their 151 natural-language sense. 153 For purposes of readability examples are not URL encoded. 154 Implementers MUST percent encode URLs as described in Section 2.1 of 155 [RFC3986]. 157 Throughout this documents all figures MAY contain spaces and extra 158 line-wrapping for readability and space limitations. Similarly, some 159 URI's contained within examples, have been shortened for space and 160 readability reasons. 162 1.2. Definitions 164 The following definitions are used with Identity Events: 166 Feed Publisher 167 The Feed Publisher provides events to be distributed to registered 168 subscribers. In JWT terminology, the Feed Publisher is also known 169 as the issuer "iss"). 171 Event 172 An event is a security event token that is a statement that is to 173 be distributed to one or more registered subscribers. An event is 174 constructed as a JWT token and MAY be signed or encrypted using 175 JWS/JWE for authentication and confidentiality reasons. 177 Feed 178 A feed a logical grouping of events or a context under which 179 events may be issued. An interested client registers with the 180 Feed Publisher to subscribe to events associated with a feed. How 181 a feed is defined or the method for subscription is out-of-scope 182 of this specification. 184 Subscriber 185 A Subscriber registers to receive event notifications from a Feed 186 Publisher using a protocol such as HTTP. The method of 187 registration and delivery is out-of-scope of this specification. 189 Security Subject 190 The security subject about which the event is about. A security 191 subject may be a principle (e.g. Section 4.1.2 [RFC7519]), a web 192 resource, or other thing such as an IP address about which an 193 Event is about. 195 2. Events 197 A SET conveys a statement (in the form of a JWT token [RFC7519]) 198 about a Security Subject that may be of interest to a subscriber or 199 set of subscribers receiving events from a Feed Publisher. 201 The schema and structure of an event follows the JWT [RFC7519] 202 specification. An event token has the following characteristics: 204 o a common set of attributes common to every event at the top level 205 including an events attribute describing the type of event, and 207 o one or more JSON sub-objects that attributes associated with an 208 event URI value. The attributes to be included with any 209 particular event are to be defined by the event as specified by 210 the event URI value in the "events" attribute. 212 In addition to the JWT attributes "iss" and "aud", an SET contains 213 the attribute "events" with at least one URI value used to indicate 214 the type of event that has occurred and what information (attributes) 215 may be present in the event token. and what type of event (e.g. 216 resource modified) is contained in the event token. 218 An event MAY contain an attribute for each value of "events" whose 219 value is a JSON object (also known as an event extension object) that 220 contains additional attributes relevant to the specified event URI. 221 For example, many events will include an "iss" that identifies the 222 context of the Security Subject being reported (as distinct from the 223 issuer of the SET), and a "sub" or "jti" or some other attribute that 224 uniquely identifies the Security Subject. 226 The following is a non-normative example showing a password change 227 event that conveys a SCIM event (see [idevent-scim]): 229 { 230 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", 231 "events":[ 232 "urn:ietf:params:scim:event:passwordReset", 233 "https://example.com/scim/event/password" 234 ], 235 "iat": 1458496025, 236 "iss": "https://scim.example.com", 237 "aud":[ 238 "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", 239 "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" 240 ], 241 "urn:ietf:params:scim:event:passwordReset":{ 242 "id":"44f6142df96bd6ab61e7521d9", 243 "sub": 244 "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9" 245 }, 246 "https://example.com/scim/event/password":{ 247 "resetAttempts":5 248 } 249 } 251 Figure 1: Example SCIM Password Reset Event 253 The event in the figure above expresses hypothetical password reset 254 event for SCIM [RFC7644]. The JWT consists of: 256 o An _events_ attribute specifying the hypothetical SCIM urn 257 ("urn:ietf:params:scim:event:passwordReset") for a password reset, 258 and a custom extension, "https://example.com/scim/event/password", 259 that is used to provide additional event information presumably 260 specified by the location URI provided. 262 o An "iss" attribute which denotes the event publisher. 264 o The "aud" attribute specifies the intended audience for the event. 265 In practical terms this MAY be the URI for the event feed that a 266 client has subscribed to. 268 Additional extensions to an event may be added by adding more values 269 to the "events" attribute. For each event URI value specified, there 270 MAY be a corresponding attribute that has a JSON object that contains 271 the attributes associated with that event (e.g. 272 "https://example.com/scim/event/password"). In this example, the 273 SCIM event indicates that a password has been updated and the current 274 password reset count is 5. Notice that the value for "resetAttempts" 275 is actually part of its own JSON object 276 "https://example.com/scim/event/password". 278 Here is another example event token, this one for a Logout Token: 280 { 281 "iss": "https://server.example.com", 282 "aud": "s6BhdRkqt3", 283 "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", 284 "iat": 1458668180, 285 "exp": 1458668580, 286 "events": [ 287 "https://specs.openid.net/logout" 288 ], 289 "https://specs.openid.net/logout": { 290 "iss": "https://token.example.com", 291 "sub": "248289761001", 292 "jti": "08a5019c-17e1-4977-8f42-65a12843ea02" 293 } 294 } 296 Figure 2: Example OpenID Logout Event 298 In the above example, the event has its own issuer, 299 "https://server.example.com" while the event is about the logging out 300 of a user session identified in the event extension by "jti" that was 301 issued by "https://token.example.com". 303 In the following example, a fictional medical service collects 304 consent for medical actions and notifies other parties. The 305 individual for whom consent is identified was originally 306 authenticated via OpenID Connect. In this case, the issuer of the 307 SET event is an application rather than the OpenID provider: 309 { 310 "jti": "fb4e75b5411e4e19b6c0fe87950f7749", 311 "events":[ 312 "https://openid.net/heart/consent.html" 313 ], 314 "iat": 1458496025, 315 "iss": "https://my.examplemed.com", 316 "aud":[ 317 "https://examplemedlab/Feeds/98d52461fa5bbc879593b7754" 318 ], 319 "https://openid.net/heart/consent":{ 320 "iss": "https://token.example.com", 321 "sub": "248289761001", 322 "consentUri":[ 323 "https://terms.examplemed.com/labdisclosure.html#Agree" 324 ] 325 } 326 } 328 Figure 3: Example Consent Event 330 In the above example "iss" and "sub" contained within the attribute 331 "https://openid.net/heart/consent", refer to the subject and issuer 332 of the original OpendID Provider. They are distinct from the top 333 level value of "iss" which always refers to the issuer of the event; 334 a medical consent service that is a relying party to the OpenID 335 Provider. 337 2.1. Core Event Attributes 339 The following are attributes that are based on [RFC7519] claim 340 definitions and are profiled for use in an event token: 342 jti 343 As defined by Section 4.1.7 [RFC7519] contains a unique identifier 344 for an event. The identifier SHOULD be unique within a particular 345 event feed and MAY be used by clients to track whether a 346 particular event has already been received. This attribute is 347 REQUIRED. 349 iss 350 A single valued String containing the URI of the service provider 351 publishing the event (the issuer). This attribute is REQUIRED. 353 aud 354 A multi-valued String containing the URIs representing the 355 audience of the event. Values are typically URLs of the feeds the 356 event is associated with. When an event has multiple audiences 357 that go to the same subscriber, the publisher is not obligated to 358 deliver repeated events to the same subscriber. This attribute is 359 RECOMMENDED. 361 iat 362 As defined by Section 4.1.6 [RFC7519], a value containing a 363 NumericDate which represents when the event was issued. Unless 364 otherwise specified, the value SHOULD be interpreted by the 365 subscriber as equivalent to the actual time of the event. This 366 attribute is REQUIRED. 368 nbf 369 As defined by Section 4.1.5 [RFC7519], a value containing a 370 NumericDate which represents a future date when the event will 371 occur. This attribute is OPTIONAL. 373 The following is a new attribute defined by this specification: 375 events 376 A multi-valued String that contains the URIs of event types 377 contained within the JWT. Values in this attribute further 378 indicate what other JSON objects are present within the parent 379 JSON event structure. Each OPTIONAL JSON sub-object is denoted by 380 an attribute that matches a value in "events". This attribute is 381 REQUIRED. 383 2.2. Security Event Token Construction 385 A SET is a JWT [RFC7519] that is constructed by building a JSON 386 structure that constitutes an event object and which is then used as 387 the body of a JWT. 389 While this specification uses JWT to convey a SET, implementers SHALL 390 NOT use SETs to convey authentication or authorization assertions. 392 The following is an example event token (it has been modified for 393 readability): 395 { 396 "jti": "4d3559ec67504aaba65d40b0363faad8", 397 "iat": 1458496404, 398 "iss": "https://scim.example.com", 399 "aud":[ 400 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", 401 "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" 402 ], 404 "events":[ 405 "urn:ietf:params:scim:event:create" 406 ], 407 "urn:ietf:params:scim:event:create":{ 408 "ref": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", 409 "attributes":["id","name","userName","password","emails"], 410 "values":{ 411 "emails":[ 412 {"type":"work","value":"jdoe@example.com"} 413 ], 414 "password":"not4u2no", 415 "userName":"jdoe", 416 "id":"44f6142df96bd6ab61e7521d9", 417 "name":{ 418 "givenName":"John", 419 "familyName":"Doe" 420 } 421 } 422 } 423 } 425 Figure 4: Example Event JSON Data 427 When transmitted, the above JSON body must be converted into a JWT as 428 per [RFC7519]. In this example, because the event contains attribute 429 values, the token MUST be encrypted per JWE (see [RFC7516]) before 430 transmission. 432 The following is an example of a SCIM Event expressed in an unsecured 433 JWT token. The JWT header of: 435 {"alg":"none"} 436 Base64url encoding of the octets of the UTF-8 representation of the 437 header yields: 439 eyJhbGciOiJub25lIn0 441 The example JSON Event Data is encoded as follows: 443 eyAgCiAgImp0aSI6ICI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsCiAg 444 ImlhdCI6IDE0NTg0OTY0MDQsCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5j 445 b20iLCAgCiAgImF1ZCI6WwogICAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRz 446 Lzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLAogICAiaHR0cHM6Ly9zY2ltLmV4YW1w 447 bGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciCiAgXSwgIAogIAog 448 ICJldmVudHMiOlsKICAgICJ1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpjcmVhdGUi 449 CiAgXSwKICAidXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6Y3JlYXRlIjp7CiAgICAi 450 cmVmIjogImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9Vc2Vycy80NGY2MTQyZGY5NmJk 451 NmFiNjFlNzUyMWQ5IiwKICAgICJhdHRyaWJ1dGVzIjpbImlkIiwibmFtZSIsInVzZXJO 452 YW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiXSwKICAgICJ2YWx1ZXMiOnsKICAgICAgImVt 453 YWlscyI6WwogICAgICAgeyJ0eXBlIjoid29yayIsInZhbHVlIjoiamRvZUBleGFtcGxl 454 LmNvbSJ9CiAgICAgIF0sCiAgICAgICJwYXNzd29yZCI6Im5vdDR1Mm5vIiwKICAgICAg 455 InVzZXJOYW1lIjoiamRvZSIsCiAgICAgICJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3 456 NTIxZDkiLAogICAgICAibmFtZSI6ewogICAgICAgICJnaXZlbk5hbWUiOiJKb2huIiwK 457 ICAgICAgICAiZmFtaWx5TmFtZSI6IkRvZSIKICAgICAgfQogICAgfSAgCiAgfQp9 459 The encoded JWS signature is the empty string. Concatenating the 460 parts yields: 462 eyJhbGciOiJub25lIn0 463 . 464 eyAgCiAgImp0aSI6ICI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsCiAg 465 ImlhdCI6IDE0NTg0OTY0MDQsCiAgImlzcyI6ICJodHRwczovL3NjaW0uZXhhbXBsZS5j 466 b20iLCAgCiAgImF1ZCI6WwogICAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRz 467 Lzk4ZDUyNDYxZmE1YmJjODc5NTkzYjc3NTQiLAogICAiaHR0cHM6Ly9zY2ltLmV4YW1w 468 bGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIxZDA4NjQxZDc2NzZlZTciCiAgXSwgIAogIAog 469 ICJldmVudHMiOlsKICAgICJ1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpjcmVhdGUi 470 CiAgXSwKICAidXJuOmlldGY6cGFyYW1zOnNjaW06ZXZlbnQ6Y3JlYXRlIjp7CiAgICAi 471 cmVmIjogImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9Vc2Vycy80NGY2MTQyZGY5NmJk 472 NmFiNjFlNzUyMWQ5IiwKICAgICJhdHRyaWJ1dGVzIjpbImlkIiwibmFtZSIsInVzZXJO 473 YW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiXSwKICAgICJ2YWx1ZXMiOnsKICAgICAgImVt 474 YWlscyI6WwogICAgICAgeyJ0eXBlIjoid29yayIsInZhbHVlIjoiamRvZUBleGFtcGxl 475 LmNvbSJ9CiAgICAgIF0sCiAgICAgICJwYXNzd29yZCI6Im5vdDR1Mm5vIiwKICAgICAg 476 InVzZXJOYW1lIjoiamRvZSIsCiAgICAgICJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3 477 NTIxZDkiLAogICAgICAibmFtZSI6ewogICAgICAgICJnaXZlbk5hbWUiOiJKb2huIiwK 478 ICAgICAgICAiZmFtaWx5TmFtZSI6IkRvZSIKICAgICAgfQogICAgfSAgCiAgfQp9 479 . 481 Figure 5: Example Unsecured Event Token 483 To create and or validate a signed or encrypted SET follow the 484 instructions in section 7 of [RFC7519]. 486 3. Security Considerations 488 SETs may often contain sensitive information. Therefore methods for 489 distribution of events SHOULD require the use of a transport-layer 490 security mechanism when distributing events. Parties MUST support 491 TLS 1.2 [RFC5246] and MAY support additional transport-layer 492 mechanisms meeting its security requirements. When using TLS, the 493 client MUST perform a TLS/SSL server certificate check, per 494 [RFC6125]. Implementation security considerations for TLS can be 495 found in "Recommendations for Secure Use of TLS and DTLS" [RFC7525]. 497 Security Events distributed through third-parties or that carry 498 personally identifiable information, SHOULD be encrypted using JWE 499 [RFC7516] or secured for confidentiality by other means. 501 Security Events distributed without authentication over the channel, 502 such as via TLS ([RFC5246] and [RFC6125]), and/or OAuth2 [RFC6749], 503 or Basic Authentication [RFC7617], MUST be signed using JWS [RFC7515] 504 so that individual events MAY be authenticated and validated by the 505 subscriber. 507 4. Privacy Considerations 509 If an SET needs to be retained for audit purposes, JWS MAY be used to 510 provide verification of its authenticity. 512 Event Publishers should attempt to specialize feeds so that the 513 content is targeted to the specific business and protocol needs of 514 subscribers. 516 When sharing personally identifiable information or information that 517 is otherwise considered confidential to affected users, the 518 publishers and subscribers MUST have the appropriate legal agreements 519 and user consent in place. 521 The propagation of subject identifiers can be perceived as personally 522 identifiable information. Where possible, publishers and subscribers 523 should devise approaches the prevents propagation. For example the 524 passing of a hash value that requires the subscriber to already know 525 the subject. 527 5. IANA Considerations 529 There are no IANA requirements. 531 6. References 533 6.1. Normative References 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, 537 DOI 10.17487/RFC2119, March 1997, 538 . 540 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 541 Resource Identifier (URI): Generic Syntax", STD 66, 542 RFC 3986, DOI 10.17487/RFC3986, January 2005, 543 . 545 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 546 (TLS) Protocol Version 1.2", RFC 5246, 547 DOI 10.17487/RFC5246, August 2008, 548 . 550 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 551 Verification of Domain-Based Application Service Identity 552 within Internet Public Key Infrastructure Using X.509 553 (PKIX) Certificates in the Context of Transport Layer 554 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 555 2011, . 557 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 558 RFC 6749, DOI 10.17487/RFC6749, October 2012, 559 . 561 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 562 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 563 . 565 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 566 "Recommendations for Secure Use of Transport Layer 567 Security (TLS) and Datagram Transport Layer Security 568 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 569 2015, . 571 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 572 RFC 7617, DOI 10.17487/RFC7617, September 2015, 573 . 575 6.2. Informative References 577 [idevent-scim] 578 Oracle Corporation, "SCIM Event Extensions (work in 579 progress)". 581 [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 582 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, 583 August 2013, . 585 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 586 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 587 2014, . 589 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 590 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 591 2015, . 593 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 594 RFC 7516, DOI 10.17487/RFC7516, May 2015, 595 . 597 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 598 DOI 10.17487/RFC7517, May 2015, 599 . 601 [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., 602 and C. Mortimore, "System for Cross-domain Identity 603 Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, 604 September 2015, . 606 Appendix A. Contributors 608 Appendix B. Acknowledgments 610 The editor would like to thank the participants in the id-events 611 mailing list and related working groups for their support of this 612 specification. 614 Appendix C. Change Log 616 Draft 00 - PH - First Draft 618 Draft 01 - PH - Fixed some alignment issues with JWT. Remove event 619 type attribute. 621 Draft 02 - PH - Renamed to Security Events, Removed questions, 622 clarified examples and intro text, and added security and privacy 623 section. 625 Authors' Addresses 627 Phil Hunt (editor) 628 Oracle Corporation 630 Email: phil.hunt@yahoo.com 632 William Denniss 633 Salesforce.com 635 Email: wdenniss@google.com 637 Morteza Ansari 638 Cisco 640 Email: morteza.ansari@cisco.com