idnits 2.17.1 draft-hunt-idevent-distribution-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 29, 2016) is 2766 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: 'RFC5988' is defined on line 1189, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-webpush-protocol' is defined on line 1214, but no explicit reference was found in the text == Unused Reference: 'RFC7515' is defined on line 1223, but no explicit reference was found in the text == Unused Reference: 'RFC7516' is defined on line 1227, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-hunt-idevent-token-05 ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-12) exists of draft-ietf-webpush-protocol-02 Summary: 2 errors (**), 0 flaws (~~), 8 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 M. Scurtescu 5 Expires: April 2, 2017 Google 6 M. Ansari 7 Cisco 8 September 29, 2016 10 SET Token Distribution and Subscription Management Profile 11 draft-hunt-idevent-distribution-01 13 Abstract 15 The specification defines how a subscriber to a feed of security 16 events (SETs) may query for, subscribe and receive SETs from a 17 security event feed. The specification defines a single mandatory- 18 to-implement method using HTTP Post to deliver events to registered 19 subscribers and a registry for new methods. 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 April 2, 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. Event Notification Process . . . . . . . . . . . . . . . . . 5 59 3. Event Feeds . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Feed Types . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Feed Metadata . . . . . . . . . . . . . . . . . . . . . . 7 62 3.3. SCIM Feed Management . . . . . . . . . . . . . . . . . . 9 63 4. Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.1. Subscription Metadata . . . . . . . . . . . . . . . . . . 10 65 4.2. Subscription State Model . . . . . . . . . . . . . . . . 12 66 4.3. SCIM Subscription Management . . . . . . . . . . . . . . 14 67 4.3.1. SCIM Subscription Resource Type . . . . . . . . . . . 14 68 4.3.2. New Subscription Requests . . . . . . . . . . . . . . 16 69 4.3.3. Updating Subscriptions . . . . . . . . . . . . . . . 18 70 4.4. Subscription Verification . . . . . . . . . . . . . . . . 19 71 4.4.1. Verifying Subscriptions . . . . . . . . . . . . . . . 19 72 5. Event Delivery . . . . . . . . . . . . . . . . . . . . . . . 20 73 5.1. Introduction to Event Delivery Methods . . . . . . . . . 20 74 5.2. Delivery Processing . . . . . . . . . . . . . . . . . . . 21 75 5.3. HTTP Web Callback Method . . . . . . . . . . . . . . . . 22 76 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 22 77 5.3.2. Delivery Message Format . . . . . . . . . . . . . . . 23 78 5.3.3. Subscription Verification . . . . . . . . . . . . . . 23 79 5.3.4. Delivery Procedure . . . . . . . . . . . . . . . . . 25 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 82 7.1. Event Notification Mechanism Registry . . . . . . . . . . 27 83 7.2. SCIM Schema Registration . . . . . . . . . . . . . . . . 27 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 86 8.2. Informative References . . . . . . . . . . . . . . . . . 28 87 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 29 88 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 29 89 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 29 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 92 1. Introduction and Overview 94 This specification defines a method by which SETs (see 95 [I-D.hunt-idevent-token]) can be delivered by publishers to feed 96 subscribers using HTTP POST [RFC7231] as well as an extension 97 registry enabling other methods of delivery. This specification also 98 defines how subscribers MAY query for available Feeds, and manage 99 event Subscriptions using SCIM [RFC7644]. 101 The following diagram shows a typical SET Feed Provider and the 102 services provided to Subscribers. Arrow heads point to the service 103 provider (the direction of an HTTP request): 105 +------------+ +-------------+ 106 | |Feeds Catalog | | 107 | <------------------------+ | 108 | SCIM | | SET | 109 | Feed |Subscription Request | Feed | 110 | Mgmt <------------------------+ Subscriber | 111 | | | | 112 | |Subscription Mgmt | | 113 | <------------------------+ | 114 | | | | 115 +------------+ | | 116 +------------+ | | 117 | | | | 118 | FEED |SET Delivery | | 119 | +------------------------> | 120 | Provider | | | 121 | | | | 122 +------------+ +-------------+ 124 Figure 1: Subscription Management and Delivery 126 A SET Feed Provider MAY be directly integrated into a source service 127 that generates events, or it may be a separate service entity that 128 off-loads event distribution from the event generator to act as its 129 delegated publisher. For the purposes of this specification, while 130 SET distribution may be handled separately, this specification will 131 consider the method for how event generators send events to 132 publishers as out-of-scope. 134 The specification uses SCIM protocol [RFC7644] to advertise available 135 Feeds and to enable Subscribers to request, subscriber to, and manage 136 Subscriptions. 138 The specification defines a registry by which multiple SET delivery 139 methods can be registered. The specification includes a web callback 140 method which uses HTTP POST [RFC7231] to deliver SETs to Subscribers. 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 This specification assumes terminology defined in the Security Event 165 Token specification[I-D.hunt-idevent-token]. 167 The following definitions are specific to Identity Event publishing: 169 Feed Provider 170 The Feed Provider publishes SETs to be distributed to registered 171 subscribers. 173 Feed 174 A Feed is a URI that describes the set of resources and events 175 under which events may be issued. An interested subscriber 176 registers with the feed provider to subscribe to an event URI to 177 receive SETs associated with a Feed. An individual Feed MAY have 178 zero or more Subscriptions. 180 Subscription 181 A Subscription contains the information needed by a Feed Provider 182 (e.g. delivery endpoints, credentials) to deliver a Feed of SETs 183 to an individual Subscriber. A Subscription has ONE Feed. 185 Notification Mechanism 186 A URI that describes the chosen event notification mechanism. 187 When subscribing to a feed, a client may choose a specific 188 mechanism by which it wishes to receive notification events. 190 Subscriber 191 A Subscriber is an party or security entity registers in the form 192 of a Subscription to receive SETs from a feed provider that are 193 part of a Feed. 195 2. Event Notification Process 197 When a Security Event occurs, the Feed Provider constructs a SET 198 token [I-D.hunt-idevent-token] that describes the event. The feed 199 provider determines the feeds that the event should be distributed 200 to, and determines which Subscribers need to be notified. 202 How Feeds are defined and the process by which events are identified 203 for subscribers is out-of-scope of this specification. 205 When a SET is available for a subscriber, the Feed Provider attempts 206 to deliver the SET based on the Subscriber's registered delivery 207 mechanism: 209 o The subscriber provided a web-callback endpoint, the publisher 210 uses an HTTP/1.1 POST to the endpoint to deliver the event to the 211 registered subscriber; 213 o Or, the Feed Provider delivers the event through a different 214 method not defined by this specification. 216 After a SET is delivered to all subscribers, Feed Providers do not 217 typically maintain SETs or histories. As such, published SETs SHOULD 218 be self-validating (e.g. signed). 220 If delivery to any particular subscriber has been delayed for an 221 extended period of time, the Feed Provider MAY suspend the 222 subscription and even stop maintaining outstanding SETs for the 223 Subscriber at its discretion and available resources. See 224 subscription "state" in Section 4.1. 226 Upon receiving a SET, the Subscriber reads the token and validates 227 it. Based on the content of the token, the subscriber decides what 228 if any action it needs to take in response to the SET. For example, 229 in response to a SCIM event [idevent-scim] indicating a changed 230 resource, the subscriber might perform a SCIM GET request (see 231 Section 3.4 [RFC7644]) to the affected resource URI in order to 232 confidentially obtain the current state of the affected SCIM 233 resource. 235 The action a Subscriber takes in response to a SET MAY be 236 substantially different than merely copying the action of the 237 publisher. A single SET MAY trigger multiple receiver actions. For 238 example, upon receiving notification that a user resource has been 239 added to a group, the Subscriber may first determine that the user 240 does not exist in the Subscriber's domain. The Subscriber translates 241 the event into two actions: 243 1. Retrieve the user (e.g. using SCIM GET) and then provisions the 244 user locally. After enabling the user, 246 2. The Subscriber then enables the user for the application 247 associated with membership in the Feed Publisher's group. 249 3. Event Feeds 251 An Feed is defined by a "feedUri". The Feed provides a stream of 252 SETs to be delivered to registered Subscribers based on a 253 Subscription. An individual Subscription contains the metadata about 254 a particular Subscriber regarding their subscription to a particular 255 "feedUri". Subscription metadata indicates the current subscription 256 state indicating whether all events are delivered, pending, or 257 whether delivery has failed. Subscription metadata also describes 258 the method of event delivery, and any associated security and 259 configuration information (see Section 4.1 ). 261 3.1. Feed Types 263 A Feed Provider MAY define Feeds based on a number of criteria. This 264 specification does not specify or limit the basis for which a service 265 provider defines the resources or entities contained in a Feed or how 266 feed URIs should be specified. Some possible methods for defining 267 entities covered by a Feed include: 269 By Resource or Subject 270 A resource or subject might have its own associated event 271 notification Feed. For example, a User's mobile application may 272 require notification of changes or rights defined in a SCIM User 273 resource associated with the mobile user. 275 By Endpoint 276 A Feed might be defined by an endpoint where any event relating to 277 a resource within an endpoint is delivered to a subscriber. This 278 type of feed is likely to have many notifications as the number of 279 resources in an endpoint grows (e.g. a SCIM "/Users") and SHOULD 280 be used with caution. Typically only privileged partners would be 281 allowed to use this type of feed. For example, an enterprise 282 wishes to be notified of all change events to any of its users 283 assuming all users within the endpoint are related to the 284 subscribing enterprise. 286 By Filter 287 A Feed might define a collection of resources based on a filter 288 that describes a set of matching criteria a resource may be 289 included in a Feed. Note that this type of Feed may require extra 290 processing by the Feed Provider to determine if any particular SET 291 event matches the filter criteria. It may also be difficult for 292 the Feed Provider to notify Subscribers of additions and deletions 293 of resources to the Feed as the resources in the Feed MAY change 294 based on the filter itself. 296 By Group 297 All entities or resources within some specified group. For 298 example, all resources within a SCIM Group could be used to define 299 the resources for which SETs will be issued within a particular 300 Feed. 302 The list above is intended to show common use cases for defining 303 Feeds. How Feeds are defined is out-of-scope of this specification. 305 3.2. Feed Metadata 307 Feed metadata consists of the following singular attributes: 309 feedName 310 A required string value containing a name for the feed. May be 311 used in administrative user interfaces to assist subscribers in 312 Feed selection. The value MUST be unique within a given 313 administrative domain. This is a REQUIRED attribute. 315 feedUri 316 An attribute of type "String" that is a unique URI identifying the 317 feed. This attribute characteristic "mutability" is "immutable" 318 and SHALL NOT change once assigned. The value of this attribute 319 MAY be the SCIM URI for the Feed resource (e.g. 320 "https://scim.example.com/Feeds/88bc00de"). This is a REQUIRED 321 attribute. 323 description 324 A "String" attribute that describes the purpose of the feed in 325 human readable form. This is an OPTIONAL attribute. 327 events 328 An attribute whose value is a JSON object consisting of multi- 329 valued JSON attributes where each attribute is the name of a 330 primary event URI and each value represents an event extension to 331 the primary event. An empty array SHALL indicate there are no 332 extensions. When set, Feeds SHALL only provide the primary events 333 defined. However, a Feed Provider MAY provide additional 334 extensions that are not declared. This is an OPTIONAL attribute. 336 The following is a non-normative example events claim: 338 "events":{ 339 "urn:ietf:params:scim:event:passwordReset":[ 340 "https://example.com/scim/event/passwordResetExt"], 341 "https://specs.openid.net/logout":[] 342 } 344 Figure 2: Example Events Attribute 346 In the above example, the feed has two events defined. The first 347 is a hypothetical password reset, and the second is a hypothetical 348 OpenID Connect logout. The password reset event has one extension 349 defined which is "https://example.com/scim/event/ 350 passwordResetExt". 352 type 353 An OPTIONAL String attribute that MAY have values such as: 355 resource Indicates that the Feed is for events related to a 356 specific resource. In such cases, the value of the attribute 357 "filter" is set to a specific resource URI or "/Me" . 359 endpoint Indicates that the Feed is for all events that occur for 360 resources within a specific endpoint. In such cases, "filter" 361 is set to an endpoint container for a group of resources (e.g. 362 "/Users" ). 364 filter Indicates that events for a Feed will be selected based on 365 events relating to the set of resources described by a filter. 366 For example, the value of the attribute "filter" is a SCIM 367 filter Section 3.4.2 [RFC7644] that describes a condition that 368 selects a set of resources that match before or after a 369 resource state change. 371 group Indicates that events for a Feed will be based on events 372 relating to the set of resources listed in a group such as a 373 SCIM GroupSection 4.2 [RFC7643]. 375 The attribute is typically used by the Feed Publisher to determine 376 the meaning and content of the Feed "filter" attribute. 378 filter 379 An OPTIONAL String value containing a filter whose syntax is 380 defined by a profiling specification (e.g. SCIM) or the Feed 381 Publisher. For example in SCIM, a filter MAY be a filter 382 Section 3.4.2.2 [RFC7644]), a resource, or a SCIM endpoint URI 383 depending on the value of "type". And, if the SCIM Feed type is 384 "resource", than the filter value is a URI for a SCIM resource. 386 The following multi-valued attributes are defined: 388 deliveryModes 389 One or more URIs representing the methods of delivery supported by 390 the Feed Publisher. Values in this attribute correspond to the 391 Subscription "methodUri" attribute (see Section 4.1). 393 3.3. SCIM Feed Management 395 When Feeds are managed within a SCIM service provider [RFC7644], Feed 396 resources use schema defined in Section 3.2 and use a schema value of 397 "urn:ietf:params:scim:schemas:event:2.0:Feed". The SCIM 398 "ResourceType" definition defines the location of the SCIM service 399 provider endpoint for "Feed" resources. 401 The Feed "ResourceType" definition is typically defined as follows: 403 { 404 "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"], 405 "id": "Feed", 406 "name": "Feed", 407 "endpoint": "/Feeds", 408 "description": "Event Feeds", 409 "schema": "urn:ietf:params:scim:schemas:event:2.0:Feed", 410 "schemaExtensions": [] 411 } 413 Figure 3: SCIM Feed ResourceType Definition 415 To retrieve information about a "Feed" or a number of feeds, 416 subscribers or management clients MAY query the "/Feeds" endpoint as 417 defined in Section 3.4 [RFC7644]. 419 The example below retrieves a specific Feed resource whose "id" is 420 "548b7c3f77c8bab33a4fef40". 422 GET /Feeds/88bc00de776d49d5b535ede882d98f74 423 Host: example.com 424 Accept: application/scim+json 425 Authorization: Bearer h480djs93hd8 427 Figure 4: Example Feed GET Request 429 The response below shows an example Feed resource that describes an 430 available feed. 432 HTTP/1.1 200 OK 433 Content-Type: application/scim+json 434 Location: 435 https://example.com/v2/Feeds/88bc00de776d49d5b535ede882d98f74 436 ETag: 9d1c124149f522472e7a511c85b3a31b 438 { 439 "schemas":["urn:ietf:params:scim:schemas:event:2.0:Feed"], 440 "id":"88bc00de776d49d5b535ede882d98f74", 441 "feedName":"OIDCLogoutFeed", 442 "feedUri":"https://oidc.example.com/", 443 "description":"Logout events from oidc.example.com", 444 "type":"resource", 445 "events":[ 446 "https://specs.openid.net/logout":[] 447 ] 448 "meta":{ 449 ... SCIM meta attributes ... 450 } 451 } 453 Figure 5: Example Feed GET Response 455 In the above example (Figure 5) we can observe that the Feed has only 456 one event type, "https://specs.openid.net/logout" and has no 457 extensions defined for the event (see empty square brackets). Note 458 also, that no value for "filter" has been specified suggesting that 459 the Feed will return events about all subjects of the publisher. 461 4. Subscriptions 463 A subscription represents an agreement to deliver SETs from a 464 specified Feed URI from a Feed Provider to an individual Subscriber 465 entity also known as the "audience". The method of delivery and the 466 parameters for delivery are specified a set of parameters called 467 subscription metadata (see Section 4.1). 469 4.1. Subscription Metadata 471 A subscription is defined by the following metadata: 473 feedUri 474 A String value containing the URI for a feed supported by the feed 475 provider. It describes the content of the feed and MAY also be a 476 resolvable URI where the feed meta data may be returned as a JSON 477 object. REQUIRED. 479 methodUri 480 A REQUIRED single-valued string which is a URI with a prefix of 481 "urn:ietf:params:set:method". This specification defines HTTP 482 POST delivery Section 5: 483 "urn:ietf:params:set:method:HTTP:webCallback" 484 in which the Feed Provider delivers events using HTTP POST to a 485 specified callback URI. 487 deliveryUri 488 A URI that describes the location SETs are delivered. Its format 489 and usage requirements are defined by the associated "methodUri" 490 specification. 492 aud 493 An OPTIONAL URI representing the audience of the subscription. 494 The value SHALL be the value of "aud" when the subscriber receives 495 SETs from the feed. 497 feedJwk 498 An OPTIONAL public JSON Web Key (see [RFC7517]) that will be used 499 to sign published SETs. If present, the Subscriber can 500 authenticate SETs relayed from the Feed Provider. 502 confidentialJwk 503 An OPTIONAL Subscriber provided public JSON Web Key (see 504 [RFC7517]) that MAY be used by the Feed Provider to encrypt SET 505 tokens for the specified Subscriber. 507 subStatus 508 An OPTIONAL value that indicates the current status of a 509 Subscription: 511 "on" - indicates the Subscription has been verified and that 512 the Feed Provider MAY pass SETs to the Subscriber. 514 "verify" - indicates the Subscription is pending verification. 515 While in "verify", published SETs SHALL NOT be stored or 516 delivered to the Subscriber. Once verified, the status returns 517 to "on". 519 "paused" - indicates the Feed Provider is temporarily 520 suspending delivery to Subscriber. While "paused", SETs SHOULD 521 be retained and delivered when state returns to "on". 522 Verification is NOT required when returning to "on". 524 "off" - indicates that the Subscription is no longer passing 525 SETs. While in off mode, the subscription metadata is 526 maintained, but new events are ignored, not delivered or 527 retained. Before returning to "on", a verification MUST be 528 performed. 530 "fail" - indicates that the feed provider was unable to deliver 531 SETs to the Subscriber for an extended period of time, or due 532 to a call failure to the registered web call back URI. Unlike 533 paused status, a failed subscription no longer receives SETs, 534 nor are they retained by the Feed Provider. Before returning 535 to "on", a verification MUST be performed. 537 maxRetries 538 An OPTIONAL number indicating the maximum number of attempts to 539 deliver a SET. A value of '0' indicates there is no maximum. 540 Upon reaching the maximum, the Subscription "subStatus" attribute 541 is set to "failed". 543 maxDeliveryTime 544 An OPTIONAL number indicating the maximum amount of time in 545 seconds a SET MAY take for successful delivery. Upon reaching the 546 maximum, the subscription "subStatus" is set to "failed". If 547 undefined, there is no maximum time. 549 minDeliveryInterval 550 An OPTIONAL integer that represents the minimum interval in 551 seconds between deliveries. A value of '0' indicates delivery 552 should happen immediately. When delivery is a polling method 553 (e.g. HTTP GET), it is the expected time between subscriber 554 attempts. When in push mode (e.g. HTTP POST), it is the interval 555 the server will wait before sending a new event or events. 557 4.2. Subscription State Model 559 The Subscription attribute "subStatus" tracks the state of any 560 particular subscription with regards to whether SETs are ready or 561 able to be delivered. The impact on delivery processing is described 562 in Table 1. 564 The following is the state machine representation of a subscription 565 on a Feed Publisher. Note that a subscription cannot be made active 566 until a verification process has been completed. As such, a newly 567 created subscription begins with state "verify". 569 + 570 | 571 Create 572 v 573 +------+ +----------+ 574 | fail +->Restart---->| verify | 575 +------+ +----+-----+ 576 ^ | 577 |<----Confirm Fail<----+ 578 | Confirm 579 | v 580 | +----------+ +--------+ 581 | | +--->Suspend--->| | 582 +------Timeout<---+ on | | paused | 583 | |<--Resume<-----+ | 584 +-+--------+ +--------+ 585 | ^ 586 Disable Enable 587 v | 588 +--------+-+ 589 | off | 590 +----------+ 592 Figure 6: Subscription States at Feed Publisher 594 In the above diagram, the following actions impact the state of a 595 Subscription. "subStatus" values are shown in the boxes, and change 596 based on the following actions: 598 Create 599 A Subscriber or an administrator creates a new subscription using 600 SCIM as described in Section 4.3.2. The initial state is 601 "verify". 603 Confirm 604 The Feed Publisher sends a verification SET to the Subscriber 605 which confirms with the correct response as described in 606 Section 4.4. If it succeeds to deliver, the Feed Publisher mail 607 retry or set state to "on". 609 Confirm Fail 610 If the confirmation fails, the Feed Publisher sets the state to 611 "fail" requiring administrative action to correct the issue and 612 "Restart". 614 Timeout 615 A Feed Publisher having not being able to deliver a SET over one 616 or more retries which has reached a limit of attempts 617 ("maxRetries") or time ("maxDeliveryTime") MAY set the 618 subscription state to "fail". In general, the intention is to 619 indicate the maximum number of retries or time a Feed Publisher is 620 able to wait until SET event loss begins to occur resulting in the 621 failed state. 623 Restart 624 An administrator having corrected the failed delivery condition 625 modifies the Subscription state to "verify" (e.g. see 626 Section 4.3.3). 628 Suspend and Resume 629 A Subscription MAY be suspended and resumed by updating the 630 Subscription state to "paused" or "on". For example, see see 631 Section 4.3.3. While suspended, the Feed Publisher MAY retain 632 undelivered SETs for a period of time. If the Feed Publisher is 633 no longer able to retain SETs, the subscription state SHOULD be 634 set to "off" to indicate SETs are being lost. 636 Enable and Disable 637 A subscription MAY be disabled and enabled by updating the 638 Subscription state to "off" or "on". For example, see see 639 Section 4.3.3. While the Subscription is disabled, all SETs that 640 occur at the Feed Publisher are lost. 642 4.3. SCIM Subscription Management 644 A Feed Publisher MAY use SCIM to support management of subscriptions. 645 Typically this involves support for the Subscription Resource Type, 646 and the corresponding SCIM operations to create, update, retrieve 647 Subscription Resources. For SCIM service provider capability and 648 schema discovery, see Section 4 [RFC7644]. 650 4.3.1. SCIM Subscription Resource Type 652 When Subscriptions are managed within a SCIM service provider 653 [RFC7644], Subscription resources use schema defined in Section 4.1 654 and use a schema value of 655 "urn:ietf:params:scim:schemas:event:2.0:Subscription". 657 The SCIM Subscription "ResourceType" definition is defined as 658 follows: 660 { 661 "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"], 662 "id": "Subscription", 663 "name": "Subscription", 664 "endpoint": "/Subscriptions", 665 "description": "Subscribers to SET Feeds", 666 "schema": "urn:ietf:params:scim:schemas:event:2.0:Subscription", 667 "schemaExtensions": [] 668 } 670 Figure 7: SCIM Subscription ResourceType Definition 672 To retrieve information about one or more Subscriptions, Subscribers 673 or management clients MAY query the "/Subscriptions" endpoint as 674 defined in Section 3.4 [RFC7644]. 676 The example below retrieves a specific "Subscription" resource whose 677 "id" is "548b7c3f77c8bab33a4fef40". 679 GET /Subscriptions/767aad7853d240debc8e3c962051c1c0 680 Host: example.com 681 Accept: application/scim+json 682 Authorization: Bearer h480djs93hd8 684 Figure 8: Example SCIM Subscription GET Request 686 The response below shows an example Feed resource that describes an 687 available feed. 689 HTTP/1.1 200 OK 690 Content-Type: application/scim+json 691 Location: 692 https://example.com/v2/Subscriptions/767aad7853d240debc8e3c962051c1c0 694 { 695 "schemas":["urn:ietf:params:scim:schemas:event:2.0:Subscription"], 696 "id":"767aad7853d240debc8e3c962051c1c0", 697 "feedName":"OIDCLogoutFeed", 698 "feedUri": 699 "https://example.com/v2/Feeds/88bc00de776d49d5b535ede882d98f74", 700 "methodUri":"urn:ietf:params:set:method:HTTP:webCallback", 701 "deliveryUri":"https://notify.examplerp.com/Events", 702 "aud":"https://sets.myexamplerp.com", 703 "subStatus":"pending", 704 "maxDeliveryTime":3600, 705 "minDeliveryInterval":0, 706 "description":"Logout events from oidc.example.com", 707 "meta":{ 708 ... SCIM meta attributes ... 709 } 710 } 712 Figure 9: Example Subscription GET Response 714 In the above example (Figure 9) observe that the subscription is for 715 the SCIM "Feed" resource defined at "https://example.com/v2/ 716 Feeds/88bc00de776d49d5b535ede882d98f74". The current subscription 717 state is "pending" which suggest the Subscription Verification (see 718 Section 4.4) process has not yet completed. Since there is no value 719 for "feedJwk", ) or "confidentialJwk", the SETs will be sent without 720 signing or encryption (plain text). 722 4.3.2. New Subscription Requests 724 To subscribe to a feed, the subscriber of management client uses the 725 SCIM Create operation as defined in Section 3.3 [RFC7644]. SCIM 726 subscription management service providers MAY have additional schema 727 requirements which MAY be discovered using SCIM service configuration 728 and schema discovery, see Section 4 [RFC7644]. 730 In the following non-normative example, a new Subscription resource 731 is requested. Note that the SCIM service provider automatically 732 assigns the "id" attribute. 734 POST /Subscriptions 735 Host: example.com 736 Accept: application/scim+json 737 Content-Type: application/scim+json 738 Authorization: Bearer h480djs93hd8 740 { 741 "schemas":["urn:ietf:params:scim:schemas:event:2.0:Subscription"], 742 "feedName":"OIDCLogoutFeed", 743 "feedUri": 744 "https://example.com/v2/Feeds/88bc00de776d49d5b535ede882d98f74", 745 "methodUri":"urn:ietf:params:set:method:HTTP:webCallback", 746 "deliveryUri":"https://notify.examplerp.com/Events", 747 "aud":"https://sets.myexamplerp.com", 748 "maxDeliveryTime":3600, 749 "minDeliveryInterval":0, 750 "description":"Logout events from oidc.example.com" 751 } 753 Figure 10: Example New Subscription Request in SCIM 755 In following non-normative response, the SCIM service provider has 756 automatically assigned a resource location as well as an "id". 757 Usually upon creation, the initial value of "subStatus" is "pending" 758 indicating that the Subscription Verification (see Section 4.4) has 759 not been completed. 761 HTTP/1.1 201 Created 762 Content-Type: application/scim+json 763 Location: 764 https://example.com/v2/Subscriptions/767aad7853d240debc8e3c962051c1c0 766 { 767 "schemas":["urn:ietf:params:scim:schemas:event:2.0:Subscription"], 768 "id":"767aad7853d240debc8e3c962051c1c0", 769 "feedName":"OIDCLogoutFeed", 770 "feedUri": 771 "https://example.com/v2/Feeds/88bc00de776d49d5b535ede882d98f74", 772 "methodUri":"urn:ietf:params:set:method:HTTP:webCallback", 773 "deliveryUri":"https://notify.examplerp.com/Events", 774 "aud":"https://sets.myexamplerp.com", 775 "subStatus":"pending", 776 "maxDeliveryTime":3600, 777 "minDeliveryInterval":0, 778 "description":"Logout events from oidc.example.com", 779 "meta":{ 780 ... SCIM meta attributes ... 781 } 782 } 784 Figure 11: Example Response to Subscription Request 786 4.3.3. Updating Subscriptions 788 To modify a Subscription, a Subscriber or authorized management 789 client MAY use the SCIM PUT operation (see Section 3.5.1 [RFC7644]) 790 and MAY use the SCIM PATCH operation (see Section 3.5.2 [RFC7644]) if 791 supported by the SCIM Subscription server. 793 In the following non-normative example, the client is requesting that 794 "subStatus" be changed to "paused" for the Subscription whose path is 795 identified by the request URI path. 797 PATCH /Subscriptions/767aad7853d240debc8e3c962051c1c0 798 Host: example.com 799 Accept: application/scim+json 800 Content-Type: application/scim+json 801 Authorization: Bearer h480djs93hd8 803 { 804 "schemas": 805 ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], 806 "Operations": [{ 807 "op":"replace", 808 "path":"subStatus", 809 "value":"paused" 810 }] 811 } 813 Figure 12: Example SCIM Subscription Update 815 4.4. Subscription Verification 817 In order to avoid ongoing communication issues and to minimize 818 requirements for Feed Providers to maintain a series of SETs 819 indefinitely, a verification process is used to confirm that the 820 requested Subscription distribution endpoints are valid and that SETs 821 may be successfully delivered. When a Subscription is created or 822 modified, or goes into a failed or off state, the Feed Provider SHALL 823 set the Subscription state attribute "subStatus" to "verify" and send 824 a Verify SET message to the subscriber. If the SET is delivered 825 successfully, the subscription state SHOULD be turned to "on". If 826 however verification fails due to a timeout or connection failure, or 827 any other cause, the Subscription status SHALL be set to "fail". 829 4.4.1. Verifying Subscriptions 831 The verification process serves to verify that the identified 832 Subscriber is willing to receive SETs and is correctly configured. 833 In the case of push style subscriptions, where the publisher 834 initiates the action to deliver a SET, Verification can also serve to 835 prevent a Feed Publication server from flooding an endpoint which did 836 not actually request a Subscription. 838 A Feed Provider MAY send a Verify SET at any time in order to 839 reverify connectivity and to assure the subscriber the subscription 840 is valid (e.g. as a keep alive technique). 842 To confirm a subscription, the Feed Provider SHALL send a 843 verification SET to the subscriber using the registered "methodUri" 844 mechanism. The Verify SET contains the following attributes: 846 events Set with a value of "[[this RFC URL]]#verify". 848 iss Set to the URI of the feed publisher (see 849 [I-D.hunt-idevent-token]). 851 aud MUST be set to a value that matches the subscription "feedUri" 852 requested. 854 exp A value that indicates the time the verification request will 855 expire. Once expired, the server will set the subscription state 856 to "fail". 858 In the SET payload area, a specific delivery method MAY include an 859 attribute that can be used to confirm the subscriber has successfully 860 received and parsed the SET (e.g. such as the inclusion of a 861 challenge attribute, see Section 5.3.3). If a confidential JWK was 862 supplied, then the SET SHOULD be encrypted with the provided key. 863 Successful parsing of the message confirms that provides confirmation 864 of correct configuration and possession of keys. 866 Note that the verification event URI ("[[this RFC URL]]#verify") type 867 is not normally listed as part of the definition of a Feed as it is 868 not part of the normal information flow of a Feed. Any Feed MAY 869 include a SET verification event whether listed or not in the Feed 870 event metadata. 872 Upon receiving the SET, the subscriber acknowledges receipt as 873 defined by the method profile (for example, see Section 5.3.3). 875 If the subscriber is unable to parse the verification SET, fails to 876 return the correct challenge, or the SET is not delivered after a 877 period of time. The Feed Publisher will set "subStatus" to "failed". 879 5. Event Delivery 881 5.1. Introduction to Event Delivery Methods 883 Each event delivery method SHOULD have the following information: 885 Description 886 The "methodUri" URI value for the delivery method and a 887 description of the method. 889 Subscription Verification Procedure 890 The procedure that the configuration for a subscription is 891 confirmed causing the subscription status to be set to "on". 893 Delivery Message Format 894 A description of an event delivery message and how to locate the 895 event token(s) as well as any additional error signalling. 897 Delivery Procedure 898 The protocol procedure for a delivery request (push or poll), and 899 the expected successful response. 901 Failure Conditions 902 A description of the failure conditions that might occur and the 903 impact on the subscriptions operational status ("subStatus") if 904 any. 906 This specification defines the first delivery method known as "HTTP 907 Web Callback Method" which uses HTTP POST. 909 5.2. Delivery Processing 911 As mentioned in Section 4.1, the attribute "subStatus" defines the 912 current state of a subscribers subscription. Figure 6 shows a state 913 diagram for Subscriptions. The following describes that actions 914 taken by the Feed Publisher based upon "subStatus". 916 +--------+----------------------------------------------------------+ 917 | Status | Action | 918 +--------+----------------------------------------------------------+ 919 | on | Delivery SHALL be attempted based on the method defined | 920 | | in the subscription attribute "methodUri". If the SET | 921 | | fails to deliver it MAY be retained for a retry delivery | 922 | | in a minimum of "minDeliveryInterval" seconds. If new | 923 | | SETs arrive before the interval, the SETs MUST be held | 924 | | for delivery in order of reception. If this is a repeat | 925 | | attempt to deliver, the Feed Publisher MAY discard the | 926 | | SET if "maxRetries" or "maxDeliveryTime" is exceeded. If | 927 | | a SET is discarded, the Feed Publisher MAY set | 928 | | "subStatus" to "failed". | 929 | verify | If the SET is not a Verify SET, the SET MAY be retained | 930 | | for a retry at the Feed Publishers discretion. If a | 931 | | Verify SET fails to deliver, the Feed Publisher SHALL | 932 | | set "subStatus" to "failed". The Feed Publish MAY opt to | 933 | | make multiple attempts to complete a verification during | 934 | | which status remains as "verify". | 935 | paused | The SET is held for delivery in a queue. The Feed | 936 | | Publisher MAY at its own discretion set the subscription | 937 | | state to "failed" if "subStatus" is not returned to "on" | 938 | | in what the Feed Publisher determines to be a reasonable | 939 | | amount of time. | 940 | off | The SET is ignored. | 941 | fail | The SET is ignored due to a previous unrecoverable | 942 | | error. | 943 +--------+----------------------------------------------------------+ 945 Table 1: Delivery Processing By Status 947 5.3. HTTP Web Callback Method 949 5.3.1. Description 951 This method allows a feed provider to use HTTP POST (Section 4.3.3 952 [RFC7231]) to deliver SETs to a registered web callback URI. The 953 Subscription "methodUri" value for this method is 954 "urn:ietf:params:set:method:HTTP:webCallback". 956 This delivery method is capable of delivering a single SET per HTTP 957 POST request. Depending on the settings for the subscription 958 metadata (see Section 4.1), the SET MAY be signed and/or encrypted as 959 defined in [I-D.hunt-idevent-token]. 961 The Subscription's "deliveryUri" attribute indicates the location of 962 a Subscriber provided endpoint which can accept HTTP POST requests 963 (e.g. "https://notify.examplerp.com/Events"). 965 5.3.2. Delivery Message Format 967 The content-type for this method is "application/jwt" and consists of 968 a single SET token (see [I-D.hunt-idevent-token]). 970 eyJhbGciOiJub25lIn0 971 . 972 eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV 973 kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj 974 FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ 975 WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6 976 WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ 977 hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG 978 VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX 979 SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk 980 b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF 981 tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW 982 1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ 983 . 985 Figure 13: Example Web Callback POST Message 987 5.3.3. Subscription Verification 989 This profile specifies the verification method for HTTP POST and is 990 based on the general verification method described in Section 4.4.1. 992 To confirm a subscription, the Feed Provider SHALL send a 993 verification SET to the subscriber using the registered "methodUri" 994 mechanism which in this case is 995 "urn:ietf:params:set:method:HTTP:webCallback". The Verify SET 996 contains the attributes listed in Section 4.4.1. 998 A payload attribute "confirmChallenge" is provided with a String 999 value that the subscriber SHALL echo back in its response. The 1000 intent is to confirm that the Subscriber has successfully parsed the 1001 SET and is not just echoing back HTTP success. 1003 A non-normative JSON representation of an event to be sent to a 1004 subscriber as a subscription confirmation. Note the event is not yet 1005 encoded as a JWT token: 1007 { 1008 "jti": "4d3559ec67504aaba65d40b0363faad8", 1009 "events":["[[this RFC URL]]#verify"], 1010 "iat": 1458496404, 1011 "iss": "https://scim.example.com", 1012 "exp": 1458497000, 1013 "aud":[ 1014 "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754", 1015 "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7" 1016 ], 1017 "[[this RFC URL]]#verify":{ 1018 "confirmChallenge":"ca2179f4-8936-479a-a76d-5486e2baacd7" 1019 } 1020 } 1022 Figure 14: Example Verification SET with Challenge 1024 The above SET is encoded as a JWT and transmitted to the Subscriber 1025 as shown in Figure 16. 1027 Upon receiving a subscription verify SET, a confirming subscriber 1028 SHALL respond with a JSON object that includes a "challengeResponse" 1029 attribute and the value that was provided in "confirmChallenge". The 1030 content type header is set to "application/json". 1032 The following is a non-normative example response to a Verify SET 1033 received via HTTP/1.1 POST and includes a JSON object containing the 1034 confirmation attribute and value. 1036 HTTP/1.1 200 OK 1037 Content-Type: application/json 1039 { 1040 "challengeResponse":"ca2179f4-8936-479a-a76d-5486e2baacd7" 1041 } 1043 Figure 15: Example Response to Verify SET with Challenge 1045 If the subscriber returns a non-matching value or an HTTP status 1046 other than a 200 series response, the subscription "state" SHALL be 1047 set to "fail". A declining subscriber MAY simply respond with any 1048 400 series HTTP error (e.g. 404). 1050 5.3.4. Delivery Procedure 1052 To deliver an event, the publisher generates an event delivery 1053 message and uses HTTP POST to the registered endpoint. The content- 1054 type of the message is "application/jwt" and the expected response 1055 type (accept) is "application/json". 1057 POST /Events HTTP/1.1 1059 Host: notify.examplerp.com 1060 Accept: application/json 1061 Content-Type: application/jwt 1062 "eyJhbGciOiJub25lIn0 1063 . 1064 eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV 1065 kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj 1066 FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ 1067 WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6 1068 WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ 1069 hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG 1070 VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX 1071 SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk 1072 b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF 1073 tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW 1074 1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ 1075 . 1077 Figure 16: Example Web Callback POST Request 1079 Upon receipt of the request, the Subscriber SHALL validate the JWT 1080 structure of the SET as defined in Section 7.2 [RFC7519]. The 1081 Subscriber SHALL also validate the SET information as described in 1082 Section 2 [I-D.hunt-idevent-token]. 1084 If the SET is determined to be valid, the Subscriber SHALL indicate 1085 successful submission by responding with HTTP Status 202 as 1086 "Accepted" (see Section 6.3.3 [RFC7231]). 1088 If SET or JWT is invalid, or there is an HTTP error, the Subscriber 1089 SHALL respond with the appropriate HTTP error or an HTTP Status 400 1090 Bad Request error as follows: 1092 +----------+--------------------------------------------------------+ 1093 | Err | Description | 1094 | Value | | 1095 +----------+--------------------------------------------------------+ 1096 | jwtParse | Invalid or unparsable JWT or JSON structure. | 1097 | jwtHdr | In invalid JWT header was detected. | 1098 | jwtCypto | Unable to parse due to unsupported algorithm. | 1099 | jws | Signature was not validated. | 1100 | jwe | Unable to decrypt JWE encoded data. | 1101 | jwtAud | Invalid audience value. | 1102 | jwtIss | Issuer not recognized. | 1103 | setType | An unexpected event type was received. | 1104 | setParse | Invalid structure was encountered such as inability to | 1105 | | parse SET event payload. | 1106 | setData | SET event claims incomplete or invalid. | 1107 | dup | A duplicate SET was received and has been ignored. | 1108 +----------+--------------------------------------------------------+ 1110 Table 2: HTTP Status 400 Errors 1112 The following is a non-normative example of a successful receipt of a 1113 SET. 1115 HTTP/1.1 202 Accepted 1117 Figure 17: Example Successful Delivery Response 1119 An HTTP Status 400 Bad Request response includes a JSON object which 1120 provides details about the error. The JSON object includes the JSON 1121 attributes: 1123 err 1124 A value which is a keyword that describes the error (see Table 2). 1126 description 1127 A human-readable text that provides additional diagnostic 1128 information. 1130 The following is an example non-normative Bad Request error. 1132 HTTP/1.1 400 Bad Request 1133 Content-Type: application/json 1135 { 1136 "err":"dup", 1137 "description":"SET already received. Ignored." 1139 } 1141 Figure 18: Example Bad Request Response 1143 6. Security Considerations 1145 [TO BE COMPLETED] 1147 7. IANA Considerations 1149 7.1. Event Notification Mechanism Registry 1151 [TODO: Registration for Notification Mechanisms] 1153 7.2. SCIM Schema Registration 1155 As per the "SCIM Schema URIs for Data Resources" registry established 1156 by Section 10.3 [RFC7643], the following defines and registers the 1157 following SCIM URIs and Resource Types for Feeds and Subscriptions. 1159 +-----------------------+--------------+--------------+-------------+ 1160 | Schema URI | Name | ResourceType | Reference | 1161 +-----------------------+--------------+--------------+-------------+ 1162 | urn:ietf:params:scim: | SET Event | Feed | Section 3.3 | 1163 | schemas:event:2.0: | Feed | | | 1164 | Feed | | | | 1165 | urn:ietf:params:scim: | SET Event | Subscription | Section 4.3 | 1166 | schemas:event:2.0: | Subscription | | | 1167 | Subscription | | | | 1168 +-----------------------+--------------+--------------+-------------+ 1170 8. References 1172 8.1. Normative References 1174 [I-D.hunt-idevent-token] 1175 Hunt, P., Denniss, W., Ansari, M., and M. Jones, "Security 1176 Event Token (SET)", draft-hunt-idevent-token-05 (work in 1177 progress), September 2016. 1179 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1180 Requirement Levels", BCP 14, RFC 2119, 1181 DOI 10.17487/RFC2119, March 1997, 1182 . 1184 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1185 Resource Identifier (URI): Generic Syntax", STD 66, 1186 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1187 . 1189 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 1190 DOI 10.17487/RFC5988, October 2010, 1191 . 1193 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1194 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1195 DOI 10.17487/RFC7231, June 2014, 1196 . 1198 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1199 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1200 . 1202 [RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. 1203 Mortimore, "System for Cross-domain Identity Management: 1204 Core Schema", RFC 7643, DOI 10.17487/RFC7643, September 1205 2015, . 1207 [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., 1208 and C. Mortimore, "System for Cross-domain Identity 1209 Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, 1210 September 2015, . 1212 8.2. Informative References 1214 [I-D.ietf-webpush-protocol] 1215 Thomson, M., Damaggio, E., and B. Raymor, "Generic Event 1216 Delivery Using HTTP Push", draft-ietf-webpush-protocol-02 1217 (work in progress), November 2015. 1219 [idevent-scim] 1220 Oracle Corporation, "SCIM Event Extensions (work in 1221 progress)". 1223 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1224 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1225 2015, . 1227 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1228 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1229 . 1231 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1232 DOI 10.17487/RFC7517, May 2015, 1233 . 1235 Appendix A. Contributors 1237 Appendix B. Acknowledgments 1239 The editor would like to thank the participants in the the SCIM 1240 working group for their support of this specification. 1242 Appendix C. Change Log 1244 Draft 00 - PH - First Draft 1246 Draft 01 - PH - 1248 o Removed the version from filename in GITHUB version 1250 o Aligned document with new SET terminology from I-D.hunt-idevent- 1251 token 1253 o Simplified draft to only define HTTP POST profile (TBD) 1255 o Removed webpush and polling modes (can be re-added later). 1257 o Added SCIM management definitions for Feeds 1259 o Added delivery information including errors 1261 o Added subscription management information (e.g. how to subscribe) 1263 o Updated reference to idevent-token to published IETF version 1265 o Added a state diagram for Subscriptions 1267 Authors' Addresses 1269 Phil Hunt (editor) 1270 Oracle Corporation 1272 Email: phil.hunt@yahoo.com 1273 Marius Scurtescu 1274 Google 1276 Email: mscurtescu@google.com 1278 Morteza Ansari 1279 Cisco 1281 Email: morteza.ansari@cisco.com