forked from independentid/Identity-Events
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-hunt-idevent-token-00.xml
553 lines (478 loc) · 25.8 KB
/
draft-hunt-idevent-token-00.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-hunt-idevent-token-01" ipr="trust200902">
<front>
<title abbrev="draft-hunt-idevent-token">Identity Event Token</title>
<author fullname="Phil Hunt" initials="P." role="editor" surname="Hunt">
<organization abbrev="Oracle">Oracle Corporation</organization>
<address>
<email>phil.hunt@yahoo.com</email>
</address>
</author>
<author fullname="William Denniss" initials="W." surname="Denniss">
<organization abbrev="Google">Salesforce.com</organization>
<address>
<email>wdenniss@google.com</email>
</address>
</author>
<author fullname="Morteza Ansari" initials="M.A." surname="Ansari">
<organization abbrev="Cisco">Cisco</organization>
<address>
<email>morteza.ansari@cisco.com</email>
</address>
</author>
<date year="2016"/>
<keyword>Identity</keyword>
<keyword>Event</keyword>
<keyword>Token</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This specification defines an Identity Event token which may
be distributed via a protocol such as HTTP. An identity event token
is based on the JSON Web Token and may be optionally signed and/or encrypted. It
describes a statement of fact that may be shared by an event publisher
with registered subscribers.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction and Overview" toc="default">
<t>This specification defines an extensible event token format which may
be exchanged using protocols such as HTTP. The specification builds
on the JSON Web Token format <xref target="RFC7519"/> in order to provide a self-contained
message "token" that can be optionally signed using JSON Web Signature <xref target="RFC7515"/>
and/or encrypted using JSON Web Encryption <xref target="RFC7516"/>.</t>
<t>For the purpose of this specification an "event" is a statement
of fact by a publisher (also known as an issuer) that the state of
a resource it controls has changed in some way (explicitly or
implicitly). Based on some agreed upon criteria for an event feed,
the publisher distributes the event to the appropriate subscribers.</t>
<t>[[Background: to be removed from final specification]]At the time
of writing of this specifications there are several discussions regarding the need
for identity events. Some of these include:<list style="symbols">
<t>Events to allow SCIM resource co-ordination between SCIM domains.</t>
<t>OAuth Token Revocation (see <xref target="RFC7009"/>)</t>
<t>OpenID Logout or downstream logout notification.</t>
<t>Session Cancellation</t>
<t>OpenID Risk Incident Sharing and Coordination (RISC) Events. See <xref target="RISC"/></t>
<t>The HEART WG <xref target="HEART"/> which intends to define privacy and security related events
in health-related data sharing APIs.</t>
</list>This specification uses example SCIM events which are intended
to be non-normative for the purpose of showing how an event may be
used in practice.</t>
<t>A resource state change event typically includes explicit operation events such as:
a resource has been created, modified, removed, or updated in some way.</t>
<t>In addition to explicit operations there may be higher-level statements
made that describe an effect resulting from a change. For example, a
publisher may wish to indicate that a user resource has taken over an email
identifier that may have been used in the past. This cumulative event
is a high-level statement that takes into account that another resource
had a personal identifier that potentially conflicts with a newer resource.
Because of the security impact, the publisher wishes to
notify its subscribers of the identifier re-use. In this way, the event
is not describing a particular state change to a resource, it describes
a meta-conclusion based on its own business and security rules (this
scenario is often called an 'account takeover' event).</t>
<t>A subscriber having received an event, validates and interprets the
event and takes its own independent action, if any. For example,
having been informed of a personal identifier now being associated
with a different resource (i.e. is being used by someone-else), the
subscriber may choose to ensure that the new user is not granted
access to resources associated with the previous user.</t>
<t>Events SHOULD NOT be used to convey commands or requests. To do so
requires complex bidirectional signalling and error recovery mechanisms which fall
outside the scope of this specification. The intent of this specification
is to define a way of exchanging historical statements of fact that
subscribers may interpret for their own use.</t>
<t>This specification is scoped to security and identity related events.
While event tokens may be used for other purposes, the specification
only considers security and privacy concerns relevant to identity
and personal information.</t>
<t>This specification may be optionally used with the identity
event subscription management specification which provides the details
of event feeds and how subscribers register for events(see
<xref target="idevent-subscription"/>), defines a protocol registry for
event transmission methods including transmission using HTTP.</t>
<section anchor="notat" title="Notational Conventions" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>. These keywords are capitalized when used to
unambiguously specify requirements of the protocol or application
features and behavior that affect the interoperability and security of
implementations. When these words are not capitalized, they are meant
in their natural-language sense.</t>
<t>For purposes of readability examples are not URL encoded.
Implementers MUST percent encode URLs as described in <xref
target="RFC3986">Section 2.1 of</xref>.</t>
<t>Throughout this documents all figures MAY contain spaces and extra
line-wrapping for readability and space limitations. Similarly, some
URI's contained within examples, have been shortened for space and
readability reasons.</t>
</section>
<section anchor="defs" title="Definitions" toc="default">
<t>
The following definitions are used with Identity Events:
<list style="hanging">
<t hangText="Feed Publisher"><vspace blankLines="0"/>The Feed Provider publishes
events to be distributed to registered subscribers. In JWT
terminology, the Feed Publisher is also known as the issuer
<spanx style="verb">iss</spanx>).
</t>
<t hangText="Event"><vspace blankLines="0"/>An event is a resource change statement that is to be
distributed to one or more registered subscribers. An event is
constructed as a JWT token and MAY be signed or encrypted using
JWS/JWE for authentication and confidentiality reasons.
</t>
<t hangText="Feed"><vspace blankLines="0"/>A feed is a URI that describes the set of
resources and events under which events may be issued. An
interested client registers with the Feed Provider to subscribe
to events associated with a feed. When expressed in a JWT token,
a feed is defined as the event's audience (<spanx style="verb">aud</spanx>).
</t>
<t hangText="Subscriber"><vspace blankLines="0"/>A Subscriber registers to receive event
notifications from a Feed Provider using a protocol such as
HTTP.
</t>
</list>
</t>
</section>
</section>
<section anchor="events" title="Events">
<t>An identity event conveys a message (in the form of a JWT token <xref target="RFC7519"/>) about
a resource (i.e. a security subject) that may be of interest to a
subscriber or set of subscribers participating in an event feed
(see <xref target="idevent-subscription"/>).</t>
<t>In addition to the JWT attributes <spanx style="verb">iss</spanx> and
<spanx style="verb">aud</spanx>, an event message contains the attribute
<spanx style="verb">events</spanx> with at least one value.
The event URI values indicate what event information (attributes)
and what type of event (e.g. resource modified) is contained in the
event message. The definition of registered events are found in the
event registry (see <xref target="registry"/>), and implementers are free to
define their own event types.</t>
<t>The schema and structure of an event follows the JWT <xref target="RFC7519"/>.
An event JWT has the following characteristics:<list style="symbols">
<t>a common set of attributes common to every event, and</t>
<t>one or more event extensions
that each contain a set of attributes that belonging to an extension.</t>
</list> </t>
<figure anchor="examplePassword" title="Example SCIM Password Reset Event">
<preamble>The following is a non-normative example showing a password change event
that conveys a SCIM event (see <xref target="idevent-scim"/>):</preamble>
<artwork>{
"jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
"events":[
"urn:ietf:params:event:SCIM:password",
"https://example.com/event/password"
],
"iat": 1458496025,
"iss": "https://scim.example.com",
"aud":[
"https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
],
"sub":
"https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
"urn:ietf:params:event:SCIM:password":{
"id":"44f6142df96bd6ab61e7521d9",
},
"https://example.com/scim/event/password":{
"resetAttempts":5
}
}</artwork>
</figure>
<t>The event in the figure above expresses hypothetical password
reset event for SCIM. The JWT consists of an <spanx style="verb">iss</spanx>
attribute which denotes the event publisher. The <spanx style="verb">aud</spanx>
attribute specifies the intended audience for the event. In practical
terms this MAY be the the URI for the event feed that a client has
subscribed to.</t>
<t>Additional extensions to an event may be added by adding more values
to the <spanx style="verb">events</spanx> attribute. For each event URI
value specified, there is a corresponding attribute that has its on JSON
object that contains the attributes associated with that event (e.g.
<spanx style="verb">https://example.com/scim/event/password</spanx>).
In this example, the SCIM event indicates that a password has been updated
and the current password reset count is 5. Notice that the value for
"resetAttempts" is actually part of its own JSON object
<spanx style="verb">https://example.com/scim/event/password</spanx>.
</t>
<t><figure anchor="exampleBackLogoutEvent" title="Example OpenID Logout Event">
<preamble>Here is another example event message, this one
for a Back-Channel Logout Token:</preamble>
<artwork>{
"iss": "https://server.example.com",
"aud": "s6BhdRkqt3",
"jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
"sub": "248289761001",
"iat": 1458668180,
"exp": 1458668580,
"events": [
"https://specs.openid.net/logout"
],
"https://specs.openid.net/logout": {
"sid": "08a5019c-17e1-4977-8f42-65a12843ea02"
}
}</artwork>
</figure></t>
<section title="Core Event Attributes">
<t>The following are attributes that are based on <xref target="RFC7519"/>
claim definitions and are profiled for use in an event
message:<list style="hanging">
<t hangText="jti"><vspace blankLines="0"/>As defined by
<xref target="RFC7519">Section 4.1.7</xref> contains a unique
identifier for an event. The identifier SHOULD be unique within
a particular event feed and MAY be used by clients to track
whether a particular event has already been received. This
attribute is REQUIRED. [[Do we need a way to detect order of
or missing events? Or should this be provided by the
subscription spec?]]</t>
<t hangText="iss"><vspace blankLines="0"/>A single valued
String containing the URI of the service provider publishing
the event (the issuer). For example, in SCIM, this is the
SCIM Service Provider's root endpoint. This attribute is REQUIRED.</t>
<t hangText="aud"><vspace blankLines="0"/>A multi-valued String containing the URIs
representing the audience of the event. Values are typically URLs of
the feeds the event is associated with. When an event has
multiple audiences that go to the same subscriber, the publisher is not
obligated to deliver repeated events to the same subscriber.
This attribute is RECOMMENDED.</t>
<t hangText="iss"><vspace blankLines="0"/>A single valued
String containing the URI of the service provider publishing
the event (the issuer). For example, in SCIM <xref target="RFC7644"/>, this is the
SCIM Service Provider's root endpoint. This attribute is REQUIRED.</t>
<t hangText="sub"><vspace blankLines="0"/>A value that identifies
the subject of the event. This SHOULD be the URI of the affected
resource. Some example resources include: users, tokens, grants,
sessions, and any addressable resource about which a change in
state may be described. This attribute is REQUIRED.</t>
<t hangText="iat"><vspace blankLines="0"/>As defined by <xref target="RFC7519">Section 4.1.6</xref>,
a value containing a NumericDate which represents when the
event was issued. Unless otherwise specified,
the value SHOULD be interpreted by the subscriber as equivalent
to the actual time of the event. This attribute is REQUIRED.
[[DISCUSS: DO WE NEED TO DIFFERENTIATE?]]</t>
<t hangText="nbf"><vspace blankLines="0"/>As defined by
<xref target="RFC7519">Section 4.1.5</xref>, a value
containing a NumericDate which represents a future date when
the event will occur. This attribute is OPTIONAL.</t>
</list>
</t>
<t>The following are new attributes defined by this specification:<list style="hanging">
<t hangText="events"><vspace blankLines="0"/>A multi-valued String
that contains the URIs of events contained within the JWT. Values
in this attribute further indicate what other JSON objects are present
within the parent JSON event structure. Each OPTIONAL JSON sub-object is
denoted by an attribute that matches a value in
<spanx style="verb">events</spanx>. This attribute is REQUIRED.</t>
</list></t>
</section>
<section anchor="eventMessage" title="Event Token Construction">
<t>An Event Token is a JWT <xref target="RFC7519"/> that is
constructed by building a JSON structure that constitutes an event
object and which is then used as the body of a JWT.</t>
<t>While this specification uses JWT to convey an event message, implementers
SHALL NOT use these events to convey authentication or authorization assertions.</t>
<t><figure anchor="exampleJsonEvent" title="Example Event JSON Data">
<preamble>The
following is an example event message(it has been modified
for readability):</preamble>
<artwork>{
"jti": "4d3559ec67504aaba65d40b0363faad8",
"iat": 1458496404,
"iss": "https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
],
"sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
"events":[
"urn:ietf:params:event:SCIM:create"
],
"urn:ietf:params:event:SCIM:create":{
"attributes":["id","name","userName","password","emails"],
"values":{
"emails":[
{"type":"work","value":"jdoe@example.com"}
],
"password":"not4u2no",
"userName":"jdoe",
"id":"44f6142df96bd6ab61e7521d9",
"name":{
"givenName":"John",
"familyName":"Doe"
}
}
}
}</artwork>
</figure></t>
<t>When transmitted, the above JSON body must be converted into a JWT
as per <xref target="RFC7519"/>. In this
example, because the event contains attribute values, the token MUST
be encrypted per JWE (see <xref
target="RFC7516"/>) before transmission.</t>
<t><figure>
<preamble>The following is an example of a SCIM Event expressed in
an unsecured JWT token. The JWT header of:</preamble>
<artwork>{"alg":"none"}</artwork>
</figure><figure>
<preamble>Base64url encoding of the octets of the UTF-8
representation of the header yields:</preamble>
<artwork>eyJhbGciOiJub25lIn0</artwork>
</figure><figure>
<preamble>The example JSON Event Data is encoded as
follows:</preamble>
<artwork>
eyAgCiAgImp0aSI6ICI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIs
CiAgImV2ZW50VXJpcyI6WwogICAgInVybjppZXRmOnBhcmFtczpldmVudDpTQ0lN
OmNyZWF0ZSIKICBdLAogICJpYXQiOiAxNDU4NDk2NDA0LAogICJpc3MiOiAiaHR0
cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwgIAogICJhdWQiOlsKICAgImh0dHBzOi8v
c2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0
IiwKICAgImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZi
MWQwODY0MWQ3Njc2ZWU3IgogIF0sICAKICAic3ViIjogImh0dHBzOi8vc2NpbS5l
eGFtcGxlLmNvbS9Vc2Vycy80NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5IiwKICAi
dXJuOmlldGY6cGFyYW1zOmV2ZW50OlNDSU06Y3JlYXRlIjp7CiAgICAiYXR0cmli
dXRlcyI6WyJpZCIsIm5hbWUiLCJ1c2VyTmFtZSIsInBhc3N3b3JkIiwiZW1haWxz
Il0sCiAgICAidmFsdWVzIjp7CiAgICAgICJlbWFpbHMiOlsKICAgICAgIHsidHlw
ZSI6IndvcmsiLCJ2YWx1ZSI6Impkb2VAZXhhbXBsZS5jb20ifQogICAgICBdLAog
ICAgICAicGFzc3dvcmQiOiJub3Q0dTJubyIsCiAgICAgICJ1c2VyTmFtZSI6Impk
b2UiLAogICAgICAiaWQiOiI0NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5IiwKICAg
ICAgIm5hbWUiOnsKICAgICAgICAiZ2l2ZW5OYW1lIjoiSm9obiIsCiAgICAgICAg
ImZhbWlseU5hbWUiOiJEb2UiCiAgICAgIH0KICAgIH0gIAogIH0KfQ</artwork>
</figure><figure anchor="eventToken"
title="Example Unsecured Event Token">
<preamble>The encoded JWS signature is the empty string.
Concatenating the parts yields:</preamble>
<artwork>eyJhbGciOiJub25lIn0
.
eyAgCiAgImp0aSI6ICI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIs
CiAgImV2ZW50VXJpcyI6WwogICAgInVybjppZXRmOnBhcmFtczpldmVudDpTQ0lN
OmNyZWF0ZSIKICBdLAogICJpYXQiOiAxNDU4NDk2NDA0LAogICJpc3MiOiAiaHR0
cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwgIAogICJhdWQiOlsKICAgImh0dHBzOi8v
c2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M2I3NzU0
IiwKICAgImh0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy81ZDc2MDQ1MTZi
MWQwODY0MWQ3Njc2ZWU3IgogIF0sICAKICAic3ViIjogImh0dHBzOi8vc2NpbS5l
eGFtcGxlLmNvbS9Vc2Vycy80NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5IiwKICAi
dXJuOmlldGY6cGFyYW1zOmV2ZW50OlNDSU06Y3JlYXRlIjp7CiAgICAiYXR0cmli
dXRlcyI6WyJpZCIsIm5hbWUiLCJ1c2VyTmFtZSIsInBhc3N3b3JkIiwiZW1haWxz
Il0sCiAgICAidmFsdWVzIjp7CiAgICAgICJlbWFpbHMiOlsKICAgICAgIHsidHlw
ZSI6IndvcmsiLCJ2YWx1ZSI6Impkb2VAZXhhbXBsZS5jb20ifQogICAgICBdLAog
ICAgICAicGFzc3dvcmQiOiJub3Q0dTJubyIsCiAgICAgICJ1c2VyTmFtZSI6Impk
b2UiLAogICAgICAiaWQiOiI0NGY2MTQyZGY5NmJkNmFiNjFlNzUyMWQ5IiwKICAg
ICAgIm5hbWUiOnsKICAgICAgICAiZ2l2ZW5OYW1lIjoiSm9obiIsCiAgICAgICAg
ImZhbWlseU5hbWUiOiJEb2UiCiAgICAgIH0KICAgIH0gIAogIH0KfQ.</artwork>
</figure></t>
<t>To create and or validate a signed or encrypted event token follow
the instructions in section 7 of <xref
target="RFC7519"/>.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations" toc="default">
<t>[[TO BE COMPLETED ]] <list style="symbols">
<t>Avoid using Maximal disclosure mode</t>
<t>Use TLS best practices.</t>
<t>Subscribers SHOULD use SCIM GET to obtain full state when
not disclosed in the event.</t>
<t>Subscribers MAY use SCIM GET to get the latest state on a
resource and discard events with iat and nbf that is older.</t>
<t>Subscribers must authenticae the message using either TLS, and/or
validating signed event messages.</t>
<t>Publishers should avoid retaining events except for audit
purposes. Events should not be accessible indefinitely - re: LDAP
changelog problems.</t>
</list>
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<section anchor="eventParam" title="Registration of Event URN Sub-namespace">
<t>IANA has added an entry to the "IETF URN Sub-namespace for Registered
Protocol Parameter Identifiers" registry and created a sub-namespace
for the Registered Parameter Identifier as per <xref
target="RFC3553"/>:
<spanx style="verb">urn:ietf:params:event</spanx>.</t>
<t>To manage this sub-namespace, IANA is requested to create the
"Event" Registry which shall be used to manage entries within the
<spanx style="verb">urn:ietf:params:scim</spanx> namespace. The
registry description is as follows:</t>
<t><list style="symbols">
<t>Registry name: Event</t>
<t>Specification: [this document]</t>
<t>Repository: [see <xref target="registry"/>]</t>
<t>Index value: values [see <xref target="registry"/>]</t>
</list></t>
</section>
<section anchor="registry" title="Event Registry">
<t>[[TO BE COMPLETED]]</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="idevent-subscription">
<front>
<title>Identity Event Subscription Protocol (work in progress)</title>
<author fullname="Phil Hunt"><organization>Oracle Corporation</organization></author>
<date/>
</front>
<format type="TXT" target="draft-hunt-idevent-subscription-00.txt"/>
</reference>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' ?><!-- Keywords -->
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3553.xml'?><!-- URN Sub-namespace -->
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml'?><!-- URIs -->
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5988.xml'?><!-- Web Linking -->
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7159.xml'?><!-- JSON -->
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7519.xml'?><!-- JWT -->
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7643.xml'?><!-- SCIM Schema -->
</references>
<references title="Informative References">
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7009.xml'?><!-- OAuth Revocation -->
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7515.xml'?><!-- JWS -->
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7516.xml'?><!-- JWE -->
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7517.xml'?><!-- JWK -->
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.7644.xml'?><!-- SCIM Protocl -->
<reference anchor="idevent-scim">
<front>
<title>SCIM Event Extensions (work in progress)</title>
<author fullname="Phil Hunt"><organization>Oracle Corporation</organization></author>
<date/>
</front>
<format type="TXT" target="draft-hunt-idevent-scim-00.txt"/>
</reference>
<reference anchor="RISC">
<front>
<title>RISC (Risk and Incident Sharing and Coordination) Working Group (work in progress)</title>
<author> <organization>The OpenId Foundation</organization></author>
<date/>
</front>
<format type="HTML" target="http://openid.net/wg/risc/"/>
</reference>
<reference anchor="HEART">
<front>
<title>HEART Working Group (work in progress)</title>
<author> <organization>The OpenId Foundation</organization></author>
<date/>
</front>
<format type="HTML" target="http://openid.net/wg/heart/"/>
</reference>
</references>
<section title="Contributors"/>
<section title="Acknowledgments">
<t>The editor would like to thank the participants in the id-events
mailing list and related working groups for their support of this specification.</t>
</section>
<section title="Change Log">
<t>Draft 00 - PH - First Draft</t>
</section>
</back>
</rfc>