draft-hunt-idevent-token-00.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-idevent-token-01" ipr="trust200902">
  <front>
    <title abbrev="draft-hunt-idevent-token">Identity Event Token</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="William Denniss" initials="W." surname="Denniss">
      <organization abbrev="Google">Salesforce.com</organization>

      <address>
        <email>wdenniss@google.com</email>
      </address>
    </author>
    

    <author fullname="Morteza Ansari" initials="M.A." surname="Ansari">
      <organization abbrev="Cisco">Cisco</organization>

      <address>
        <email>morteza.ansari@cisco.com</email>
      </address>
    </author>

    
    <date year="2016"/>
    <keyword>Identity</keyword>
    <keyword>Event</keyword>
    <keyword>Token</keyword>
    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>This specification defines an Identity Event token which may
      be distributed via a protocol such as HTTP. An identity event token 
      is based on the JSON Web Token and may be optionally signed and/or encrypted. It 
      describes a statement of fact that may be shared by an event publisher
      with registered subscribers.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction and Overview" toc="default">
      <t>This specification defines an extensible event token format which may
      be exchanged using protocols such as HTTP. The specification builds
      on the JSON Web Token format <xref target="RFC7519"/> in order to provide a self-contained 
      message "token" that can be optionally signed using JSON Web Signature <xref target="RFC7515"/>
      and/or encrypted using JSON Web Encryption <xref target="RFC7516"/>.</t>
      
      <t>For the purpose of this specification an "event" is a statement
      of fact by a publisher (also known as an issuer) that the state of 
      a resource it controls has changed in some way (explicitly or 
      implicitly). Based on some agreed upon criteria for an event feed, 
      the publisher distributes the event to the appropriate subscribers.</t>
      
      <t>[[Background: to be removed from final specification]]At the time 
      of writing of this specifications there are several discussions regarding the need 
      for identity events. Some of these include:<list style="symbols">
        <t>Events to allow SCIM resource co-ordination between SCIM domains.</t>
        <t>OAuth Token Revocation (see <xref target="RFC7009"/>)</t>
        <t>OpenID Logout or downstream logout notification.</t>
        <t>Session Cancellation</t>
        <t>OpenID Risk Incident Sharing and Coordination (RISC) Events. See <xref target="RISC"/></t>
        <t>The HEART WG <xref target="HEART"/> which intends to define privacy and security related events
        in health-related data sharing APIs.</t>
      </list>This specification uses example SCIM events which are intended
      to be non-normative for the purpose of showing how an event may be 
      used in practice.</t>
      
      <t>A resource state change event typically includes explicit operation events such as:
      a resource has been created, modified, removed, or updated in some way.</t>
      
      <t>In addition to explicit operations there may be higher-level statements 
      made that describe an effect resulting from a change. For example, a
      publisher may wish to indicate that a user resource has taken over an email
      identifier that may have been used in the past. This cumulative event 
      is a high-level statement that takes into account that another resource 
      had a personal identifier that potentially conflicts with a newer resource.
      Because of the security impact, the publisher wishes to
      notify its subscribers of the identifier re-use. In this way, the event
      is not describing a particular state change to a resource, it describes
      a meta-conclusion based on its own business and security rules (this
      scenario is often called an 'account takeover' event).</t>
      
      <t>A subscriber having received an event, validates and interprets the
      event and takes its own independent action, if any. For example, 
      having been informed of a personal identifier now being associated 
      with a different resource (i.e. is being used by someone-else), the 
      subscriber may choose to ensure that the new user is not granted 
      access to resources associated with the previous user.</t>
      
      <t>Events SHOULD NOT be used to convey commands or requests. To do so
      requires complex bidirectional signalling and error recovery mechanisms which fall
      outside the scope of this specification. The intent of this specification
      is to define a way of exchanging historical statements of fact that 
      subscribers may interpret for their own use.</t>
      
      <t>This specification is scoped to security and identity related events.
      While event tokens may be used for other purposes, the specification
      only considers security and privacy concerns relevant to identity 
      and personal information.</t>
      
      <t>This specification may be optionally used with the identity
      event subscription management specification which provides the details 
      of event feeds and how subscribers register for events(see 
      <xref target="idevent-subscription"/>), defines a protocol registry for
      event transmission methods including transmission using HTTP.</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 interoperability 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>
          The following definitions are used with Identity Events:
          <list style="hanging">
            <t hangText="Feed Publisher"><vspace blankLines="0"/>The Feed Provider publishes
              events to be distributed to registered subscribers. In JWT
              terminology, the Feed Publisher is also known as the issuer
              <spanx style="verb">iss</spanx>).
            </t>

            <t hangText="Event"><vspace blankLines="0"/>An event is a resource change statement that is to be
              distributed to one or more registered subscribers. An event is
              constructed as a JWT token and MAY be signed or encrypted using
              JWS/JWE for authentication and confidentiality reasons.
            </t>

            <t hangText="Feed"><vspace blankLines="0"/>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 Feed Provider to subscribe
              to events associated with a feed. When expressed in a JWT token,
              a feed is defined as the event's audience (<spanx style="verb">aud</spanx>).
            </t>
            <t hangText="Subscriber"><vspace blankLines="0"/>A Subscriber registers to receive event
              notifications from a Feed Provider using a protocol such as
              HTTP.
            </t>
          </list>
        </t>
      </section>
    </section>

    <section anchor="events" title="Events">
      <t>An identity event conveys a message (in the form of a JWT token <xref target="RFC7519"/>) about 
      a resource (i.e. a security subject) that may be of interest to a 
      subscriber or set of subscribers participating in an event feed 
      (see <xref target="idevent-subscription"/>).</t>
      
      <t>In addition to the JWT attributes <spanx style="verb">iss</spanx> and 
      <spanx style="verb">aud</spanx>, an event message contains the attribute 
      <spanx style="verb">events</spanx> with at least one value. 
      The event URI values indicate what event information (attributes) 
      and what type of event (e.g. resource modified) is contained in the 
      event message. The definition of registered events are found in the 
      event registry (see <xref target="registry"/>), and implementers are free to
      define their own event types.</t>

      <t>The schema and structure of an event follows the JWT <xref target="RFC7519"/>. 
      An event JWT has the following characteristics:<list style="symbols">
        <t>a common set of attributes common to every event, and</t>
        <t>one or more event extensions  
        that each contain a set of attributes that belonging to an extension.</t>
      </list> </t>
      <figure anchor="examplePassword" title="Example SCIM Password Reset Event">
        <preamble>The following is a non-normative example showing a password change event
        that conveys a SCIM event (see <xref target="idevent-scim"/>):</preamble>
        <artwork>{ 
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "events":[
    "urn:ietf:params:event:SCIM:password",
    "https://example.com/event/password"
  ],
  "iat": 1458496025,
  "iss": "https://scim.example.com",  
  "aud":[
    "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
    "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
  ],  
  "sub": 
    "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
  "urn:ietf:params:event:SCIM:password":{
    "id":"44f6142df96bd6ab61e7521d9",
  },
  "https://example.com/scim/event/password":{
     "resetAttempts":5
  }
}</artwork>
      </figure>      
      <t>The event in the figure above expresses hypothetical password
      reset event for SCIM. The JWT consists of an <spanx style="verb">iss</spanx>
      attribute which denotes the event publisher. The <spanx style="verb">aud</spanx>
      attribute specifies the intended audience for the event. In practical 
      terms this MAY be the the URI for the event feed that a client has 
      subscribed to.</t>
      
      <t>Additional extensions to an event may be added by adding more values
      to the <spanx style="verb">events</spanx> attribute. For each event URI
      value specified, there is a corresponding attribute that has its on JSON
      object that contains the attributes associated with that event (e.g. 
      <spanx style="verb">https://example.com/scim/event/password</spanx>).
      In this example, the SCIM event indicates that a password has been updated 
      and the current password reset count is 5. Notice that the value for 
      "resetAttempts" is actually part of its own JSON object 
      <spanx style="verb">https://example.com/scim/event/password</spanx>.  
      </t>

              <t><figure anchor="exampleBackLogoutEvent" title="Example OpenID Logout Event">
            <preamble>Here is another example event message, this one
              for a Back-Channel Logout Token:</preamble>

            <artwork>{
  "iss": "https://server.example.com",
  "aud": "s6BhdRkqt3",
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "sub": "248289761001",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": [
    "https://specs.openid.net/logout"
  ],
  "https://specs.openid.net/logout": {
    "sid": "08a5019c-17e1-4977-8f42-65a12843ea02"
  }
}</artwork>
          </figure></t>
      
      <section title="Core Event Attributes">
        <t>The following are attributes that are based on <xref target="RFC7519"/>
        claim definitions and are profiled for use in an event
        message:<list style="hanging">
            <t hangText="jti"><vspace blankLines="0"/>As defined by 
            <xref target="RFC7519">Section 4.1.7</xref> contains a unique
            identifier for an event. The identifier SHOULD be unique within
            a particular event feed and MAY be used by clients to track
            whether a particular event has already been received. This 
            attribute is REQUIRED. [[Do we need a way to detect order of
            or missing events? Or should this be provided by the 
            subscription spec?]]</t>
        
            <t hangText="iss"><vspace blankLines="0"/>A single valued
            String containing the URI of the service provider publishing
            the event (the issuer). For example, in SCIM, this is the 
            SCIM Service Provider's root endpoint. This attribute is REQUIRED.</t>

            <t hangText="aud"><vspace blankLines="0"/>A multi-valued String containing the URIs
            representing the audience of the event. Values are typically URLs of
            the feeds the event is associated with. When an event has
            multiple audiences that go to the same subscriber, the publisher is not
            obligated to deliver repeated events to the same subscriber.
            This attribute is RECOMMENDED.</t>

            <t hangText="iss"><vspace blankLines="0"/>A single valued
            String containing the URI of the service provider publishing
            the event (the issuer). For example, in SCIM <xref target="RFC7644"/>, this is the 
            SCIM Service Provider's root endpoint. This attribute is REQUIRED.</t>

            <t hangText="sub"><vspace blankLines="0"/>A value that identifies
            the subject of the event. This SHOULD be the URI of the affected
            resource. Some example resources include: users, tokens, grants,
            sessions, and any addressable resource about which a change in
            state may be described. This attribute is REQUIRED.</t>
            
            <t hangText="iat"><vspace blankLines="0"/>As defined by <xref target="RFC7519">Section 4.1.6</xref>,
            a value containing a NumericDate which represents when the 
            event was issued. Unless otherwise specified,
            the value SHOULD be interpreted by the subscriber as equivalent 
            to the actual time of the event. This attribute is REQUIRED. 
            [[DISCUSS: DO WE NEED TO DIFFERENTIATE?]]</t> 
            
            <t hangText="nbf"><vspace blankLines="0"/>As defined by 
            <xref target="RFC7519">Section 4.1.5</xref>, a value 
            containing a NumericDate which represents a future date when
            the event will occur. This attribute is OPTIONAL.</t>           
          </list>
        </t>
        <t>The following are new attributes defined by this specification:<list style="hanging">
            <t hangText="events"><vspace blankLines="0"/>A multi-valued String 
            that contains the URIs of events contained within the JWT. Values
            in this attribute further indicate what other JSON objects are present
            within the parent JSON event structure. Each OPTIONAL JSON sub-object is
            denoted by an attribute that matches a value in 
            <spanx style="verb">events</spanx>.  This attribute is REQUIRED.</t>
        </list></t>
      </section>

      <section anchor="eventMessage" title="Event Token Construction">
        <t>An Event Token is a JWT <xref target="RFC7519"/> that is 
        constructed by building a JSON structure that constitutes an event 
        object and which is then used as the body of a JWT.</t>
        <t>While this specification uses JWT to convey an event message, implementers
        SHALL NOT use these events to convey authentication or authorization assertions.</t>

        <t><figure anchor="exampleJsonEvent" title="Example Event JSON Data">
            <preamble>The
            following is an example event message(it has been modified
            for readability):</preamble>

            <artwork>{  
  "jti": "4d3559ec67504aaba65d40b0363faad8",
  "iat": 1458496404,
  "iss": "https://scim.example.com",  
  "aud":[
   "https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
   "https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
  ],  
  "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
  "events":[
    "urn:ietf:params:event:SCIM:create"
  ],
  "urn:ietf:params:event:SCIM: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"
      }
    }  
  }
}</artwork>
          </figure></t>

        <t>When transmitted, the above JSON body must be converted into a JWT
        as per <xref target="RFC7519"/>. In this
        example, because the event contains attribute values, the token MUST
        be encrypted per JWE (see <xref
        target="RFC7516"/>) before transmission.</t>
     
        <t><figure>
            <preamble>The following is an example of a SCIM Event expressed in
            an unsecured JWT token. The JWT header of:</preamble>

            <artwork>{"alg":"none"}</artwork>
          </figure><figure>
            <preamble>Base64url encoding of the octets of the UTF-8
            representation of the header yields:</preamble>

            <artwork>eyJhbGciOiJub25lIn0</artwork>
          </figure><figure>
            <preamble>The example JSON Event Data is encoded as
            follows:</preamble>

            <artwork>
