< draft-hunt-idevent-distribution-00.txt		draft-hunt-idevent-distribution-01.txt >
	Network Working Group P. Hunt, Ed.		Network Working Group P. Hunt, Ed.
	Internet-Draft Oracle		Internet-Draft Oracle
	Intended status: Standards Track M. Ansari		Intended status: Standards Track M. Scurtescu
	Expires: October 6, 2016 Cisco		Expires: April 2, 2017 Google
	April 4, 2016		M. Ansari
			Cisco
			September 29, 2016
	Identity Event Subscription Protocol		SET Token Distribution and Subscription Management Profile
	draft-hunt-idevent-distribution-00		draft-hunt-idevent-distribution-01
	Abstract		Abstract
	This specification defines a registry to define methods to distribute		The specification defines how a subscriber to a feed of security
	identity events to subscribers. It includes a definition for		events (SETs) may query for, subscribe and receive SETs from a
	publishers to use HTTP POST to push events to clients via web		security event feed. The specification defines a single mandatory-
	callback, and a method for subscribers to use HTTP GET to retrieve		to-implement method using HTTP Post to deliver events to registered
	events in a feed queue.		subscribers and a registry for new methods.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 6, 2016.		This Internet-Draft will expire on April 2, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3		1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
	1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Event Notification Process . . . . . . . . . . . . . . . . . 5		2. Event Notification Process . . . . . . . . . . . . . . . . . 5
	3. Event Feeds . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Event Feeds . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Feed Types . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Feed Types . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Feed Metadata . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Feed Metadata . . . . . . . . . . . . . . . . . . . . . . 7
	4. Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . 8		3.3. SCIM Feed Management . . . . . . . . . . . . . . . . . . 9
	4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.2. Subscription Metadata . . . . . . . . . . . . . . . . . . 9		4.1. Subscription Metadata . . . . . . . . . . . . . . . . . . 10
	4.3. Subscription Verification . . . . . . . . . . . . . . . . 10		4.2. Subscription State Model . . . . . . . . . . . . . . . . 12
	4.3.1. Verifying 'Push' Style Subscriptions . . . . . . . . 11		4.3. SCIM Subscription Management . . . . . . . . . . . . . . 14
	4.3.2. Verifying 'Polling' Style Subscriptions . . . . . . . 12		4.3.1. SCIM Subscription Resource Type . . . . . . . . . . . 14
	5. Event Delivery . . . . . . . . . . . . . . . . . . . . . . . 13		4.3.2. New Subscription Requests . . . . . . . . . . . . . . 16
	5.1. Introduction to Event Delivery Methods . . . . . . . . . 13		4.3.3. Updating Subscriptions . . . . . . . . . . . . . . . 18
	5.2. HTTP Web Callback Method . . . . . . . . . . . . . . . . 14		4.4. Subscription Verification . . . . . . . . . . . . . . . . 19
	5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 14		4.4.1. Verifying Subscriptions . . . . . . . . . . . . . . . 19
	5.2.2. Delivery Message Format . . . . . . . . . . . . . . . 14		5. Event Delivery . . . . . . . . . . . . . . . . . . . . . . . 20
	5.2.3. Subscription Verification . . . . . . . . . . . . . . 15		5.1. Introduction to Event Delivery Methods . . . . . . . . . 20
	5.2.4. Delivery Procedure . . . . . . . . . . . . . . . . . 15		5.2. Delivery Processing . . . . . . . . . . . . . . . . . . . 21
	5.2.5. Failure Conditions . . . . . . . . . . . . . . . . . 17		5.3. HTTP Web Callback Method . . . . . . . . . . . . . . . . 22
	5.3. HTTP Polling . . . . . . . . . . . . . . . . . . . . . . 17		5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 22
	5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 17		5.3.2. Delivery Message Format . . . . . . . . . . . . . . . 23
	5.3.2. Delivery Message Format . . . . . . . . . . . . . . . 18		5.3.3. Subscription Verification . . . . . . . . . . . . . . 23
	5.3.3. Subscription Verification . . . . . . . . . . . . . . 18		5.3.4. Delivery Procedure . . . . . . . . . . . . . . . . . 25
	5.3.4. Delivery Procedure . . . . . . . . . . . . . . . . . 18		6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	5.3.5. Failure Conditions . . . . . . . . . . . . . . . . . 20		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	5.4. Push Notification Extensions . . . . . . . . . . . . . . 20		7.1. Event Notification Mechanism Registry . . . . . . . . . . 27
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 20		7.2. SCIM Schema Registration . . . . . . . . . . . . . . . . 27
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.1. SCIM Event Notification Mechanism Registry . . . . . . . 20		8.1. Normative References . . . . . . . . . . . . . . . . . . 27
	7.2. SCIM Event Type Registry . . . . . . . . . . . . . . . . 20		8.2. Informative References . . . . . . . . . . . . . . . . . 28
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 29
	8.1. Normative References . . . . . . . . . . . . . . . . . . 20		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 29
	8.2. Informative References . . . . . . . . . . . . . . . . . 21		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 29
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 22
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction and Overview		1. Introduction and Overview
	Many service providers have a requirement to co-ordinate state of		This specification defines a method by which SETs (see
	entities and services between each other. Each service provider		[I-D.hunt-idevent-token]) can be delivered by publishers to feed
	often tracks different information about entities and thus positive		subscribers using HTTP POST [RFC7231] as well as an extension
	update commands such as HTTP POST or PATCH may not be possible as		registry enabling other methods of delivery. This specification also
	this would introduce complex error and signal requirements. In		defines how subscribers MAY query for available Feeds, and manage
	contrast, when one service provider notifies another of an event, the		event Subscriptions using SCIM [RFC7644].
	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 can be used by
	publishers to distribute identity event tokens (see [idevent-token])
	to subscribers. This specification defines a registry for profiling
	existing messaging protocols that may be used for event delivery by a
	particular subscriber. The specification also defines two methods
	HTTP POST and GET to deliver events.
	The following diagram shows a typical Identity Feed Provider and its		The following diagram shows a typical SET Feed Provider and the
	event notification Subscribers:		services provided to Subscribers. Arrow heads point to the service
			provider (the direction of an HTTP request):
	+------------+ +-------------+		+------------+ +-------------+
	| |Feeds Catalog | |		| |Feeds Catalog | |
	| +------------------------> |		| <------------------------+ |
	| Identity | | Identity |		| SCIM | | SET |
	| Feed |Subscription Request | Feed |		| Feed |Subscription Request | Feed |
	| Provider <------------------------+ Subscriber |		| Mgmt <------------------------+ Subscriber |
	| |Subscription Confirm | |
	| +------------------------> |
	| | | |		| | | |
			| |Subscription Mgmt | |
			| <------------------------+ |
	| | | |		| | | |
			+------------+ | |
			+------------+ | |
			| | | |
			| FEED |SET Delivery | |
	| +------------------------> |		| +------------------------> |
	| |Event Delivery | |		| Provider | | |
	| | | |		| | | |
	+------------+ +-------------+		+------------+ +-------------+
	Figure 1: Subscription Management		Figure 1: Subscription Management and Delivery
	An Identity feed provider may be directly integrated into a source		A SET Feed Provider MAY be directly integrated into a source service
	service that generates events, or it may be a separate service entity		that generates events, or it may be a separate service entity that
	that off-loads event distribution from the event generator to act as		off-loads event distribution from the event generator to act as its
	its publisher. For the purposes of this specification, while event		delegated publisher. For the purposes of this specification, while
	distribution may be handled separately, this specification will		SET distribution may be handled separately, this specification will
	consider the definition of those exchanges out of scope.		consider the method for how event generators send events to
			publishers as out-of-scope.
	This specification addresses event delivery only. It is assumed that		The specification uses SCIM protocol [RFC7644] to advertise available
	there are other protocols or administrative methods for providing		Feeds and to enable Subscribers to request, subscriber to, and manage
	event feeds catalogs and subscription management.		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		1.1. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119] . These		document are to be interpreted as described in [RFC2119] . These
	keywords are capitalized when used to unambiguously specify		keywords are capitalized when used to unambiguously specify
	requirements of the protocol or application features and behavior		requirements of the protocol or application features and behavior
	that affect the inter-operability and security of implementations.		that affect the inter-operability and security of implementations.
	When these words are not capitalized, they are meant in their		When these words are not capitalized, they are meant in their
	skipping to change at page 4, line 27 ¶		skipping to change at page 4, line 27 ¶
	Implementers MUST percent encode URLs as described in Section 2.1 of		Implementers MUST percent encode URLs as described in Section 2.1 of
	[RFC3986] .		[RFC3986] .
	Throughout this documents all figures MAY contain spaces and extra		Throughout this documents all figures MAY contain spaces and extra
	line-wrapping for readability and space limitations. Similarly, some		line-wrapping for readability and space limitations. Similarly, some
	URI's contained within examples, have been shortened for space and		URI's contained within examples, have been shortened for space and
	readability reasons.		readability reasons.
	1.2. Definitions		1.2. Definitions
	The following definitions are specific to Identity Event publishing:		This specification assumes terminology defined in the Security Event
			Token specification[I-D.hunt-idevent-token].
	Feed Provider The feed provider publishes events 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 is a URI that describes the set of resources and events		The following definitions are specific to Identity Event publishing:
	under which events may be issued. An interested client registers
	with the feed provider to subscribe to events associated with a
	feed.
	Notification Mechanism A URI that describes the chosen event		Feed Provider
	notification mechanism. When subscribing to a feed, a client may		The Feed Provider publishes SETs to be distributed to registered
	choose a specific mechanism by which it wishes to receive		subscribers.
	notification events. Examples of possible delivery mechanisms
	include:
	Registered Callback - The feed provider will deliver events by		Feed
	using HTTP POST to a registered endpoint.		A Feed is a URI that describes the set of resources and events
			under which events may be issued. An interested subscriber
			registers with the feed provider to subscribe to an event URI to
			receive SETs associated with a Feed. An individual Feed MAY have
			zero or more Subscriptions.
	Polling - The subscriber will periodically poll the feed		Subscription
	provider for one or more events by performing an HTTP GET to a		A Subscription contains the information needed by a Feed Provider
	specified URI (mailbox endpoint).		(e.g. delivery endpoints, credentials) to deliver a Feed of SETs
			to an individual Subscriber. A Subscription has ONE Feed.
	Platform/Mobile Notification Services (e.g. Apple Push		Notification Mechanism
	Notification Service, Google Cloud Messaging, and Windows		A URI that describes the chosen event notification mechanism.
	Notification Services). Future profiles that support delivery		When subscribing to a feed, a client may choose a specific
	of SCIM events vis platform specific messaging services.		mechanism by which it wishes to receive notification events.
	Subscriber A Subscriber registers to receive event notifications		Subscriber
	from a feed provider.		A Subscriber is an party or security entity registers in the form
			of a Subscription to receive SETs from a feed provider that are
			part of a Feed.
	2. Event Notification Process		2. Event Notification Process
	When an event occurs, the feed provider constructs a JWT based		When a Security Event occurs, the Feed Provider constructs a SET
	Identity Event token [idevent-token] that describes the event. The		token [I-D.hunt-idevent-token] that describes the event. The feed
	feed provider determines the feeds that the event should be published		provider determines the feeds that the event should be distributed
	to, and determines which subscribers are effected. The process by		to, and determines which Subscribers need to be notified.
	which events are categorized and selected for subscribers is out of
	scope of this specification.
	When an event is available for a subscriber, the feed provider		How Feeds are defined and the process by which events are identified
	attempts to deliver the event based on the subscribers registered		for subscribers is out-of-scope of this specification.
	delivery mechanism. For example,
			When a SET is available for a subscriber, the Feed Provider attempts
			to deliver the SET based on the Subscriber's registered delivery
			mechanism:
	o The subscriber provided a web-callback endpoint, the publisher		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		uses an HTTP/1.1 POST to the endpoint to deliver the event to the
	registered subscriber;		registered subscriber;
	o For subscribers electing to poll for events, the feed publisher		o Or, the Feed Provider delivers the event through a different
	retains the events for a period of time or until the registered		method not defined by this specification.
	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 method (e.g.
	WebPUSH, Apple APNS, Google GMS), delivery is facilitated via the
	registered delivery profile for that method.
	After an event is delivered to all subscribers, feed providers will		After a SET is delivered to all subscribers, Feed Providers do not
	not typically maintain event records or histories. As such,		typically maintain SETs or histories. As such, published SETs SHOULD
	published events SHOULD be self-validating (e.g. signed).		be self-validating (e.g. signed).
	If delivery to any particular subscriber has been delayed for an		If delivery to any particular subscriber has been delayed for an
	extended period of time, the feed provider MAY suspend the		extended period of time, the Feed Provider MAY suspend the
	subscription and even stop maintaining outstanding events for the		subscription and even stop maintaining outstanding SETs for the
	subscriber at its discretion and available resources. See		Subscriber at its discretion and available resources. See
	subscription "state" in Section 4.2.		subscription "state" in Section 4.1.
	Upon receiving an event token (or tokens in the case of multiple		Upon receiving a SET, the Subscriber reads the token and validates
	events), the subscriber reads the token and validates it. Based on		it. Based on the content of the token, the subscriber decides what
	the content of the token, the subscriber decides what if any action		if any action it needs to take in response to the SET. For example,
	it needs to take in response to the event. For example, in response		in response to a SCIM event [idevent-scim] indicating a changed
	to a SCIM event [idevent-scim] indicating a changed resource, the		resource, the subscriber might perform a SCIM GET request (see
	subscriber might perform a SCIM GET request (see Section 3.4		Section 3.4 [RFC7644]) to the affected resource URI in order to
	[RFC7644] ) to the affected resource URI in order to confidentially		confidentially obtain the current state of the affected SCIM
	obtain the current state of the affected resource. The receiver of		resource.
	the event then determines what action, if any, needs to be taken
	within the subscriber's domain.
	The action a receiver takes may be substantially different than		The action a Subscriber takes in response to a SET MAY be
	merely copying the action of the publisher. A single publisher event		substantially different than merely copying the action of the
	MAY trigger multiple receiver actions. For example, upon receiving		publisher. A single SET MAY trigger multiple receiver actions. For
	notification that a user resource has been added to a group, the		example, upon receiving notification that a user resource has been
	receiver may first determine that the user does not exist in the		added to a group, the Subscriber may first determine that the user
	subscriber's domain. The receiver translates the event into two		does not exist in the Subscriber's domain. The Subscriber translates
	actions. Retrieve the user (e.g. using SCIM GET) and then provisions		the event into two actions:
	the user locally. After enabling the user, the receiver then enables
	the user for the application associated with membership in the		1. Retrieve the user (e.g. using SCIM GET) and then provisions the
	publisher's group.		user locally. After enabling the user,
			2. The Subscriber then enables the user for the application
			associated with membership in the Feed Publisher's group.
	3. Event Feeds		3. Event Feeds
	An event feed is service that provides a series of events made		An Feed is defined by a "feedUri". The Feed provides a stream of
	available that a client (known as the "subscriber") MAY subscribe to.		SETs to be delivered to registered Subscribers based on a
	A subscription contains the information about a particular client and		Subscription. An individual Subscription contains the metadata about
	their subscription to a particular "feedUri". The subscription		a particular Subscriber regarding their subscription to a particular
	metadata describes the client that has subscribed, the current		"feedUri". Subscription metadata indicates the current subscription
	delivery status indicating whether all events are delivered, pending,		state indicating whether all events are delivered, pending, or
	or whether delivery has failed. Subscription metadata also describes		whether delivery has failed. Subscription metadata also describes
	the method of event delivery and any associated configuration		the method of event delivery, and any associated security and
	information (see Section 4.2 ).		configuration information (see Section 4.1 ).
	3.1. Feed Types		3.1. Feed Types
	A feed provider MAY define feeds based on a number of criteria. This		A Feed Provider MAY define Feeds based on a number of criteria. This
	specification does not specify or limit the basis for which a service		specification does not specify or limit the basis for which a service
	provider defines a feed or how feed URIs should be specified. Some		provider defines the resources or entities contained in a Feed or how
	possible methods for defining feeds include:		feed URIs should be specified. Some possible methods for defining
			entities covered by a Feed include:
	By Resource Each resource might have its own event notification		By Resource or Subject
	feed. For example, a User's mobile application may require		A resource or subject might have its own associated event
	notification of changes or rights defined in a SCIM User resource		notification Feed. For example, a User's mobile application may
	associated with the mobile user.		require notification of changes or rights defined in a SCIM User
			resource associated with the mobile user.
	By Endpoint A feed might be defined by an endpoint where any event		By Endpoint
	relating to a resource within an endpoint is delivered to a		A Feed might be defined by an endpoint where any event relating to
	subscriber. This type of feed is likely to have many		a resource within an endpoint is delivered to a subscriber. This
	notifications as the number of resources in an endpoint grows		type of feed is likely to have many notifications as the number of
	(e.g. a SCIM "/Users"). Typically only privileged partners would		resources in an endpoint grows (e.g. a SCIM "/Users") and SHOULD
	be allowed to use this type of feed. For example an enterprise		be used with caution. Typically only privileged partners would be
	wishes to be notified of all events to any of its Users assuming		allowed to use this type of feed. For example, an enterprise
	all Users within the endpoint are related to the subscribing		wishes to be notified of all change events to any of its users
	enterprise.		assuming all users within the endpoint are related to the
			subscribing enterprise.
	By Filter A feed might define a collection of resources based on a		By Filter
	filter that describes a set of matching criteria a resource may be		A Feed might define a collection of resources based on a filter
	included in a feed. Note that this type of feed may require extra		that describes a set of matching criteria a resource may be
	processing by the service provider to determine if any particular		included in a Feed. Note that this type of Feed may require extra
	resource event matches the filter criteria. It may also be		processing by the Feed Provider to determine if any particular SET
	difficult for the service provider to notify subscribers of Feed		event matches the filter criteria. It may also be difficult for
	additions and deletions as these will occur dynamically based on		the Feed Provider to notify Subscribers of additions and deletions
	the filter.		of resources to the Feed as the resources in the Feed MAY change
			based on the filter itself.
	By Group For example, all resources within a SCIM Group could be		By Group
	used to define the resources within a particular feed. [TODO		All entities or resources within some specified group. For
	define a FEED Group extensions that define the attributes and		example, all resources within a SCIM Group could be used to define
	events included within a particular Feed Group]		the resources for which SETs will be issued within a particular
			Feed.
	How feeds are defined or implemented is out of the scope of this		The list above is intended to show common use cases for defining
	specification. The above are examples about how feeds might be		Feeds. How Feeds are defined is out-of-scope of this specification.
	defined.
	3.2. Feed Metadata		3.2. Feed Metadata
	A feed description consists of the following singular attributes:		Feed metadata consists of the following singular attributes:
	feedName		feedName
	A required string value containing a name for the feed. May be		A required string value containing a name for the feed. May be
	used in administrative user interfaces to assist subscribers in		used in administrative user interfaces to assist subscribers in
	feed selection. The value MUST be unique within a given		Feed selection. The value MUST be unique within a given
	administrative domain. This is a required attribute.		administrative domain. This is a REQUIRED attribute.
	feedUri		feedUri
	An attribute of type "String" that is a unique URI identifying the		An attribute of type "String" that is a unique URI identifying the
	feed. This attribute characteristic "mutability" is "immutable"		feed. This attribute characteristic "mutability" is "immutable"
	and SHALL NOT change once assigned. This is a required attribute.		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
			attribute.
	description		description
	A "String" attribute that describes the purpose of the feed in		A "String" attribute that describes the purpose of the feed in
	human readable form. This is an optional attribute.		human readable form. This is an OPTIONAL attribute.
			events
			An attribute whose value is 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 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		type
	A "Reference" attribute that is one of the following canonical		An OPTIONAL String attribute that MAY have values such as:
	values:
	resource Indicates that the feed is for events related to a		resource Indicates that the Feed is for events related to a
	specific resource. In such cases, the value of the attribute		specific resource. In such cases, the value of the attribute
	"filter" is set to a specific resource URI or "/Me" .		"filter" is set to a specific resource URI or "/Me" .
	endpoint Indicates that the feed is for all events that occur for		endpoint Indicates that the Feed is for all events that occur for
	resources within a specific endpoint. In such cases, "filter"		resources within a specific endpoint. In such cases, "filter"
	is set to an endpoint container for a group of resources (e.g.		is set to an endpoint container for a group of resources (e.g.
	"/Users" ).		"/Users" ).
	filter Indicates that events for a feed will be selected based on		filter Indicates that events for a Feed will be selected based on
	events relating to the set of resources described by a filter.		events relating to the set of resources described by a filter.
	The value of the attribute "filter" is a SCIM filter that		For example, the value of the attribute "filter" is a SCIM
	describes a condition that selects a set of resources that		filter Section 3.4.2 [RFC7644] that describes a condition that
	match before or after a resource state change.		selects a set of resources that match before or after a
			resource state change.
	group Indicates that events for a feed will be based on events		group Indicates that events for a Feed will be based on events
	relating to the set of resources listed in a SCIM Group. The		relating to the set of resources listed in a group such as a
	value of the attribute "filter" is a URI that corresponds to a		SCIM GroupSection 4.2 [RFC7643].
	SCIM Group containing a set of members to be monitored.
	hangText="publisher">Indicates a group whose definition is		The attribute is typically used by the Feed Publisher to determine
	specific to the service provider publisher.The value of the		the meaning and content of the Feed "filter" attribute.
	attribute "filter" if used, is defined by the service
	provider.[[SHOULD THERE BE AN EXTENSION POINT?]]
	filter		filter
	A String value containing a SCIM filter (see Section 3.4.2.2		An OPTIONAL String value containing a filter whose syntax is
	[RFC7644] ), a resource, or a SCIM endpoint URI. The contents of		defined by a profiling specification (e.g. SCIM) or the Feed
	the value is indicated by the feed "type" attribute.		Publisher. For example in SCIM, a filter MAY be a filter
			Section 3.4.2.2 [RFC7644]), a resource, or a SCIM endpoint URI
			depending on the value of "type". And, if the SCIM Feed type is
			"resource", than the filter value is a URI for a SCIM resource.
	The following multi-valued attributes are defined:		The following multi-valued attributes are defined:
	events One or more String values that contain the Event URIs		deliveryModes
	supported[[TBD]]. By default, all available events MAY be		One or more URIs representing the methods of delivery supported by
	published.		the Feed Publisher. Values in this attribute correspond to the
			Subscription "methodUri" attribute (see Section 4.1).
	deliveryModes One or more URIs representing the methods of delivery		3.3. SCIM Feed Management
	supported by the feed. By default, all delivery modes are
	supported.
	4. Subscriptions		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.
	4.1. Overview		The Feed "ResourceType" definition is typically defined as follows:
	A subscription represents an agreement to deliver events from a		{
	specified feed of events from a feed provider to an individual		"schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
	subscriber entity. The method of delivery and the parameters for		"id": "Feed",
	delivery are specified a set of parameters called subscription		"name": "Feed",
	metadata (see Section 4.2).		"endpoint": "/Feeds",
			"description": "Event Feeds",
			"schema": "urn:ietf:params:scim:schemas:event:2.0:Feed",
			"schemaExtensions": []
			}
	4.2. Subscription Metadata		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.
			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 subjects of the publisher.
			4. Subscriptions
			A subscription represents an agreement to deliver SETs from a
			specified Feed URI from a Feed Provider to an individual 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.1).
			4.1. Subscription Metadata
	A subscription is defined by the following metadata:		A subscription is defined by the following metadata:
	feedUri		feedUri
	A string value containing the URI for a feed supported by the feed		A 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		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		resolvable URI where the feed meta data may be returned as a JSON
	object. REQUIRED.		object. REQUIRED.
	deliveryUri		methodUri
	A REQUIRED single-valued string which is a URI with a prefix of		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
	Section 5:		POST delivery Section 5:
			"urn:ietf:params:set:method:HTTP:webCallback"
	urn:ietf:params:event:delivery:HTTP:webCallback		in which the Feed Provider delivers events using HTTP POST to a
	The feed provider delivers events using HTTP POST to a		specified callback URI.
	specified callback URI.
	urn:ietf:params:event:delivery:HTTP:poll		deliveryUri
	The subscriber will poll for events using HTTP GET.		A URI that describes the location SETs are delivered. Its format
			and usage requirements are defined by the associated "methodUri"
			specification.
	subUri		aud
	A URI representing the unique identifier for a single subscriber		An OPTIONAL URI representing the audience of the subscription.
	of a feed. It MAY also be an actual event polling endpoint which		The value SHALL be the value of "aud" when the subscriber receives
	the subscriber MAY use to receive such as with "deliveryUri"		SETs from the feed.
	method of "urn:ietf:params:event:delivery:HTTP:poll".
	feedJwk		feedJwk
	AN OPTIONAL JSON Web Key (see [RFC7517]) that will be used to sign		An OPTIONAL public JSON Web Key (see [RFC7517]) that will be used
	published events. If present, the subscriber can authenticate		to sign published SETs. If present, the Subscriber can
	events relayed from the feed provider.		authenticate SETs relayed from the Feed Provider.
	confidentialJwk		confidentialJwk
	An OPTIONAL subscriber provided public JSON Web Key (see		An OPTIONAL Subscriber provided public JSON Web Key (see
	[RFC7517]) that may be used by the feed provider to encrypt event		[RFC7517]) that MAY be used by the Feed Provider to encrypt SET
	messages for the subscriber.		tokens for the specified Subscriber.
	subStatus		subStatus
	An optional value which indicates the current status of a		An OPTIONAL value that indicates the current status of a
	subscription:		Subscription:
	"on" - the default setting indicates the feed provider		"on" - indicates the Subscription has been verified and that
	processing events and will pass them to the subscriber.		the Feed Provider MAY pass SETs to the Subscriber.
	"verify" - the subscription is pending verification. While in		"verify" - indicates the Subscription is pending verification.
	"verify", published events SHALL NOT be stored or delivered to		While in "verify", published SETs SHALL NOT be stored or
	the subscriber.		delivered to the Subscriber. Once verified, the status returns
			to "on".
	"paused" - indicates the feed provider is temporarily		"paused" - indicates the Feed Provider is temporarily
	suspending delivery to subscriber. While in "paused" events		suspending delivery to Subscriber. While "paused", SETs SHOULD
	SHOULD be retained and delivered when state returns to "on".		be retained and delivered when state returns to "on".
			Verification is NOT required when returning to "on".
	"off" - indicates that the subscription is no longer passing		"off" - indicates that the Subscription is no longer passing
	events. While in off mode, the subscription metadata is		SETs. While in off mode, the subscription metadata is
	maintained, but new events are ignored and not processed or		maintained, but new events are ignored, not delivered or
	retained.		retained. Before returning to "on", a verification MUST be
			performed.
	"fail" - Indicates that the feed provider was unable to deliver		"fail" - indicates that the feed provider was unable to deliver
	events to the subscriber for an extended period of time, or due		SETs to the Subscriber for an extended period of time, or due
	to a call failure to the registered web call back URI. Unlike		to a call failure to the registered web call back URI. Unlike
	paused status, a failed subscription is no longer receiving		paused status, a failed subscription no longer receives SETs,
	events nor are they retained by the feed provider.		nor are they retained by the Feed Provider. Before returning
			to "on", a verification MUST be performed.
	maxRetries		maxRetries
	An OPTIONAL number indicating the maximum number of attempts to		An OPTIONAL number indicating the maximum number of attempts to
	deliver an event. A value of '0' indicates there is no maximum.		deliver a SET. A value of '0' indicates there is no maximum.
	Upon reaching the maximum, the subscription "subStatus" is set to		Upon reaching the maximum, the Subscription "subStatus" attribute
	"failed" [[or "paused"?]].		is set to "failed".
	maxDeliveryTime		maxDeliveryTime
	An OPTIONAL number indicating the maximum amount of time an event		An OPTIONAL number indicating the maximum amount of time in
	MAY wait before delivery. Upon reaching the maximum, the		seconds a SET MAY take for successful delivery. Upon reaching the
	subscription "subStatus" is set to "failed" [[or "paused"?]].		maximum, the subscription "subStatus" is set to "failed". If
			undefined, there is no maximum time.
	minDeliveryInterval		minDeliveryInterval
	An OPTIONAL integer that represents the minimum interval in		An OPTIONAL integer that represents the minimum interval in
	seconds between deliveries. A value of '0' indicates delivery		seconds between deliveries. A value of '0' indicates delivery
	should happen immediately. When delivery is a polling method		should happen immediately. When delivery is a polling method
	(e.g. HTTP GET), it is the expected time between subscriber		(e.g. HTTP GET), it is the expected time between subscriber
	attempts. When in push mode (e.g. HTTP POST), it is the interval		attempts. When in push mode (e.g. HTTP POST), it is the interval
	the server will wait before sending a new event or events.		the server will wait before sending a new event or events.
	4.3. Subscription Verification		4.2. Subscription State Model
	In order to avoid ongoing communication issues and to minimize		The Subscription attribute "subStatus" tracks the state of any
	requirements for feed providers to maintain events indefinitely, a		particular subscription with regards to whether SETs are ready or
	verification process is used to confirm that the requested event		able to be delivered. The impact on delivery processing is described
	distribution endpoints are correct and that events may be		in Table 1.
	successfully delivered. When a subscription is created or modified,
	the feed provider SHALL set the subscription state ("subStatus") to
	"verify" and send a test event message to the subscriber. If the
	event is delivered successfully, the subscription state MAY be turned
	to "on". If however verification fails due to a hard failure, or the
	client fails to retrieve the event within a [reasonable?] period, the
	subscription status SHALL be set to "fail".
	4.3.1. Verifying 'Push' Style Subscriptions		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".
	When using the WebCallback mode, or any other 'push'-style		+
	communication scheme, the verification process serves to verify that		|
	the identified endpoint consents to receiving events and is valid.		Create
	This prevents a notification server from flooding an endpoint which		v
	did not actually request an event subscription.		+------+ +----------+
			| fail +->Restart---->| verify |
			+------+ +----+-----+
			^ |
			|<----Confirm Fail<----+
			| Confirm
			| v
			| +----------+ +--------+
			| | +--->Suspend--->| |
			+------Timeout<---+ on | | paused |
			| |<--Resume<-----+ |
			+-+--------+ +--------+
			| ^
			Disable Enable
			v |
			+--------+-+
			| off |
			+----------+
	To confirm a subscription, the feed provider SHALL send a		Figure 6: Subscription States at Feed Publisher
	verification event to the subscriber using the registered
	_deliveryUri_ mechanism. The event contains the following
	attributes:
	eventUris Set with a value of "urn:ietf:params:event:event:verify".		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:
	iss Set to the URI of the feed publisher (see [idevent-token]).		Create
			A Subscriber or an administrator creates a new subscription using
			SCIM as described in Section 4.3.2. The initial state is
			"verify".
	aud MUST be set to a value that matches the subscription "feedUri"		Confirm
	requested.		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".
	confirmChallenge A String value that the subscriber SHALL echo back		Confirm Fail
	in its response. See deliveryUri method profile for usage		If the confirmation fails, the Feed Publisher sets the state to
	details.		"fail" requiring administrative action to correct the issue and
			"Restart".
	exp A value that indicates the time the verification request will		Timeout
	expire. Once expired, the server will set the subscription state		A Feed Publisher having not being able to deliver a SET over one
	to "fail".		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.
	If a confidential JWK was supplied, then the event SHOULD be		Restart
	encrypted with the provided key. Successful parsing of the message		An administrator having corrected the failed delivery condition
	confirms that both the endpoint is valid including confirmation of		modifies the Subscription state to "verify" (e.g. see
	keys.		Section 4.3.3).
	A non-normative JSON representation of an event to be sent to a		Suspend and Resume
	subscriber as a subscription confirmation. Note the event is not yet		A Subscription MAY be suspended and resumed by updating the
	encoded as a JWT token.		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
	"jti": "4d3559ec67504aaba65d40b0363faad8",		A subscription MAY be disabled and enabled by updating the
	"eventUris":["urn:ietf:params:event:event:verify"],		Subscription state to "off" or "on". For example, see see
	"iat": 1458496404,		Section 4.3.3. While the Subscription is disabled, all SETs that
	"iss": "https://scim.example.com",		occur at the Feed Publisher are lost.
	"aud":[
	"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
	"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
	],
	"confirmChallenge":"ca2179f4-8936-479a-a76d-5486e2baacd7",
	"exp": 1458497000
	}		4.3. SCIM Subscription Management
	Upon receiving a subscription confirmation request, a confirming		A Feed Publisher MAY use SCIM to support management of subscriptions.
	subscriber responds with a confirmation using the method described in		Typically this involves support for the Subscription Resource Type,
	the deliveryUri profile. The response includes a "challengeResponse"		and the corresponding SCIM operations to create, update, retrieve
	value. For example, depending on the deliveryUri profile used, the		Subscription Resources. For SCIM service provider capability and
	subscriber might respond with the value of "confirmChallenge" . For		schema discovery, see Section 4 [RFC7644].
	example, if the request is received via HTTP/1.1 POST, then the
	following HTTP response is used to confirm. A non-normative example
	of the response is:
	HTTP/1.1 200 OK		4.3.1. SCIM Subscription Resource Type
	Content-Type: application/json
			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:
	{		{
	"challengeResponse":"ca2179f4-8936-479a-a76d-5486e2baacd7"		"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": []
	}		}
	If the subscriber returns a non-matching value or an HTTP status		Figure 7: SCIM Subscription ResourceType Definition
	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).
	4.3.2. Verifying 'Polling' Style Subscriptions
	For clients that use a subscription mode (e.g.		To retrieve information about one or more Subscriptions, Subscribers
	"urn:ietf:params:scimnotify:api:messages:2.0:poll") that pick up		or management clients MAY query the "/Subscriptions" endpoint as
	events from a subscription endpoint, the client MAY confirm the		defined in Section 3.4 [RFC7644].
	subscription by simply reading the event using an HTTP GET at the
	endpoint specified by the attribute "subUri" in the subscription.
	Once the confirmation event has been retrieved, the service provider
	MAY mark the subscription as confirmed.
	A non-normative example of a client, having previously subscribed,		The example below retrieves a specific "Subscription" resource whose
	picking up the initial subscription confirmation message.		"id" is "548b7c3f77c8bab33a4fef40".
	GET /Events/548b7c3f77c8bab33a4fef40/		GET /Subscriptions/767aad7853d240debc8e3c962051c1c0
	Host: example.com		Host: example.com
	Accept: application/scim+json		Accept: application/scim+json
	Authorization: Bearer h480djs93hd8		Authorization: Bearer h480djs93hd8
	Content-Length: ...
	To which the event provider responds with the available events which		Figure 8: Example SCIM Subscription GET Request
	SHOULD include a confirmation event (non-normative example):
			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:notify:2.0:Event"],		"schemas":["urn:ietf:params:scim:schemas:event:2.0:Subscription"],
	"publisherUri":"https://scim.example.com",		"feedName":"OIDCLogoutFeed",
	"feedUris":[		"feedUri":
	"https://notify.example.com/Feeds/98d52461fa5bbc879593b7754"		"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
	"type":"CONFIRMATION",
	"confirmChallenge":"ca2179f4-8936-479a-a76d-5486e2baacd7",		In following non-normative response, the SCIM service provider has
	"expires":""		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
			{
			"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 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 to maintain a series of SETs
			indefinitely, a verification process is used to confirm that the
			requested Subscription distribution endpoints are valid and that SETs
			may be successfully delivered. When a Subscription is created or
			modified, or goes into a failed or off state, the Feed Provider SHALL
			set the Subscription state attribute "subStatus" to "verify" and send
			a Verify SET message to the subscriber. If the SET is delivered
			successfully, the subscription state SHOULD be turned to "on". If
			however verification fails due to a timeout or connection failure, or
			any other cause, the Subscription status SHALL be set to "fail".
			4.4.1. Verifying Subscriptions
			The verification process serves to verify that the identified
			Subscriber is willing to receive SETs and is correctly configured.
			In the case of push style subscriptions, where the publisher
			initiates the action to deliver a SET, Verification can also serve to
			prevent a Feed Publication server from flooding an endpoint which did
			not actually request 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 SHALL send a
			verification SET to the subscriber using the registered "methodUri"
			mechanism. The Verify SET contains the following attributes:
			events Set with a value of "[[this RFC URL]]#verify".
			iss Set to the URI of the feed publisher (see
			[I-D.hunt-idevent-token]).
			aud MUST be set to a value that matches the subscription "feedUri"
			requested.
			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 SET SHOULD be encrypted with the provided key.
			Successful parsing of the message confirms that provides confirmation
			of correct configuration and possession of keys.
			Note that the verification event URI ("[[this RFC URL]]#verify") type
			is not normally listed as part of the definition of a Feed as it is
			not part of the normal information flow of a Feed. Any Feed MAY
			include a SET verification event whether listed or not in the Feed
			event metadata.
			Upon receiving the SET, the subscriber acknowledges receipt as
			defined by the method profile (for example, see Section 5.3.3).
			If the subscriber is unable to parse the verification SET, fails to
			return the correct challenge, or the SET is not delivered after a
			period of time. The Feed Publisher will set "subStatus" to "failed".
	5. Event Delivery		5. Event Delivery
	5.1. Introduction to Event Delivery Methods		5.1. Introduction to Event Delivery Methods
	Each event delivery method SHALL have the following information:		Each event delivery method SHOULD have the following information:
	Description		Description
	The _deliveryUri_ URI value for the delivery method and a		The "methodUri" URI value for the delivery method and a
	description of the method.		description of the method.
	Subscription Verification Procedure		Subscription Verification Procedure
	The procedure that the configuration for a subscription is		The procedure that the configuration for a subscription is
	confirmed causing the subscription status to be set to "on".		confirmed causing the subscription status to be set to "on".
	Delivery Message Format		Delivery Message Format
	A description of an event delivery message and how to locate the		A description of an event delivery message and how to locate the
	event token(s) as well as any additional signaling parameters.		event token(s) as well as any additional error signalling.
	Delivery Procedure		Delivery Procedure
	The protocol procedure for a delivery request (push or poll), and		The protocol procedure for a delivery request (push or poll), and
	the expected successful response.		the expected successful response.
	Failure Conditions		Failure Conditions
	A description of the failure conditions that might occur and the		A description of the failure conditions that might occur and the
	impact on the subscriptions operational status ("subStatus") if		impact on the subscriptions operational status ("subStatus") if
	any.		any.
	Multi-Event Message Considerations		This specification defines the first delivery method known as "HTTP
	A description of any special considerations when passing multiple		Web Callback Method" which uses HTTP POST.
	events in a single delivery.[[is this needed?]]
	5.2. HTTP Web Callback Method		5.2. Delivery Processing
	5.2.1. Description		As mentioned in Section 4.1, the attribute "subStatus" defines the
			current state of a subscribers subscription. Figure 6 shows a state
			diagram for Subscriptions. The following describes that actions
			taken by the Feed Publisher based upon "subStatus".
	This method allows a feed provider to use HTTP POST to deliver events		+--------+----------------------------------------------------------+
	to a registered web callback URL. The "deliveryUri" value for this		| Status | Action |
	method is "urn:ietf:params:event:delivery:HTTP:webCallback".		+--------+----------------------------------------------------------+
			| 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 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 is a repeat |
			| | attempt to deliver, the Feed Publisher MAY discard the |
			| | SET if "maxRetries" or "maxDeliveryTime" is exceeded. If |
			| | a SET is discarded, the Feed Publisher MAY set |
			| | "subStatus" to "failed". |
			| verify | If the SET is not a Verify SET, the SET MAY be retained |
			| | for a retry at the Feed Publishers discretion. If a |
			| | Verify SET fails to deliver, the Feed Publisher SHALL |
			| | set "subStatus" to "failed". The Feed Publish MAY opt to |
			| | make multiple attempts to complete a verification during |
			| | which status remains as "verify". |
			| paused | The SET is held for delivery in a queue. The Feed |
			| | Publisher MAY at its own discretion set the subscription |
			| | state to "failed" if "subStatus" is not returned to "on" |
			| | in what the Feed Publisher determines to be a reasonable |
			| | amount of time. |
			| off | The SET is ignored. |
			| fail | The SET is ignored due to a previous unrecoverable |
			| | error. |
			+--------+----------------------------------------------------------+
	Depending on the settings for the subscription metadata, this		Table 1: Delivery Processing By Status
	delivery method is capable of delivering multiple signed events in a
	single delivery.
	5.2.2. Delivery Message Format		5.3. HTTP Web Callback Method
	The content-type for this method is "application/json" and consists		5.3.1. Description
	of a JSON object containing the following attributes:
	eventTkns		This method allows a feed provider to use HTTP POST (Section 4.3.3
	A multi-valued String with each value containing an identity event		[RFC7231]) to deliver SETs to a registered web callback URI. The
	token ([idevent-token]). Each value MAY represent an unsigned,		Subscription "methodUri" value for this method is
	signed, or encrypted token. At least one value MUST be present in		"urn:ietf:params:set:method:HTTP:webCallback".
	a delivery request.
	eventCnt		This delivery method is capable of delivering a single SET per HTTP
	An integer representing the number of events present in the		POST request. Depending on the settings for the subscription
	message. REQUIRED.		metadata (see Section 4.1), the SET MAY be signed and/or encrypted as
			defined in [I-D.hunt-idevent-token].
	eventPend		The Subscription's "deliveryUri" attribute indicates the location of
	An boolean indicating more deliveries are pending. The default		a Subscriber provided endpoint which can accept HTTP POST requests
	value is false.		(e.g. "https://notify.examplerp.com/Events").
	invalidEvents		5.3.2. Delivery Message Format
	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.
	{		The content-type for this method is "application/jwt" and consists of
	"eventTkns":[		a single SET token (see [I-D.hunt-idevent-token]).
	"eyJhbGciOiJub25lIn0
			eyJhbGciOiJub25lIn0
	.		.
	eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV		eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
	kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj		kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
	FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ		FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
	WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6		WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
	WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ		WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
	hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG		hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
	VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX		VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
	SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk		SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
	b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF		b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
	tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW		tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
	1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ		1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
	."],		.
	"eventCnt":1,
	"eventPend":false
	}
	Example Web Callback POST Message		Figure 13: Example Web Callback POST Message
	5.2.3. Subscription Verification		5.3.3. Subscription Verification
	See Section 4.3.1.		This profile specifies the verification method for HTTP POST and is
			based on the general verification method described in Section 4.4.1.
	5.2.4. Delivery Procedure		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.
	To deliver an event, the publisher generates an event delivery		A payload attribute "confirmChallenge" is provided with a String
	message and uses HTTP POST to the registered endpoint.		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:
	POST /Events HTTP/1.1
	Host: notify.example.com
	Accept: application/json
	Content-Type: application/json
	{		{
	"eventTkns":[		"jti": "4d3559ec67504aaba65d40b0363faad8",
	"eyJhbGciOiJub25lIn0		"events":["[[this RFC URL]]#verify"],
	.		"iat": 1458496404,
	eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV		"iss": "https://scim.example.com",
	kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj		"exp": 1458497000,
	FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ		"aud":[
	WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6		"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
	WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ		"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
	hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
	VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
	SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
	b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
	tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
	1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
	.",
	"eyJhbGciOiJub25lIn0
	.
	eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
	kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
	FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
	WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
	WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
	hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
	VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
	SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
	b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
	tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
	1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
	."
	],		],
	"eventCnt":2		"[[this RFC URL]]#verify":{
			"confirmChallenge":"ca2179f4-8936-479a-a76d-5486e2baacd7"
			}
	}		}
	Example Web Callback POST Request		Figure 14: Example Verification SET with Challenge
	In response, if the event token is validated, the server SHALL		The above SET is encoded as a JWT and transmitted to the Subscriber
	indicate successful submission by responding with:		as shown in Figure 16.
	HTTP/1.1 202 Accepted		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".
	or to indicate errors it MAY respond with		The following is a non-normative example response to a Verify SET
	HTTP/1.1 202 Accepted		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		Content-Type: application/json
	{		{
	"invalidEvents":[		"challengeResponse":"ca2179f4-8936-479a-a76d-5486e2baacd7"
	{"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 to forward events		Figure 15: Example Response to Verify SET with Challenge
	to registered subscribers, the Feed Provider is not obligated to
	inform the publisher of a permanent event URI that was created.
	Servers MAY allow HTTP clients to check for undelivered events by
	performing a GET against the same endpoint as the Event submission
	endpoint described above.
	5.2.5. Failure Conditions
	[[TO BE COMPLETED]]		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. HTTP Polling		5.3.4. Delivery Procedure
	5.3.1. Description		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".
	This method allows a subscriber to use HTTP GET to poll for events to		POST /Events HTTP/1.1
	the "subUri" provided to the subscriber by the publisher. The
	"deliveryUri"value for this method is
	"urn:ietf:params:event:delivery:HTTP:poll".
	Depending on the settings for the subscription metadata, this		Host: notify.examplerp.com
	delivery method is capable of delivering multiple signed events in a		Accept: application/json
	single delivery poll request.		Content-Type: application/jwt
			"eyJhbGciOiJub25lIn0
			.
			eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
			kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
			FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
			WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
			WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
			hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
			VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
			SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
			b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
			tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
			1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ
			.
	5.3.2. Delivery Message Format		Figure 16: Example Web Callback POST Request
	The delivery message is the same as Section 5.2.2.		Upon receipt of the 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].
	5.3.3. Subscription Verification		If the SET is determined to be valid, the Subscriber SHALL indicate
			successful submission by responding with HTTP Status 202 as
			"Accepted" (see Section 6.3.3 [RFC7231]).
	Subscription verification is described in Section 4.3.2.		If SET or JWT is invalid, or there is an HTTP error, the Subscriber
			SHALL respond with the appropriate HTTP error or an HTTP Status 400
			Bad Request error as follows:
	5.3.4. Delivery Procedure		+----------+--------------------------------------------------------+
			| Err | Description |
			| Value | |
			+----------+--------------------------------------------------------+
			| jwtParse | Invalid or unparsable JWT or JSON structure. |
			| jwtHdr | In invalid JWT header was detected. |
			| jwtCypto | Unable to parse due to unsupported algorithm. |
			| jws | Signature was not validated. |
			| jwe | Unable to decrypt JWE encoded data. |
			| jwtAud | Invalid audience value. |
			| jwtIss | Issuer not recognized. |
			| setType | An unexpected event type was received. |
			| setParse | Invalid structure was encountered such as inability to |
			| | parse SET event payload. |
			| setData | SET event claims incomplete or invalid. |
			| dup | A duplicate SET was received and has been ignored. |
			+----------+--------------------------------------------------------+
	To deliver an event, the publisher places the event in a queue/buffer		Table 2: HTTP Status 400 Errors
	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 HTTP GET to the URI		The following is a non-normative example of a successful receipt of a
	provided by the event publisher in "subUri".		SET.
	In response to the HTTP GET request, the feed publisher responds with		HTTP/1.1 202 Accepted
	a body that corresponds to the event delivery message format (see
	Section 5.2.2).
	An example polling request by a subscriber. The example has been		Figure 17: Example Successful Delivery Response
	formatted for readability:
	GET /subscriber/66444423ab24430fb06cf0de1ab75247		An HTTP Status 400 Bad Request response includes a JSON object which
	Host: pub.example.com		provides details about the error. The JSON object includes the JSON
	Accept: application/json		attributes:
	Authorization: Bearer h480djs93hd8
	An example poll response (formatted for readability):		err
			A value which is a keyword that describes the error (see Table 2).
	HTTP/1.1 200 OK		description
	Content-Type: application/json		A human-readable text that provides additional diagnostic
	Location:		information.
	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
	}
	[[TO BE DISCUSSED: Should the subscriber be able to request events		The following is an example non-normative Bad Request error.
	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		HTTP/1.1 400 Bad Request
			Content-Type: application/json
	[[TO BE DISCUSSED: The polling mode provides no way for a subscriber		{
	to indicate parsing validation errors directly in response to a		"err":"dup",
	delivery. When errors occur, subscriber administrators must re-		"description":"SET already received. Ignored."
	confirm the subscription configuration.]]
	5.4. Push Notification Extensions		}
	[[TO BE COMPLETED]]		Figure 18: Example Bad Request Response
	6. Security Considerations		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]		[TO BE COMPLETED]
	7. IANA Considerations		7. IANA Considerations
	7.1. SCIM Event Notification Mechanism Registry		7.1. Event Notification Mechanism Registry
	TODO: Registration for Notification Mechanisms		[TODO: Registration for Notification Mechanisms]
	7.2. SCIM Event Type Registry		7.2. SCIM Schema Registration
	TODO: Registration of Event Types		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.
			+-----------------------+--------------+--------------+-------------+
			| Schema URI | Name | ResourceType | Reference |
			+-----------------------+--------------+--------------+-------------+
			| urn:ietf:params:scim: | SET Event | Feed | Section 3.3 |
			| schemas:event:2.0: | Feed | | |
			| Feed | | | |
			| urn:ietf:params:scim: | SET Event | Subscription | Section 4.3 |
			| schemas:event:2.0: | Subscription | | |
			| Subscription | | | |
			+-----------------------+--------------+--------------+-------------+
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[idevent-token]		[I-D.hunt-idevent-token]
	Oracle Corporation, "Identity Event Token (work in		Hunt, P., Denniss, W., Ansari, M., and M. Jones, "Security
	progress)".		Event Token (SET)", draft-hunt-idevent-token-05 (work in
			progress), September 2016.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<http://www.rfc-editor.org/info/rfc3986>.		<http://www.rfc-editor.org/info/rfc3986>.
	[RFC5988] Nottingham, M., "Web Linking", RFC 5988,		[RFC5988] Nottingham, M., "Web Linking", RFC 5988,
	DOI 10.17487/RFC5988, October 2010,		DOI 10.17487/RFC5988, October 2010,
	<http://www.rfc-editor.org/info/rfc5988>.		<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		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<http://www.rfc-editor.org/info/rfc7519>.		<http://www.rfc-editor.org/info/rfc7519>.
	[RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.		[RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
	Mortimore, "System for Cross-domain Identity Management:		Mortimore, "System for Cross-domain Identity Management:
	Core Schema", RFC 7643, DOI 10.17487/RFC7643, September		Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
	2015, <http://www.rfc-editor.org/info/rfc7643>.		2015, <http://www.rfc-editor.org/info/rfc7643>.
	[RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,		[RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
	skipping to change at page 22, line 16 ¶		skipping to change at page 29, line 24 ¶
	Appendix B. Acknowledgments		Appendix B. Acknowledgments
	The editor would like to thank the participants in the the SCIM		The editor would like to thank the participants in the the SCIM
	working group for their support of this specification.		working group for their support of this specification.
	Appendix C. Change Log		Appendix C. Change Log
	Draft 00 - PH - First Draft		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		Authors' Addresses
	Phil Hunt (editor)		Phil Hunt (editor)
	Oracle Corporation		Oracle Corporation
	Email: phil.hunt@yahoo.com		Email: phil.hunt@yahoo.com
			Marius Scurtescu
			Google
			Email: mscurtescu@google.com
	Morteza Ansari		Morteza Ansari
	Cisco		Cisco
	Email: morteza.ansari@cisco.com		Email: morteza.ansari@cisco.com
End of changes. 159 change blocks.
	572 lines changed or deleted		882 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/