wdiff draft-hunt-idevent-distribution-00.txt draft-hunt-idevent-distribution-01.txt

Network Working Group P. Hunt, Ed.
Internet-Draft Oracle
Intended status: Standards Track M. Ansari Scurtescu
Expires: October 6, 2016 Cisco April 4, 2, 2017 Google
M. Ansari
Cisco
September 29, 2016

Identity Event

SET Token Distribution and Subscription Protocol
draft-hunt-idevent-distribution-00 Management Profile
draft-hunt-idevent-distribution-01

Abstract

This

The specification defines how a registry to define methods to distribute
identity events subscriber to subscribers. It includes a definition for
publishers to use HTTP POST to push feed of security
events to clients via web
callback, (SETs) may query for, subscribe and receive SETs from a
security event feed. The specification defines a single mandatory-
to-implement method for subscribers to use using HTTP GET Post to retrieve deliver events in to registered
subscribers and a feed queue. registry for new methods.

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 October 6, 2016. April 2, 2017.

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 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Event Notification Process . . . . . . . . . . . . . . . . . 5
3. Event Feeds . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Feed Types . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Feed Metadata . . . . . . . . . . . . . . . . . . . . . . 7
4. Subscriptions . . . . . .
3.3. SCIM Feed Management . . . . . . . . . . . . . . . . . . 8
4.1. Overview 9
4. Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. 10
4.1. Subscription Metadata . . . . . . . . . . . . . . . . . . 9
4.3. 10
4.2. Subscription Verification State Model . . . . . . . . . . . . . . . . 10
4.3.1. Verifying 'Push' Style Subscriptions 12
4.3. SCIM Subscription Management . . . . . . . . 11
4.3.2. Verifying 'Polling' Style Subscriptions . . . . . . 14
4.3.1. SCIM Subscription Resource Type . 12
5. Event Delivery . . . . . . . . . . 14
4.3.2. New Subscription Requests . . . . . . . . . . . . . 13
5.1. Introduction to Event Delivery Methods . . . . 16
4.3.3. Updating Subscriptions . . . . . 13
5.2. HTTP Web Callback Method . . . . . . . . . . . . 18
4.4. Subscription Verification . . . . 14
5.2.1. Description . . . . . . . . . . . . 19
4.4.1. Verifying Subscriptions . . . . . . . . . 14
5.2.2. Delivery Message Format . . . . . . 19
5. Event Delivery . . . . . . . . . 14
5.2.3. Subscription Verification . . . . . . . . . . . . . . 15
5.2.4. 20
5.1. Introduction to Event Delivery Procedure . . . . . . Methods . . . . . . . . . 20
5.2. Delivery Processing . . 15
5.2.5. Failure Conditions . . . . . . . . . . . . . . . . . 17 21
5.3. HTTP Polling . . . . . . Web Callback Method . . . . . . . . . . . . . . . . 17 22
5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 17 22
5.3.2. Delivery Message Format . . . . . . . . . . . . . . . 18 23
5.3.3. Subscription Verification . . . . . . . . . . . . . . 18 23
5.3.4. Delivery Procedure . . . . . . . . . . . . . . . . . 18
5.3.5. Failure Conditions . . . . . . . . . . . . . . . . . 20
5.4. Push Notification Extensions . . . . . . . . . . . . . . 20 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 27
7.1. SCIM Event Notification Mechanism Registry . . . . . . . 20 . . . 27
7.2. SCIM Event Type Registry Schema Registration . . . . . . . . . . . . . . . . 20 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 27
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 27
8.2. Informative References . . . . . . . . . . . . . . . . . 21 28
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 22 29
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 22 29
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 22 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 29

1. Introduction and Overview

Many service providers have a requirement to co-ordinate state of
entities and services between each other. Each service provider
often tracks different information about entities and thus positive
update commands such as HTTP POST or PATCH may not be possible as
this would introduce complex error and signal requirements. In
contrast, when one service provider notifies another of an event, the
subscriber is free to take local action as it has access to the
relevant local state information.

This specification defines a set of capabilities that method by which SETs (see
[I-D.hunt-idevent-token]) can be used delivered by publishers to distribute identity event tokens (see [idevent-token])
to subscribers. This specification defines a feed
subscribers using HTTP POST [RFC7231] as well as an extension
registry for profiling
existing messaging protocols that may be used for event delivery by a
particular subscriber. The enabling other methods of delivery. This specification also
defines two methods
HTTP POST how subscribers MAY query for available Feeds, and GET to deliver events. manage
event Subscriptions using SCIM [RFC7644].

The following diagram shows a typical Identity SET Feed Provider and its
event notification Subscribers: the
services provided to Subscribers. Arrow heads point to the service
provider (the direction of an HTTP request):

Figure 1: Subscription Management

An Identity feed provider may and Delivery

A SET Feed Provider MAY be directly integrated into a source service
that generates events, or it may be a separate service entity that
off-loads event distribution from the event generator to act as its
delegated publisher. For the purposes of this specification, while event
SET distribution may be handled separately, this specification will
consider the definition of those exchanges out of scope.

This specification addresses event delivery only. It is assumed that
there are other protocols or administrative methods method for providing how event feeds catalogs generators send events to
publishers as out-of-scope.

The specification uses SCIM protocol [RFC7644] to advertise available
Feeds and subscription management. to enable Subscribers to request, subscriber to, and manage
Subscriptions.

The specification defines a registry by which multiple SET delivery
methods can be registered. The specification includes a web callback
method which uses HTTP POST [RFC7231] to deliver SETs to Subscribers.

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
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.

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

