[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                       P. Hunt, Ed.
Internet-Draft                                                    Oracle
Intended status: Standards Track                               M. Ansari
Expires: September 9, 2015                                         Cisco
                                                               I. Glazer
                                                              Salesforce
                                                           March 8, 2015


                        SCIM Event Notification
                       draft-hunt-scim-notify-00

Abstract

   The System for Cross-Domain Identity Management (SCIM) specification
   is an HTTP based protocol that makes managing identities in multi-
   domain scenarios easier to support through a standardized HTTP
   service.

   In a SCIM environment, changes to resources may be requested by
   multiple parties.  As time goes by an interested subscriber may wish
   to be informed about resource state changes that are occurring at the
   SCIM service provider.  This specification defines a hub notification
   service that can be used to publish and distribute events to
   interested registered subscribers.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 9, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Hunt, et al.            Expires September 9, 2015               [Page 1]


Internet-Draft           draft-hunt-scim-notify               March 2015


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction and Overview . . . . . . . . . . . . . . . . . .   3
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   4
     1.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Notification Process  . . . . . . . . . . . . . . . . . . . .   6
   3.  SCIM Events . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Event Types . . . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Event Metadata  . . . . . . . . . . . . . . . . . . . . .   8
     3.3.  Event Message . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Discovery . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.1.  SCIM Server Resource Link Headers . . . . . . . . . . . .  11
     4.2.  Feeds Endpoint  . . . . . . . . . . . . . . . . . . . . .  12
   5.  SCIM Feeds  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Feed Discovery  . . . . . . . . . . . . . . . . . . . . .  13
   6.  Notification Hub  . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Subscriber Services . . . . . . . . . . . . . . . . . . .  13
       6.1.1.  Subscription Metadata . . . . . . . . . . . . . . . .  14
       6.1.2.  Request Subscription  . . . . . . . . . . . . . . . .  15
       6.1.3.  Subscription Verification . . . . . . . . . . . . . .  17
       6.1.4.  Cancel A Subscription . . . . . . . . . . . . . . . .  19
     6.2.  Publisher Services  . . . . . . . . . . . . . . . . . . .  19
       6.2.1.  Feed Registration . . . . . . . . . . . . . . . . . .  19
       6.2.2.  Feed Definition Operations  . . . . . . . . . . . . .  23
       6.2.3.  Event POSTing . . . . . . . . . . . . . . . . . . . .  23
       6.2.4.  Polling for Publisher Events  . . . . . . . . . . . .  25
     6.3.  Event Delivery  . . . . . . . . . . . . . . . . . . . . .  25
       6.3.1.  Web Callback  . . . . . . . . . . . . . . . . . . . .  26
       6.3.2.  Polling . . . . . . . . . . . . . . . . . . . . . . .  26
       6.3.3.  Push Notification Extensions  . . . . . . . . . . . .  26
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
     8.1.  SCIM Event Notification Mechanism Registry  . . . . . . .  26
     8.2.  SCIM Event Type Registry  . . . . . . . . . . . . . . . .  26
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  26
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  27
   Appendix A.  Contributors . . . . . . . . . . . . . . . . . . . .  27



Hunt, et al.            Expires September 9, 2015               [Page 2]


Internet-Draft           draft-hunt-scim-notify               March 2015


   Appendix B.  Acknowledgments  . . . . . . . . . . . . . . . . . .  27
   Appendix C.  Change Log . . . . . . . . . . . . . . . . . . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

1.  Introduction and Overview

   The System for Cross-Domain Identity Management (SCIM) specification
   is an HTTP based protocol that makes managing identities in multi-
   domain scenarios easier to support through a standardized HTTP
   service.

   In a SCIM environment, changes to resources may be requested by
   multiple parties.  As time goes by an interested subscriber may wish
   to be informed about resource state changes that are occurring at the
   SCIM service provider.  This specification defines a hub notification
   service that can be used to publish and distribute events to
   interested registered subscribers.  This specification's design is
   inspired by [pubsubhubbub], but is significantly adapted to use JSON
   and JWT tokens.

   The goal of this specification is to avoid alternative approaches
   such as ATOM feeds or LDAP changelogs that require historical change
   history be maintained.  These techniques not only causes scalability
   issues, but may also provide security risks over time because of the
   difficulties in filtering history and data for specific subscribers
   based on their authorized access to information.

   This specification defines a Notification Hub which receives events
   from a SCIM Service Provider.  The role of the notification hub is to
   offload the SCIM Service provider by taking care of:

   o  Re-publishing events to appropriate Feeds where the event is a
      match.

   o  Distributing events to registered subscribers using their
      registered notification mechanism.

   o  Persisting events as necessary until all registered subscribers
      have received the event.












Hunt, et al.            Expires September 9, 2015               [Page 3]


Internet-Draft           draft-hunt-scim-notify               March 2015


   The following diagram shows a typical Notification Hub and its
   service relationships with SCIM Service Providers and registered
   notification Subscribers.

                            +----------------+
                            |     SCIM       |
                            |Service Provider|
                            |  "Publisher"   |
                            +-------+--------+
                                    |
                                    |
                            +-------v--------+
                            |  Notification  |
                            |     "Hub"      |
                            +------+---------+
                                   |  |   |
                                   |  |   |
                                   |  v   v
                             +-----v------+
                             |    Feed    |+
                             |"Subscriber"||+
                             |            |||
                             +------------+||
                              +------------+|
                               +------------+

                   Figure 1: Notification Relationships

   The specification supports two layers of authentication.  The base
   layer uses normal HTTP Authentication techniques that may include TLS
   mutual-authentication and OAuth access token authorizations.  The
   second layer involves the exchange of JWT keys that may be used to
   authenticate messages and encrypt content for registered subscribers.

   For a feed subscriber, this specification makes it possible to
   receive update or change-of-state notifications that may be of
   interest.  By providing state change event notifications, a large
   cross-section of subscribers can be developed to support use cases
   such as: work-flow co-ordination, overall enterprise identity
   governance co-ordination, and cross-domain replication.  [DISCUSS:
   should we elaborate on this?]

1.1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].  These
   keywords are capitalized when used to unambiguously specify