eyAgCiAgImp0aSI6ICI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIs
CiAgImV2ZW50VXJpcyI6WwogICAgInVybjppZXRmOnBhcmFtczpldmVudDpTQ0lN
OmNyZWF0ZSIKICBdLAogICJpYXQiOiAxNDU4NDk2NDA0LAogICJpc3MiOiAiaHR0
cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwgIAogICJhdWQiOlsKICAgImh0dHBzOi8v
c2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0
IiwKICAgImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZi
MWQwODY0MWQ3Njc2ZWU3IgogIF0sICAKICAic3ViIjogImh0dHBzOi8vc2NpbS5l
eGFtcGxlLmNvbS9Vc2Vycy80NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5IiwKICAi
dXJuOmlldGY6cGFyYW1zOmV2ZW50OlNDSU06Y3JlYXRlIjp7CiAgICAiYXR0cmli
dXRlcyI6WyJpZCIsIm5hbWUiLCJ1c2VyTmFtZSIsInBhc3N3b3JkIiwiZW1haWxz
Il0sCiAgICAidmFsdWVzIjp7CiAgICAgICJlbWFpbHMiOlsKICAgICAgIHsidHlw
ZSI6IndvcmsiLCJ2YWx1ZSI6Impkb2VAZXhhbXBsZS5jb20ifQogICAgICBdLAog
ICAgICAicGFzc3dvcmQiOiJub3Q0dTJubyIsCiAgICAgICJ1c2VyTmFtZSI6Impk
b2UiLAogICAgICAiaWQiOiI0NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5IiwKICAg
ICAgIm5hbWUiOnsKICAgICAgICAiZ2l2ZW5OYW1lIjoiSm9obiIsCiAgICAgICAg
ImZhbWlseU5hbWUiOiJEb2UiCiAgICAgIH0KICAgIH0gIAogIH0KfQ</artwork>
</figure><figure anchor="eventToken"
            title="Example Unsecured Event Token">
            <preamble>The encoded JWS signature is the empty string.
            Concatenating the parts yields:</preamble>

            <artwork>eyJhbGciOiJub25lIn0
