draft-hunt-secevent-usecases-scim.xml

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-hunt-secevent-usecases-scim-00"
	ipr="trust200902">
	<front>
		<title abbrev="draft-hunt-secevent-usecases">
			SCIM Use Cases for SECEVENTS</title>

		<author fullname="Phil Hunt" initials="P." role="editor"
			surname="Hunt">
			<organization abbrev="Oracle">Oracle Corporation</organization>

			<address>
				<email>phil.hunt@yahoo.com</email>
			</address>
		</author>
    
    <author fullname="Morteza Ansari" initials="M." surname="Ansari">
      <organization abbrev="Cisco">Cisco</organization>

      <address>
        <email>moransar@cisco.com</email>
      </address>
    </author>

		<date year="2017" />

		<keyword>Internet-Draft</keyword>

		<abstract>
			<t>
				This specification defines the SCIM use cases for the SECEVENTs
        working group.
        </t>
		</abstract>
	</front>

	<middle>
		<section anchor="intro" title="Introduction and Overview" toc="default">
			
      <t>
      SCIM is a system intended for provisioning 
      identities (such as enterprise users or consumers) and other objects 
      across security domains to a cloud based service providers.
      SCIM defines an extensible JSON <xref target="RFC7643"/>
      document format and profiles HTTP protocol <xref target="RFC7644"/>.  
      In practice, SCIM service providers are applications supporting
      pre-provisioning support, or may be a service provider directory upon 
      which applications are integrated.
      </t>
      
      <t>This document defines the operational requirements SCIM deployers
      have for the use of triggers, as defined in the SCIM Use Cases 
      specification <xref target="RFC7642"/>, and used in the form of 
      security events and the requirements for management based on 
      SCIM architectural assumptions.</t>
 
 			<section anchor="notat" title="Notational Conventions" toc="default">
				<t>
					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
					<xref target="RFC2119" />
					. These keywords are capitalized when used to
					unambiguously specify requirements of the protocol or application
					features and behavior that affect the inter-operability and security of
					implementations. When these words are not capitalized, they are
					meant
					in their natural-language sense.
				</t>

				<t>
					For purposes of readability examples are not URL encoded.
					Implementers MUST percent encode URLs as described in
					<xref target="RFC3986">Section 2.1 of</xref>
					.
				</t>

				<t>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.
				</t>
			</section>

			<section anchor="defs" title="Definitions" toc="default">
        <t>This specification assumes terminology defined in the Security
        Event Token specification<xref target="I-D.ietf-secevent-token"/>
        .</t>
				
        <t>This specification assumes terminology defined in the SCIM
        specifications, specifically <xref target="RFC7643"/> and 
        <xref target="RFC7644"/></t>
        
        <t>This specification defines the following terms:<list style="hanging">
          <t hangText="Directory"><vspace/>Defined as any centralized 
          repository of security objects shared by multiple applications. 
          A SCIM Directory, though not formally defined is simply a 
          directory that supports SCIM protocol.</t>
        </list></t>
			</section>
		</section>
   
  <section title="SCIM Background">
           
      <t>The SCIM Core Schema specification <xref target="RFC7643"/> is 
      a profile of JSON <xref target="RFC7159"/> 
      that defines attribute types, mutability, data formats, 
      composites, and multi-value attributes as well as SCIM Service
      Provider feature and schema discovery metadata.
      As core schema defines standard resource types: Users and Groups 
      which are common to most service providers. Each resource type 
      establishes a common set of attribute definitions that can be  
      mapped to SAML <xref target="saml-core-2.0"/> and to OpenID Connect 
      <xref target="openid-connect-core"/> as well as application 
      specific attributes. The core schema specification provides an 
      extension mechanism which has been popular in:<list style="symbols">
       <t>Being extended to describe many security objects such as OAuth 
       Clients, Applications, IoT objects, among others.</t>
       <t>Enabling localized extensions to standard resource types (e.g. 
       Users) without compromising inter-operability of existing
       implementations.</t>
      </list>
      </t>
      
      <t>The SCIM Protocol specification <xref target="RFC7644"/> 
      describes a RESTful profile of HTTP <xref target="RFC7231"/> that
      defines create, read, update and delete life-cycle for 
      resources. The processing rules follow Jon Postel's 
      "Robustness Principle" (see 
      <xref target="RFC761">Section 2.10</xref>) which help avoid
      many of the failings of previous XML based approaches. In 
      particular the use of robust RESTful JSON helped ensure
      client and server ability to deal with inter-domain
      differences in schema, data, and implementation avoiding a lot
      of per implementation/deployment custom connector approaches.</t>
      
      <t>SCIM clients use HTTP
      requests to SCIM service providers as follows to:<list style="symbols">
        <t>Query for resources (users and groups) based on filters using 
        HTTP GET or confidentially using HTTP POST.</t>
        <t>Retrieve specific resources using HTTP GET.</t>
        <t>Create new resources using HTTP POST.</t>
        <t>Replace a resource using HTTP PUT.</t>
        <t>Update a resource using HTTP PATCH. And,</t>
        <t>Delete a resource using HTTP DELETE.</t>
      </list></t>

      <t>The SCIM Protocol defines capabilities 
      for:<list style="symbols">
        <t>Complex or composite attributes that contain multiple values
        and the need to select and update specific values. This includes 
        how to express sub-attributes and values in filters and the
        ability to change them as part of a resource.  An example of a 
        composite attribute in SCIM is: addresses (e.g. street name, 
        city, country). Note: In SECEVENTs a corresponding example 
        complex/composite attribute is an OpenID Connect user which is
        identified by both 'sub' and 'iss'.</t>
        <t>How to handle attributes that are immutable or read-only in 
        the context of operations like PUT. How to handle attributes 
        that are hashed or write-only and cannot be retrieved.</t>
        <t>Flexibility for web applications to take what they want without
        having traditional schema enforcement as with XML Schema.</t>
        <t>How to handle identifiers between clients and service providers
        and across domains.</t>
        <t>Referential stability of resources over time.</t>
      </list>
      </t>
      
      <t>Some other relevant information:<list style="symbols">
        <t>SCIM Polling Draft form Craig McMurtry <xref target="I-D.mcmurtry-scim-polling"/></t>
        <t>Early SCIM Events proposal <xref target="I-D.hunt-idevent-scim"/></t>
      </list>
      </t>  
      
   </section>

   <section title="High-Level Requirements">
   
   <section title="SCIM Event Trigger Requirements">
      <t>SCIM's need for Security Events arises from a requirement for triggers
      identified in the SCIM Use Case specification <xref target="RFC7642"/>.
      Clients and service providers that operate across
      security domains have independent resource management that causes
      co-ordination and governance challenges between domains. The use
      of triggers is intended to alert clients (e.g. enterprises) of 
      state changes within service providers that may
      be of interest to SCIM clients that may need to be co-ordinated or
      reconciled across domains.
      </t>
      
      <t>As a general example, a change to a resource that occurs within
      a cloud software as a service (SaaS) provider generates an Event 
      to be sent to a registered recipient via an Event Stream. Upon 
      receipt of the event, the receiver performs a SCIM GET to obtain 
      additional information and then decide if a local update or other
      action is required.</t>
      
   </section>
      
   <section title="SCIM Security Model Considerations">
        
        <t><list style="hanging">
        
          <t hangText="Authentication and Authorization"><vspace/>
          SCIM follows normal authentication and authorization 
          practices for HTTP (See <xref target="RFC7644">Sections 2 and 7</xref>). 
          In typical deployed cases, access to SCIM endpoints is managed 
          by OAuth authorization in both cross-domain provisioning, 
          delegated administration, and self-service applications. Many 
          integrators also support basic authentication, and TLS mutual 
          authentication.  SCIM is often accessed in a couple of ways:
          <list style="symbols">
            <t>End-user servers (e.g. as facilitated via a /Me endpoint) via 
            a self-service web application or Javascript client.</t>
            <t>Administrative - where an administrator identity has 
            access to groups of objects they are entitled to administer.  
            </t>
            <t>Server-to-server, where identity provisioning systems 
            implementing management workflows initiate commands across 
            domains using OAuth enabled authorization.</t>
          </list></t>
        
          <t hangText="PII Confidentiality"><vspace/>
          Querying using personally identifiable information (PII)  
          causes privacy concerns when using HTTP GET. In typical HTTP
          usage, since HTTP <xref target="RFC7231"/> does not allow for 
          query payloads on an HTTP GET, query parameters and filters 
          are typically passed as part of the URL. When queries contain 
          PII (most will in the case of RISC), there are security issues 
          (e.g. leakage via audit logs and browser histories) relating 
          to passing filter terms that contain PII in URLs. See 
          <xref target="RFC7642"/> Security Considerations, section 
          7.5.2. From the perspective of SECEVENTs, the SCIM community
          has the same PII requirement that the management of SECEVENT
          streams and delivery not pass PII in request URIs.</t>
          
          <t hangText="Scale, PII, and Multi-Valued Data"><vspace/>
          One of the concerns the SCIM working group had when developing 
          SCIM was the challenge that Groups (e.g. a group of users) 
          will tend to get very big at Internet scale. The bigger a 
          Group gets, the more expensive it is to enumerate. With a 
          high change rate it quickly become impractical to do a simple 
          PUT to replace an entire Group object due to the likely number 
          of independent update conflicts that would occur. To avoid this,
          implementers often:<list style="symbols">
            <t>Severely restrict when clients are actually authorized 
            to return large objects (million member groups).
            </t>
            <t>Set access policy to allow search filters that confirm 
            membership but avoid returning the members attribute (to 
            avoid enumeration of all values).</t>
            <t>Use HTTP PATCH (a derivative of JSON Patch) to remove or 
            add specific subjects without having to know the entire 
            contents (e.g. the group).</t>
          </list>
          </t>
        </list>
        </t>
      </section>
      
   <section title="Control Plane Assumptions">
      <t>In the original SCIM identity event proposals, "Control Plane" 
      functionality was accomplished by SCIM. SCIM protocol was proposed to 
      configure and provision "streams" that deliver events via other
      protocols or profiles. The SCIM proposal allowed Event Receivers 
      to check for delivery problems
      by retrieving Stream "resources" (which contain the stream
      configuration attributes) of which "status" is an attribute 
      that could be used to report operational state of a stream. 
      Updates to Stream resource enable Event Recipients to do things 
      like rotate credentials, or suspend streams. To initiate a
      verification to test a stream is functional, the Receiver or an authorized
      administrator can modify the Stream resource to "request" a verify 
      by changing the value of "status" to "verify". 
      In SCIM the subjects in a 
      stream can be identified by a number of methods:<list style="symbols">
        <t>Members of a Group</t>
        <t>The addition of a "streams" attribute to Users and other objects
        that may be part of a stream.</t>
        <t>An attribute or filter condition. E.g. the members of a Stream
        are defined by those Users with entitlements or roles containing
        a specific value (e.g. "entitlements" eq "CRM").</t>
      </list></t>
      
      <t>The SCIM WG in re-using SCIM as the control plane had assumed
      the following is already defined (and any alternative proposal would have
      to support):<list style="symbols">
        <t>Defined processing of attributes based on type, mutability, etc
        for each HTTP method. For example,
        the handling of omitted attributes in a PUT or POST operation. Is
        a value intended to be defaulted or set to null?</t>
        <t>Handling of extensibility semantics as defined in the SCIM
        specifications such as the definition of new resource types (objects) and addition of
        new attributes by other profiling specifications.</t>
        <t>The ability of a service provider to override or modify client
        provider asserted values.</t>
        <t>Identifier and resource URI stability and referential integrity.</t>
        <t>Querying of subjects using various standard identifiers such
        as "id", "emails", "telephoneNumbers", etc. The ability to express
        composite queries such as "sub" and "iss" in a query.</t>
        <t>Ability to add and remove subjects from a group while keeping
        enumeration of that group from the client. Ability to confirm
        membership in a group without enumeration (facilitated through
        support for write-only/compare-only schema or access control).
        </t>
        <t>Standardized error control, handling and processing rules. See
        <xref target="RFC7644">Section 3.12</xref> and <xref target="RFC7231"/>.</t>
      </list></t>
   </section>
   
   <section title="Network and Protocol Operational Considerations">
   <t>The SCIM WG discussed that transmission (now called 
   data-plane or stream) can have much simpler semantics and error 
   conditions and thus did not need to profile JSON beyond simple SET
   transfer (no need for attribute types, filters, etc). The SCIM WG
   also anticipated some varied requirements for delivery that include:<list style="symbols">
     <t>PUSH delivery via HTTP POST (the generally preferred ideal solution).</t>
     <t>POLLING (to enable delivery across firewalls) using HTTP GET.</t>
     <t>PUSH delivery via messaging systems like APNS, GMS, SMS, etc - 
     many of these had to do with provisioning and entitlement signals 
     for mobile applications (e.g. WebEx). For example user contacts
     synchronization where after a change to a user's contact list, an
     application can receive an Event notification through the mobile 
     platform's messaging solution as a trigger to fetch changes.</t>
   </list>
   </t>
   
   </section>
   
   <section title="Dynamic Filtering Considerations">
   <t>When defining filtered Streams, SCIM has to consider some special
   cases when the contents of a Stream is based upon a filter (query)
   to define which affected resources are included. For example,
   if the contents of a Stream is defined as Events related to resources
   where <spanx style="verb">emails.value sw "A"</spanx> and a resource
   is deleted, then the deleted resource won't match the filter anymore but
   notification may still need to be sent. </t>
   
   </section>
   
   <section title="Directory and Application Provisioning">
   <t>Network relationships for connections are typically:
   <list style="symbols">
     <t>Enterprise Directory to Cloud Directory. </t>
     <t>Cloud Directory to Cloud Directory.</t>
     <t>Enterprise or Cloud to Cloud Application (applications used by 
     many users).</t>
     <t>Enterprise or Cloud to Mobile Application (applications 
     running on a device controlled by a single user).</t>
   </list></t>
   
   <t>An enterprise directory is typically (but not always) legacy-LDAP.  
   In the cloud, a directory is simply any shared 
   centralized profile store (e.g. Google Dir, Azure Directory/OpenGraph, 
   SCIM Directory, etc). Important:  While for many organizations LDAP 
   remains the center of administrative control, it is important to 
   note that cloud directories and applications hold significantly more 
   PII than enterprise directories. This creates a challenge for 
   enterprise organizations to ensure proper governance and management
   of data given that a lot of cloud data is independently managed
   and updated. </t>
   
   <t>As with an enterprise directory, a cloud directory is often 
   shared by multiple applications. Cloud directories not only contain 
   entitlement information but now also contain CRM data, contact, 
   credentials, personalization and localization data, social network 
   data, etc (the list goes on). While some cloud providers centralize 
   others are tenancy structured with different directory endpoints per 
   tenancy (e.g. Oracle).</t>
   
   <t>As described above, because data, particularly PII, is being independently
   managed across multiple domains, there is a need to generate change 
   signals (events) from cloud based directories and applications back 
   to the enterprise. This was originally identified in the SCIM Use 
   Cases (see <xref target="RFC7642">Section 2.2.1</xref>).</t>
   </section>
   
   </section>   
   
   <section title="Use Cases">
   <t>The following use cases are expressed in terms of the direction of 
   flow of events.  In typical SCIM cases, there is only 1-way event 
   exchange. Typical usage of events is to act as a “trigger” 
   (see <xref target="RFC7642"/>) to let a receiver know that an event 
   has occurred in the transmitter's domain that may require action on 
   the part of the receiver.  Events can be simple resource changed 
   events, to higher level account status and change events (e.g.
   account or password reset). While many events are similar to OpenID RISC
   proposed events, a major distinction is that SCIM events are often
   triggered by user, administrative, or workflow provisioning action 
   rather than a risk analytical engine (e.g. that might detect suspicious
   activity).</t>
   
   <section anchor="scenario1" title="Scenario 1[P0]: Cloud-to-Enterprise PUSH and Cloud-to-Cloud PUSH">
   <t>Pre-conditions:<list>
     <t>The Event Receiver already has SCIM access to the Event 
     Transmitter service provider. This includes HTTP credentials
     and endpoint.</t>
     <t>Event Receivers and Transmitters can agree out-of-band on SET/JWT
     security requirements including use of signing and/or encryption
     to be documented in a Stream Configuration.</t>
   </list></t>
   
   <figure anchor="scimPush" title="SCIM Provisioining with PUSH Triggers">
   <artwork align="center">+----------------+--------+