This specification assumes terminology defined in the Security Event
Token specification[I-D.hunt-idevent-token].

The following definitions are specific to Identity Event publishing:

Feed Provider
The feed provider Feed Provider publishes events SETs to be distributed to registered
subscribers.

Event An event is an identify event [idevent-token] 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 Feed is a URI that describes the set of resources and events
under which events may be issued. An interested client subscriber
registers with the feed provider to subscribe to events an event URI to
receive SETs associated with a
feed. Feed. An individual Feed MAY have
zero or more Subscriptions.

Subscription
A Subscription contains the information needed by a Feed Provider
(e.g. delivery endpoints, credentials) to deliver a Feed of SETs
to an individual Subscriber. A Subscription has ONE 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. Examples of possible delivery mechanisms
include:

Registered Callback - The feed provider will deliver events by
using HTTP POST to a registered endpoint.

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

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 is an party or security entity registers in the form
of a Subscription to receive event notifications SETs from a feed provider. provider that are
part of a Feed.

2. Event Notification Process

When an event a Security Event occurs, the feed provider Feed Provider constructs a JWT based
Identity Event SET
token [idevent-token] [I-D.hunt-idevent-token] that describes the event. The feed
provider determines the feeds that the event should be published distributed
to, and determines which subscribers Subscribers need to be notified.

How Feeds are effected. The defined and the process by which events are categorized and selected identified
for subscribers is out of
scope out-of-scope of this specification.

When an event a SET is available for a subscriber, the feed provider Feed Provider attempts
to deliver the event SET based on the subscribers Subscriber's registered delivery mechanism. For example,
mechanism:

o The subscriber provided a web-callback endpoint, the publisher
uses an HTTP/1.1 POST to the endpoint to deliver the event to the
registered subscriber;

o For subscribers electing to poll for events, Or, the feed publisher
retains Feed Provider delivers the events for event through a period of time or until the registered
subscriber retrieves all pending events via HTTP/1.1 GET to the
subscriber's assigned retrieval endpoint by the feed publisher;
or,

o The subscriber elected to use an alternate delivery different
method (e.g.
WebPUSH, Apple APNS, Google GMS), delivery is facilitated via the
registered delivery profile for that method. not defined by this specification.

After an event a SET is delivered to all subscribers, feed providers will Feed Providers do not
typically maintain event records SETs or histories. As such, published events SETs SHOULD
be self-validating (e.g. signed).

If delivery to any particular subscriber has been delayed for an
extended period of time, the feed provider Feed Provider MAY suspend the
subscription and even stop maintaining outstanding events SETs for the
subscriber
Subscriber at its discretion and available resources. See
subscription "state" in Section 4.2. 4.1.

Upon receiving an event token (or tokens in the case of multiple
events), a SET, the subscriber Subscriber reads the token and validates
it. Based on the content of the token, the subscriber decides what
if any action it needs to take in response to the event. SET. For example,
in response to a SCIM event [idevent-scim] indicating a changed
resource, the subscriber might perform a SCIM GET request (see
Section 3.4
[RFC7644] ) [RFC7644]) to the affected resource URI in order to
confidentially obtain the current state of the affected SCIM
resource.

The receiver of
the event then determines what action, if any, needs to be taken
within the subscriber's domain.

The action a receiver Subscriber takes may in response to a SET MAY be
substantially different than merely copying the action of the
publisher. A single publisher event SET MAY trigger multiple receiver actions. For
example, upon receiving notification that a user resource has been
added to a group, the
receiver Subscriber may first determine that the user
does not exist in the
subscriber's Subscriber's domain. The receiver Subscriber translates
the event into two
actions. actions:

1. Retrieve the user (e.g. using SCIM GET) and then provisions the
user locally. After enabling the user, the receiver

2. The Subscriber then enables the user for the application
associated with membership in the
publisher's Feed Publisher's group.

3. Event Feeds

An event feed Feed is service that defined by a "feedUri". The Feed provides a series stream of events made
available that
SETs to be delivered to registered Subscribers based on a client (known as the "subscriber") MAY subscribe to.
A subscription
Subscription. An individual Subscription contains the information metadata about
a particular client and Subscriber regarding their subscription to a particular
"feedUri". The subscription Subscription metadata describes the client that has subscribed, indicates the current
delivery status subscription
state indicating whether all events are delivered, pending, or
whether delivery has failed. Subscription metadata also describes
the method of event delivery delivery, and any associated security and
configuration information (see Section 4.2 4.1 ).

3.1. Feed Types

A feed provider Feed Provider MAY define feeds Feeds based on a number of criteria. This
specification does not specify or limit the basis for which a service
provider defines the resources or entities contained in a feed Feed or how
feed URIs should be specified. Some possible methods for defining feeds
entities covered by a Feed include:

By Resource Each or Subject
A resource or subject might have its own associated event
notification
feed. 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 Feed might be defined by an endpoint where any event relating to
a resource within an endpoint is delivered to a subscriber. This
type of feed is likely to have many notifications as the number of
resources in an endpoint grows (e.g. a SCIM "/Users"). "/Users") and SHOULD
be used with caution. Typically only privileged partners would be
allowed to use this type of feed. For example example, an enterprise
wishes to be notified of all change events to any of its Users users
assuming all Users users within the endpoint are related to the
subscribing enterprise.

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

By Group
All entities or resources within some specified group. For
example, all resources within a SCIM Group could be used to define
the resources for which SETs will be issued within a particular feed. [TODO
define a FEED Group extensions that define the attributes and
events included within a particular Feed Group]
Feed.

The list above is intended to show common use cases for defining
Feeds. How feeds Feeds are defined or implemented is out of the scope out-of-scope of this specification. The above are examples about how feeds might be
defined.