.
eyAgCiAgImp0aSI6ICI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIs
CiAgImV2ZW50VXJpcyI6WwogICAgInVybjppZXRmOnBhcmFtczpldmVudDpTQ0lN
OmNyZWF0ZSIKICBdLAogICJpYXQiOiAxNDU4NDk2NDA0LAogICJpc3MiOiAiaHR0
cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwgIAogICJhdWQiOlsKICAgImh0dHBzOi8v
c2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0
IiwKICAgImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZi
MWQwODY0MWQ3Njc2ZWU3IgogIF0sICAKICAic3ViIjogImh0dHBzOi8vc2NpbS5l
eGFtcGxlLmNvbS9Vc2Vycy80NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5IiwKICAi
dXJuOmlldGY6cGFyYW1zOmV2ZW50OlNDSU06Y3JlYXRlIjp7CiAgICAiYXR0cmli
dXRlcyI6WyJpZCIsIm5hbWUiLCJ1c2VyTmFtZSIsInBhc3N3b3JkIiwiZW1haWxz
Il0sCiAgICAidmFsdWVzIjp7CiAgICAgICJlbWFpbHMiOlsKICAgICAgIHsidHlw
ZSI6IndvcmsiLCJ2YWx1ZSI6Impkb2VAZXhhbXBsZS5jb20ifQogICAgICBdLAog
ICAgICAicGFzc3dvcmQiOiJub3Q0dTJubyIsCiAgICAgICJ1c2VyTmFtZSI6Impk
b2UiLAogICAgICAiaWQiOiI0NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5IiwKICAg
ICAgIm5hbWUiOnsKICAgICAgICAiZ2l2ZW5OYW1lIjoiSm9obiIsCiAgICAgICAg
ImZhbWlseU5hbWUiOiJEb2UiCiAgICAgIH0KICAgIH0gIAogIH0KfQ.</artwork>
          </figure></t>

        <t>To create and or validate a signed or encrypted event token follow
        the instructions in section 7 of <xref
        target="RFC7519"/>.</t>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations" toc="default">

      <t>[[TO BE COMPLETED ]] <list style="symbols">
        <t>Avoid using Maximal disclosure mode</t>
        <t>Use TLS best practices.</t>
        <t>Subscribers SHOULD use SCIM GET to obtain full state when
        not disclosed in the event.</t>
        <t>Subscribers MAY use SCIM GET to get the latest state on a 
        resource and discard events with iat and nbf that is older.</t>
        <t>Subscribers must authenticae the message using either TLS, and/or
        validating signed event messages.</t>
        <t>Publishers should avoid retaining events except for audit
        purposes. Events should not be accessible indefinitely - re: LDAP
        changelog problems.</t>      
      </list>
     </t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <section anchor="eventParam" title="Registration of Event URN Sub-namespace">
       <t>IANA has added an entry to the "IETF URN Sub-namespace for Registered
       Protocol Parameter Identifiers" registry and created a sub-namespace
       for the Registered Parameter Identifier as per <xref
        target="RFC3553"/>: 
       <spanx style="verb">urn:ietf:params:event</spanx>.</t>
       
       <t>To manage this sub-namespace, IANA is requested to create the
        "Event" Registry which shall be used to manage entries within the
        <spanx style="verb">urn:ietf:params:scim</spanx> namespace. The
        registry description is as follows:</t>

        <t><list style="symbols">
            <t>Registry name: Event</t>

            <t>Specification: [this document]</t>

            <t>Repository: [see <xref target="registry"/>]</t>

            <t>Index value: values [see <xref target="registry"/>]</t>
          </list></t>
      </section>
      
      <section anchor="registry" title="Event Registry">
      <t>[[TO BE COMPLETED]]</t>
      </section>
      
    </section>
  </middle>

  <back>
    <references title="Normative References">

      <reference anchor="idevent-subscription">
        
        <front>
          <title>Identity Event Subscription Protocol (work in progress)</title>
          <author fullname="Phil Hunt"><organization>Oracle Corporation</organization></author>
          <date/>
        </front>  
        <format type="TXT" target="draft-hunt-idevent-subscription-00.txt"/>    
      </reference>
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' ?><!-- Keywords -->

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3553.xml'?><!-- URN Sub-namespace -->
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml'?><!-- URIs -->

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5988.xml'?><!-- Web Linking -->

      <?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.7519.xml'?><!-- JWT -->
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7643.xml'?><!-- SCIM Schema -->
    </references>
 
    <references title="Informative References">
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7009.xml'?><!-- OAuth Revocation -->
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7515.xml'?><!-- JWS -->
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7516.xml'?><!-- JWE -->
      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7517.xml'?><!-- JWK -->

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7644.xml'?><!-- SCIM Protocl -->
    
       <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>
 
      <reference anchor="RISC">
        <front>
          <title>RISC (Risk and Incident Sharing and Coordination) Working Group (work in progress)</title>
          <author> <organization>The OpenId Foundation</organization></author>
          <date/>
        </front>
        <format type="HTML" target="http://openid.net/wg/risc/"/>
      </reference>

      <reference anchor="HEART">
        <front>
          <title>HEART Working Group (work in progress)</title>
          <author> <organization>The OpenId Foundation</organization></author>
          <date/>
        </front>
        <format type="HTML" target="http://openid.net/wg/heart/"/>
      </reference>

    </references>

    <section title="Contributors"/>

    <section title="Acknowledgments">
      <t>The editor would like to thank the participants in the id-events
      mailing list and related working groups for their support of this specification.</t>
    </section>

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