forked from KantaraInitiative/wg-uma
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathdraft-uma-trust-00.html
More file actions
680 lines (628 loc) · 56.9 KB
/
draft-uma-trust-00.html
File metadata and controls
680 lines (628 loc) · 56.9 KB
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
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Binding Obligations on User-Managed Access (UMA) Participants</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Binding Obligations on User-Managed Access (UMA) Participants">
<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Network Working Group</td><td class="header">E. Maler, Ed.</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">XMLgrrl.com</td></tr>
<tr><td class="header">Intended status: Standards Track</td><td class="header">T. Hardjono</td></tr>
<tr><td class="header">Expires: July 29, 2013</td><td class="header">MIT</td></tr>
<tr><td class="header"> </td><td class="header">January 25, 2013</td></tr>
</table></td></tr></table>
<h1><br />Binding Obligations on User-Managed Access (UMA) Participants<br />draft-maler-uma-trust-00</h1>
<h3>Abstract</h3>
<p>User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy. This document provides a contractual framework that defines the minimum obligations of parties that operate and use UMA-conforming software programs and services. The goal of this framework is to support end-to-end legal enforceability of the terms and conditions of access sharing relationships between authorizing and requesting sides that use UMA. The audience for this document includes technologists, legal professionals, and operators of UMA-conforming services.
</p>
<h3>Status of this Memo</h3>
<p>
This Internet-Draft is submitted in full
conformance with the provisions of BCP 78 and BCP 79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as “work in progress.”</p>
<p>
This Internet-Draft will expire on July 29, 2013.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.</p>
<p>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.</p>
<a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#introduction">1.</a>
Introduction<br />
<a href="#anchor1">1.1.</a>
Sample Use Cases for Sharing Access to Resources<br />
<a href="#anchor2">1.2.</a>
How to Use the Contractual Framework<br />
<a href="#anchor3">1.3.</a>
Obligations Not in the Scope of the Contractual Framework<br />
<a href="#clauses">2.</a>
Binding Obligations on UMA Participants<br />
<a href="#terminology-clauses">2.1.</a>
Terminology<br />
<a href="#anchor4">2.1.1.</a>
Terms<br />
<a href="#anchor5">2.1.2.</a>
Abbreviations<br />
<a href="#anchor6">2.2.</a>
Obligations of the Requesting Party<br />
<a href="#anchor7">2.2.1.</a>
Requesting Party-Authorizing Party: Adhere-to-Terms<br />
<a href="#anchor8">2.2.2.</a>
Requesting Party-Authorizing Party: Make-Factual-Representations<br />
<a href="#anchor9">2.2.3.</a>
Requesting Party-Authorization Server Operator: Supply-Truthful-Claims<br />
<a href="#anchor10">2.2.4.</a>
Requesting Party-Resource Server Operator: Is-Legitimate-Bearer<br />
<a href="#anchor11">2.3.</a>
Obligations of the Resource Server Operator<br />
<a href="#anchor12">2.3.1.</a>
Resource Server Operator-Authorizing Party: Delegate-Protection<br />
<a href="#anchor13">2.3.2.</a>
Resource Server Operator-Authorization Server Operator: Register-Accurately-and-Timely<br />
<a href="#anchor14">2.3.3.</a>
Resource Server Operator-Authorization Server Operator: Respect-Permissions<br />
<a href="#anchor15">2.3.4.</a>
Resource Server Operator-Requesting Party: Give-Accurate-Access<br />
<a href="#anchor16">2.4.</a>
Obligations of the Authorization Server Operator<br />
<a href="#anchor17">2.4.1.</a>
Authorization Server Operator-Authorizing Party: Follow-Policies-Accurately-and-Timely<br />
<a href="#anchor18">2.4.2.</a>
Authorization Server Operator-Resource Server Operator: Follow-Policies-Accurately-and-Timely<br />
<a href="#anchor19">2.4.3.</a>
Authorization Server Operator-Requesting Party: Request-Limited-Claims<br />
<a href="#anchor20">2.5.</a>
Obligations of the Authorizing Party<br />
<a href="#anchor21">2.5.1.</a>
Authorizing Party-Requesting Party: Adhere-to-Terms<br />
<a href="#anchor22">2.5.2.</a>
Authorizing Party-Authorization Server Operator: Introduce-Resource-Server<br />
<a href="#anchor23">2.5.3.</a>
Authorizing Party-Resource Server Operator: Introduce-Authorization-Server<br />
<a href="#Acknowledgments">3.</a>
Acknowledgments<br />
<a href="#rfc.references1">4.</a>
References<br />
<a href="#rfc.references1">4.1.</a>
Normative References<br />
<a href="#rfc.references2">4.2.</a>
Informative References<br />
<a href="#History">Appendix A.</a>
Document History<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="introduction"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>User-Managed Access (UMA) <a class='info' href='#UMAcore'>[UMAcore]<span> (</span><span class='info'>Hardjono, T., “User-Managed Access (UMA) Profile of OAuth 2.0,” December 2012.</span><span>)</span></a> is a profile of OAuth 2.0. UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy. This document provides a contractual framework that defines the minimum obligations of parties that operate and use UMA-conforming software programs and services. The goal of this framework is to support end-to-end legal enforceability of the terms and conditions of access sharing relationships between authorizing and requesting sides that use UMA. The audience for this document includes technologists, legal professionals, and operators of UMA-conforming services.
</p>
<p>Capitalized terms and abbreviations used in this document are defined in <a class='info' href='#terminology-clauses'>Section 2.1<span> (</span><span class='info'>Terminology</span><span>)</span></a> because they form a normative part of the framework defined in <a class='info' href='#clauses'>Section 2<span> (</span><span class='info'>Binding Obligations on UMA Participants</span><span>)</span></a>. Readers are strongly encouraged to review these definitions before reading the rest of the introduction.
</p>
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.
Sample Use Cases for Sharing Access to Resources</h3>
<p>UMA makes possible a loosely coupled end-to-end access sharing relationship between an Authorizing Party and a Requesting Party, with its primary goals being to constrain access according to the Authorizing Party's access policies and to encourage the Requesting Party to adhere to any obligations it consented to in the authorization process by raising the consequences for doing otherwise. Following are sample use cases that explore the potential differences in these obligations beyond the basic level represented in the contractual framework.</p>
<blockquote class="text"><dl>
<dt>Person-to-self sharing</dt>
<dd>Here, Alice is both the Authorizing Party and the Requesting Party. This use case describes most types of today's OAuth-mediated access, for example, when Alice introduces the Klout service to her Twitter account. She uses both services herself, and wants them to communicate together on her behalf. With UMA, Alice can potentially manage the entire set of such access connections from a single place rather than from Twitter and other online "home bases" separately. In this circumstance, it's unlikely Alice will want to impose stringent contract terms on herself.
</dd>
<dt>Person-to-person sharing</dt>
<dd>Here, Alice is an Authorizing Party and Bob is a Requesting Party. Today, many Web 2.0 sites offer some level of selective sharing between people, but methods, strengths, and interfaces are inconsistent between sites and people are unable to reuse policies across sites. Alice can share Flickr photos with Bob by adding him to her Flickr friends list or family list or by mailing him a special link to a photo album, or Alice can add Bob as a friend on Facebook. With UMA, Alice can craft authorization policies that let Bob "qualify in" to get access to her photo album and even to other resources she manages at other sites, without her having to be present during this process.
</dd>
<dt>Mediated person-to-organization sharing</dt>
<dd>Here, Alice is an Authorizing Party, the DentalCare company is a Requesting Party, and the company's office assistant Carl is a Requesting Party Agent. Alice wants to give her dentist's office, DentalCare, temporary access to her calendar to make it easier to schedule a series of root canal appointments. Carl might be the actual person acting on behalf of the dental practice who actually asks for and views Alice's calendar. With UMA, Alice can require Carl to prove he is acting on behalf of DentalCare -- for example, demonstrating control of an email address in the dentalcare.com domain -- before seeing her calendar.
</dd>
<dt>Autonomous person-to-organization sharing</dt>
<dd>Here, Alice is an Authorizing Party and the Valley Vehicles car dealership is a Requesting Party. Alice has crafted a "personal request for proposals" because she's in the market for a new car, and she's willing to let car dealerships in her region of the country see her request and make offers to her. With UMA, Valley Vehicles and other dealerships might use Web crawler services to go out and collect requests for proposals, without human helpers, and these services might have to prove in automated fashion that they legitimately represent the right kind of business. Alice can also ensure each dealership agrees to her terms before seeing her request for proposals.
</dd>
</dl></blockquote>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.2"></a><h3>1.2.
How to Use the Contractual Framework</h3>
<p>The contractual framework in <a class='info' href='#clauses'>Section 2<span> (</span><span class='info'>Binding Obligations on UMA Participants</span><span>)</span></a> is the normative portion of this document. It is intended to apply to all Subjects that take part in software interactions using services that are declared to be UMA-conforming. It defines the minimum set of obligations that these Subjects accept. The Subjects can adopt additional obligations, and can further refine or constrain the obligations listed here, but cannot make these minimum obligations less strict.
</p>
<p>Each clause takes the following form:
</p>
<p>"[<em>Clause ID</em>]. When [<em>protocol interaction takes place</em>], the [<em>obligated Subject</em>] gains an obligation to the [<em>expecting Subject</em>] to [<em>behave towards it in a particular way</em>]."
</p>
<p>The clause ID has the following internal structure:
</p>
<p>"[<em>obligated</em>]-[<em>expecting</em>]-[<em>keyword</em>]"
</p>
<p>It uses abbreviations for the obligated and expecting Subjects as follows: RqP for Requesting Party, RSO for Resource Server Operator, ASO for Authorization Server Operator, and AzP for Authorizing Party. Clauses are generally followed by non-normative explanatory comments, which are labeled with "Comments:", and occasionally open issues, which are labeled with "Issues:". The latter are meant to be resolved and removed before final publication.
</p>
<p>Specific obligations come as a result of precise protocol interactions, so that at a moment in time, any one Subject may not yet have taken on all of the obligations defined in the contractual framework as belonging to that Subject. By analogy, if Alice were to visit a website that imposes terms of service on the site's users, but it requires users to consent actively by clicking on an "I Agree" button, Alice would take on terms-of-service obligations only after she clicks on the button.
</p>
<p>Following are the key UMA interactions that result in obligations, with specific cross-references into the <a class='info' href='#UMAcore'>[UMAcore]<span> (</span><span class='info'>Hardjono, T., “User-Managed Access (UMA) Profile of OAuth 2.0,” December 2012.</span><span>)</span></a> specification. A non-normative visual correlation of interactions to binding obligations can be found at <a class='info' href='#UMAFAQ-swim'>[UMAFAQ‑swim]<span> (</span><span class='info'>US Federal Government, “UMA Frequently Asked Questions: What is the UMA protocol flow?,” January 2013.</span><span>)</span></a>. (Lowercase versions of names are references to constructs in the technical specification versus this document.)</p>
<ul class="text">
<li>An authorization server issues a protection API token (PAT) to a resource server: Section 1.3.1.
</li>
<li>An authorization server issues an authorization API token (AAT) to a client: Section 1.3.1.
</li>
<li>An authorization server issues a requesting party token (RPT) to a client: Section 3.4.1.
</li>
<li>An authorization server responds positively to a client's authorization request: Section 3.4.2.
</li>
<li>A resource server determines the status of an RPT: Section 3.3.
</li>
<li>A resource server registers a client-requested permission: Section 3.2.
</li>
<li>A requesting party supplies claims to an authorization server: Section 3.5.
</li>
<li>A resource server responds to a client's request for access: Sections 3.1.1 and 3.1.2.
</li>
<li>A client successfully receives access: Section 3.1.2.
</li>
</ul>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.3"></a><h3>1.3.
Obligations Not in the Scope of the Contractual Framework</h3>
<p>Of the Subject types defined and discussed in this document, some -- Requesting Party Agents and Client Operators -- have no UMA-dictated obligations, though they might have obligations as part of contractual agreements with other UMA-related Subjects, for example, pairwise contracts or membership in trust frameworks. Additionally, pairs or groups of Subjects that do have obligations imposed by the contractual framework might have additional obligations among themselves beyond those in the framework. Following are some typical examples:</p>
<ul class="text">
<li>When a Resource Owner registers for an account at a Resource Server, the Authorizing Party might gain an obligation to the Resource Server Operator to adhere to the Resource Server Operator's terms of service.
</li>
<li>When a Client registers with an Authorization Server for OAuth client credentials (for example, through an explicit approval process or through a passive "API-wrap" process), the Client Operator might gain an obligation to the Authorization Server Operator (apart from any particular Requesting Party's usage of that Client) to adhere to the Authorization Server Operator's terms of service for API clients.
</li>
<li>When a Subject becomes a Requesting Party Agent for a Requesting Party (for example, through an employment agreement), the Requesting Party Agent might gain an obligation to adhere to any agent agreements in place in the Subject's UMA-related interactions performed on behalf of the Requesting Party.
</li>
<li>When a Requesting Party contracts with a Client Operator to engage in UMA-related interactions on the Requesting Party's behalf, the Client Operator might gain an obligation to adhere to the terms of that contract. For example, a car dealership may contract out to use a cloud service that crawls the Web looking for personal RFPs that meet the dealership's criteria, and want to impose confidentiality requirements.
</li>
<li>When a Client accesses a protected resource at a Resource Server, the Resource Server Operator might gain an obligation to the Client Operator to be trustworthy as a source of the expected data. For example, in a scenario where the Requesting Party is also the Authorizing Party and is trying to fill in an online loan application through an online financial service (the Client), where the Resource Server Operator provides credit risk data about the Authorizing User, the Client Operator will want to authenticate the Resource Server service in some fashion.
</li>
</ul>
<a name="clauses"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Binding Obligations on UMA Participants</h3>
<p>This section constitutes a normative framework that defines the minimum obligations gained by parties that operate and use software programs and services that the operators declare to be UMA-conforming. The framework consists of clauses, where each subsection with content is a clause.
</p>
<a name="terminology-clauses"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1"></a><h3>2.1.
Terminology</h3>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1.1"></a><h3>2.1.1.
Terms</h3>
<p>
</p>
<p>This framework uses the following terms. Where terms are used without capitalization and are not otherwise defined in the <a class='info' href='#UMAcore'>[UMAcore]<span> (</span><span class='info'>Hardjono, T., “User-Managed Access (UMA) Profile of OAuth 2.0,” December 2012.</span><span>)</span></a>, they are used in their normal sense.</p>
<blockquote class="text"><dl>
<dt>Individual</dt>
<dd>A natural person (that is, a human being) with the capacity to take on contractual duties and obligations as a participant in an UMA interaction.
</dd>
<dt>Non-Person Entity (NPE)</dt>
<dd>A legal person (such as a corporation) with the capacity to take on contractual duties and obligations as a participant in an UMA interaction.
</dd>
<dt>Subject</dt>
<dd>An Individual or NPE. Subjects play various roles in achieving and seeking user-managed access, and the same Subject might serve in multiple contractual roles.
</dd>
<dt>Conformance</dt>
<dd>Claimed adherence of a running software program or service to the requirements of one or more of the roles "authorization server", "resource server", or "client", as defined in <a class='info' href='#UMAcore'>[UMAcore]<span> (</span><span class='info'>Hardjono, T., “User-Managed Access (UMA) Profile of OAuth 2.0,” December 2012.</span><span>)</span></a>. Software components play various roles in participating in the technical interactions necessary to achieve and seek user-managed access, and the same software component might serve in multiple technical roles.
</dd>
<dt>Authorizing Party</dt>
<dd>A Subject that fills the "resource owner" role as defined in <a class='info' href='#UMAcore'>[UMAcore]<span> (</span><span class='info'>Hardjono, T., “User-Managed Access (UMA) Profile of OAuth 2.0,” December 2012.</span><span>)</span></a>, using and configuring software services that variously fill the "authorization server" and "resource server" roles. This Subject is the "user" in "User-Managed Access"; UMA's first priority is to enable Individuals to serve in the Authorizing Party role, though NPEs can serve in this role as well.
</dd>
<dt>Authorization Server</dt>
<dd>A software service that fills the "authorization server" role as defined in <a class='info' href='#UMAcore'>[UMAcore]<span> (</span><span class='info'>Hardjono, T., “User-Managed Access (UMA) Profile of OAuth 2.0,” December 2012.</span><span>)</span></a>.
</dd>
<dt>Authorization Server Operator</dt>
<dd>A Subject responsible for running and operating an Authorization Server.
</dd>
<dt>Resource Server</dt>
<dd>A software service that fills the "resource server" role as defined in <a class='info' href='#UMAcore'>[UMAcore]<span> (</span><span class='info'>Hardjono, T., “User-Managed Access (UMA) Profile of OAuth 2.0,” December 2012.</span><span>)</span></a>.
</dd>
<dt>Resource Server Operator</dt>
<dd>A Subject responsible for running and operating a Resource Server.
</dd>
<dt>Client</dt>
<dd>A software application or service that fills the "client" role as defined in <a class='info' href='#UMAcore'>[UMAcore]<span> (</span><span class='info'>Hardjono, T., “User-Managed Access (UMA) Profile of OAuth 2.0,” December 2012.</span><span>)</span></a>.
</dd>
<dt>Client Operator</dt>
<dd>A Subject responsible for running and operating a Client.
</dd>
<dt>Requesting Party</dt>
<dd>A Subject that uses a Client to seek access to a protected resource. This Subject may be an Individual or an NPE. The Requesting Party and the Authorizing Party may be the same Subject or different Subjects.
</dd>
<dt>Requesting Party Agent</dt>
<dd>A Subject using a Client to seek access to a protected resource on behalf of a Requesting Party. Typically this Subject is an Individual acting on behalf of an NPE.
</dd>
</dl></blockquote>
<p>Comments: The <a class='info' href='#UETA'>[UETA]<span> (</span><span class='info'>Smedinghoff, T., “Uniform Electronic Transactions Act,” 1999.</span><span>)</span></a> defines two terms that are particularly relevant to understanding the interactions among UMA participants:</p>
<ul class="text">
<li>"'Automated transaction' means a transaction conducted or performed, in whole or in part, by electronic means or electronic records, in which the acts or records of one or both parties are not reviewed by an individual in the ordinary course in forming a contract, performing under an existing contract, or fulfilling an obligation required by the transaction."
</li>
<li>"'Electronic agent' means a computer program or an electronic or other automated means used independently to initiate an action or respond to electronic records or performances in whole or in part, without review or action by an individual."
</li>
</ul><p>Where a Client is used by a human Requesting Party or a human Requesting Party Agent, at times human-computer interaction (HCI) will be required, but otherwise the access-attempt transaction is likely to be fully automatic from the perspective of the "requesting side". Furthermore, where the Authorizing Party and the Requesting Party are the same natural person, or where the Authorizing Party has set a policy that requires real-time approval through some out-of-band method, this person can expect to engage in HCI. Otherwise the access-attempt transaction is likely to be fully automatic from the perspective of the "authorizing side" because the access attempt is made without any requirement for the Authorizing Party to be present at run time.
</p>
<p>The National Strategy for Trusted Identities in Cyberspace <a class='info' href='#NSTIC'>[NSTIC]<span> (</span><span class='info'>US Federal Government, “National Strategy for Trusted Identities in Cyberspace,” April 2011.</span><span>)</span></a> defines some terms similar to those defined here:</p>
<ul class="text">
<li>"An individual is a person engaged in an online transaction. Individuals are the first priority of the Strategy."
</li>
<li>"A non-person entity (NPE) may also require authentication in the Identity Ecosystem. NPEs can be organizations, hardware, networks, software, or services and are treated much like individuals within the Identity Ecosystem. NPEs may engage in or support a transaction."
</li>
<li>"The subject of a transaction may be an individual or an NPE."
</li>
</ul>
<p>UMA shares with NSTIC a priority to enable and empower individual people in the context of their online interactions. Note that this framework uses the terms Individual, NPE, and Subject exclusively for parties that have the capacity to take on contractual obligations, distinguishing them "from hardware, networks, software, or services", which do not have this capacity.
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1.2"></a><h3>2.1.2.
Abbreviations</h3>
<p>This framework uses the following abbreviations.</p>
<blockquote class="text"><dl>
<dt>UMA</dt>
<dd>User-Managed Access, the interoperability protocol defined by in <a class='info' href='#UMAcore'>[UMAcore]<span> (</span><span class='info'>Hardjono, T., “User-Managed Access (UMA) Profile of OAuth 2.0,” December 2012.</span><span>)</span></a> and the other specifications it includes normatively by reference.
</dd>
<dt>API</dt>
<dd>Application programming interface.
</dd>
<dt>PAT</dt>
<dd>Protection API token, as defined iin <a class='info' href='#UMAcore'>[UMAcore]<span> (</span><span class='info'>Hardjono, T., “User-Managed Access (UMA) Profile of OAuth 2.0,” December 2012.</span><span>)</span></a>.
</dd>
<dt>AAT</dt>
<dd>Authorization API token, as defined in <a class='info' href='#UMAcore'>[UMAcore]<span> (</span><span class='info'>Hardjono, T., “User-Managed Access (UMA) Profile of OAuth 2.0,” December 2012.</span><span>)</span></a>.
</dd>
<dt>RPT</dt>
<dd>Requesting party token, as defined in <a class='info' href='#UMAcore'>[UMAcore]<span> (</span><span class='info'>Hardjono, T., “User-Managed Access (UMA) Profile of OAuth 2.0,” December 2012.</span><span>)</span></a>.
</dd>
</dl></blockquote>
<p>Comments: Tokens are critical to managing authorization and auditing of resource access. Section 1.3 is recommended reading for understanding what the various tokens represent and how they are issued and used. The RPT, in particular, has a definition that can vary depending on the RPT profile in use; thus, any obligations in this framework that depend on an RPT profile specify it by name.
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2"></a><h3>2.2.
Obligations of the Requesting Party</h3>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2.1"></a><h3>2.2.1.
Requesting Party-Authorizing Party: Adhere-to-Terms</h3>
<p>When the Client successfully gains access from a Resource Server to a protected resource by wielding a valid "bearer" RPT associated with at least one currently valid permission for the type of access sought, the Requesting Party using that Client gains an obligation to the Authorizing Party to adhere to any terms it agreed to in order to gain the permission.
</p>
<p>Comments: This key obligation enables the end-to-end access authorization agreement that UMA exists to forge. At a previous stage, the Requesting Party asked for a relevant permission from the Authorization Server and might have had to provide claims of a promissory nature. Accepting access to the protected resource binds the Requesting Party to any terms it agreed to using the claims mechanism, for example, agreeing only to read the resource rather than modifying it, or forbearing from selling the resource data to someone else.
</p>
<p>Issues: Note that the obligation goes into effect the first time a Client gains access under the power of a "currently valid permission". If there was more than one valid permission attached to different sets of promises, if a secure record was not kept by the Resource Server and/or Authorization Server of which permission was used for granting access, ambiguity is introduced. Defining and using RPT profiles other than the "bearer" profile might lessen the potential ambiguity.
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2.2"></a><h3>2.2.2.
Requesting Party-Authorizing Party: Make-Factual-Representations</h3>
<p>When the Requesting Party provides, or facilitates the sourcing of, claims to an Authorization Server in a claims-gathering flow, the Requesting Party gains an obligation to the Authorizing Party to stand behind any factual representations it makes in order to gain the permission, to the best of its knowledge at the time it makes them.
</p>
<p>Comments: This obligation is gained during the providing of actual claims, rather than at the time of AAT issuance or protected resource access, because factual claims might age and expire. Where the Requesting Party supplies or sources claims in a manner that can be verified by the Authorization Server, the risk imposed by this need for "trust" can be reduced. Note that UMA defines an optional OpenID Connect claim profile that provides one way to collect trusted claims from third-party claim providers.
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2.3"></a><h3>2.2.3.
Requesting Party-Authorization Server Operator: Supply-Truthful-Claims</h3>
<p>When the Authorization Server issues an AAT to a Client and for as long as the AAT is valid, the Requesting Party using that Client gains an obligation to the Authorization Server Operator to supply or facilitate access to truthful claims required for access authorization at this AM, when it chooses to supply them, to the best of its knowledge at the time it supplies them.
</p>
<p>Comments: At a later stage, the Requesting Party might be asked to provide claims to support authorization processes at this Authorization Server for accessing <em>all</em> resources protected by this Authorization Server, managed by any Authorizing Parties, at any Resource Servers. The Requesting Party's responsibility to act in good faith in interacting with this Authorization Server begins now because factual claims it supplies could be reused for more than one access-sharing relationship. This obligation can be removed through AAT revocation.
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2.4"></a><h3>2.2.4.
Requesting Party-Resource Server Operator: Is-Legitimate-Bearer</h3>
<p>When the Authorization Server issues an RPT to a Client and for as long as the RPT is valid, the Requesting Party using that Client gains an obligation to the Resource Server Operator to represent the legitimate bearer of the RPT or its authorized representative, and not to allow others to impersonate the Requesting Party.
</p>
<p>Comments: In the case where the "bearer" RPT profile or any other bearer-style RPT profile is used, the token may not be bound in any technically confirmable way to the specific client and requesting party it applies to. Defining and using different UMA token profiles can mitigate the risk of failure or malice on the Requesting Party's part. The "authorized representative" phrase is intended to clear the way for token-chaining profiles or similar.
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3"></a><h3>2.3.
Obligations of the Resource Server Operator</h3>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3.1"></a><h3>2.3.1.
Resource Server Operator-Authorizing Party: Delegate-Protection</h3>
<p>When the Authorization Server issues a PAT to a Resource Server and as long as the PAT is valid, the Resource Server Operator gains an obligation to the Authorizing Party to delegate protection services to the Authorization Server Operator for the set of protectable resources for which it represents this capability to the Authorizing Party, and to respect the authorization data that the Authorization Server has associated with an RPT when the Resource Server subsequently allows or disallows access by the Client that presented that RPT.
</p>
<p>Comments: Once the Authorization Server Operator becomes the Authorizing Party's authorization proxy, it begins relying on the Resource Server Operator in other, more specific ways. The Resource Server has the opportunity to inspect AM-issued permissions or take other actions that delegate protection responsibility to the Authorization Server at a later stage, but its responsibility for respecting them begins now. The specific protection services made available to the Resource Server by the Authorization Server differ depending on the RPT profile in use. This obligation can be removed through PAT revocation.
</p>
<a name="anchor13"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3.2"></a><h3>2.3.2.
Resource Server Operator-Authorization Server Operator: Register-Accurately-and-Timely</h3>
<p>When the Authorization Server issues a PAT to the Resource Server and as long as the PAT is valid, the Resource Server Operator gains an obligation to the Authorization Server Operator to register resource set descriptions accurately and timely according to the Authorizing Party’s expressed instructions for protection.
</p>
<p>Comments: At a later stage, the Resource Server has the opportunity to register resource sets, but its responsibility for performing this task begins now. The Resource Server Operator may have contracted with the Authorizing Party for service-level agreements to respond specifically to timeliness needs and so on. This obligation can be removed through PAT revocation.
</p>
<a name="anchor14"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3.3"></a><h3>2.3.3.
Resource Server Operator-Authorization Server Operator: Respect-Permissions</h3>
<p>When the Resource Server successfully introspects a "bearer" RPT, the Resource Server Operator gains an obligation to the Authorization Server Operator to respect the permissions that the Authorization Server has associated with the RPT when the Resource Server subsequently allows or disallows access by the Client that presented that RPT.
</p>
<p>Comments: The Resource Server Operator, as a Subject that is otherwise potentially not obligated to the Authorization Server Operator, carries a great deal of responsibility here not to allow access where the Authorization Server has not granted permission and to make every effort to grant access where the Authorization Server has granted permission. Its interpretation of scopes and permissions is not directly auditable by the Authorization Server. Further, issues can arise from the skew between permission validity periods and actual access. Defining and using different RPT profiles can mitigate the risk of failure or malice on the Resource Server Operator's part.
</p>
<a name="anchor15"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3.4"></a><h3>2.3.4.
Resource Server Operator-Requesting Party: Give-Accurate-Access</h3>
<p>When the Resource Server responds in any fashion to a Client's access request, the Resource Server Operator gains an obligation to the Requesting Party to give accurate access to the protected resource according to whether the Requesting Party has permission to do so.
</p>
<p>Comments: The Resource Server Operator, as a Subject that is otherwise potentially not obligated to the Authorization Server Operator, carries a great deal of responsibility here to make every effort to grant access where the Authorization Server has associated authorization data to guide access. Its interpretation of scopes and permissions, particularly in the case where the RPT presented by the Client uses the "bearer" RPT profile, is not entirely auditable by the requester or Authorization Server. Further, issues can arise from the skew between permission validity periods and actual access. Defining and using different RPT profiles can mitigate the risk of failure on the Resource Server Operator's part.
</p>
<p>Issues: The relying party traditionally always has the right of refusal. The resource server may have additional authorization context available only to it that suggests it should not grant access, for example. Should this obligation be struck?
</p>
<a name="anchor16"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.4"></a><h3>2.4.
Obligations of the Authorization Server Operator</h3>
<a name="anchor17"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.4.1"></a><h3>2.4.1.
Authorization Server Operator-Authorizing Party: Follow-Policies-Accurately-and-Timely</h3>
<p>When the Authorization Server issues a PAT to the Resource Server and as long as the PAT is valid, the Authorization Server Operator gains an obligation to the Authorizing Party to adhere to the Authorizing Party's policies accurately and timely in granting permissions.
</p>
<p>Comments: At a later stage, the Authorization Server will require the Resource Server to present the PAT whenever it uses the Authorization Server’s protection API on behalf of this Authorizing Party. The Authorization Server Operator may have contracted with the Authorizing Party for service-level agreements to respond specifically to timeliness needs and so on. This obligation can be removed through PAT revocation.
</p>
<a name="anchor18"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.4.2"></a><h3>2.4.2.
Authorization Server Operator-Resource Server Operator: Follow-Policies-Accurately-and-Timely</h3>
<p>When the Resource Server registers a requested permission at the Authorization Server, the Authorization Server Operator gains an obligation to the Resource Server Operator to adhere to the Authorizing Party’s authorization policies accurately and timely in associating authorization data with RPTs presented with the registered permission's ticket.
</p>
<p>Comments: At a later stage, when a Client approaches the Authorization Server presenting an RPT and a permission ticket, the Authorization Server matches Authorizing Party policies to the requested permission to drive any requests for claims and ultimate authorization processes, but its responsibility for performing this task begins now.
</p>
<a name="anchor19"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.4.3"></a><h3>2.4.3.
Authorization Server Operator-Requesting Party: Request-Limited-Claims</h3>
<p>When the Authorization Server issues an AAT to a Client and as long as the AAT is valid, the Authorization Server Operator gains an obligation to the Requesting Party to request only claims that support the purpose of satisfying an Authorizing Party's policy.
</p>
<p>Comments: At a later stage, the Authorization Server might ask the Requesting Party to provide claims for specific permission purposes at multiple Resource Servers and/or for multiple Authorizing Parties, but its responsibility begins now. This obligation can be removed through AAT revocation.
</p>
<a name="anchor20"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.5"></a><h3>2.5.
Obligations of the Authorizing Party</h3>
<a name="anchor21"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.5.1"></a><h3>2.5.1.
Authorizing Party-Requesting Party: Adhere-to-Terms</h3>
<p>When the Authorization Server responds positively to a Client's request for authorization, the Authorizing Party gains an obligation to the Requesting Party using that Client to adhere to the terms offered to and accepted by the Requesting Party in the form of requests for claims driven by the Authorizing Party's policy at the Authorization Server.
</p>
<p>Comments: For example, the Authorizing User cannot subsequently protest or sue the Requesting Party for resale of the user’s data if this was allowed by the terms of access authorization.
</p>
<a name="anchor22"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.5.2"></a><h3>2.5.2.
Authorizing Party-Authorization Server Operator: Introduce-Resource-Server</h3>
<p>When the Authorization Server issues a PAT to a Resource Server and as long as the PAT is valid, the Authorizing Party gains an obligation to the Authorization Server Operator to introduce the desired Resource Server to this Authorization Server in outsourcing protection of this Resource Server's resources.
</p>
<p>Comments: How the Resource Server learned of the Authorization Server's location is out of band for UMA; it is the Authorizing Party's responsibility to check that it has been redirected to an acceptable Authorization Server before the Authorization Server successfully issues the PAT. This obligation can be removed through PAT revocation.
</p>
<a name="anchor23"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.5.3"></a><h3>2.5.3.
Authorizing Party-Resource Server Operator: Introduce-Authorization-Server</h3>
<p>When the Authorization Server issues a PAT to a Resource Server and as long as the PAT is valid, the Authorizing Party gains an obligation to the Resource Server Operator to introduce the desired Authorization Server to this Resource Server in outsourcing protection of this Resource Server's resources.
</p>
<p>Comments: Once the Authorization Server Operator becomes the Authorizing Party’s authorization proxy, the Resource Server Operator begins relying on it in other, more specific ways. How the Authorizing Party indicated the desired Authorization Server to the host is out of band for UMA; it is the Authorizing Party's responsibility to check that it has been redirected to an acceptable Authorization Server before the Authorization Server successfully issues the PAT. This obligation can be removed through PAT revocation.
</p>
<a name="Acknowledgments"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Acknowledgments</h3>
<p>The current editor of this document is Eve Maler of XMLgrrl.com. The following people are co-authors:</p>
<ul class="text">
<li>Domenico Catalano, Oracle Corp.
</li>
<li>Kevin Cox, Edentiti
</li>
<li>Sal D'Agostino, IDmachines
</li>
<li>Susan Morrow, Avoco Secure
</li>
<li>Dazza Greenwood, Civics.com
</li>
</ul>
<p>Additional contributors to this document include the Kantara UMA Work Group participants, a list of whom can be found at <a class='info' href='#UMAnitarians'>[UMAnitarians]<span> (</span><span class='info'>Maler, E., “UMA Participant Roster,” 2012.</span><span>)</span></a>. The co-authors and contributors thank Scott David, Dazza Greenwood, and Tom Smedinghoff for offering their legal expertise and insight in the preparation of this document.
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
References</h3>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>4.1. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="UMAcore">[UMAcore]</a></td>
<td class="author-text">Hardjono, T., “<a href="http://tools.ietf.org/html/draft-hardjono-oauth-umacore">User-Managed Access (UMA) Profile of OAuth 2.0</a>,” December 2012.</td></tr>
</table>
<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>4.2. Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="NSTIC">[NSTIC]</a></td>
<td class="author-text">US Federal Government, “<a href="http://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf">National Strategy for Trusted Identities in Cyberspace</a>,” April 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="UETA">[UETA]</a></td>
<td class="author-text">Smedinghoff, T., “<a href="http://www.law.upenn.edu/bll/archives/ulc/fnact99/1990s/ueta99.htm">Uniform Electronic Transactions Act</a>,” 1999.</td></tr>
<tr><td class="author-text" valign="top"><a name="UMAFAQ-swim">[UMAFAQ-swim]</a></td>
<td class="author-text">US Federal Government, “<a href="http://kantarainitiative.org/confluence/display/uma/UMA+FAQ#UMAFAQ-WhatistheUMAprotocolflow">UMA Frequently Asked Questions: What is the UMA protocol flow?</a>,” January 2013.</td></tr>
<tr><td class="author-text" valign="top"><a name="UMAnitarians">[UMAnitarians]</a></td>
<td class="author-text">Maler, E., “<a href="http://kantarainitiative.org/confluence/display/uma/Participant+Roster">UMA Participant Roster</a>,” 2012.</td></tr>
</table>
<a name="History"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.
Document History</h3>
<p>NOTE: To be removed by RFC editor before publication as an RFC.
</p>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Eve Maler (editor)</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">XMLgrrl.com</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:eve@xmlgrrl.com">eve@xmlgrrl.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Thomas Hardjono</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">MIT</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:hardjono@mit.edu">hardjono@mit.edu</a></td></tr>
</table>
</body></html>