3.2. Feed Metadata

A feed description

Feed metadata consists of the following singular attributes:

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

feedUri
An attribute of type "String" that is a unique URI identifying the
feed. This attribute characteristic "mutability" is "immutable"
and SHALL NOT change once assigned. The value of this attribute
MAY be the SCIM URI for the Feed resource (e.g.
"https://scim.example.com/Feeds/88bc00de"). This is a required REQUIRED
attribute.

description
A "String" attribute that describes the purpose of the feed in
human readable form. This is an optional OPTIONAL attribute.

type
A "Reference"

events
An attribute that whose value is one a JSON object consisting of multi-
valued JSON attributes where each attribute is the name of a
primary event URI and each value represents an event extension to
the primary event. An empty array SHALL indicate there are no
extensions. When set, Feeds SHALL only provide the primary events
defined. However, a Feed Provider MAY provide additional
extensions that are not declared. This is an OPTIONAL attribute.

The following canonical
values: is a non-normative example events claim:

"events":{
"urn:ietf:params:scim:event:passwordReset":[
"https://example.com/scim/event/passwordResetExt"],
"https://specs.openid.net/logout":[]
}

Figure 2: Example Events Attribute

In the above example, the feed has two events defined. The first
is a hypothetical password reset, and the second is a hypothetical
OpenID Connect logout. The password reset event has one extension
defined which is "https://example.com/scim/event/
passwordResetExt".

type
An OPTIONAL String attribute that MAY have values such as:

resource Indicates that the feed Feed is for events related to a
specific resource. In such cases, the value of the attribute
"filter" is set to a specific resource URI or "/Me" .

endpoint Indicates that the feed Feed is for all events that occur for
resources within a specific endpoint. In such cases, "filter"
is set to an endpoint container for a group of resources (e.g.
"/Users" ).

filter Indicates that events for a feed Feed will be selected based on
events relating to the set of resources described by a filter.
The
For example, the value of the attribute "filter" is a SCIM
filter Section 3.4.2 [RFC7644] that describes a condition that
selects a set of resources that match before or after a
resource state change.

group Indicates that events for a feed Feed will be based on events
relating to the set of resources listed in a group such as a
SCIM Group. GroupSection 4.2 [RFC7643].

The
value of the attribute "filter" is a URI that corresponds to a
SCIM Group containing a set of members to be monitored.

hangText="publisher">Indicates a group whose definition is
specific typically used by the Feed Publisher to determine
the service provider publisher.The value meaning and content of the
attribute Feed "filter" if used, attribute.

filter
An OPTIONAL String value containing a filter whose syntax is
defined by a profiling specification (e.g. SCIM) or the service
provider.[[SHOULD THERE BE AN EXTENSION POINT?]] Feed
Publisher. For example in SCIM, a filter
A String value containing MAY be a SCIM filter (see
Section 3.4.2.2
[RFC7644] ), [RFC7644]), a resource, or a SCIM endpoint URI. The contents of URI
depending on the value of "type". And, if the SCIM Feed type is indicated by
"resource", than the feed "type" attribute. filter value is a URI for a SCIM resource.

The following multi-valued attributes are defined:

events One or more String values that contain the Event URIs
supported[[TBD]]. By default, all available events MAY be
published.

deliveryModes
One or more URIs representing the methods of delivery supported by
the Feed Publisher. Values in this attribute correspond to the
Subscription "methodUri" attribute (see Section 4.1).

3.3. SCIM Feed Management

When Feeds are managed within a SCIM service provider [RFC7644], Feed
resources use schema defined in Section 3.2 and use a schema value of
"urn:ietf:params:scim:schemas:event:2.0:Feed". The SCIM
"ResourceType" definition defines the location of the SCIM service
provider endpoint for "Feed" resources.

The Feed "ResourceType" definition is typically defined as follows:

{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
"id": "Feed",
"name": "Feed",
"endpoint": "/Feeds",
"description": "Event Feeds",
"schema": "urn:ietf:params:scim:schemas:event:2.0:Feed",
"schemaExtensions": []
}

Figure 3: SCIM Feed ResourceType Definition

To retrieve information about a "Feed" or a number of feeds,
subscribers or management clients MAY query the "/Feeds" endpoint as
defined in Section 3.4 [RFC7644].

The example below retrieves a specific Feed resource whose "id" is
"548b7c3f77c8bab33a4fef40".

GET /Feeds/88bc00de776d49d5b535ede882d98f74
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8

Figure 4: Example Feed GET Request

The response below shows an example Feed resource that describes an
available feed. By default,

HTTP/1.1 200 OK
Content-Type: application/scim+json
Location:
https://example.com/v2/Feeds/88bc00de776d49d5b535ede882d98f74
ETag: 9d1c124149f522472e7a511c85b3a31b

{
"schemas":["urn:ietf:params:scim:schemas:event:2.0:Feed"],
"id":"88bc00de776d49d5b535ede882d98f74",
"feedName":"OIDCLogoutFeed",
"feedUri":"https://oidc.example.com/",
"description":"Logout events from oidc.example.com",
"type":"resource",
"events":[
"https://specs.openid.net/logout":[]
]
"meta":{
... SCIM meta attributes ...
}
}

Figure 5: Example Feed GET Response

In the above example (Figure 5) we can observe that the Feed has only
one event type, "https://specs.openid.net/logout" and has no
extensions defined for the event (see empty square brackets). Note
also, that no value for "filter" has been specified suggesting that
the Feed will return events about all delivery modes are
supported. subjects of the publisher.