Hunt, et al.            Expires September 9, 2015               [Page 4]


Internet-Draft           draft-hunt-scim-notify               March 2015


   requirements of the protocol or application features and behavior
   that affect the interoperability and security of implementations.
   When these words are not capitalized, they are meant in their
   natural-language sense.

   For purposes of readability examples are not URL encoded.
   Implementers MUST percent encode URLs as described in Section 2.1 of
   [RFC3986].

   Throughout this documents all figures MAY contain spaces and extra
   line-wrapping for readability and space limitations.  Similarly, some
   URI's contained within examples, have been shortened for space and
   readability reasons.

1.2.  Definitions

   SCIM Service Provider  The SCIM service provider as defined in SCIM
      core schema.  A SCIM service provider publishes events to be
      distributed by a trusted Notification Hub.

   Notification Hub  A service provider in the same domain as the SCIM
      Service Provider.  Because the "hub" manages individual
      subscribers, the "hub" must have access to all event message
      content so that it may encrypt it for specific subscribers when
      required.

   Event  An event is a SCIM change event that is to be distributed to
      one or more registered subscribers.  An event is encapsulated as a
      JWT token and MAY be signed or encrypted using JWS/JWE for
      authentication and confidentiality reasons.

   Feed  A feed is a URI that describes the set of resources and events
      under which events may be issued.  An interested client registers
      with the Notification Hub to subscribe to events associated with a
      feed.

   Notification Mechanism  A URI that describes the chosen event
      notification mechanism.  When subscribing to a feed, a client may
      choose a specific mechanism by which it wishes to receive
      notification events.  [This specification will define a delivery
      extension point.]  Examples of possible delivery mechanisms
      include:

      *  Registered Callback - The Notification Hub will deliver events
         by using HTTP POST to a registered endpoint.






Hunt, et al.            Expires September 9, 2015               [Page 5]


Internet-Draft           draft-hunt-scim-notify               March 2015


      *  Polling - The subscriber will periodically poll the
         notification hub for one or more events by performing an HTTP
         GET to a specified URI (mailbox endpoint).

      *  WebPush - An HTTP/2 based method for delivering real-time
         events. https://tools.ietf.org/wg/webpush/

      *  Platform/Mobile Notification Services (e.g.  Apple Push
         Notification Service, Google Cloud Messaging, and Windows
         Notification Services).  Future profiles that support delivery
         of SCIM events vis platform specific messaging services.

   Subscriber  A Subscriber registers to receive event notifications
      from a Notification Hub on behalf of a SCIM Service Provider.

2.  Notification Process

   When a resource has changed, a SCIM Service Provider constructs a JWT
   that describes the event.  The service provider MAY include the
   affected feedURIs for the Notification Hub to process.  The SCIM
   service provider publishes the event to the Notification Hub using
   either an HTTP POST, or will hold the event (along with other events)
   until the notification retrieves pending events via an HTTP GET.
   After an event is delivered to the Notification Hub, the service
   provider has no further obligation to maintain or distribute the
   event.  The service provider MAY subsequently receive requests from
   subscribers for more information about the current state of a
   resource using a normal SCIM GET request.

   An event is a set of attributes combined together in a JWT token.  An
   event typically includes:

   o  Affected resource URI

   o  A list of attributes modified

   o  An event type (patch, create, delete)

   o  Optional attribute values for affected attributes.  Note: JWT MUST
      be a JWE if raw data is included.

   An event describes what state change has occurred at a publishing
   service provider resource.  An event should not be interpreted as a
   command to change by the subscriber.

   Upon receiving an event, the notification hub, categorizes the event
   and determine which feeds should be notified of the event.  For each
   feed, the notification hub delivers the events to any registered



Hunt, et al.            Expires September 9, 2015               [Page 6]


Internet-Draft           draft-hunt-scim-notify               March 2015


   clients.  If the event contains raw attribute values, the
   notification hub encrypts the JWT so that only the registered
   subscriber(s) may receive the event.  To deliver the event, the
   notification hub uses the registered notification mechanism requested
   by the subscriber.

   Upon receiving an event (or events for polling subscribers), the
   subscriber reads the JWT or JWE token and validates it if signed (a
   JWS).  Based on the content of the JWT, the subscriber decides what
   if any action it needs to take in response to the event from the SCIM
   Service Provider.  The subscriber MAY perform a SCIM GET request to
   the affected resource URI in order to confidentially obtain the
   current state of the affected resource.

