forked from KantaraInitiative/wg-uma
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathdraft-oauth-resource-reg.html
More file actions
executable file
·968 lines (907 loc) · 50.4 KB
/
draft-oauth-resource-reg.html
File metadata and controls
executable file
·968 lines (907 loc) · 50.4 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
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>OAuth 2.0 Resource Set Registration</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* 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.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents"/>
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction"/>
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Notational Conventions"/>
<link href="#rfc.section.1.2" rel="Chapter" title="1.2 Terminology"/>
<link href="#rfc.section.1.3" rel="Chapter" title="1.3 Authorization Server Configuration Data"/>
<link href="#rfc.section.2" rel="Chapter" title="2 Resource Set Registration"/>
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Scope Descriptions"/>
<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Resource Set Descriptions"/>
<link href="#rfc.section.2.3" rel="Chapter" title="2.3 Resource Set Registration API"/>
<link href="#rfc.section.2.3.1" rel="Chapter" title="2.3.1 Create Resource Set Description"/>
<link href="#rfc.section.2.3.2" rel="Chapter" title="2.3.2 Read Resource Set Description"/>
<link href="#rfc.section.2.3.3" rel="Chapter" title="2.3.3 Update Resource Set Description"/>
<link href="#rfc.section.2.3.4" rel="Chapter" title="2.3.4 Delete Resource Set Description"/>
<link href="#rfc.section.2.3.5" rel="Chapter" title="2.3.5 List Resource Set Descriptions"/>
<link href="#rfc.section.3" rel="Chapter" title="3 Error Messages"/>
<link href="#rfc.section.4" rel="Chapter" title="4 Security Considerations"/>
<link href="#rfc.section.5" rel="Chapter" title="5 Privacy Considerations"/>
<link href="#rfc.section.6" rel="Chapter" title="6 Conformance"/>
<link href="#rfc.section.7" rel="Chapter" title="7 IANA Considerations"/>
<link href="#rfc.section.8" rel="Chapter" title="8 Example of Registering Resource Sets"/>
<link href="#rfc.section.9" rel="Chapter" title="9 Acknowledgments"/>
<link href="#rfc.references" rel="Chapter" title="10 References"/>
<link href="#rfc.references.1" rel="Chapter" title="10.1 Normative References"/>
<link href="#rfc.references.2" rel="Chapter" title="10.2 Informative References"/>
<link href="#rfc.appendix.A" rel="Chapter" title="A Document History"/>
<link href="#rfc.authors" rel="Chapter"/>
<meta name="generator" content="xml2rfc version 2.4.9dev0 - http://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Hardjono, T., Ed." />
<meta name="dct.identifier" content="urn:ietf:id:draft-hardjono-oauth-resource-reg-03" />
<meta name="dct.issued" scheme="ISO8601" content="2014-7-20" />
<meta name="dct.abstract" content="This specification defines a resource set registration mechanism between an OAuth 2.0 authorization server and resource server. The resource server registers information about the semantics and discovery properties of its resources with the authorization server. This revision of the specification is part of UMA V0.9." />
<meta name="description" content="This specification defines a resource set registration mechanism between an OAuth 2.0 authorization server and resource server. The resource server registers information about the semantics and discovery properties of its resources with the authorization server. This revision of the specification is part of UMA V0.9." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Network Working Group</td>
<td class="right">T. Hardjono, Ed.</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">MIT</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">July 20, 2014</td>
</tr>
<tr>
<td class="left">Expires: January 21, 2015</td>
<td class="right"></td>
</tr>
</tbody>
</table>
<p class="title">OAuth 2.0 Resource Set Registration<br />
<span class="filename">draft-hardjono-oauth-resource-reg-03</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<p>This specification defines a resource set registration mechanism between an OAuth 2.0 authorization server and resource server. The resource server registers information about the semantics and discovery properties of its resources with the authorization server. This revision of the specification is part of UMA V0.9.</p>
<p>Erratum added 2014-07-24: The copyright statement below applies to the specification version submitted as an <a href="http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-03">IETF Internet-Draft</a>. The Kantara copyright statement applying to this specification version can be viewed on the <a href="http://kantarainitiative.org/confluence/download/attachments/2293776/Kantara%20Initiative%20IPR%20Policies%20_V1.1_.pdf?version=1&modificationDate=1244488630000&api=v2">Kantara site</a>.</p>
<h1 id="rfc.status">
<a href="#rfc.status">Status of This Memo</a>
</h1>
<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 January 21, 2015.</p>
<h1 id="rfc.copyrightnotice">
<a href="#rfc.copyrightnotice">Copyright Notice</a>
</h1>
<p>Copyright (c) 2014 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>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a></li>
<ul><li>1.1. <a href="#rfc.section.1.1">Notational Conventions</a></li>
<li>1.2. <a href="#rfc.section.1.2">Terminology</a></li>
<li>1.3. <a href="#rfc.section.1.3">Authorization Server Configuration Data</a></li>
</ul><li>2. <a href="#rfc.section.2">Resource Set Registration</a></li>
<ul><li>2.1. <a href="#rfc.section.2.1">Scope Descriptions</a></li>
<li>2.2. <a href="#rfc.section.2.2">Resource Set Descriptions</a></li>
<li>2.3. <a href="#rfc.section.2.3">Resource Set Registration API</a></li>
<ul><li>2.3.1. <a href="#rfc.section.2.3.1">Create Resource Set Description</a></li>
<li>2.3.2. <a href="#rfc.section.2.3.2">Read Resource Set Description</a></li>
<li>2.3.3. <a href="#rfc.section.2.3.3">Update Resource Set Description</a></li>
<li>2.3.4. <a href="#rfc.section.2.3.4">Delete Resource Set Description</a></li>
<li>2.3.5. <a href="#rfc.section.2.3.5">List Resource Set Descriptions</a></li>
</ul></ul><li>3. <a href="#rfc.section.3">Error Messages</a></li>
<li>4. <a href="#rfc.section.4">Security Considerations</a></li>
<li>5. <a href="#rfc.section.5">Privacy Considerations</a></li>
<li>6. <a href="#rfc.section.6">Conformance</a></li>
<li>7. <a href="#rfc.section.7">IANA Considerations</a></li>
<li>8. <a href="#rfc.section.8">Example of Registering Resource Sets</a></li>
<li>9. <a href="#rfc.section.9">Acknowledgments</a></li>
<li>10. <a href="#rfc.references">References</a></li>
<ul><li>10.1. <a href="#rfc.references.1">Normative References</a></li>
<li>10.2. <a href="#rfc.references.2">Informative References</a></li>
</ul><li>Appendix A. <a href="#rfc.appendix.A">Document History</a></li>
<li><a href="#rfc.authors">Author's Address</a></li>
</ul>
<h1 id="rfc.section.1"><a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">There are various circumstances under which an OAuth 2.0 <a href="#OAuth2">[OAuth2]</a> resource server may need to communicate to its authorization server information about its protected resources:</p>
<ul>
<li>In some OAuth 2.0 deployments, the resource server and authorization server are operated by the same organization and deployed in the same domain, but many resource servers share a single authorization server (a security token service (STS) component). Thus, even though the trust between these two is typically tightly bound, there is value in defining a singular standardized resource protection communications interface between the authorization server and each of the resource servers.</li>
<li>In some deployments of OpenID Connect <a href="#OpenIDConnect">[OpenIDConnect]</a>, which has a dependency on OAuth 2.0, the OpenID Provider (OP) component is a specialized version of an OAuth authorization server that brokers availability of user attributes by dealing with an ecosystem of attribute providers (APs). These APs effectively function as third-party resource servers. Thus, there is value in defining a mechanism by which all of the third-party APs can communicate with a central OP, as well as ensuring that trust between the authorization server and resource servers is able to be established in a dynamic, loosely coupled fashion.</li>
<li>In some deployments of User-Managed Access <a href="#UMA">[UMA]</a>, which has a dependency on OAuth 2.0, an end-user resource owner (the "user" in UMA) may choose their own authorization server as an independent "CloudOS" authorization service, along with using any number of resource servers that make up their "personal cloud". Thus, there is value in defining a mechanism by which all of the third-party resource servers can outsource resource protection (and potentially discovery) to a central authorization server, as well as ensuring that trust between the authorization server and resource servers is able to be established by the resource owner in a dynamic, loosely coupled fashion.</li>
</ul>
<p id="rfc.section.1.p.2">This specification defines an API through which the resource server can register information about resource sets with the authorization server.</p>
<h1 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1.</a> Notational Conventions</h1>
<p id="rfc.section.1.1.p.1">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 <a href="#RFC2119">[RFC2119]</a>.</p>
<p id="rfc.section.1.1.p.2">Unless otherwise noted, all the protocol properties and values are case sensitive.</p>
<h1 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2.</a> <a href="#terminology" id="terminology">Terminology</a></h1>
<p id="rfc.section.1.2.p.1">This specification introduces the following new terms and enhancements of OAuth term definitions.</p>
<dl>
<dt>resource set</dt>
<dd style="margin-left: 6">One or more resources that the resource server manages as a set.</dd>
<dt>scope</dt>
<dd style="margin-left: 6">A bounded extent of access that is possible to perform on a resource set. In authorization policy terminology, a scope is one of the potentially many "verbs" that can logically apply to a resource set ("object"). This specification enhances the OAuth concept of a "scope" by defining scopes as applying to particular labeled resource sets, rather than leaving the relevant resources (such as API endpoints or URIs) implicit. A resource set can have any number of scopes, which together describe the universe of actions that <em>can be</em> taken on this protected resource set. For example, a resource set representing a status update API might have scopes that include adding an update or reading updates. A resource set representing a photo album might have scopes that include viewing a slideshow or printing the album. The resource server registers resource sets and their scopes when there is not yet any particular client in the picture.</dd>
<dt>resource set registration endpoint</dt>
<dd style="margin-left: 6">The endpoint at which the resource server registers resource sets it wants the authorization server to know about. The operations available at this endpoint constitute a resource set registration API (see <a href="#reg-api">Section 2.3</a>).</dd>
</dl>
<h1 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3.</a> <a href="#am-endpoints" id="am-endpoints">Authorization Server Configuration Data</a></h1>
<p id="rfc.section.1.3.p.1">If the authorization server declares its endpoints and any other configuration data in a machine-readable form, for example <a href="#OAuth-linktypes">[OAuth-linktypes]</a> or <a href="#OAuth-meta">[OAuth-meta]</a>, it SHOULD convey its resource set registration endpoint in this fashion as well.</p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#protecting-a-resource" id="protecting-a-resource">Resource Set Registration</a></h1>
<p id="rfc.section.2.p.1">This specification defines a resource set registration API. The endpoint for this API SHOULD also require some form of authentication to access this endpoint, such as Client Authentication as described in <a href="#OAuth2">[OAuth2]</a> or a separate OAuth access token. The methods of managing and validating these authentication credentials are out of scope of this specification.</p>
<p id="rfc.section.2.p.2">For any of the resource owner's sets of resources this authorization server needs to be aware of, the resource server MUST register these resource sets at the authorization server's registration endpoint.</p>
<h1 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1.</a> <a href="#action-desc" id="action-desc">Scope Descriptions</a></h1>
<p id="rfc.section.2.1.p.1">A scope is a bounded extent of access that is possible to perform on a resource set. A scope description is a JSON document with the following properties:</p>
<dl>
<dt>name</dt>
<dd style="margin-left: 8">REQUIRED. A human-readable string describing some scope (extent) of access. This name MAY be used by the authorization server in its resource owner user interface for the resource owner.</dd>
<dt>icon_uri</dt>
<dd style="margin-left: 8">OPTIONAL. A URI for a graphic icon representing the scope. The referenced icon MAY be used by the authorization server in its resource owner user interface for the resource owner.</dd>
</dl>
<p>For example, this description characterizes a scope that involves reading or viewing resources (vs. creating them or editing them in some fashion):</p>
<pre>
{
"name": "View",
"icon_uri": "http://www.example.com/icons/reading-glasses"
}
</pre>
<p id="rfc.section.2.1.p.2">scope descriptions MAY contain extension properties that are not defined in this specification. Extension names that are unprotected from collisions are outside the scope of the current specification.</p>
<p id="rfc.section.2.1.p.3">A resource server MUST list a resource set's available scopes using URI references (as defined in <a href="#resource-set-desc">Section 2.2</a>). The scopes available for use at any one resource server MUST have unique URI references so that the resource server's scope descriptions are uniquely distinguishable. A scope URI reference MAY include a fragment identifier. Scope descriptions MAY reside anywhere. The resource server is not required to self-host scope descriptions and may wish to point to standardized scope descriptions residing elsewhere. Scope description documents MUST be accessible to authorization servers through GET calls made to these URI references.</p>
<p id="rfc.section.2.1.p.4">See <a href="#resource-reg-example">Section 8</a> for a long-form example of scopes used in resource set registration.</p>
<h1 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2.</a> <a href="#resource-set-desc" id="resource-set-desc">Resource Set Descriptions</a></h1>
<p id="rfc.section.2.2.p.1">The resource server defines a resource set that the authorization server needs to be aware of by registering a resource set description at the authorization server. This registration process results in a unique identifier for the resource set that the resource server can later use for managing its description.</p>
<p id="rfc.section.2.2.p.2">The resource server is free to use its own methods of describing resource sets. A resource set description is a JSON document with the following properties:</p>
<dl>
<dt>name</dt>
<dd style="margin-left: 8">REQUIRED. A human-readable string describing a set of one or more resources. This name MAY be used by the authorization server in its resource owner user interface for the resource owner.</dd>
<dt>icon_uri</dt>
<dd style="margin-left: 8">OPTIONAL. A URI for a graphic icon representing the resource set. The referenced icon MAY be used by the authorization server in its resource owner user interface for the resource owner.</dd>
<dt>scopes</dt>
<dd style="margin-left: 8">REQUIRED. An array providing the URI references of scope descriptions that are available for this resource set.</dd>
<dt>type</dt>
<dd style="margin-left: 8">OPTIONAL. A string uniquely identifying the semantics of the resource set. For example, if the resource set consists of a single resource that is an identity claim that leverages standardized claim semantics for "verified email address", the value of this property could be an identifying URI for this claim.</dd>
</dl>
<p>For example, this description characterizes a resource set (a photo album) that can potentially be only viewed, or alternatively to which full access can be granted; the URIs point to scope descriptions as defined in <a href="#action-desc">Section 2.1</a>:</p>
<pre>
{
"name": "Photo Album",
"icon_uri": "http://www.example.com/icons/flower.png",
"scopes": [
"http://photoz.example.com/dev/scopes/view",
"http://photoz.example.com/dev/scopes/all"
],
"type": "http://www.example.com/rsets/photoalbum"
}
</pre>
<p id="rfc.section.2.2.p.3">Resource set descriptions MAY contain extension properties that are not defined in this specification. Extension names that are unprotected from collisions are outside the scope of the current specification.</p>
<p id="rfc.section.2.2.p.4">When a resource server creates or updates a resource set description (see <a href="#reg-api">Section 2.3</a>), the authorization server MUST attempt to retrieve the referenced scope descriptions so that it can present fresh data in any resource owner interactions.</p>
<h1 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3.</a> <a href="#reg-api" id="reg-api">Resource Set Registration API</a></h1>
<p id="rfc.section.2.3.p.1">The resource server uses the RESTful API at the authorization server's resource set registration endpoint to create, read, update, and delete resource set descriptions, along with retrieving lists of such descriptions.</p>
<p id="rfc.section.2.3.p.2">(Note carefully the similar but distinct senses in which the word "resource" is used in this section. The resource set descriptions are themselves managed as web resources at the authorization server through this API.)</p>
<p id="rfc.section.2.3.p.3">The authorization server MUST present an API for registering resource set descriptions at a set of URIs with the following structure:</p>
<p id="rfc.section.2.3.p.4">{rsreguri}/resource_set/{rsid}</p>
<p id="rfc.section.2.3.p.5">The method of authentication that the resource server uses SHOULD sufficient context to distinguish between identical resource set identifiers assigned by different resource servers.</p>
<p id="rfc.section.2.3.p.6">The components of these URIs are defined as follows:</p>
<dl>
<dt>{rsreguri}</dt>
<dd style="margin-left: 8">The authorization server's resource set registration endpoint as advertised in its configuration data (see <a href="#am-endpoints">Section 1.3</a>).</dd>
<dt>{rsid}</dt>
<dd style="margin-left: 8">An identifier for a resource set description. It is RECOMMENDED to obscure resource set identifiers in order to avoid leaking personally identifiable information to clients that are exposed to scope information.</dd>
</dl>
<p id="rfc.section.2.3.p.7">Following is a summary of the five registration operations the authorization server is REQUIRED to support. Each is defined in its own section below. All other methods are unsupported. This API uses ETag and If-Match to ensure the desired resource at the authorization server is targeted.</p>
<ul>
<li>Create resource set description: PUT /resource_set/{rsid}</li>
<li>Read resource set description: GET /resource_set/{rsid}</li>
<li>Update resource set description: PUT /resource_set/{rsid} with If-Match</li>
<li>Delete resource set description: DELETE /resource_set/{rsid}</li>
<li>List resource set descriptions: GET /resource_set/ with If-Match</li>
</ul>
<p id="rfc.section.2.3.p.8">If the request to the resource set registration endpoint is incorrect, then the authorization server responds with an error message by including one of the following error codes with the response (see <a href="#errors">Section 3</a>):</p>
<dl>
<dt>unsupported_method_type</dt>
<dd style="margin-left: 8">The resource server request used an unsupported HTTP method. The authorization server MUST respond with the HTTP 405 (Method Not Allowed) status code and MUST fail to act on the request.</dd>
<dt>not_found</dt>
<dd style="margin-left: 8">The resource set requested from the authorization server cannot be found. The authorization server MUST respond with HTTP 404 (Not Found) status code.</dd>
<dt>precondition_failed</dt>
<dd style="margin-left: 8">The resource set that was requested to be deleted or updated at the authorization server did not match the If-Match value present in the request. The authorization server MUST respond with HTTP 412 (Precondition Failed) status code and MUST fail to act on the request.</dd>
</dl>
<h1 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1.</a> <a href="#create-resource-set" id="create-resource-set">Create Resource Set Description</a></h1>
<p id="rfc.section.2.3.1.p.1">Adds a new resource set description using the PUT method. If the request is successful, the authorization server MUST respond with a status message that includes an ETag header and _id and _rev properties for managing resource set description versioning.</p>
<p>Form of a "create resource set description" HTTP request:</p>
<pre>
PUT /resource_set/{rsid} HTTP/1.1
Content-Type: application/json
...
(body contains JSON resource set description to be created)
</pre>
<p>Form of a successful HTTP response:</p>
<pre>
HTTP/1.1 201 Created
Content-Type: application/json
ETag: (matches "_rev" property in returned object)
...
{
"status": "created",
"_id": (id of created resource set),
"_rev": (ETag of created resource set)
}
</pre>
<p id="rfc.section.2.3.1.p.2">On successful registration, the authorization server MAY return a redirect policy URI to the resource server in a property with the name "policy_uri". This URI allows the resource server to redirect the resource owner to a specific user interface within the authorization server where the resource owner can immediately set or modify access policies for the resource set that was just registered.</p>
<p>Form of a successful HTTP response:</p>
<pre>
HTTP/1.1 201 Created
Content-Type: application/json
ETag: (matches "_rev" property in returned object)
...
{
"status": "created",
"_id": (id of created resource set),
"_rev": (ETag of created resource set)
"policy_uri":"http://as.example.com/rs/222/resource/333/policy"
}
</pre>
<h1 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2.</a> <a href="#read-resource-set" id="read-resource-set">Read Resource Set Description</a></h1>
<p id="rfc.section.2.3.2.p.1">Reads a previously registered resource set description using the GET method. If the request is successful, the authorization server MUST respond with a status message that includes an ETag header and _id and _rev properties for managing resource set description versioning.</p>
<p>Form of a "read resource set description" HTTP request:</p>
<pre>
GET /resource_set/{rsid} HTTP/1.1
...
</pre>
<p>Form of a successful HTTP response:</p>
<pre>
HTTP/1.1 200 OK
Content-Type: application/json
...
(body contains JSON resource set description, including _id and _rev)
</pre>
<p id="rfc.section.2.3.2.p.2">If the referenced resource does not exist, the authorization server MUST produce an error response with an error property value of "not_found", as defined in <a href="#reg-api">Section 2.3</a>.</p>
<p id="rfc.section.2.3.2.p.3">On successful read, the authorization server MAY return a redirect policy URI to the resource server in a property with the name "policy_uri". This URI allows the resource server to redirect the resource owner to a specific user interface within the authorization server where the resource owner can immediately set or modify access policies for the resource set that was read.</p>
<h1 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3.</a> <a href="#update-resource-set" id="update-resource-set">Update Resource Set Description</a></h1>
<p id="rfc.section.2.3.3.p.1">Updates a previously registered resource set description using the PUT method. If the request is successful, the authorization server MUST respond with a status message that includes an ETag header and _id and _rev properties for managing resource set description versioning.</p>
<p>Form of an "update resource set description" HTTP request:</p>
<pre>
PUT /resource_set/{rsid} HTTP/1.1
Content-Type: application/json
If-Match: (entity tag of resource)
...
(body contains JSON resource set description to be updated)
</pre>
<p>Form of a successful HTTP response:</p>
<pre>
HTTP/1.1 204 No Content
ETag: "2"
...
</pre>
<p id="rfc.section.2.3.3.p.2">If the entity tag does not match, the authorization server MUST produce an error response with an error property value of "precondition_failed", as defined in <a href="#reg-api">Section 2.3</a>.</p>
<p id="rfc.section.2.3.3.p.3">On successful update, the authorization server MAY return a redirect policy URI to the resource server in a property with the name "policy_uri". This URI allows the resource server to redirect the user to a specific user interface within the authorization server where the user can immediately set or modify access policies for the resource set that was just updated.</p>
<h1 id="rfc.section.2.3.4"><a href="#rfc.section.2.3.4">2.3.4.</a> <a href="#delete-resource-set" id="delete-resource-set">Delete Resource Set Description</a></h1>
<p id="rfc.section.2.3.4.p.1">Deletes a previously registered resource set description using the DELETE method, thereby removing it from the authorization server's protection regime.</p>
<p>Form of a "delete resource set description" HTTP request:</p>
<pre>
DELETE /resource_set/{rsid}
If-Match: (entity tag of resource)
...
</pre>
<p>Form of a successful HTTP response:</p>
<pre>
HTTP/1.1 204 No content
...
</pre>
<p id="rfc.section.2.3.4.p.2">As defined in <a href="#reg-api">Section 2.3</a>, if the referenced resource does not exist the authorization server MUST produce an error response with an error property value of "not_found", and if the entity tag does not match the authorization server MUST produce an error response with an error property value of "precondition_failed".</p>
<h1 id="rfc.section.2.3.5"><a href="#rfc.section.2.3.5">2.3.5.</a> <a href="#list-resource-sets" id="list-resource-sets">List Resource Set Descriptions</a></h1>
<p id="rfc.section.2.3.5.p.1">Lists all previously registered resource set identifiers for this user using the GET method. The authorization server MUST return the list in the form of a JSON array of {rsid} values.</p>
<p id="rfc.section.2.3.5.p.2">The resource server uses this method as a first step in checking whether its understanding of protected resources is in full synchronization with the authorization server's understanding.</p>
<p>Form of a "list resource set descriptions" HTTP request:</p>
<pre>
GET /resource_set HTTP/1.1
...
</pre>
<p>HTTP response:</p>
<pre>
HTTP/1.1 200 OK
...
(body contains JSON array of {rsid} values)
</pre>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#errors" id="errors">Error Messages</a></h1>
<p id="rfc.section.3.p.1">When a resource server attempts to access the resource set registration endpoint at the authorization server, if the request is successfully authenticated by OAuth means, but is invalid for another reason, the authorization server produces an error response by adding the following properties to the entity body of the HTTP response:</p>
<dl>
<dt>error</dt>
<dd style="margin-left: 8">REQUIRED. A single error code, as noted in the API definition. Value for this property is defined in the specific authorization server endpoint description.</dd>
<dt>error_description</dt>
<dd style="margin-left: 8">OPTIONAL. A human-readable text providing additional information, used to assist in the understanding and resolution of the error occurred.</dd>
<dt>error_uri</dt>
<dd style="margin-left: 8">OPTIONAL. A URI identifying a human-readable web page with information about the error, used to provide the end-user with additional information about the error.</dd>
</dl>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> Security Considerations</h1>
<p id="rfc.section.4.p.1">This specification relies on OAuth for API security and shares its security and vulnerability considerations.</p>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> Privacy Considerations</h1>
<p id="rfc.section.5.p.1">The communication between the authorization server and resource server may expose personally identifiable information. The context in which this API is used SHOULD deal with its own unique privacy considerations.</p>
<h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#conformance" id="conformance">Conformance</a></h1>
<p id="rfc.section.6.p.1">This specification makes optional normative reference to <a href="#OAuth2">[OAuth2]</a> for API protection. This specification is anticipated to be used as a module in higher-order specifications, where additional constraints and profiling may appear.</p>
<h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#IANA" id="IANA">IANA Considerations</a></h1>
<p id="rfc.section.7.p.1">This document makes no request of IANA.</p>
<h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a href="#resource-reg-example" id="resource-reg-example">Example of Registering Resource Sets</a></h1>
<p id="rfc.section.8.p.1">The following example illustrates the intent and usage of resource set descriptions and scope descriptions as part of resource set registration for the purposes of <a href="#UMA">[UMA]</a>.</p>
<p id="rfc.section.8.p.2">This example contains some steps that are exclusively in the realm of user experience rather than web protocol, to achieve realistic illustration. These steps are labeled "User experience only". Some other steps are exclusively internal to the operation of the entity being discussed. These are labeled "Internal only".</p>
<p id="rfc.section.8.p.3">A resource owner, Alice Adams, has just uploaded a photo of her new puppy to a resource server, Photoz.example.com, and wants to ensure that this specific photo is not publicly accessible.</p>
<p id="rfc.section.8.p.4">Alice has already introduced this resource server to her authorization server, CopMonkey.example.com. However, Alice has not previously instructed Photoz to use CopMonkey to protect any photos of hers.</p>
<p id="rfc.section.8.p.5">Alice has previously visited CopMonkey to map a default "do not share with anyone" policy to any resource sets registered by Photoz, until such time as she maps some other more permissive policies to those resources. (User experience only. This may have been done at the time Alice introduced the resource server to the authorization server, and/or it could have been a global or resource server-specific preference setting. A different constraint or no constraint at all might be associated with newly protected resources.) Other kinds of policies she may eventually map to particular photos or albums might be "Share only with husband@email.example.net" or "Share only with people in my 'family' group".</p>
<p id="rfc.section.8.p.6">Photoz itself has a publicly documented application-specific API that offers two dozen different methods that apply to single photos, such as "addTags" and "getSizes", but rolls them up into two photo-related scopes of access: "view" (consisting of various read-only operations) and "all" (consisting of various reading, editing, and printing operations). It defines two scope descriptions that represent these scopes, which it is able to reuse for all of its users (not just Alice), and ensures that these scope description documents are available through HTTP GET requests that may be made by authorization servers.</p>
<p id="rfc.section.8.p.7">The "name" property values are intended to be seen by Alice when she maps authorization constraints to specific resource sets and actions while visiting CopMonkey, such that Alice would see the strings "View Photo and Related Info" and "All Actions", likely accompanied by the referenced icons, in the CopMonkey interface. (Other users of Photoz might similarly see the same labels at CopMonkey or whatever other authorization server they use. Photoz could distinguish natural-language labels per user if it wishes, by pointing to scopes with differently translated names.)</p>
<p id="rfc.section.8.p.8">Example of the viewing-related scope description document available at http://photoz.example.com/dev/scopes/view:</p>
<pre>
{
"name": "View Photo and Related Info",
"icon_uri": "http://www.example.com/icons/reading-glasses.png"
}
</pre>
<p id="rfc.section.8.p.9">Example of the broader scope description document available at http://photoz.example.com/dev/scopes/all:</p>
<pre>
{
"name": "All Actions",
"icon_uri": "http://www.example.com/icons/galaxy.png"
}
</pre>
<p id="rfc.section.8.p.10">While visiting Photoz, Alice selects a link or button that instructs the site to "Protect" or "Share" this single photo (user experience only; Photoz could have made this a default or preference setting).</p>
<p id="rfc.section.8.p.11">As a result, Photoz defines for itself a resource set that represents this photo (internal only; Photoz is the only application that knows how to map a particular photo to a particular resource set). Photoz also prepares the following resource set description, which is specific to Alice and her photo. The "name" property value is intended to be seen by Alice in mapping authorization policies to specific resource sets and actions when she visits CopMonkey. Alice would see the string "Steve the puppy!", likely accompanied by the referenced icon, in the CopMonkey interface. The possible scopes of access on this resource set are indicated with URI references to the scope descriptions, as shown just above.</p>
<pre>
{
"name": "Steve the puppy!",
"icon_uri": "http://www.example.com/icons/flower",
"scopes": [
"http://photoz.example.com/dev/scopes/view",
"http://photoz.example.com/dev/scopes/all"
]
}
</pre>
<p id="rfc.section.8.p.12">Photoz uses the "create resource set description" method of CopMonkey's standard OAuth resource set registration API, presenting its Alice-specific access token to use the API to register and assign an identifier to the resource set description.</p>
<pre>
PUT /resource_set/112210f47de98100 HTTP/1.1
Content-Type: application/json
...
{
"name": "Steve the puppy!",
"icon_uri": "http://www.example.com/icons/flower.png",
"scopes": [
"http://photoz.example.com/dev/scopes/view",
"http://photoz.example.com/dev/scopes/all"
]
}
</pre>
<p id="rfc.section.8.p.13">If the registration attempt succeeds, CopMonkey responds in the following fashion.</p>
<pre>
HTTP/1.1 201 Created
Content-Type: application/json
ETag: "1"
...
{
"status": "created",
"_id": "112210f47de98100",
"_rev": "1"
}
</pre>
<p id="rfc.section.8.p.14">At the time Alice indicates she would like this photo protected, Photoz can choose to redirect Alice to CopMonkey for further policy setting, access auditing, and other authorization server-related tasks (user experience only).</p>
<p id="rfc.section.8.p.15">Once it has successfully registered this description, Photoz is responsible for outsourcing protection to CopMonkey for access attempts made to this photo.</p>
<p id="rfc.section.8.p.16">Over time, as Alice uploads other photos and creates and organizes photo albums, Photoz can use additional methods of the resource set registration API to ensure that CopMonkey's understanding of Alice's protected resources matches its own.</p>
<p id="rfc.section.8.p.17">For example, if Photoz suspects that somehow its understanding of the resource set has gotten out of sync with CopMonkey's, it can ask to read the resource set description as follows.</p>
<pre>
GET /resource_set/112210f47de98100 HTTP/1.1
Host: as.example.com
...
</pre>
<p id="rfc.section.8.p.18">CopMonkey responds with the full content of the resource set description, including its _id and its current _rev, as follows:</p>
<p>Example of an HTTP response to a "read resource set description" request, containing a resource set description from the authorization server:</p>
<pre>
HTTP/1.1 200 OK
Content-Type: application/json
ETag: "1"
...
{
"_id": "112210f47de98100",
"_rev": "1",
"name": "Photo album",
"icon_uri": "http://www.example.com/icons/flower.png",
"scopes": [
"http://photoz.example.com/dev/scopes/view",
"http://photoz.example.com/dev/scopes/all"
]
}
</pre>
<p id="rfc.section.8.p.19">If for some reason Photoz and CopMonkey have gotten dramatically out of sync, Photoz can ask for the list of resource set identifiers CopMonkey currently knows about:</p>
<pre>
GET /resource_set HTTP/1.1
Host: as.example.com
...
</pre>
<p id="rfc.section.8.p.20">CopMonkey's response might look as follows:</p>
<pre>
HTTP/1.1 200 OK
...
[ "112210f47de98100", "34234df47eL95300" ]
</pre>
<p id="rfc.section.8.p.21">If Alice later changes the photo's title (user experience only) on Photoz from "Steve the puppy!" to "Steve on October 14, 2011", Photoz would use the "update resource set description" method to ensure that Alice's experience of policy-setting at CopMonkey remains consistent with what she sees at Photoz. Following is an example of this request.</p>
<pre>
PUT /resource_set/112210f47de98100 HTTP/1.1
Content-Type: application/json
Host: as.example.com
If-Match: "1"
...
{
"name": "Steve on October 14, 2011",
"icon_uri": "http://www.example.com/icons/flower.png",
"scopes": [
"http://photoz.example.com/dev/scopes/view",
"http://photoz.example.com/dev/scopes/all"
]
}
</pre>
<p id="rfc.section.8.p.22">CopMonkey would respond as follows.</p>
<pre>
HTTP/1.1 201 Created
Content-Type: application/json
ETag: "2"
...
{
"status": "updated",
"_id": "112210f47de98100",
"_rev": "2"
}
</pre>
<p id="rfc.section.8.p.23">There are other reasons Photoz might want to update resource set descriptions, having nothing to do with Alice's actions or wishes. For example, it might extend its API to include new features, and want to add new scopes to all of Alice's and other users' resource set descriptions.</p>
<p id="rfc.section.8.p.24">if Alice later decides to entirely remove sharing protection (user experience only) on this photo while visiting Photoz, ensuring that the public can get access without any protection, Photoz is responsible for deleting the relevant resource set registration, as follows:</p>
<pre>
DELETE /resource_set/112210f47de98100 HTTP/1.1
Host: as.example.com
If-Match: "2"
...
</pre>
<h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a href="#Acknowledgments" id="Acknowledgments">Acknowledgments</a></h1>
<p id="rfc.section.9.p.1">The current editor of this specification is Thomas Hardjono of MIT. The following people are co-authors:</p>
<ul>
<li>Paul C. Bryan, ForgeRock US, Inc.</li>
<li>Domenico Catalano, Oracle Corp.</li>
<li>George Fletcher, AOL</li>
<li>Maciej Machulak, Cloud Identity Ltd</li>
<li>Eve Maler, ForgeRock</li>
<li>Lukasz Moren, Cloud Identity Ltd</li>
<li>Christian Scholz, COMlounge GmbH</li>
<li>Nat Sakimura, NRI</li>
<li>Jacek Szpot, Newcastle University</li>
</ul>
<h1 id="rfc.references"><a href="#rfc.references">10.</a> References</h1>
<h1 id="rfc.references.1"><a href="#rfc.references.1">10.1.</a> Normative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="OAuth2">[OAuth2]</b>
</td>
<td class="top"><a title="IETF">Hardt, D.</a>, "<a href="http://tools.ietf.org/html/rfc6749">The OAuth 2.0 Authorization Framework</a>", October 2012.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC2119">[RFC2119]</b>
</td>
<td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">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.</td>
</tr>
</tbody>
</table>
<h1 id="rfc.references.2"><a href="#rfc.references.2">10.2.</a> Informative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="OAuth-linktypes">[OAuth-linktypes]</b>
</td>
<td class="top"><a>Richer, J.</a>, "<a href="http://tools.ietf.org/html/draft-wmills-oauth-lrdd">Link Type Registrations for OAuth 2</a>", October 2012.</td>
</tr>
<tr>
<td class="reference">
<b id="OAuth-meta">[OAuth-meta]</b>
</td>
<td class="top"><a>Sakimura, N.</a>, "<a href="http://tools.ietf.org/html/draft-sakimura-oauth-meta">JSON Metadata for OAuth Responses</a>", December 2012.</td>
</tr>
<tr>
<td class="reference">
<b id="OpenIDConnect">[OpenIDConnect]</b>
</td>
<td class="top"><a>Sakimura, N.</a>, "<a href="http://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Standard 1.0 - draft 07</a>", December 2011.</td>
</tr>
<tr>
<td class="reference">
<b id="UMA">[UMA]</b>
</td>
<td class="top"><a title="MIT">Hardjono, T.</a>, "<a href="http://docs.kantarainitiative.org/uma/draft-uma-core.html">User-Managed Access (UMA) Profile of OAuth 2.0 (V0.9)</a>", July 2014.</td>
</tr>
</tbody>
</table>
<h1 id="rfc.appendix.A"><a href="#rfc.appendix.A">Appendix A.</a> <a href="#History" id="History">Document History</a></h1>
<p id="rfc.section.A.p.1">NOTE: To be removed by RFC editor before publication as an RFC.</p>
<p id="rfc.section.A.p.2">At I-D rev 00:</p>
<ul>
<li>Broken out of draft-oauth-umacore (post-rev 05) I-D and made generic to apply to a variety of OAuth-based use cases.</li>
</ul>
<p id="rfc.section.A.p.3">From rev 00 to 01:</p>
<ul>
<li>Made editorial changes based on comments from Amanda Anganes.</li>
<li>Removed previously overlooked references to UMA-specific constructs in the normative section.</li>
</ul>
<h1 id="rfc.authors">
<a href="#rfc.authors">Author's Address</a>
</h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Thomas Hardjono</span> (editor)
<span class="n hidden">
<span class="family-name">Hardjono</span>
</span>
</span>
<span class="org vcardline">MIT</span>
<span class="adr">
<span class="vcardline">
<span class="locality"></span>
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline"></span>
</span>
<span class="vcardline">EMail: <a href="mailto:hardjono@mit.edu">hardjono@mit.edu</a></span>
</address>
</div>
</body>
</html>