4. Subscriptions

4.1. Overview

A subscription represents an agreement to deliver events SETs from a
specified feed of events Feed URI from a feed provider Feed Provider to an individual
subscriber entity. Subscriber
entity also known as the "audience". The method of delivery and the
parameters for delivery are specified a set of parameters called
subscription metadata (see Section 4.2).

4.2. 4.1).

4.1. Subscription Metadata

A subscription is defined by the following metadata:

feedUri
A string String value containing the URI for a feed supported by the feed
provider. It describes the content of the feed and MAY also be a
resolvable URI where the feed meta data may be returned as a JSON
object. REQUIRED.

deliveryUri

methodUri
A REQUIRED single-valued string which is a URI with a prefix of
"urn:ietf:params:event:delivery". The following are defined in
"urn:ietf:params:set:method". This specification defines HTTP
POST delivery Section 5:

urn:ietf:params:event:delivery:HTTP:webCallback
The feed provider
"urn:ietf:params:set:method:HTTP:webCallback"
in which the Feed Provider delivers events using HTTP POST to a
specified callback URI.

urn:ietf:params:event:delivery:HTTP:poll
The subscriber will poll for events using HTTP GET.

subUri

deliveryUri
A URI that describes the location SETs are delivered. Its format
and usage requirements are defined by the associated "methodUri"
specification.

aud
An OPTIONAL URI representing the unique identifier for a single subscriber audience of a feed. It MAY also the subscription.
The value SHALL be an actual event polling endpoint which the subscriber MAY use to receive such as with "deliveryUri"
method value of "urn:ietf:params:event:delivery:HTTP:poll". "aud" when the subscriber receives
SETs from the feed.

feedJwk
AN
An OPTIONAL public JSON Web Key (see [RFC7517]) that will be used
to sign published events. SETs. If present, the subscriber Subscriber can
authenticate
events SETs relayed from the feed provider. Feed Provider.

confidentialJwk
An OPTIONAL subscriber Subscriber provided public JSON Web Key (see
[RFC7517]) that may MAY be used by the feed provider Feed Provider to encrypt event
messages SET
tokens for the subscriber. specified Subscriber.

subStatus
An optional OPTIONAL value which that indicates the current status of a
subscription:
Subscription:

"on" - the default setting indicates the feed provider
processing events Subscription has been verified and will that
the Feed Provider MAY pass them SETs to the subscriber. Subscriber.

"verify" - indicates the subscription Subscription is pending verification.
While in "verify", published events SETs SHALL NOT be stored or
delivered to the subscriber. Subscriber. Once verified, the status returns
to "on".

"paused" - indicates the feed provider Feed Provider is temporarily
suspending delivery to subscriber. Subscriber. While in "paused" events "paused", SETs SHOULD
be retained and delivered when state returns to "on".
Verification is NOT required when returning to "on".

"off" - indicates that the subscription Subscription is no longer passing
events.
SETs. While in off mode, the subscription metadata is
maintained, but new events are ignored and ignored, not processed delivered or
retained. Before returning to "on", a verification MUST be
performed.

"fail" - Indicates indicates that the feed provider was unable to deliver
events
SETs to the subscriber Subscriber for an extended period of time, or due
to a call failure to the registered web call back URI. Unlike
paused status, a failed subscription is no longer receiving
events receives SETs,
nor are they retained by the feed provider. Feed Provider. Before returning
to "on", a verification MUST be performed.

maxRetries
An OPTIONAL number indicating the maximum number of attempts to
deliver an event. a SET. A value of '0' indicates there is no maximum.
Upon reaching the maximum, the subscription Subscription "subStatus" attribute
is set to
"failed" [[or "paused"?]]. "failed".

maxDeliveryTime
An OPTIONAL number indicating the maximum amount of time an event in
seconds a SET MAY wait before take for successful delivery. Upon reaching the
maximum, the subscription "subStatus" is set to "failed" [[or "paused"?]]. "failed". If
undefined, there is no maximum time.

minDeliveryInterval
An OPTIONAL integer that represents the minimum interval in
seconds between deliveries. A value of '0' indicates delivery
should happen immediately. When delivery is a polling method
(e.g. HTTP GET), it is the expected time between subscriber
attempts. When in push mode (e.g. HTTP POST), it is the interval
the server will wait before sending a new event or events.

4.2. Subscription State Model

The Subscription attribute "subStatus" tracks the state of any
particular subscription with regards to whether SETs are ready or
able to be delivered. The impact on delivery processing is described
in Table 1.

The following is the state machine representation of a subscription
on a Feed Publisher. Note that a subscription cannot be made active
until a verification process has been completed. As such, a newly
created subscription begins with state "verify".

+
|
Create
v
+------+ +----------+
| fail +->Restart---->| verify |
+------+ +----+-----+
^ |
|<----Confirm Fail<----+
| Confirm
| v
| +----------+ +--------+
| | +--->Suspend--->| |
+------Timeout<---+ on | | paused |
| |<--Resume<-----+ |
+-+--------+ +--------+
| ^
Disable Enable
v |
+--------+-+
| off |
+----------+

Figure 6: Subscription States at Feed Publisher

In the above diagram, the following actions impact the state of a
Subscription. "subStatus" values are shown in the boxes, and change
based on the following actions:

Create
A Subscriber or an administrator creates a new subscription using
SCIM as described in Section 4.3.2. The initial state is
"verify".

Confirm
The Feed Publisher sends a verification SET to the Subscriber
which confirms with the correct response as described in
Section 4.4. If it succeeds to deliver, the Feed Publisher mail
retry or set state to "on".