|      SCIM      |  SCIM  |
|Service Provider| Events |
|                | Stream |
+--------^-------+--------+
     SCIM|          |Events via
 Commands|          |HTTP POST
         |          |
         |          |
         |          |
         |          |
       +-+----------v-+
       | SCIM Client  |
       | Provisioning |
       |  Controller  |
       +--------------+</artwork>
   </figure>
   
   <t>In <xref target="scimPush"/>, the SCIM client initiates RESTful
   SCIM commands to a SCIM service provider. In addition to provisioning
   security objects such as Users and Groups, the client also uses 
   SCIM to provision Event Streams in order to receive Events to an
   endpoint the provisioning controller requests.  The service provider
   MUST be able to POST to the client's domain. Usually this means the 
   client is able to have a public HTTP endpoint available to receive 
   SET events.</t>
   
   <t>Stream Creation Flow:</t>
   <figure anchor="pushStreamPost" title="Stream Creation Operation">
   <preamble>To create a Stream, the Event Receiver (or an administrator)
   uses their SCIM access credential to access the SCIM endpoint and creates
   a Stream resource configuration:</preamble>
   <artwork>POST /Streams
Host: scim.bighost.com
Authorization: Bearer h480djs93hd8 
{ "receiverId":"&lt;client-id>",
  "method":"webCallBack", 
  "receiverUri":"https://set.example.com/events/", 
  "aud":"&lt;client-id>", 
  "type":"SCIM", 
  "receiverJwkUri":"&lt;receiver's public key url>", 
  "authorization":"&lt;btoken|BasicAuth>"
}</artwork>
   </figure>
   
   <t>Note: If the Transmitter does not have an HTTP credential to 
   send events, the receiver should include one in its registration POST 
   request or negotiate one out-of-band.</t>
   
   <t>In the stream configuration there is likely a definition as to 
   what types of events (event families) and which subjects constitute 
   the feed.  In SCIM this will likely be a group of objects, or filter 
   condition such as “roles” eq ”CRM_Users”.  This is likely based on 
   the relationship between parties that determines which entities are 
   provisioned between domains.</t>
   
   <figure anchor="pushStreamResponse" title="Stream Creation Response">
   <preamble>Upon successful creation of the Stream, the SCIM Event
   Transmitter Responds with:</preamble>
   <artwork>HTTP/1.1 201 Created