3.  SCIM Events

   A SCIM Event notifies a subscriber of a possible change in state of a
   resource contained within a specified feed.  The event specifies the
   URI of an affected resource and the type of event that has occurred.
   The event message may also contain additional metadata describing the
   attributes that may have been modified, and/or values representing
   the final state of the affected attribute(s).

3.1.  Event Types

   This specification defines 8 events.  Additional event types may be
   defined using the Event Type IANA registration process described in
   Section 8.2.

   ADD
      The specified resource URI was added to the feed.  An add does not
      necessarily indicate a resource is new or has been recently
      created, but rather that it has been added to a feed.  For
      example, an existing user has had a new role (e.g.  CRM_User)
      added to their profile which has caused their resource to join a
      feed.

   CREATE
      The new resource URI has been created at the service provider and
      has been added to the feed.  When a CREATE event is sent, a
      corresponding ADD event is not issued.  For example, a new user
      was created via HTTP POST, whose attribute profile met the
      criteria of a current feed.

   ACTIVATE
      The specified resource (e.g.  User) has been activated or is
      otherwise available for use.  [TODO: this seems to be a higher




Hunt, et al.            Expires September 9, 2015               [Page 7]


Internet-Draft           draft-hunt-scim-notify               March 2015


      level concept that may consist of multiple attributes changing -
      How to differentiate between activate and MODIFY events]

   MODIFY
      The specified resource has been updated (e.g. one or more
      attributes has changed).

   DEACTIVATE
      The specified resource (e.g.  User) has been deactivated.  [TODO:
      Is there a corresponding MODIFY event?]

   DELETE  The specified resource has been deleted from the service
      provider and is also removed from the feed.  When a DELETE is
      sent, a corresponding REMOVE is not issued.

   REMOVE
      The specified resource has been removed from the feed.  Removal
      does not indicate that the resource was deleted or otherwise
      deactivated.

   PASSWORD
      The specified resource (e.g.  User) has changed its password.  If
      secure exchange is possible with the subscriber, the event may
      also include the raw password update text.  A PASSWORD event MUST
      be transmitted in encrypted form (see Section 3.3).

   CONFIRMATION  A special event that is used during Polling Feed
      Registrations and Web Callback URI subscriptions to confirm
      successful configuration of an event feed.  The contents of a
      CONFIRMATION event SHALL be defined by the registration process
      documented in following sections [TODO add reference]

3.2.  Event Metadata

   The following are attributes that may be included in an event
   message:

   schemas  A multi-valued String attribute that contains the value
      "urn:ietf:params:scim:schemas:notify:2.0:Event".

   feedUris  A multivalued String containing the URIs of the feeds the
      event is associated with.  The notification hub may filter these
      values to be only those values relevant to a particular
      subscriber.  In doing so, the notification hub is not obligated to
      deliver repeated events to the same subscriber.  [DISCUSS: Is this
      problematic if the subscriber is using multiple endpoints?]

   publisherUri



Hunt, et al.            Expires September 9, 2015               [Page 8]


Internet-Draft           draft-hunt-scim-notify               March 2015


      A single valued string containing the URI of the SCIM Service
      Provider publishing the event.  Typically this is the SCIM Service
      Provider's root endpoint.

   resourceUris
      A multi-valued string that contains the URIs of one or more
      affected resources in the event.  For each resource URI included,
      the event must be identical.

   type
      A single-valued string that contains the type of event as
      described in Section 3.1 or defined in the event extension
      registry in Section 8.2.

   attributes
      A multi-valued list of affected SCIM attributes.  Each attribute
      listed may be a fully-qualified attribute name or an attribute
      "path" as defined in Figure 7 of Section 3.3.2 of
      [I-D.ietf-scim-api]

   values
      A JSON object structure containing the affected attributes and
      their associated values.  If the "values" attribute is supplied,
      the event message MUST be encrypted.  Service providers SHOULD
      take care to ensure that eligible subscribers are able to see
      attribute values.  Alternatively, subscribers MAY use the
      resourceURIs to retrieve the final attribute values.  When doing
      so, the SCIM service provider can then assess the subscribers
      right to obtain the actual attribute values.

      For a password change event, the clear text password attribute
      value MAY be included in the values attribute.  "PASSWORD" event.

3.3.  Event Message

















Hunt, et al.            Expires September 9, 2015               [Page 9]


Internet-Draft           draft-hunt-scim-notify               March 2015


   An event message is a JSON structure consisting of the attributes
   described in the Event Metadata section above.  The following is a
   non-normative example event that has been modified for readability:

   {
     "schemas":["urn:ietf:params:scim:schemas:notify:2.0:Event"],
     "publisherUri":"https://scim.example.com",
     "feedUris":[
      "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
      "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
     ],
     "resourceUris":[
       "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9"
     ],
     "type":"CREATE",
     "attributes":["id","name","userName","password","emails"],
     "values":{
       "emails":[
        {"type":"work","value":"jdoe@example.com"}
       ],
       "password":"not4u2no",
       "userName":"jdoe",
       "id":"44f6142df96bd6ab61e7521d9",
       "name":{
         "givenName":"John",
         "familyName":"Doe"
       }
     }
   }

                     Figure 2: Example Event JSON Data

   When transmitted, the above JSON body must be converted into a JWT as
   per [I-D.ietf-oauth-json-web-token].  In this example, because the
   event contains attribute values, the token MUST be encrypted per JWE
   (see [I-D.ietf-jose-json-web-encryption]) before transmission.

   The following is an example of a SCIM Event expressed in an unsecured
   JWT token.  The JWT header of:

   {"alg":"none"}

   Base64url encoding of the octets of the UTF-8 representation of the
   header yields:

   eyJhbGciOiJub25lIn0