Confirm Fail
If the confirmation fails, the Feed Publisher sets the state to
"fail" requiring administrative action to correct the issue and
"Restart".

Timeout
A Feed Publisher having not being able to deliver a SET over one
or more retries which has reached a limit of attempts
("maxRetries") or time ("maxDeliveryTime") MAY set the
subscription state to "fail". In general, the intention is to
indicate the maximum number of retries or time a Feed Publisher is
able to wait until SET event loss begins to occur resulting in the
failed state.

Restart
An administrator having corrected the failed delivery condition
modifies the Subscription state to "verify" (e.g. see
Section 4.3.3).

Suspend and Resume
A Subscription MAY be suspended and resumed by updating the
Subscription state to "paused" or "on". For example, see see
Section 4.3.3. While suspended, the Feed Publisher MAY retain
undelivered SETs for a period of time. If the Feed Publisher is
no longer able to retain SETs, the subscription state SHOULD be
set to "off" to indicate SETs are being lost.

Enable and Disable
A subscription MAY be disabled and enabled by updating the
Subscription state to "off" or "on". For example, see see
Section 4.3.3. While the Subscription is disabled, all SETs that
occur at the Feed Publisher are lost.

4.3. SCIM Subscription Management

A Feed Publisher MAY use SCIM to support management of subscriptions.
Typically this involves support for the Subscription Resource Type,
and the corresponding SCIM operations to create, update, retrieve
Subscription Resources. For SCIM service provider capability and
schema discovery, see Section 4 [RFC7644].

4.3.1. SCIM Subscription Resource Type

When Subscriptions are managed within a SCIM service provider
[RFC7644], Subscription resources use schema defined in Section 4.1
and use a schema value of
"urn:ietf:params:scim:schemas:event:2.0:Subscription".

The SCIM Subscription "ResourceType" definition is defined as
follows:

{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
"id": "Subscription",
"name": "Subscription",
"endpoint": "/Subscriptions",
"description": "Subscribers to SET Feeds",
"schema": "urn:ietf:params:scim:schemas:event:2.0:Subscription",
"schemaExtensions": []
}

Figure 7: SCIM Subscription ResourceType Definition

To retrieve information about one or more Subscriptions, Subscribers
or management clients MAY query the "/Subscriptions" endpoint as
defined in Section 3.4 [RFC7644].

The example below retrieves a specific "Subscription" resource whose
"id" is "548b7c3f77c8bab33a4fef40".

GET /Subscriptions/767aad7853d240debc8e3c962051c1c0
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8

Figure 8: Example SCIM Subscription GET Request

The response below shows an example Feed resource that describes an
available feed.

HTTP/1.1 200 OK
Content-Type: application/scim+json
Location:
https://example.com/v2/Subscriptions/767aad7853d240debc8e3c962051c1c0

{
"schemas":["urn:ietf:params:scim:schemas:event:2.0:Subscription"],
"id":"767aad7853d240debc8e3c962051c1c0",
"feedName":"OIDCLogoutFeed",
"feedUri":
"https://example.com/v2/Feeds/88bc00de776d49d5b535ede882d98f74",
"methodUri":"urn:ietf:params:set:method:HTTP:webCallback",
"deliveryUri":"https://notify.examplerp.com/Events",
"aud":"https://sets.myexamplerp.com",
"subStatus":"pending",
"maxDeliveryTime":3600,
"minDeliveryInterval":0,
"description":"Logout events from oidc.example.com",
"meta":{
... SCIM meta attributes ...
}
}

Figure 9: Example Subscription GET Response

In the above example (Figure 9) observe that the subscription is for
the SCIM "Feed" resource defined at "https://example.com/v2/
Feeds/88bc00de776d49d5b535ede882d98f74". The current subscription
state is "pending" which suggest the Subscription Verification (see
Section 4.4) process has not yet completed. Since there is no value
for "feedJwk", ) or "confidentialJwk", the SETs will be sent without
signing or encryption (plain text).

4.3.2. New Subscription Requests

To subscribe to a feed, the subscriber of management client uses the
SCIM Create operation as defined in Section 3.3 [RFC7644]. SCIM
subscription management service providers MAY have additional schema
requirements which MAY be discovered using SCIM service configuration
and schema discovery, see Section 4 [RFC7644].

In the following non-normative example, a new Subscription resource
is requested. Note that the SCIM service provider automatically
assigns the "id" attribute.

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

{
"schemas":["urn:ietf:params:scim:schemas:event:2.0:Subscription"],
"feedName":"OIDCLogoutFeed",
"feedUri":
"https://example.com/v2/Feeds/88bc00de776d49d5b535ede882d98f74",
"methodUri":"urn:ietf:params:set:method:HTTP:webCallback",
"deliveryUri":"https://notify.examplerp.com/Events",
"aud":"https://sets.myexamplerp.com",
"maxDeliveryTime":3600,
"minDeliveryInterval":0,
"description":"Logout events from oidc.example.com"
}

Figure 10: Example New Subscription Request in SCIM

In following non-normative response, the SCIM service provider has
automatically assigned a resource location as well as an "id".
Usually upon creation, the initial value of "subStatus" is "pending"
indicating that the Subscription Verification (see Section 4.4) has
not been completed.

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

Figure 11: Example Response to Subscription Request

4.3.3. Updating Subscriptions

To modify a Subscription, a Subscriber or authorized management
client MAY use the SCIM PUT operation (see Section 3.5.1 [RFC7644])
and MAY use the SCIM PATCH operation (see Section 3.5.2 [RFC7644]) if
supported by the SCIM Subscription server.