Location: https://events.bighost.com/Streams/2819c223-7f76-453a
{ "receiverId":"&lt;client-id>",
  "method":"webCallBack", 
  "receiverUri":"https://set.example.com/events/", 
  "aud":"&lt;client-id>", 
  "type":"SCIM", 
  "receiverJwkUri":"&lt;receiver's public key url>", 
  "authorization":"&lt;btoken|BasicAuth>”,
  ”status”:”on"
}</artwork>
<postamble>Note that in the above figure, the Location URI is the 
fixed reference to the Stream for as long as it exists. Administrative 
users and Event Receiver
entities MAY use the location to check status or update configuration 
as needed.</postamble>
   </figure>
   
   <t>[[TBD, the event receiver, needs to issue the event transmitter
   a credential in order for it to issue HTTP POSTs to the Event 
   Receivers callback endpoint. In some cases there may be an existing
   OpenID Connect relationship but in most cases this not expected -
   especially in directory-to-directory synchronization scenarios.]]</t>
   
   <t>Stream Verification:<vspace blankLines="1"/>During the initial stream 
   creation request and at any point the transmitter deems appropriate 
   (e.g. as a ping), the transmitter verifies configuration by sending 
   a verification event to the receiver that demonstrates the receiver:
   <list style="symbols">
     <t>is willing accept the event, and</t>
     <t>is able to parse the event - especially if encrypted.</t>
   </list>
   </t>
   
   <t>Conversely an Event Receiver should be able to initiate a verification
   request and may provide a confirmation challenge and nonce to verify
   the relationship from the Event Receiver's perspective.</t>
   
   <t>Delivery:<vspace blankLines="1"/>Delivery is accomplished by doing 
   a simple HTTP POST to the registered endpoint of the receiver. The 
   payload of the POST is application/jwt and contains a single JWT 
   (which is actually a SET).</t>
   
   <t>Before responding with a 2xx success message, the receiver should 
   ensure it was able to read and validate the SET. If the transmitter 
   receives a 2xx response, the transmitter may assume the event was 
   successfully delivered.</t>
   
   <t>A set of Status 400 error conditions are defined which the 
   receiver can use to indicate various JWT validation conditions.</t>
   
   </section>
   
   <section title="Scenario 2[P0]: Cloud-to-Enterprise POLLING">
   <t>Pre-conditions:<list>
     <t>The Event Receiver already has SCIM access to the Event 
     Transmitter service provider. This includes HTTP credentials
     and endpoint.</t>
     <t>Event Receivers and Transmitters can agree out-of-band on SET/JWT
     security requirements including use of signing and/or encryption
     to be documented in a Stream Configuration.</t>
     <t>The Event Receiver is unable to open an endpoint to receive
     SETs inside the firewall.</t>
   </list></t>
   <figure anchor="scimPolling" title="Event Delivery with Firewall">
   <artwork align="center">     +----------------+--------+
     |      SCIM      |  SCIM  |
     |Service Provider| Events |
     |                |        |
     +--------^-------+--^-----+
          SCIM|          |Events via
      Commands|          |HTTP GET Long Poll
              |          |&amp; POST Acks
 Firewall     |          |