Hunt, et al.            Expires September 9, 2015              [Page 10]


Internet-Draft           draft-hunt-scim-notify               March 2015


   The example JSON Event Data is encoded as follows:

   eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
   kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
   FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
   WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
   WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
   hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
   VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
   SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
   b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
   tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
   1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ

   The encoded JWS signature is the empty string.  Concatenating the
   parts yields:

   eyJhbGciOiJub25lIn0
   .
   eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
   kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
   FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
   WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
   WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
   hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
   VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
   SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
   b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
   tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
   1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
   .

                  Figure 3: Example Unsecured Event Token

   To create and or validate a signed or encrypted event token follow
   the instructions in section 7 of [I-D.ietf-oauth-json-web-token].

4.  Discovery

4.1.  SCIM Server Resource Link Headers

   A SCIM Service Provider MAY provide resource link headers per
   [RFC5988] for the purpose of feed and endpoint discovery.  When
   querying a SCIM Service Provider, the following resource link headers
   are defined:

   rel=notifyHub




Hunt, et al.            Expires September 9, 2015              [Page 11]


Internet-Draft           draft-hunt-scim-notify               March 2015


      The URI provided is the base URI for a SCIM Notification Hub and
      its associated HTTP services.

   rel=oauth
      The URI provides is for an OAuth authorization endpoint that will
      authorize access to a SCIM feed.  When requesting authorization,
      clients should request an OAuth scope of "notifyHub".  This allows
      the client to register and request access to specific feeds.  [TBD
      is this needed?]

   rel=scimfeed
      The URI provided is for a SCIM Feed for the current resource.  The
      feed URI might be specific to the current resource, or for a
      larger set of resources (e.g. /Users).  There may be more than one
      feed for any particular resource or set of resources.

4.2.  Feeds Endpoint

   A service provider may publish a set of Feed resources that each
   describe an available feed at a "/Feeds" endpoint.  [TODO: Define the
   schema and resource type configuration for a feed based on SCIM Feed
   definitions in the next section]

5.  SCIM Feeds

   A SCIM Service Provider may define feeds based on a number of
   criteria.  This specification does not specify or limit the basis for
   which a service provider defines a feed or how feed URIs should be
   specified.  Some possible methods for defining feeds include:

   By Resource
      Each resource might have its own event notification feed.  For
      example, a User's mobile application may require notification of
      changes or rights defined in a SCIM User resource associated with
      the mobile user.

   By Endpoint
      A feed might be defined by an endpoint where any event relating to
      a resource within an endpoint is transmitted to subscriber.  This
      type of feed is likely to have many notifications as the number of
      resources in an endpoint grows (e.g. /Users).  Typically only
      privileged partners would be allowed to use this type of feed.
      For example an enterprise wishes to be notified of all events to
      any of its Users assuming all Users within the endpoint are
      related to the subscribing enterprise.

   By Filter




Hunt, et al.            Expires September 9, 2015              [Page 12]


Internet-Draft           draft-hunt-scim-notify               March 2015


      A feed might define a collection of resources based on a SCIM
      search filter.  Based on a set of matching criteria a resource may
      be included in a feed.  Note that this type of feed may require
      extra processing by the service provider to determine if any
      particular resource event matches the filter criteria.  It may
      also be difficult for the service provider to notify subscribers
      of Feed additions and deletions as these will occur dynamically
      based on the filter.

   By Group
      A designated SCIM Group could be used to define the resources
      within a particular feed.  [TODO define a FEED Group extensions
      that define the attributes and events included within a particular
      Feed Group]

5.1.  Feed Discovery

   [TBD] May be discovered by resource link headers, or by querying for
   SCIM Feed Groups [TBD].

6.  Notification Hub

   The notification hub is usually deployed as a separate but trusted
   server (in the same security domain) in relation to a SCIM Service
   Provider.  A single server MAY support both SCIM services and the API
   described in the notification hub.  The notification hub's API
   follows the SCIM API specification unless indicated otherwise.  The
   notification hub provides 2 core services:

   o  A set of publisher endpoints that allows SCIM Service Providers to
      define feeds and to post SCIM Events.

   o  A set of subscriber endpoints that allows subscription clients to
      subscribe to feeds and to receive events.

6.1.  Subscriber Services

   Subscribers MAY manage their subscriptions using the notification
   hub's "/Subscriptions" endpoint.  With the exception of the PATCH
   operation (which is not used), endpoints within the notification hub
   follow the same message format and API guidelines as per the SCIM API
   specification (see [I-D.ietf-scim-api]).  The subscriptions endpoint
   supports HTTP GET, POST, PUT, and DELETE to manage the full life
   cycle of a subscription.







Hunt, et al.            Expires September 9, 2015              [Page 13]


Internet-Draft           draft-hunt-scim-notify               March 2015