In the following non-normative example, the client is requesting that
"subStatus" be changed to "paused" for the Subscription whose path is
identified by the request URI path.

PATCH /Subscriptions/767aad7853d240debc8e3c962051c1c0
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8

{
"schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [{
"op":"replace",
"path":"subStatus",
"value":"paused"
}]
}

Figure 12: Example SCIM Subscription Update

4.4. Subscription Verification

In order to avoid ongoing communication issues and to minimize
requirements for feed providers Feed Providers to maintain events a series of SETs
indefinitely, a verification process is used to confirm that the
requested event Subscription distribution endpoints are correct valid and that events SETs
may be successfully delivered. When a subscription Subscription is created or
modified, or goes into a failed or off state, the feed provider Feed Provider SHALL
set the subscription Subscription state ("subStatus") attribute "subStatus" to "verify" and send
a test event Verify SET message to the subscriber. If the
event SET is delivered
successfully, the subscription state MAY SHOULD be turned to "on". If
however verification fails due to a hard timeout or connection failure, or
any other cause, the
client fails to retrieve the event within a [reasonable?] period, the
subscription Subscription status SHALL be set to "fail".

4.3.1.

4.4.1. Verifying 'Push' Style Subscriptions

When using the WebCallback mode, or any other 'push'-style
communication scheme, the

The verification process serves to verify that the identified endpoint consents
Subscriber is willing to receiving events receive SETs and is valid.
This prevents correctly configured.
In the case of push style subscriptions, where the publisher
initiates the action to deliver a notification SET, Verification can also serve to
prevent a Feed Publication server from flooding an endpoint which did
not actually request an event subscription. a Subscription.

A Feed Provider MAY send a Verify SET at any time in order to
reverify connectivity and to assure the subscriber the subscription
is valid (e.g. as a keep alive technique).

To confirm a subscription, the feed provider Feed Provider SHALL send a
verification event SET to the subscriber using the registered
_deliveryUri_ "methodUri"
mechanism. The event Verify SET contains the following attributes:

eventUris

events Set with a value of "urn:ietf:params:event:event:verify". "[[this RFC URL]]#verify".

iss Set to the URI of the feed publisher (see [idevent-token]).
[I-D.hunt-idevent-token]).

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

confirmChallenge A String value that the subscriber SHALL echo back
in its response. See deliveryUri method profile for usage
details.

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

In the SET payload area, a specific delivery method MAY include an
attribute that can be used to confirm the subscriber has successfully
received and parsed the SET (e.g. such as the inclusion of a
challenge attribute, see Section 5.3.3). If a confidential JWK was
supplied, then the event SET SHOULD be encrypted with the provided key.
Successful parsing of the message confirms that both the endpoint is valid including provides confirmation
of
keys.

A non-normative JSON representation correct configuration and possession of an event to be sent to a
subscriber as a subscription confirmation. keys.

Note that the verification event URI ("[[this RFC URL]]#verify") type
is not yet
encoded normally listed as a JWT token.

{
"jti": "4d3559ec67504aaba65d40b0363faad8",
"eventUris":["urn:ietf:params:event:event:verify"],
"iat": 1458496404,
"iss": "https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
],
"confirmChallenge":"ca2179f4-8936-479a-a76d-5486e2baacd7",
"exp": 1458497000

}

Upon receiving a subscription confirmation request, a confirming
subscriber responds with a confirmation using the method described in
the deliveryUri profile. The response includes a "challengeResponse"
value. For example, depending on the deliveryUri profile used, the
subscriber might respond with the value part of "confirmChallenge" . For
example, if the request is received via HTTP/1.1 POST, then the
following HTTP response definition of a Feed as it is used to confirm. A non-normative example
not part of the response is:

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

{
"challengeResponse":"ca2179f4-8936-479a-a76d-5486e2baacd7"
}

If the subscriber returns a non-matching value or an HTTP status
other than normal information flow of a 200 series response, the subscription "state" SHALL be
set to "fail". A declining subscriber Feed. Any Feed MAY simply respond with any
400 series HTTP error (e.g. 404).

4.3.2. Verifying 'Polling' Style Subscriptions

For clients that use a subscription mode (e.g.
"urn:ietf:params:scimnotify:api:messages:2.0:poll") that pick up
events from
include a subscription endpoint, the client MAY confirm the
subscription by simply reading the SET verification event using an HTTP GET at the
endpoint specified by the attribute "subUri" whether listed or not in the subscription.
Once the confirmation Feed
event has been retrieved, metadata.

Upon receiving the service provider
MAY mark SET, the subscription subscriber acknowledges receipt as confirmed.

A non-normative example of a client, having previously subscribed,
picking up
defined by the initial subscription confirmation message.

GET /Events/548b7c3f77c8bab33a4fef40/
Host: example.com
Accept: application/scim+json
Authorization: Bearer h480djs93hd8
Content-Length: ...

To which method profile (for example, see Section 5.3.3).

If the event provider responds with subscriber is unable to parse the available events which
SHOULD include verification SET, fails to
return the correct challenge, or the SET is not delivered after a confirmation event (non-normative example):

{
"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":""

}
period of time. The Feed Publisher will set "subStatus" to "failed".

5. Event Delivery

5.1. Introduction to Event Delivery Methods

Each event delivery method SHALL SHOULD have the following information:

Description
The _deliveryUri_ "methodUri" URI value for the delivery method and a
description of the method.

Subscription Verification Procedure
The procedure that the configuration for a subscription is
confirmed causing the subscription status to be set to "on".

Delivery Message Format
A description of an event delivery message and how to locate the
event token(s) as well as any additional signaling parameters. error signalling.