+---------------------------------------+
              |          |
            +-+----------+-+
            | SCIM Client  |
            | Provisioning |
            |  Controller  |
            +--------------+

   </artwork>
   </figure>
   
   <t>In <xref target="scimPolling"/>, the SCIM client initiates RESTful
   SCIM commands to a SCIM service provider. In addition to provisioning
   security objects such as Users and Groups, the client also uses 
   SCIM to provision Event Streams in order to receive Events to an
   endpoint the provisioning controller requests. In this case, the 
   SCIM Client "polls" for events using HTTP GET.  The client MAY 
   request immediate response based on a timed schedule, or the client
   MAY use HTTP Long Polling to wait for SETs as they become available.</t>
   
   <t>Stream Creation Flow:<vspace blankLines="1"/>The Event Receiver
   uses their SCIM credential to access the SCIM service provider endpoint
   to create a Stream resource by performing a POST</t>
   
   <figure anchor="pollPostRequest" title="Create Polling Stream">
   <artwork>POST /Streams
Host: scim.bighost.com
Authorization: Bearer h480djs93hd8 
{ "receiverId":"&lt;client-id>",
  "method”:"POLLING”, 
  "aud":"&lt;client-id>", 
  "type":"SCIM",
  "receiverJwkUri":"&lt;receiver's public key url>"
}</artwork>
   </figure>
   
   <t>It is assumed, but may not always be true. that the POLLING 
   receiver can simply use their SCIM credential to perform HTTP GETs 
   to the polling endpoint. Additional parameters will likely need to 
   be defined to control polling rate, number of events in a message, 
   etc.</t>
   
   <t>Note, in the stream configuration there is likely a definition as 
   to what types of events (event families) and which subjects 
   constitute the feed.  In SCIM this will likely be a group of objects, 
   or filter condition such as “roles” eq ”CRM_Users”.  This is likely 
   based on the relationship between parties that determines which 
   entities are provisioned between domains.</t>
   
   <figure anchor="pollPostResponse" title="Polling Stream Creation Response">
   <preamble>Upon successful creation of the stream, the 
   transmitter responds to the receiver with:</preamble>
   <artwork>HTTP/1.1 201 Created