6.1.1.  Subscription Metadata

   The following attributes are used to define a feed subscription by a
   subscription client.

   feedUri
      A string value containing the URI for a feed supported by the
      notification hub.  REQUIRED.

   mode
      A REQUIRED single-valued string which is a URI with one of the
      following values:

         "urn:ietf:params:scimnotify:api:messages:2.0:webCallback" - The
         notification hub will pass SCIM Events using HTTP POST to the
         callback URI specified in the attribute "eventUri".

         "urn:ietf:params:scimnotify:api:messages:2.0:poll" - The
         subscriber will poll for SCIM Events using HTTP GET at the URI
         specified in the attribute "eventUri"

   eventUri
      When "mode" is set to
      "urn:ietf:params:scimnotify:api:messages:2.0:poll", "eventUri"
      specifies the endpoint where the subscriber will retrieve pending
      events.  When set to
      "urn:ietf:params:scimnotify:api:messages:2.0:webCallback", it
      contains the URI where the notification hub will POST events.

   feedJwk
      AN OPTIONAL JSON Web Key (see [I-D.ietf-jose-json-web-key]) that
      will be used to sign published events.  If present, the subscriber
      can authenticate events relayed from the notification hub.

   confidentialJwk
      The subscriber may provide a public JSON Web Key (see
      [I-D.ietf-jose-json-web-key]) that may be used by the notification
      hub to encrypt event messages for the subscriber.

   pollInterval
      The optional period in seconds between event polls when the
      subscriber plans to poll for events from the notification hub.
      The interval is used by the hub to determine if a subscriber is
      offline or has otherwise failed over a number of intervals.  The
      hub MAY then change the state of the feed and/or perform some out-
      of-band administrative alert.

   state



Hunt, et al.            Expires September 9, 2015              [Page 14]


Internet-Draft           draft-hunt-scim-notify               March 2015


      An optional value which indicates the current state of the feed
      which is:

         "on" - the default setting indicates the notification hub
         processing events and will pass them to the subscriber.

         "verify" - the subscription is pending verification.  While in
         "verify", published events SHALL NOT be stored or delivered to
         the subscriber.

         "paused" - indicates the notification hub is temporarily
         suspending delivery to subscriber.  While in "paused" events
         MAY be posted and will be delivered when state returns to "on".

         "off" - indicates that the subscription is no longer passing
         events.  While in off mode, the subscription is maintained, but
         new events are ignored and not processed.

         "fail" - Indicates that the notification hub was unable to
         deliver events to the subscriber for an extended period of
         time, or due to a call failure to the registered web call back
         URI.

6.1.2.  Request Subscription

   To request a subscription, a client performs a SCIM POST to the
   /Subscriptions endpoint with a HTTP Body consisting of a JSON object
   based on the attributes described in Section 6.1.1.  The request MUST
   include the "schemas" attribute with a value of:
   "urn:ietf:params:scim:schemas:notify:2.0:Subscription".





















Hunt, et al.            Expires September 9, 2015              [Page 15]


Internet-Draft           draft-hunt-scim-notify               March 2015


   The following is a non-normative example subscription creation
   request.

   POST /Subscriptions  HTTP/1.1
   Host: notify.example.com
   Accept: application/scim+json
   Content-Type: application/scim+json
   Authorization: Bearer h480djs93hd8
   Content-Length: ...

   {
     "schemas":
       ["urn:ietf:params:scim:schemas:notify:2.0:Subscription"],
     "feedUri":"https://example.com/v2/Feeds/548b7c3f77c8bab33a4fef40",
     "mode":"urn:ietf:params:scimnotify:api:messages:2.0:webCallback",
     "eventUri":"https://subscriber.com/Events",
     "state":"verify",
     "feedJwk":{
         "kty":"EC",
         "crv":"P-256",
         "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
         "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
         "kid":"Public key for Example.com SCIM Publisher"
        }
   }

              Figure 4: Example Subscription Creation Request
























Hunt, et al.            Expires September 9, 2015              [Page 16]


Internet-Draft           draft-hunt-scim-notify               March 2015


   In response to a successful subscription creation request, the server
   responds with HTTP Status 200 and a representation of the completed
   subscription.  The following is a non-normative example response that
   has been formatted for display purposes:

   HTTP/1.1 201 Created
   Content-Type: application/scim+json
   Location:
    https://example.com/v2/Subscriptions/548b7c3f77c8bab33a4fef40

   {
     "schemas":
       ["urn:ietf:params:scim:schemas:notify:2.0:Subscription"],
     "feedUri":"https://example.com/v2/Feeds/548b7c3f77c8bab33a4fef40",
     "mode":"urn:ietf:params:scimnotify:api:messages:2.0:webCallback",
     "eventUri":"https://subscriber.com/Events",
     "feedJwk":{
         "kty":"EC",
         "crv":"P-256",
         "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
         "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
         "kid":"Public key for Example.com SCIM Publisher"
        }
   }

   Upon receiving a successful subscription response, the subscribing
   client SHOULD check the subscription "state".  If set to "verify",
   the client needs to complete the subscription verification process in
   the following section.

6.1.3.  Subscription Verification

   In order to avoid ongoing communication issues and to minimize
   requirements for notification hubs to maintain events indefinitely, a
   verification process is used to confirm that the requested event
   distribution endpoints are correct and that an event may be
   successfully delivered.

   When using the WebCallback mode, or any other "push"-style
   communication scheme, the verification process also serves to verify
   that the identified endpoint consents to receiving events.  This
   prevents a notification server from flooding an endpoint which did
   not actually request an event subscription.

   To confirm a subscription, the notification hub SHALL POST (or
   otherwise send) an event to the endpoint identified by eventUri or as
   specified by the registered push extension.  The event contains the
   following attributes:



Hunt, et al.            Expires September 9, 2015              [Page 17]


Internet-Draft           draft-hunt-scim-notify               March 2015


   type  Set to the value of "CONFIRMATION"

   publisherUri  Set to the URI used to identify the notification hub.

   feedUris  MUST be set to a value that matches the subscription
      "feedUri" requested.

   confirmChallenge  A random String value that the subscriber SHALL
      echo back in its response.

   expires  A SCIM DateTime value that indicates the time the
      verification request will expire.  Once expired, the server will
      set the subscription state to "fail".

   If a confidential JWK was supplied, then the event SHOULD be
   encrypted with the provided key.  Successful parsing of the message
   confirms that both the endpoint is valid and the subscribers ability
   to parse the message.

   A non-normative JSON representation of an event to be sent to a
   subscriber as a subscription confirmation.  Note the event is not yet
   encoded as a JWT token.

   {
     "schemas":["urn:ietf:params:scim:schemas:notify:2.0:Event"],
     "publisherUri":"https://scim.example.com",
     "feedUris":[
      "https://notify.example.com/Feeds/98d52461fa5bbc879593b7754"

     ],
     "type":"CONFIRMATION",
     "confirmChallenge":"ca2179f4-8936-479a-a76d-5486e2baacd7",
     "expires":""

   }
















Hunt, et al.            Expires September 9, 2015              [Page 18]


Internet-Draft           draft-hunt-scim-notify               March 2015


   Upon receiving a subscription confirmation request, a consenting
   client responds with a confirmation that includes the original
   "confirmChallenge" value.  A non-normative example of the response
   is:

   HTTP/1.1 200 OK
   Content-Type: application/scim+json

   {
     "schemas":["urn:ietf:params:scim:schemas:notify:2.0:Confirm"],
     "challengeResponse":"ca2179f4-8936-479a-a76d-5486e2baacd7"
     }
   }

   As per the above figure, upon receiving and parsing a confirmation
   event, the subscriber MUST respond by returning a JSON structure that
   includes the attribute "challengeResponse" with a matching value to
   "confirmChallenge" that was sent in the event.  The response is not
   formatted as an event token but rather a JSON object with schemas set
   to "urn:ietf:params:scim:schemas:notify:2.0:Confirm".  If the
   subscriber returns a non-matching value or an HTTP status other than
   a 200 series response, the subscription "state" SHALL be set to
   "fail".  A declining subscriber MAY simply respond with any 400
   series HTTP error (e.g. 404).

6.1.4.  Cancel A Subscription

   To cancel a subscription, the subscriber MAY perform a SCIM DELETE
   against the resource URI for the subscription.  In the event the
   subscriber wants to temporarily suspend the subscription, it may
   modify the "state" attribute to a value of "off".

6.2.  Publisher Services

   With the exception of the PATCH operation (which is not used), the
   endpoints within the Notification Hub follow the same message format
   and API guidelines as per the SCIM API specification (see
   [I-D.ietf-scim-api]).  Feed Registration supports HTTP GET, POST,
   PUT, and DELETE to manage the full life cycle of a Feed.

6.2.1.  Feed Registration

   To register a feed, a SCIM Service Provider makes a call to the
   Notify Hub's registration endpoint ("<Notification_base>/Feeds") by
   performing an HTTP POST containing a JSON structure based on the
   parameters defined in the following section.  In response, the server
   will return a feed location and an optional public key which the
   publisher may use to encrypt posted events to the Notification Hub.



Hunt, et al.            Expires September 9, 2015              [Page 19]


Internet-Draft           draft-hunt-scim-notify               March 2015


   In the registration request, the "schemas" attribute MUST be included
   in the registration request and be set to:
   "urn:ietf:params:scim:schemas:notify:2.0:Feed".  The following is a
   non-normative example of a request to create a new SCIM Feed.  Note
   that additional spacing has been introduced for clarity.

   POST /Feeds  HTTP/1.1
   Host: notify.example.com
   Accept: application/scim+json
   Content-Type: application/scim+json
   Authorization: Bearer h480djs93hd8
   Content-Length: ...

   {
     "schemas":["urn:ietf:params:scim:schemas:notify:2.0:Feed"],
     "feedName":"bjensen",
     "feedDescription":"Feed for changes related to bjensen",
     "feedData":{
       "$ref":
         "https://example.com/v2/Users/453a-919d-413861904646"
     }
     "mode":"post",
     "publisherJwk":{
         "kty":"EC",
         "crv":"P-256",
         "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
         "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
         "kid":"Public key for Example.com SCIM Publisher"
        }
   }

                  Figure 5: Example Feed Creation Request

   In response to a successful registration request, the Notification
   Hub SHALL respond with the location of the created feed in the HTTP
   Location header, and the HTTP body SHALL contain a JSON structure
   with the accepted registration parameters and MAY include in its
   response, the following additional parameter:

   confidentialJwk
      In its response, the Notification Hub may provide a public JSON
      Web Key (see [I-D.ietf-jose-json-web-key]) that may be used by the
      client to encrypt event messages for the notification hub.  The
      key might be the notification hub's general public key, or it may
      be generated per registered feed.  Accordingly, registering SCIM
      Service Providers should assume that each key returned MAY be
      specific to the corresponding registered feed.




Hunt, et al.            Expires September 9, 2015              [Page 20]


