SET Security Event Stream Management and ProvisioningOracle Corporationphil.hunt@yahoo.comInternet-Draft
This specification defines a "control plane" service which
enables a client (e.g. an Event Receiver) to establish,
monitor, and manage a Security Event Token
Stream.
This specification defines a "Control Plane" service that defines
how an Event Receiver or its agent may provision, monitor, and manage
the configuration of an Event Stream that delivers Security Event Tokens
(see ) using delivery
methods such as specified in the SET Delivery Using HTTP
Specification (see ).
The specification defines the common metadata Event Transmitters
and Receivers use to describe HTTP service endpoints, methods, optional
signing and encryption modes, as well as the type and content of SETs
delivered over a Stream. The specification defines how
the Event Receiver parties may review and update the current
configuration and confirm operational delivery status using HTTP over TLS.
The mandatory part of this specification (see )
uses a profile of SCIM (see and
) to implement Event Stream configuration, monitoring
and retrieval using HTTP GET Section 4.3.1.
Additionally, SCIM MAY be used to manage and update Event Stream
configuration and operational state.The choice os SCIM has been recommended as it is intended as
a general purpose layer that can be applied to many underlying systems.
SCIM's extensibility mechanisms to define data types (resource types)
enable it to be flexibly used by specifications intenting to profile
SET Tokens and Delivery for use in many ways.For the purposes of the Control Plane, SCIM Section 2
provides the JSON data definitions that enable the Control Plane to allow
service providers and clients to negotiate attributes and
resource types used in different SET Profiles. This includes
declarations and discovery of attribute types, mutability,
cardinality, and returnability that MAY differ between deployments
and SET Event type profiles. For HTTP protocol handling and error
signaling, the processing rules in SHALL be applied.
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
. 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. Many examples
show only partial response and may use ...
to indicate omitted data.
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.
This specification assumes terminology defined in the Security
Event Token specification
and SET Token Delivery specification .
The following definitions are defined for Security Event distribution:
A Control Plane represents an service offered by an Event
Transmitter that lets an Event Receiver query the current
operational and/or error status of an Event Stream. The
Control Plane MAY also be used to retrieve Event Stream
and SET configuration data.
The Data Plane represents the HTTP service offered by an
Event Receiver that allows the Event Transmitter to
deliver multiple SETs via HTTP POST as part of an Event
Stream.A Client is any actor, typically
represented by an authorization credential, authorized to
make changes to an Event Stream. Verify often this is
an actor belonging to the Event Receiver organization. Actors
can be servers, monitoring services, and administrators.The Control Plane is an HTTP service associated with an Event
Transmitter that enables the provisioning and monitoring of Event
Streams by entities such Event Receivers, administrators, and
monitoring services. This section describes required functionality
to enable Event Receivers to retrieve configuration attributes and
to detect SET delivery problems that may occur when an Event
Transmitter fails to deliver SETs.This specification also defines optional Control Plane services
to create and update streams in sections
and .
An Event Stream is defined by a set of attributes which together
define an Event Stream's operational configuration:
A read only array of JSON
String values which are the URIs of events configured for the
Event Stream. This attribute is assigned by the Control Plane
provider in response to receiving an Event Stream creation or
update request. See eventUris_req.An array of JSON String values
which are the URIs of events requested by the Event Receiver for
the Stream. This attribute is modifiable. An Event Stream
provider MAY use this attribute to request requested Event URIs
over time that may not be initially offered.A read only array of
JSON String values which are the URIs of events that the Event
Transmitter is able to support. This attribute MAY be used by
Control Plane clients to discover new events that may become
available over time.A REQUIRED JSON String value
which represents the method used to transfer SETs to the Event
Receiver. See .A JSON String value
containing a URI that describes the location where
SETs are received (e.g. via HTTP POST). Its format and usage requirements are
defined by the associated methodUri.The URI for the publisher of the SETs
that will be issued for the Event Stream. See
Section 2.1.An OPTIONAL
JSON Array of JSON String values which are URIs representing
the audience(s) of the Event Stream. The value SHALL be the value
of SET "aud" claim sent to the Event Receiver.
An OPTIONAL
String that contains the URL of the SET issuers public JSON
Web Key Set . This contains
the signing key(s) the Event Receiver uses to validate SET
signatures from the Event Transmitter that will be used by the
Event Receiver to verify the authenticity of issued SETs. An OPTIONAL
JSON Web Key Set that contains the
Event Receiver's encryption keys that MAY be used by the
Event Transmitter to
encrypt SET tokens for the specified Event Receiver.An OPTIONAL
JSON String keyword that indicates the current state of an Event Stream.
More information on the Event Stream state can be found in
. Valid keywords are:on - indicates the Event Stream
has been verified and that the Feed Provider MAY pass
SETs to the Event Receiver.paused - indicates the
Event Stream is temporarily suspended. While
paused, SETs SHOULD be
retained and delivered when state returns to
on. If delivery is paused
for an extended period defined by the Event Transmitter,
the Event Transmitter MAY change the state to
off indicating SETs are
no longer retained.off - indicates that the
Event Stream is no longer passing SETs. While in off mode,
the Event Stream configuration is maintained, but new events
are ignored, not delivered or retained. Before returning
to on, a verification MUST
be performed.fail - indicates that the
Event Stream was unable to deliver SETs to the
Event Receiver due an unrecoverable error or for an
extended period of time. Unlike paused
status, a failed Event Stream does not retain existing
or new SETs that are issued. Before returning
to on, a verification MUST
be performed.An OPTIONAL
JSON number indicating the
maximum number of attempts to deliver a SET. A value of '0'
indicates there is no maximum. Upon reaching the maximum, the
Event Stream status attribute is set
to failed.
An OPTIONAL number indicating
the maximum amount of time in seconds a SET MAY take for
successful delivery per request or cumulatively across
multiple retries. Upon reaching the maximum, the
Event Stream status is set
to failed. If undefined, there
is no maximum time.
An OPTIONAL JSON 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 Event Receiver attempts.
When in push mode (e.g. HTTP POST), it is the interval the server
will wait before sending a new event or events.
An OPTIONAL JSON String keyword value.
When the Event Stream has subState
set to fail, one of the following
error keywords is set:connection indicates an
error occurred attempting to open a TCP connection with
the assigned endpoint.tls indicates an error
occurred establishing a TLS connection with the assigned
endpoint.dnsname indicates an error
occurred establishing a TLS connection where the dnsname
was not validated.receiver indicates an error
occurred whereby the Event Receiver has indicated an error
for which the Event Transmitter is unable to correct.
An OPTIONAL String value that is
usually human readable that provides further diagnostic
detail by the indicated txErr
error code.A String value that when changed
or set by a Control Plane client will cause the Event Transmitter
to issue a single Verify Event based on the nonce value provided (see
). The intent of the value is to
allow the Event Receiver to confirm the Verify Event received
matches the value set in the configuration. While this value MAY
be updated (see ), its value is
usually not returned as part of an Event Stream configuration.
An OPTIONAL complex attribute containing sub objects whose
sub-attributes define subjects against which SETs may be issued.
The following sub-attributes are defined:A String which uniquely identifies a
subject (or set of subjects) to be included in the Stream.
The format and type of value is defined by the 'type'
sub-attribute.A String which contains the URI of the
issuer of the subject identified in the
value attribute. When not supplied
the issuer is assumed to be the Event Stream issuer.
A case-insensitive canonical String value
which defines the contents of the attribute 'value'. Valid
type values are:Is a String value corresponding to an OpenID
Connect subject. The corresponding iss
attribute is set with the OpenId Connect iss value. A String value that is a URI that
represents the subject of a SAML Identity Provider.A String Value that is the Email
addresses for a subject. The value SHOULD be specified
according to .Phone numbers for the user. The value
SHOULD be specified according to the format defined in
, e.g., 'tel:+1-201-555-0123'.A SCIM User where value is the 'id' of a
User resource in the local SCIM service provider.A SCIM Group where the value is the 'id'
of a Group resource in the local SCIM service provider.A miscellaneous subject that can be
identified by a URI.Additional Event Stream configuration (attributes) MAY be defined
as extensions. The method for adding new attributes is defined in
Section 3.3.An Event Receiver MAY check the current status of a Stream
the Event Transmitter's Control Plane service by performing an
HTTP GET using the provided URI from the Event Transmitter either
through an administrative process or via the optional Stream
creation response defined in .The format of the Stream GET request and response is defined
by Section 3.4.
In addition to the basic attributes defined in
Section 2 common to all resource
types, an EventStream resource types
uses the attributes defined in .
As with any SCIM resource, an EventStream
resource MUST include the JSON attributes schemas
and id as defined in :
Is an array of Strings with at
least a single value of
urn:ietf:params:scim:schemas:event:2.0:EventStream.
Configuration MAY be extented through the addition of other schema
URI values such as in the case where a new delivery method or
SET profile needs to define additional attributes.Is a String which is a permanent unique
identifier for EventStream resources.
The value which is also used to define a permanent Event Stream
Resource URI.In the above figure, the EventStream
shows a status of fail
due to a TCP connection error. In this case, the Event Receiver is
able to discover that its endpoint was unavailable and has been
marked failed by the Event Transmitter (possibly explaining a lack
of received SETs). Typically, with this
type of error, appropriate operations staff would be alerted and some
corrective action would be taken to check for a configuration
error or service failure.The frequency with which Event Receivers poll the
Event Stream status depends on factors such as:
The level of technical fault tolerance and availability of the
receiving endpoint.The amount of risk that can be tolerated for lost
events. For example, if Security Events are considered informational,
then infrequent (hourly or daily) may be sufficient.The amount of buffer recovery offered by an Event Transmitter
which MAY be minutes depending on SET frequency and buffer size.
In many cases Event Stream status monitoring may be triggered on a
timeout basis. Event Receivers would typically poll if they have not
received a SET for some period during which SETs would be expected
based on past experience.
Receivers MAY use the endpoint
/EventStreams to query and retrieve available
Event Streams based on the provided Authorization
header.
The Event Stream configuration attribute status
reports the current state of an Event Stream with regards to
whether the stream is operational or is in a suspended or failed state.
Additionally, the status attribute
can be used to pause or stop streams using the stream configuration
update functions described in .In , the following actions impact the
operational state of an Event Stream. status
values are shown in the boxes, and change based on the following
actions:A Event Receiver or an administrator creates
a new Event Stream as described in .
The initial state is on.An Event Transmitter that has not been
able to deliver a SET over one or more retries which has reached
a limit of attempts (maxRetries)
or time (maxDeliveryTime)
MAY set the Event Stream state to fail.
What stream status is set to failed,
the Event Transmitter is indicating that SETs are being lost
and may not be recoverable.A paused Event Stream has reached
the transmitters ability to retain SETs for delivery. The Event
Transmitter changes the state to off
indicating SET loss is potentially occurring.An administrator having corrected the
failed delivery condition modifies the Event Stream state to
on (e.g. see ).
An Event Stream MAY be
suspended and resumed by updating the Event Stream state to
paused or on. For
example, see see . While suspended,
the Event Transmitter retains undelivered SETs for a period of time
and resources specified by the Event Transmitter (see
Limited).A Event Stream MAY be
disabled and enabled by updating the Event Stream state to
off or on. For
example, see see . While the Event Stream
is disabled, all SETs that occur at the Event Transmitter are lost.This section describes optional Stream management provisioning
features that allow receivers or provisioning systems to create
streams and update configuration to perform actions such as
rotation, and operational state (e.g. suspend, stop, or resume)
management.The operations specified in this section are based on .
SCIM schema declarations for the EventStream
resources are defined in
. HTTP Protocol usage and
processing rules are provided by .To define an Event Stream, the Event Receiver or its administrator
(known as the client) first obtains an authorization credential
allowing the ability to define a new Stream. Note: the process
for registering to obtain credentials and permission to register
is out-of-scope of this specification.Upon obtaining authorization, the client issues an HTTP POST
request as defined in Section 3.3.
To complete the request, the administrative entity provides the
required Stream configuration attributes as specified
in , the delivery method
and any additional
configuration specified by the SET Event Specifications that are
being used.The client MAY discover the Event Transmitter's
Control Plane service for the schema requirements for
EventStream resource type and any
other extensions using SCIM schema discovery in
Section 4.
The process to create an Event Stream is as follows:The client initiates an HTTP POST to the Control Plane
endpoint and provides a
JSON document defining an EventStream which contains information
about the Event Receivers endpoints, settings, and keys.Upon validating the request, the Event Transmitters control
plane provisions the stream and updates the EventStream configuration
with the corresponding Event Transmitter information.The Control Plane responds to the request from step 1 and
returns the final representation of the Event Stream configuration
along with a pointer to the created EventStream resource that
the client MAY use to monitor status and update configuration.Upon receiving the response, the client completes the
client side configuration and provisioning based upon the
returned EventStream configuration.Two HTTP methods are available to update an Event Stream
configuration. The HTTP PUT operation accepts a JSON Document
representing an existing EventStream configuration and replaces
it.An optional HTTP PATCH operation uses a JSON Patch
style request format to allow manipulation
of specific EventStream configuration such as
(but not limited to) status, and
subjects.The HTTP PUT method allows a client having previously
received the EventStream JSON document to modify the document
and replace the Control Plane provider's copy. In using this
method, the client is not required to remove data normally
asserted or defined by the Event Stream Control Plane provider
(e.g. attributes that are read only).
The processing rules of enable the
client to "put back" what was previously received allowing
the Control Plane provider to figure out what attributes
need updating and which attributes are ignored. For example,
while "id" is immutable, the Control Plane provider will simply
ignore attempts to replace its value. When processing is complete
the final accepted state is represented in the HTTP Response.Periodically, Event Receiver parties MAY have need to update an
EventStream configuration for the purpose of:Rotating access credentials or keysUpdating endpoint configurationMaking operational changes such as pausing, resetting, or
disabling an Event Stream.Other operations (e.g. such as adding or removing subjects)
as defined by profiling Event specifications.As documented in Section 3.5.2,
one or more PATCH operations (which are based on
) can be made against a single
EventStream resource. The update is expressed as a JSON document.
The JSON document contains an attribute Operations
which contains an array of JSON objects each of which each have the
following attributes:A JSON attribute whose value is one of
add, remove,
or replace.A JSON attribute whose value is a document
attribute path (see Section 3.5.2)
describing the attribute or sub-attribute or
value to be updated in the case of multi-valued complex attributes
such as subjects.The value to be assigned to the JSON
document attribute defined in path.In the above figure, upon receiving the request, the Event
Transmitter would stop sending Events to the Receiver based on
the requested value of status being
set to paused.
In the above request, the second operation, the remove operation,
uses a path attribute to specify a
matching filter the correct array element of subjects
by matching the appropriate sub-attributes which are denoted by
square brackets (see Figure 1 and 2
for other examples and ABNF for filters).
In this case the composite filter of the subjects sub-attributes
type and value
are used to remove the correct JSON array element.
Upon receiving the request, the EventStream subjects attribute would be
updated to reflect the changes.
The extensibility of SCIM enables many ways to model
subjects that are part of an Event Stream. This section
explores a few alternatives that profiling specifications could
use to manage the contents of an Event Stream. These examples
include managing subjects:As an attribute of an Event Stream configuration (see );As a member of SCIM Group (see ); and,As a specific Subject resource (see ).As a privacy and scalability consideration, profiling specifications SHOULD
consider that most deployments SHOULD not allow the subjects that
are part of an Event Stream to be enumerated in a single request.
For example, in ,
the Event Stream configuration attribute subjects
is typically not returned when querying Event Stream configurations
(see ). This is because the number of
values may be too large (e.g. great than 100k values or even
in the billions or more). Further, depending on the Security
Event types being exchanged, Event Receivers MAY confirm that a
subject is part of a stream for privacy reasons. The ability to return attributes such as subjects
is indicated by Control Plane service providers in schema discovery
(see Section 4) as the schema attribute
returned. For subjects
this attribute SHOULD be set to request or
never. In request mode,
the client must specifically request the attribute subjects
to have it enumerated. If the mode is never,
the attribute SHALL NOT be returned to clients. In all cases however,
a client MAY execute a query to verify the presence of a subject:In this section, examples are given using the
subjects attribute of Event Stream
configuration described in The following sections assume subject membership within streams
is defined by the subjects attribute of
the Event Stream configuration. As defined, subjects can support a
number of value types including: OIDC Connect Subjects, SCIM Users
and Groups, e-mail and telephone number identifiers, and URI referencable
entities. Checking subject membership is a matter of performing a query
using a filter to achieve a match based on a value of the
subjects attribute.In this section, values have been added to the
subjects attribute that are email
addresses which clients to the Control Plane would like to verify are
present or not. The subjects attribute
has sub-attribute type set to
EMAIL and the sub-attribute
value contains an email address.In this section, values in the
subjects attribute are OIDC users
which clients would like to verify are present. The attribute
subjects has the sub-attribute
type set to OIDC
and the sub-attribute value contains
an OIDC sub value and the
iss sub-attribute contains the
corresponding OIDC Provider iss value.
For this example, the OIDC iss is
op.example.com and the
sub is 123456.In the above request note that iss
and value are enclosed within
square brackets. This is done, per Figure 1 to
ensure the matching condition within "[" and "]" is matched
against the same JSON array record. If the filter was expressed as
(subjects.value eq "123456" and subjects.iss eq "op.example.com")
Then an improper match may occur because a composite value of
subjects
may have 123456 while another has
op.example.com.For examples of responses to ,
see and Adding and removing subjects to an Event Stream is performed
using the HTTP PATCH method described in .
The following provides examples of adding and removing subjects
based on EMAIL and OIDC subects. SCIM defines a resource type called a
Group which can be used as a container
to manage one or more objects in a collection (See Section 4.2 of ).
Groups work in similar fashion to the operations described in
except instead of operations against
the 'subjects, the members
attribute is used. Typically the value of the members attribute is
the id of a local User or Group.
In order to use this method, the Stream configuration indicates
the SCIM Group being used by adding Group as a member of the subjects
attribute of the Stream configuration and indicating a
type of Group.In this section, values have been added to the
members attribute are
id values of known SCIM resources.
These values can be queried against the Group to see if the
id is a member.If the requester does not know the id
of the resource for which they would like to check membership,
a query can be performed as described in Section 3.4.
Adding and removing Users to an Event Stream Group is performed
using the HTTP PATCH method described in .
The following provides examples of adding and removing Users
to a GroupThis section demonstrates how to model subject participation in
an Event Stream by treating subjects as a resource (a Subject).
In this model, a subject is added, removed, and queried from an Event
Stream by through HTTP POST, DELETE, and GET methods.
In this model, a new SCIM resource type is defined that
describes the Subject resource and
its associated schema.To add a Subject to a Stream, an HTTP POST is used to create a new
Subject resource which contains attributes identifying the subject
and the associated Event Stream id.Should the record be a duplicate Subject, the Control Plane
implementation MAY choose to return the original resource registration
and location with HTTP Status 200 (OK).To query Subjects, SCIM filters can be used to return matching
resources as per Section 3.4.2Assuming only one match is found, than a response similar
to is returned. If
not matches occur, a response is returned with totalResults
equal to 0. If more than one match is returned, the additional
matches are returned in the Resources
array.Assuming the id of the Subject
resource is known, HTTP DELETE MAY be used. If it is not known,
the id MAY be queried as per .In the verify process, the Event Receiver organization initiates
a request to the Event Transmitter to verify the Stream is working
correctly. This can be used to both test for configuration errors
(e.g. incorrect keys for signing and/or encryption, endpoints)
and to verify operational state by using a Verify Event as an
occasional 'ping' test. To initiate a Verify Event, the Event Receiver organization
using the Control Plane to set a nonce value for the Stream
Configuration attribute verifyConfirm.
Once set, the Event Transmitter SHALL issue a Verify SET
the includes the client specified nonce value. Upon the changing of the Event Stream configuration attribute
verifyNonce, the Event Transmitter
sends a Verify Event SET to the Event Receiver using the registered
methodUri mechanism.The Verify SET contains the following attributes:Set with an event attribute of
urn:ietf:params:secevent:verification
and
contains the sub-attribute nonce
which contains the value of verifyNonce
.Set to the URI defined in the Event Stream
configuration.MUST be set to a value that matches the
EventStream aud value agreed to.If the Event Stream is configured to encrypt SETs for the
Event Receiver, then the SET MUST be encrypted with
the provided key. Successful parsing of the
message confirms that provides confirmation of correct
configuration and possession of keys.The above SET is encoded as a JWT and transmitted to the
Event Receiver using the configured delivery method.Upon receiving a verify SET, the Event Receiver SHALL parse
the SET and verify its claims. In particular, the Event Receiver
SHALL confirm that the values for nonce
match the value assigned to verifyNonce
in the Event Stream Configuration via the Control Plane. If
the values do not match, administrative action should be taken
to address the mis-configuration. Similarly if the SET is not
received or is unparseable, the Event Receiver organization
can check Event Stream configuration and check for errors by
reviewing the Stream configuration attributes status
and txErr. See Section 7.5 for protocol
specific privacy considerations.The Privacy Considerations of SET Token Specification
and the SET Token
Delivery specification
SHALL apply.The exact set of subject entities upon which SETs can be
issued SHOULD NOT be made available to any single party. This is
because a subject's relationship with an Event Transmitter
MAY change over time and may not be known to the Event Receiver.
A design consideration is that an Event Receiver MUST already
know personal identifiers before asking an Event Transmitter
if there is an existing relationship by asking if that
personal identifier is part of a stream. Accordingly the
subjects attribute of an Event
Stream can not normally be returned. Instead, a Control Plane
provider MAY confirm a subject is part of a stream. See
and .When receiving a request from a Control Plane client to
add a subject, the provider SHOULD consider if the subject is
appropriate to the purpose of the Event Stream being managed. For
example, for an OpenID Connect Provider, was consent obtained
to share security data with the Relying Party. Such authorization
may have been previously authorized by a user via the OpenID
consent process. Having obtained consent, the Control Plane
provider SHOULD consider
if the SET Events being requested to be streamed are appropriate. This specification depends on the Security Considerations of
. Implementations SHOULD support access roles which enable
different types of access to Event Streams via the Control
Plane service. A minimal suggested set of roles includes:
For clients to retrieve Event Stream
configuration and obtain current status. Access is limited
to read-only operations.Adds the ability to modify the
status attribute to control the
operational state of the Event Stream in addition to the rights
granted by Monitor.Provides the ability to list, create and manage
Event Streams including updating and verifying subjects.
Typically these roles are rights or scopes associated with the
security credential presented in the HTTP Authorization header
of requests (see Section 7). The
method by which these roles are implemented is out of scope
of this specification. IANA is requested to add an entry to the 'IETF URN Sub-namespace
for Registered Protocol Parameter Identifiers' registry and create a
sub-namespace for the Registered Parameter Identifier as per : urn:ietf:params:secevent:verification.The identifier is used to indicate a Verify Event as defined
in for use in the events
attribute defined in .As per the "SCIM Schema URIs for Data Resources" registry established
by Section 10.3, the following defines and registers
the following SCIM URIs and Resource Types for Feeds and Event Streams.Schema URINameResourceTypeReferenceurn:ietf:params:scim: schemas:event:2.0: EventStreamSET Event StreamEventStreamAttributes for SET Event Streams are defined in SCIM Schema and ResourceType definitions are defined in OpenID Connect Core 1.0NRIThe EventStream resource type definition
is defined as follows:
The resource type above is discoverable in the
/ResourceTypes endpoint of a SCIM service
provider and informs SCIM clients about
the endpoint location of EventStream resources and the SCIM schema used
to define the resource. The corresponding schema for the EventStream
resource MAY be retrieved from the SCIM /Schemas
endpoint (see Section 3.2).
The attributes for the EventStream resource type are defined in
.The editors would like to thanks the members of the SCIM WG which
began discussions of provisioning events starting with: draft-hunt-scim-notify-00 in 2015.This draft is a re-work of material from Sections 2 and 4 of
draft-hunt-secevent-distribution-01. The editor would like to thank
Marius Scurtescu, Tony Nadalin, and Morteza Ansari for their
contributions in previous drafts.The editor would like to thank the participants in the the SECEVENTS
working group for their support of this specification.Draft 00 - PH - First Draft based on control plane portions of draft-hunt-idevent-distribution