Location: https://events.bighost.com/Streams/2819c223-7f76-453a
{ "receiverId":"&lt;client-id>",
  "method”:"POLLING", 
  "receiverUri":"https://set.bighost.com/Events/2819c223-7f76-453a", 
  "aud":"&lt;client-id>", 
  "type":"SCIM", 
  "receiverJwkUri":"&lt;receiver's public key url>”,
  ”status”:”on"
}</artwork>
   </figure>
   
   <t>In the above response, the transmitter indicates to 
   the receiver where to poll for events by setting a value for 
   “receiverUri”. This endpoint does not need to be SCIM compliant and 
   can be a generic (e.g. shared by all polliers) endpoint such as 
   <spanx style="verb">https://events.bighost.com</spanx>.</t>
   
   <t>Stream Verification:<vspace blankLines="1"/>
   Same requirements are for Scenario 1 (see <xref target="scenario1"/>).</t>
   
   <t>Delivery:<vspace blankLines="1"/>
   Delivery is accomplished by having the Event Receiver initiate an HTTP
   request that causes a response such as:
   </t>
   
   <figure anchor="examplePollPayload" title="Example Polling Response">
   <artwork>{
 "sets":{
 "4d3559ec67504aaba65d40b0363faad8":
   "eyJhbGciOiJub25lIn0
   .
   e3sgIAogICJqdGkiOiAiNGQzNTU5ZWM2NzUwNGFhYmE2NWQ0MGIwMzYzZmFhZDgiLAog
   ICJpYXQiOiAxNDU4NDk2NDA0LAogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUu
   Y29tIiwgIAogICJhdWQiOiBbCiAgICJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vRmVl
   ZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsCiAgICJodHRwczovL3NjaW0uZXhh
   bXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIKICBdLCAgCiAg
   CiAgImV2ZW50cyI6IHsKICAgICJ1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpjcmVh
   dGUiOiB7CiAgICAgICJyZWYiOgogICAgICAgICJodHRwczovL3NjaW0uZXhhbXBsZS5j
   b20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsCiAgICAgICJhdHRyaWJ1
   dGVzIjpbImlkIiwgIm5hbWUiLCAidXNlck5hbWUiLCAicGFzc3dvcmQiLCAiZW1haWxz
   Il0KICAgIH0KICB9Cn0",
  "&lt;nextJti>":"&lt;nextJwt>"
 },
 "since":1458496025
}</artwork></figure>

   <t>In the above JSON object is a JSON attribute “sets” whose value is 
   a JSON object that contains a set of JSON attributes that correspond 
   to each event’s JTI value. the value for each attribute is the actual 
   encoded SET.</t>
   
   <t>In addition to the “sets” attribute, a “since” attribute indicates 
   the timestamp of either the last event previously transmitted or 
   potentially oldest event in the current payload (To be discussed).</t>
   
   <t>In order to acknowledge receipt, the receiver must successfully 
   parse each message and respond by doing an HTTP POST back to the 
   events endpoint using something along the lines of the following 
   JSON structure:</t>
   
   <figure anchor="pollAckResponse" title="Poll Acknowledgement Response">
   <artwork>{
  "ack":[
    “39e48e70e9f84d90b5fdbf2fbd826219”,
    “8e1ed13b871547ffa332f7027a0fdd91”,
    “0a02c62529e34541a8b3c5c7941fa545”
  ]
  "setErrs":{
    "3d0c3cf797584bd193bd0fb1bd4e7d30":{
      "err":"dup",
      "description":"SET already received. Ignored."
    }
  }
}</artwork></figure>
   
   <t>In the payload above the receiver indicates which SET event JTIs 
   have been accepted, and which SETs had errors using “accepts” and 
   “setErrs”.</t>
   
   <t>It is expected that because most errors are due to JWT crypto 
   configuration errors, that most responses will tend to be all errors 
   or all accepts.</t>
   
   <t>If a transmitter receives what it deems an unrecoverable error, 
   or a receiver fails to poll for events, the transmitter can set the 
   stream state to “failed” with an appropriate error indicator.</t>
   </section>
   
   <section title="Scenario 3[P2]: Cloud-to-Mobile Application PUSH">
   
   <t>This scenario is a hybrid of scenario 1 and 2. The scenario uses 
   mobile message delivery services (APNS, GMS, SMS) to deliver events.  
   Typically a stream has only one subject in its feed. The events are 
   used to notify client applications about changes to entitlements, or 
   other configuration (e.g. new tenancy endpoints)that might be useful 
   to user experience. 
   </t>
   
   <t>As in the polling method in Scenario 2, to acknowledge events, 
   the mobile app will need to use the POST (as defined in Scenario 2) 
   to acknowledge SET delivery.  To be discussed, this might not be 
   necessary if assured delivery is not required.</t>
   
   </section>
   </section>
   
   <section anchor="Security" title="Security Considerations" toc="default">
      
   <t>None as this is a use case document to describe considerations.</t>
      
   </section>
   
   <section title="Privacy Considerations">
   
   <t>None as this is a use case document to describe considerations.</t>

   </section>

   <section anchor="IANA" title="IANA Considerations">
      
   <t>There are no IANA considerations.</t>
  
   </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' ?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml' ?>
         

    </references>

    <references title="Informative References">
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-secevent-token-00.xml'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mcmurtry-scim-polling.xml'?>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hunt-idevent-scim.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7159.xml' ?><!-- JSON -->
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7231.xml' ?><!-- HTTP -->
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7644.xml' ?><!-- SCIM API -->
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7643.xml' ?><!-- SCIM Schema -->
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7642.xml' ?><!-- SCIM Use Cases -->

      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml' ?>
    
      <reference anchor="RFC761">
        <front>
          <title>TRANSMISSION CONTROL PROTOCOL</title>
          <author fullname="Jon Postel" role="editor"><organization>USC</organization></author>
          <date month="January" year="1980"/>
        </front>
        <format type="TXT" target="https://www.rfc-editor.org/rfc/rfc761.txt"/>
      </reference>

      <reference anchor="openid-connect-core">
        <front>
          <title>OpenID Connect Core 1.0</title>
          <author fullname="Nat Sakimura et al"><organization>NRI</organization></author>
          <date day="8" month="Nov" year="2014"/>
        </front>
        <format type="HTML" target="http://openid.net/specs/openid-connect-core-1_0.html"/>
      </reference>
      <reference anchor="saml-core-2.0">
        <front>
          <title>Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0</title>
          <author fullname="Scott Cantor et al"><organization>Internet2</organization></author>
          <date day="15" month="March" year="2005"/>
        </front>
        <format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf"/>
      </reference>
      <reference anchor="idevent-scim">
        <front>
          <title>SCIM Event Extensions (work in progress)</title>
          <author fullname="Phil Hunt"><organization>Oracle Corporation</organization></author>
          <date/>
        </front>  
        <format type="TXT" target="draft-hunt-idevent-scim-00.txt"/>    
      </reference>

     
    </references>

    

    <section title="Acknowledgments">
      <t>The editors would like to thanks the members of the SCIM WG which 
      began discussions of provisioning events starting with: draft-hunt-scim-notify-00 in 2015.</t>
      
      <t>The editor would like to thank the participants in the the SECEVENTS
      working group for their support of this specification.</t>
    </section>

    <section title="Change Log">
      <t>Draft 00 - PH - Initial draft</t>
    </section>
  </back>
</rfc>