Internet-Draft           draft-hunt-scim-notify               March 2015


   HTTP/1.1 201 Created
   Content-Type: application/scim+json
   Location:
    https://example.com/v2/Feeds/548b7c3f77c8bab33a4fef40
   ETag: 9d1c124149f522472e7a511c85b3a31b

   {
     "schemas":["urn:ietf:params:scim:schemas:notify:2.0:Feed"],
     "id":"548b7c3f77c8bab33a4fef40",
     "feedName":"bjensen",
     "feedDescription":"Feed for changes related to bjensen",
     "feedData":{
       "type":"resource",
       "$ref":
         "https://example.com/v2/Users/453a-919d-413861904646"
     }
     "mode":"post",
     "state":"on",
     "publisherJwk":{
         "kty":"EC",
         "crv":"P-256",
         "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
         "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
         "kid":"Public key for Example.com SCIM Publisher"
        }
     "confidentialJwk":{
        ...<feed public crypto key>...
     }
   }

                 Figure 6: Example Feed Creation Response

6.2.1.1.  Feed Request Parameters

   To create a feed, the following parameters are used by the SCIM
   Service Provider to register a feed:

   feedName
      A required string value containing a name for the feed.  May be
      used in administrative user interfaces to assist subscribers in
      feed selection.  The value MUST be unique within a given
      administrative domain.

   feedDescription
      An optional string value containing text that describes the
      content of the feed.  May be used in administrative user
      interfaces to assist subscribers in feed selection.




Hunt, et al.            Expires September 9, 2015              [Page 21]


Internet-Draft           draft-hunt-scim-notify               March 2015


   feedData
      A single-valued complex attribute which contains feed information.

      $ref  A SCIM Reference attribute that contains a URI as defined by
         "feedType".

   mode
      A single-valued string which is one of the following values:

         "post" - The publisher will pass SCIM Events using the HTTP
         POST option.

         "poll" - The notification hub will poll for SCIM Events using
         HTTP GET at the specified URI ("feedPollUri").

      The choice of "mode" is largely an internal decision based on the
      respective implementation architecture of the hub and its
      corresponding service providers that are publishing feeds.  For
      many service providers with high rates of change, it may be
      limiting to store events for pick-up by a hub or subscriber (who
      is "polling").  In many cases service providers will normally
      prefer to simply POST events as generated to the hub so that they
      do not have to worry about persistence, etc.  [TODO: is this a
      case for WebPUSH?]

   feedPollUri
      When "mode" is set to "poll", "feedPollUri" specifies the endpoint
      where the Notification hub will retrieve pending updates from the
      publishing SCIM Service Provider.

   publisherJwk
      The publishers optional JSON Web Key (see
      [I-D.ietf-jose-json-web-key]) that will be used to publish events.
      By registering a key, the Notification hub can authenticate events
      from SCIM Service Provider.

   pollInterval
      The optional period in seconds between event polls when the
      Notification Hub is set to poll for events from the SCIM Service
      Provider.

   state
      An optional value which indicates the current state of the feed
      which is:

         "on" - the default setting indicates the notification hub is
         receiving events and will forward them to current feed




Hunt, et al.            Expires September 9, 2015              [Page 22]


Internet-Draft           draft-hunt-scim-notify               March 2015


         subscribers.  If no subscribers exist or all subscribers have
         been notified, the events are deleted.

         "pending" - indicates the notification hub is temporarily
         suspending delivery to subscribers.  While in "pending" events
         may be posted and will be held for delivery by the hub until
         state returns to "on" (when events are subsequently delivered)
         or "fail".

         "off" - indicates an administrator or publisher has requested
         the feed to stop delivery.  While in off mode, the subscribers
         are maintained, but new events shall be ignored.

         "fail" - usually used in connection with "polling" feeds.
         Indicates that the notification hub has been unable to retrieve
         events from the service provider for an extended period of
         time, or due to a call failure to the registered polling call
         back URI.  [TODO: discuss whether a hub should continue to
         queue events in failed mode]

6.2.2.  Feed Definition Operations

   As with any SCIM resource, a notification Feed MAY be:

   o  Queried by using a SCIM HTTP GET request.  In particular,
      subscribers may perform a GET to the "/Feeds" endpoint to discover
      available feeds.

   o  Updated by using a SCIM PUT request.

   o  Deleted using a SCIM DELETE request.  Upon receiving a delete
      request, all corresponding notification subscriptions SHALL also
      be deleted.  For this reason, instead of deletion, setting feed
      status to "off" is recommended.

6.2.3.  Event POSTing

   To create an event, a SCIM Event Publisher, simply performs an HTTP
   POST "/Events" appended to the Feed location URI.  The body of the
   request includes a JSON object with the following attributes:

   schemas  A multi-valued string containing the value "

   A non-normative example is as follows:







Hunt, et al.            Expires September 9, 2015              [Page 23]