Delivery Procedure
The protocol procedure for a delivery request (push or poll), and
the expected successful response.

Failure Conditions
A description of the failure conditions that might occur and the
impact on the subscriptions operational status ("subStatus") if
any.

Multi-Event Message Considerations
A description

This specification defines the first delivery method known as "HTTP
Web Callback Method" which uses HTTP POST.

5.2. Delivery Processing

As mentioned in Section 4.1, the attribute "subStatus" defines the
current state of any special considerations when passing multiple
events a subscribers subscription. Figure 6 shows a state
diagram for Subscriptions. The following describes that actions
taken by the Feed Publisher based upon "subStatus".

+--------+----------------------------------------------------------+
| Status | Action |
+--------+----------------------------------------------------------+
| on | Delivery SHALL be attempted based on the method defined |
| | in the subscription attribute "methodUri". If the SET |
| | fails to deliver it MAY be retained for a single delivery.[[is retry delivery |
| | in a minimum of "minDeliveryInterval" seconds. If new |
| | SETs arrive before the interval, the SETs MUST be held |
| | for delivery in order of reception. If this needed?]]

Table 1: Delivery Processing By Status

5.3. HTTP Web Callback Method

5.2.1.

5.3.1. Description

This method allows a feed provider to use HTTP POST (Section 4.3.3
[RFC7231]) to deliver events SETs to a registered web callback URL. URI. The "deliveryUri"
Subscription "methodUri" value for this method is "urn:ietf:params:event:delivery:HTTP:webCallback".
"urn:ietf:params:set:method:HTTP:webCallback".

This delivery method is capable of delivering a single SET per HTTP
POST request. Depending on the settings for the subscription metadata, this
delivery method is capable of delivering multiple
metadata (see Section 4.1), the SET MAY be signed events and/or encrypted as
defined in [I-D.hunt-idevent-token].

The Subscription's "deliveryUri" attribute indicates the location of
a
single delivery.

5.2.2. Subscriber provided endpoint which can accept HTTP POST requests
(e.g. "https://notify.examplerp.com/Events").

5.3.2. Delivery Message Format

The content-type for this method is "application/json" "application/jwt" and consists of
a JSON object containing the following attributes:

eventTkns
A multi-valued String with each value containing an identity event single SET token ([idevent-token]). Each value MAY represent an unsigned,
signed, or encrypted token. At least one value MUST be present in
a delivery request.

eventCnt
An integer representing the number of events present in the
message. REQUIRED.

eventPend
An boolean indicating more deliveries are pending. The default
value is false.

invalidEvents
An optional multi-valued set of JSON objects containing events
that could not be accepted or failed. Used in a delivery
response, a subscriber MAY return an event that failed to validate
or was unparseable.

{
"eventTkns":[
"eyJhbGciOiJub25lIn0 (see [I-D.hunt-idevent-token]).

eyJhbGciOiJub25lIn0
.
eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
."],
"eventCnt":1,
"eventPend":false
}
.

Figure 13: Example Web Callback POST Message

5.2.3.

5.3.3. Subscription Verification

See

This profile specifies the verification method for HTTP POST and is
based on the general verification method described in Section 4.3.1.

5.2.4. 4.4.1.

To confirm a subscription, the Feed Provider SHALL send a
verification SET to the subscriber using the registered "methodUri"
mechanism which in this case is
"urn:ietf:params:set:method:HTTP:webCallback". The Verify SET
contains the attributes listed in Section 4.4.1.

A payload attribute "confirmChallenge" is provided with a String
value that the subscriber SHALL echo back in its response. The
intent is to confirm that the Subscriber has successfully parsed the
SET and is not just echoing back HTTP success.

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:

{
"jti": "4d3559ec67504aaba65d40b0363faad8",
"events":["[[this RFC URL]]#verify"],
"iat": 1458496404,
"iss": "https://scim.example.com",
"exp": 1458497000,
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
],
"[[this RFC URL]]#verify":{
"confirmChallenge":"ca2179f4-8936-479a-a76d-5486e2baacd7"
}
}

Figure 14: Example Verification SET with Challenge

The above SET is encoded as a JWT and transmitted to the Subscriber
as shown in Figure 16.

Upon receiving a subscription verify SET, a confirming subscriber
SHALL respond with a JSON object that includes a "challengeResponse"
attribute and the value that was provided in "confirmChallenge". The
content type header is set to "application/json".

The following is a non-normative example response to a Verify SET
received via HTTP/1.1 POST and includes a JSON object containing the
confirmation attribute and value.

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

{
"challengeResponse":"ca2179f4-8936-479a-a76d-5486e2baacd7"
}

Figure 15: Example Response to Verify SET with Challenge

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).

5.3.4. Delivery Procedure

To deliver an event, the publisher generates an event delivery
message and uses HTTP POST to the registered endpoint. The content-
type of the message is "application/jwt" and the expected response
type (accept) is "application/json".

POST /Events HTTP/1.1

Host: notify.example.com notify.examplerp.com
Accept: application/json
Content-Type: application/json
{
"eventTkns":[ application/jwt
"eyJhbGciOiJub25lIn0
.
eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
.",
"eyJhbGciOiJub25lIn0
.
eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
."
],
"eventCnt":2
}

Figure 16: Example Web Callback POST Request

In response, if

Upon receipt of the event token request, the Subscriber SHALL validate the JWT
structure of the SET as defined in Section 7.2 [RFC7519]. The
Subscriber SHALL also validate the SET information as described in
Section 2 [I-D.hunt-idevent-token].

If the SET is validated, determined to be valid, the server Subscriber SHALL indicate
successful submission by responding with:

HTTP/1.1 with HTTP Status 202 Accepted as
"Accepted" (see Section 6.3.3 [RFC7231]).

If SET or to indicate errors it MAY JWT is invalid, or there is an HTTP error, the Subscriber
SHALL respond with
HTTP/1.1 202 Accepted
Content-Type: application/json

{
"invalidEvents":[
{"err":"duplicate",
"description":"Event already received. Ignored.",
"value":"eyJhbGciOiJub25lIn0
.
eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
."
}
]
}

Since the normal operation of the Feed Provider is appropriate HTTP error or an HTTP Status 400
Bad Request error as follows:

5.2.5. Failure Conditions

[[TO BE COMPLETED]]

5.3. HTTP Polling

5.3.1. Description

Table 2: HTTP GET to poll for events to
the "subUri" provided to the subscriber by the publisher. Status 400 Errors

The
"deliveryUri"value for this method is
"urn:ietf:params:event:delivery:HTTP:poll".

Depending on the settings for the subscription metadata, this
delivery method following is capable a non-normative example of delivering multiple signed events in a
single delivery poll request.

5.3.2. Delivery Message Format

The delivery message is the same as Section 5.2.2.

5.3.3. Subscription Verification

Subscription verification is described in Section 4.3.2.

5.3.4. Delivery Procedure

To deliver an event, the publisher places the event in successful receipt of a queue/buffer
associated with the client subscription that will be requested at
some future time by the subscriber using the URI specified in
"subUri".

To pick up any events, the subscriber issues an
SET.

HTTP/1.1 202 Accepted

Figure 17: Example Successful Delivery Response

An HTTP GET to the URI
provided by the event publisher in "subUri".

In Status 400 Bad Request response to includes a JSON object which
provides details about the HTTP GET request, error. The JSON object includes the feed publisher responds with JSON
attributes:

err
A value which is a body keyword that corresponds to describes the event delivery message format error (see
Section 5.2.2).

An example polling request by a subscriber. Table 2).

description
A human-readable text that provides additional diagnostic
information.

The following is an example has been
formatted for readability:

GET /subscriber/66444423ab24430fb06cf0de1ab75247
Host: pub.example.com
Accept: application/json
Authorization: Bearer h480djs93hd8

An example poll response (formatted for readability): non-normative Bad Request error.

HTTP/1.1 200 OK 400 Bad Request
Content-Type: application/json
Location:
https://pub.example.com/subscriber/66444423ab24430fb06cf0de1ab75247

{
"eventTkns":[
"eyJhbGciOiJub25lIn0
.
eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
.",
"eyJhbGciOiJub25lIn0
.
eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
."
],
"eventCnt":2
"err":"dup",
"description":"SET already received. Ignored."

}

[[TO BE DISCUSSED: Should the subscriber be able to request events
based on an event id (e.g. since), by date, etc. How does a client
know it got them all? Should we use ETags to signal whether there
are new events?]]

5.3.5. Failure Conditions

[[TO BE DISCUSSED: The polling mode provides no way for a subscriber
to indicate parsing validation errors directly in response to a
delivery. When errors occur, subscriber administrators must re-
confirm the subscription configuration.]]

5.4. Push Notification Extensions

[[TO BE COMPLETED]]

Figure 18: Example Bad Request Response

6. 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]

7. IANA Considerations

7.1. SCIM Event Notification Mechanism Registry

TODO:

[TODO: Registration for Notification Mechanisms Mechanisms]

7.2. SCIM Event Type Registry

TODO: Schema Registration of Event

As per the "SCIM Schema URIs for Data Resources" registry established
by Section 10.3 [RFC7643], the following defines and registers the
following SCIM URIs and Resource Types for Feeds and Subscriptions.

8. References

8.1. Normative References

[idevent-token]
Oracle Corporation, "Identity

[I-D.hunt-idevent-token]
Hunt, P., Denniss, W., Ansari, M., and M. Jones, "Security
Event Token (SET)", draft-hunt-idevent-token-05 (work in
progress)".
progress), September 2016.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.

[RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010,
<http://www.rfc-editor.org/info/rfc5988>.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.

[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>.

[RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
Mortimore, "System for Cross-domain Identity Management:
Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
2015, <http://www.rfc-editor.org/info/rfc7643>.

[RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
and C. Mortimore, "System for Cross-domain Identity
Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
September 2015, <http://www.rfc-editor.org/info/rfc7644>.

8.2. Informative References

[I-D.ietf-webpush-protocol]
Thomson, M., Damaggio, E., and B. Raymor, "Generic Event
Delivery Using HTTP Push", draft-ietf-webpush-protocol-02
(work in progress), November 2015.

[idevent-scim]
Oracle Corporation, "SCIM Event Extensions (work in
progress)".

[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>.

[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<http://www.rfc-editor.org/info/rfc7516>.

[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<http://www.rfc-editor.org/info/rfc7517>.

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

Draft 01 - PH -

o Removed the version from filename in GITHUB version

o Aligned document with new SET terminology from I-D.hunt-idevent-
token

o Simplified draft to only define HTTP POST profile (TBD)

o Removed webpush and polling modes (can be re-added later).

o Added SCIM management definitions for Feeds

o Added delivery information including errors

o Added subscription management information (e.g. how to subscribe)

o Updated reference to idevent-token to published IETF version

o Added a state diagram for Subscriptions

Authors' Addresses

Phil Hunt (editor)
Oracle Corporation

Email: phil.hunt@yahoo.com
Marius Scurtescu
Google

Email: mscurtescu@google.com

Morteza Ansari
Cisco

Email: morteza.ansari@cisco.com