Internet-Draft           draft-hunt-scim-notify               March 2015


   POST /Feeds/548b7c3f77c8bab33a4fef40/Events  HTTP/1.1
   Host: notify.example.com
   Accept: application/scim+json
   Content-Type: application/scim+json
   Content-Length: ...

   {
   "schemas":["urn:ietf:params:scim:schemas:notify:2.0:Feed"]
   "eventToken":
     "eyJhbGciOiJub25lIn0
     .
     eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
     kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
     FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
     WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
     WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
     hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
     VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
     SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
     b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
     tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
     1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
     ."
   }

   In response, if the event token is validated, the server SHALL
   indicate successful submission by responding with:

   HTTP/1.1 204 No Content

   Since the normal operation of the notification hub is to forward
   events to registered subscribers, the Notification Hub is not
   obligated to inform the publisher of a permanent event URI that was
   created.  Servers MAY allow HTTP clients to check for undelivered
   events by performing a GET against the same endpoint as the Event
   submission endpoint described above.

   [TODO: Describe the error conditions and responses]

   A SCIM Event Publisher MAY publish an event of type "CONFIRMATION" to
   the provided publication endpoint to confirm successful
   configuration.  "CONFIRMATION" events SHALL NOT be passed on to
   subscribers.








Hunt, et al.            Expires September 9, 2015              [Page 24]


Internet-Draft           draft-hunt-scim-notify               March 2015


6.2.4.  Polling for Publisher Events

   When a publisher registers a feed with a "mode" of "poll", the
   notification hub SHALL confirm configuration by performing an HTTP
   GET to the "feedPollUri" provided by the publisher during
   registration of the feed.  On the first GET, the notification server
   should receive an event of type "CONFIRMATION".  The confirmation
   event should contain an event with the "resourceUris" attribute set
   to a value that corresponds to the URI of the feed registration.

   In its response to the notification polling for events by performing
   an HTTP Get to the "feedPollUri", the server shall construct a JSON
   message, with a schemas attribute consisting of the value:
   "urn:ietf:params:scim:api:messages:2.0:EventList" and a multivalued
   attribute of "eventTokens" containing one or more event tokens.  The
   following non-normative example has been modified for brevity and
   readability:

   HTTP/1.1 200 OK
   Content-Type: application/scim+json
   Location: https://example.com/FeedPoll/548b7c3f77c8bab33a4fef40
   {
   "schemas":["urn:ietf:params:scim:api:messages:2.0:EventList"],
   "eventTokens":[
     "eyJhbGciOiJub25lIn0
     .
     eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
     kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
     FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
     WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
     WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
     hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
     VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
     SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
     b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
     tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
     1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
     ."]
   }

6.3.  Event Delivery

   [TODO: Detail the event delivery extension point and define the
   following 3 methods]







Hunt, et al.            Expires September 9, 2015              [Page 25]


Internet-Draft           draft-hunt-scim-notify               March 2015


6.3.1.  Web Callback

6.3.2.  Polling

6.3.3.  Push Notification Extensions

7.  Security Considerations

   The synchronizing of User passwords between administrative domains is
   to be handled with great care.  From a security perspective the re-
   use of passwords across service providers is to be highly
   discouraged.  However, in the enterprise user experience, if the
   perception of the user is that service providers from multiple
   domains are part of a single corporate application environment, then
   password synchronization MAY be appropriate as part of an overall
   identity management and governance mechanism.

   [TO BE COMPLETED]

8.  IANA Considerations

8.1.  SCIM Event Notification Mechanism Registry

   TODO: Registration for Notification Mechanisms

8.2.  SCIM Event Type Registry

   TODO: Registration of Event Types

9.  References

9.1.  Normative References

   [I-D.ietf-oauth-json-web-token]
              Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", draft-ietf-oauth-json-web-token-32 (work in
              progress), December 2014.

   [I-D.ietf-scim-api]
              Hunt, P., Grizzle, K., Ansari, M., Wahlstroem, E., and C.
              Mortimore, "System for Cross-Domain Identity Management:
              Protocol", draft-ietf-scim-api-15 (work in progress),
              February 2015.








Hunt, et al.            Expires September 9, 2015              [Page 26]


Internet-Draft           draft-hunt-scim-notify               March 2015


   [I-D.ietf-scim-core-schema]
              Hunt, P., Grizzle, K., Wahlstroem, E., and C. Mortimore,
              "System for Cross-Domain Identity Management: Core
              Schema", draft-ietf-scim-core-schema-17 (work in
              progress), March 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988, October 2010.

9.2.  Informative References

   [I-D.ietf-jose-json-web-encryption]
              Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              draft-ietf-jose-json-web-encryption-40 (work in progress),
              January 2015.

   [I-D.ietf-jose-json-web-key]
              Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-
              key-41 (work in progress), January 2015.

   [I-D.ietf-jose-json-web-signature]
              Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", draft-ietf-jose-json-web-signature-41
              (work in progress), January 2015.

   [pubsubhubbub]
              Google, Inc, Google, Inc, Six Apart Ltd, and Notifixious
              Inc., "PubSubHubbub Core 0.4 -- Working Draft", .

Appendix A.  Contributors

Appendix B.  Acknowledgments

   The editor would like to thank the participants in the the SCIM
   working group for their support of this specification.

Appendix C.  Change Log

   Draft 00 - PH - First Draft






Hunt, et al.            Expires September 9, 2015              [Page 27]


Internet-Draft           draft-hunt-scim-notify               March 2015


Authors' Addresses

   Phil Hunt (editor)
   Oracle Corporation

   Email: phil.hunt@yahoo.com


   Morteza Ansari
   Cisco

   Email: morteza.ansari@cisco.com


   Ian Glazer
   Salesforce.com

   Email: iglazer@salesforce.com

































Hunt, et al.            Expires September 9, 2015              [Page 28]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/