connect / openid-connect-standard-1_0.xml

   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 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
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml.resource.org/authoring/rfc2629.dtd">
<rfc category="exp" docName="openid-connect-standard-1_0" ipr="trust200902">
  <?rfc toc="yes" ?>

  <?rfc tocdepth="4" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc strict="yes" ?>

  <?rfc iprnotified="no" ?>

  <?rfc private="Draft" ?>

  <front>
    <title>OpenID Connect Standard 1.0 - draft 09</title>

    <author fullname="Nat Sakimura" initials="N."
            surname="Sakimura">
      <organization abbrev="NRI">Nomura Research Institute,
      Ltd.</organization>

      <address>
        <email>n-sakimura@nri.co.jp</email>
      </address>
    </author>

    <author fullname="John Bradley" initials="J." surname="Bradley">
      <organization>Independent</organization>

      <address>
        <email>ve7jtb@ve7jtb.com</email>
      </address>
    </author>

    <author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
      <organization abbrev="Google">Google</organization>

      <address>
        <email>breno@google.com</email>
      </address>
    </author>

    <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
      <organization abbrev="Microsoft">Microsoft</organization>

      <address>
        <email>mbj@microsoft.com</email>
      </address>
    </author>

    <author fullname="Edmund Jay" initials="E." surname="Jay">
      <organization abbrev="Illumila">Illumila</organization>

      <address>
        <email>ejay@mgi1.com</email>
      </address>
    </author>

    <date day="9" month="April" year="2012" />

    <abstract>
      <t>OpenID Connect 1.0 is a simple identity layer on top of the
      OAuth 2.0 protocol. It allows Clients to verify the
      identity of the End-User based on the authentication performed by
      an Authorization Server, as well as to obtain basic profile information
      about the End-User in an interoperable and RESTful manner.</t>

      <t>OpenID Connect Standard 1.0 is an HTTP protocol binding for
      OpenID Connect Messages 1.0 request and response messages.</t>
    </abstract>
  </front>

  <middle>
    <section title='Introduction'>
      <t>This specification describes the binding of the HTTP
      protocol with the endpoints described in <xref
      target="OpenID.Messages"> OpenID Connect Messages</xref>.</t>

      <section anchor="rnc" title="Requirements Notation and Conventions">
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in <xref
	target="RFC2119"></xref> .</t>

	<t>Throughout this document, values are quoted to indicate that they are
	to be taken literally. When using these values in protocol messages, the
	quotes MUST NOT be used as part of the value.</t>
      </section>

      <section anchor="terminology" title="Terminology">
	<t>This specification uses the terms "Access Token", "Refresh Token",
	"Authorization Code", "Authorization Grant", "Authorization Server",
	"Authorization Endpoint", "Client", "Client Identifier", "Client
	Secret", "Protected Resource", "Resource Owner", "Resource Server", and
	"Token Endpoint" defined by
	<xref target="OAuth2.0">OAuth 2.0</xref>,
	and the terms defined by
	<xref target="OpenID.Messages">OpenID Connect Messages 1.0</xref>.
	This specification also defines the following terms:
	  <list style="hanging">
	    <t hangText="Request File">A document whose contents
	    is a JWT representing a set of Authorization Request
	    parameters.</t>

	    <t hangText="Request File URI">A URL that references a Request File.
	    The Request File contents MUST be retrievable by the
	    Authorization Server.</t>
	  </list></t>
      </section>
    </section>

    <section title="Authorization Endpoint">
      <t>The Authorization Endpoint performs authentication services for the
      End-User and requests authorization from the End-User to release
      information to OpenID Connect Relying Party Clients. When an End-User 
      accesses a Relying Party Client application that requires
      the End-User's identifier and other information, it sends the End-User to
      the Authorization Server's Authorization Endpoint for authentication and
      authorization. The Authorization Server then issues an ID Token that
      asserts the End-User's identifier and an Access Token that allows the
      Client to access the End-User's information at Protected Resource
      endpoints. Protected Resource endpoints MAY perform different actions or
      return different information based on the scopes associated with the 
      presented Access Token.
      Clients MUST specify 
      how the Access Token and ID Token are to be returned using the
      <spanx style="verb">response_type</spanx>
      parameter in the Authorization Request.
      </t>

      <section anchor="openid_scopes" title="OpenID Connect Scopes">
        <t>Clients MUST specify the desired scopes in an authorization request to
        obtain an Access Token with the proper permissions.</t>
        
        <t>Scopes names defined for OpenID Connect are in Section 2.1.2 of <xref
          target="OpenID.Messages">OpenID Connect Messages 1.0</xref>. 
           OAuth 2.0 allows additional scope values to be specified as extensions.</t>
         
        <t>OpenID Connect's <spanx style="verb">scope</spanx> use is consistent with Section 3.3 of 
        <xref target="OAuth2.0">OAuth 2.0</xref>. </t>
        
        <t>The Authorization Server MAY fully or partially ignore the scope values
         requested by the Client based on the Authorization Server policy or
         the End-User's instructions.</t>

        <t>To increase new account activation, a Client may elect to
        only request a subset of the information available from the
        UserInfo Endpoint.</t>

        <t><figure>
            <preamble>The following is a non-normative example of a <spanx style="verb">scope</spanx>
            parameter in an Authorization Request.</preamble>

            <artwork><![CDATA[scope=openid profile email phone]]></artwork>
          </figure></t>
      </section>
      
      <section anchor="protocol_flows" title="Protocol Flows">

        <t>Authorization Requests follow two main paths to obtain Access Tokens
        and ID Tokens, the Implicit Flow and the Authorization Code Flow. The 
        flows determine how the Access Token and ID Token are returned to the 
        Client. Access Tokens are credentials used to access Protected 
        Resources, as defined in section 1.4 of 
        <xref target="OAuth2.0">OAuth 2.0</xref>. Access Tokens represent 
        a Resource Owner's authorization and MUST NOT be exposed to 
        unauthorized parties.</t>

        <t>The Implicit Flow is mainly used by Clients implemented in a browser
        using a scripting language. The Access Token and ID Token are returned
        directly to the Client, which MAY expose them to the Resource Owner and
        other applications that have access to the Resource Owner's User-Agent.
        The Authorization Server does not perform Client authentication before
        issuing the Access Token.</t>

        <t>The Authorization Code Flow returns an Authorization Code to the
        Client, which can then exchange it for an Access Token directly. This
        provides the added benefit of not exposing the Access Token to the 
        Resource Owner and possibly other malicious applications with access
        to the Resource Owner's User-Agent. The Authorization Server can also
        authenticate the Client before exchanging the Authorization Code for an
        Access Token. The Authorization Code flow is suitable for Clients that 
        can securely maintain a Client Secret between themselves and the
        Authorization Server whereas the Implicit flow is suitable for Clients
        that cannot.</t>

        <section anchor="retrieving_code_token" 
                 title="How to Get an Authorization Code, Access Token, and ID Token">

          <t>The OAuth 2.0 specification documents two response types:

            <list style="hanging">
              <t hangText="code"> When supplied as the value for the
              <spanx style="verb">response_type</spanx> parameter, a
              successful response MUST include an Authorization Code as
              defined in the OAuth 2.0 specification. Both successful
              and error responses MUST be added as parameters to the
              query component of the response.  All tokens are returned
              from the Token Endpoint. Authorization Servers MUST support
              this <spanx style="verb">response_type</spanx>.</t>

              <t hangText="token"> When supplied as the value for the
              <spanx style="verb">response_type</spanx> parameter, a
              successful response MUST include an Access Token as
              defined in the OAuth 2.0 specification.  Both successful
              and error responses MUST be fragment-encoded.  No ID Token
              is provided to the Client.</t>
            </list>
          </t>

          <t>OpenID Connect supports these <xref
          target="OAuth.Responses">additional response types</xref> that have
          been registered:</t>
          
          <t><list style="hanging">
            <t hangText="id_token">When supplied as the value
            for the <spanx style="verb">response_type</spanx>
            parameter, a successful response MUST include an ID Token.
            Both successful and
            error responses SHOULD be fragment-encoded. Authorization
            Servers SHOULD support this <spanx
            style="verb">response_type</spanx>.</t>
              
            <t hangText="id_token token">When supplied as the value
            for the <spanx style="verb">response_type</spanx>
            parameter, a successful response MUST include both an
            Access Token as well as an ID Token.  Both successful and
            error responses SHOULD be fragment-encoded. Authorization
            Servers MUST support this <spanx
            style="verb">response_type</spanx>.</t>

            <t hangText="code token">When supplied as the value for
            the <spanx style="verb">response_type</spanx> parameter, a
            successful response MUST include both an Access Token and
            an Authorization Code as defined in the OAuth 2.0
            specification. Both successful and error responses SHOULD
            be fragment-encoded.</t>

            <t hangText="code id_token">When supplied as the value for
            the <spanx style="verb">response_type</spanx> parameter, a
            successful response MUST include both an Authorization
            Code as well as an ID Token.  Both successful and error
            responses SHOULD be fragment-encoded.</t>

            <t hangText="code id_token token">When supplied as the
            value for the <spanx style="verb">response_type</spanx>
            parameter, a successful response MUST include an
            Authorization Code, an ID Token, and an Access Token.
            Both successful and error responses SHOULD be
            fragment-encoded.</t>
          </list></t>
          <t>The Authorization Server MUST support both the <spanx
          style="verb">code</spanx> and the <spanx
          style="verb">'id_token token'</spanx> <spanx
          style="verb">response_type</spanx>.</t>
		  
          <t>The Client may request any OAuth 2.0 registered response
          type supported by the Authorization Server.</t>
          
        </section>

        <section anchor="code_flow" title="Authorization Code Flow">
          <t>The Authorization Code Flow goes through the following
          steps.</t>          
          <t><list style="numbers">
              <t>Client prepares an Authorization Request containing the desired
              request parameters.</t>

              <t>Client sends a request to the Authorization Server.</t>

              <t>Authorization Server Authenticates the End-User.</t>

              <t>Authorization Server Obtains the End-User
              Consent/Authorization.</t>

              <t>Authorization Server Sends the End-User back to the Client with
              an Authorization Code.</t>

              <t>Client requests a response using the Authorization Code at the
              <xref target="token_ep">Token Endpoint</xref>.</t>

              <t>Client receives a response that contains an Access Token and ID
              Token in the response body.</t>

              <t>(OPTIONAL) Client validates the ID Token at the <xref 
              target="check_id_ep">Check ID Endpoint</xref>.</t>

              <t>(OPTIONAL) Client receives ID Token Response with the End-User's
              identifier.</t>

              <t>(OPTIONAL) Client accesses the <xref 
              target="userinfo_ep">UserInfo Endpoint</xref>  with the Access
              Token.</t>

              <t>(OPTIONAL) Client receives UserInfo Response.</t>
             </list>Note that in each step, the party that receives a message
          MUST verify it according to the verification rule set in <xref
          target="OpenID.Messages">OpenID Connect Messages 1.0</xref>.</t>
        </section>

        <section anchor="implicit_flow" title="Implicit Flow">
          <t>The Implicit Flow follows the following steps:</t>

          <t><list style="numbers">
              <t>Client prepares an Authorization Request containing the desired
              request parameters.</t>

              <t>Client sends a request to the Authorization Server.</t>

              <t>Authorization Server Authenticates the End-User.</t>

              <t>Authorization Server Obtains the End-User
              Consent/Authorization.</t>

              <t>Authorization Server Sends the End-User back to the Client with
              an Access Token and an ID Token if requested.</t>

              <t>(OPTIONAL) Client validates the ID Token at the <xref 
              target="check_id_ep">Check ID Endpoint</xref>.</t>

              <t>(OPTIONAL) Client receives ID Token Response with the End-User's
              identifier.</t>

              <t>(OPTIONAL) Client accesses the <xref 
              target="userinfo_ep">UserInfo Endpoint</xref>  with the Access
              Token.</t>

              <t>(OPTIONAL) Client receives UserInfo Response.</t>
             </list>Note that in each step, the party that receives a message
          MUST verify it according to the verification rule set in <xref
          target="OpenID.Messages">OpenID Connect Messages 1.0</xref>.</t>
        </section>

      </section>

      <section anchor="auth_request" title="Authorization Request">
        <t>When the End-User wishes to access a Protected Resource, and the
        End-User Authorization has not yet been obtained, the Client
        prepares an Authorization Request to the Authorization Endpoint.</t>

        <t>Authorization Servers MUST require the use of a transport-layer
        security mechanism at the Authorization Endpoint. The Authorization 
        Server MUST support TLS 1.2 <xref target="RFC5246">RFC 5246</xref>
	and/or TLS 1.0 <xref target='RFC2246' />
	and MAY support other transport-layer 
        mechanisms with equivalent security.</t>

        <t>Authorization Servers MUST support the use of the HTTP "GET" and 
        "POST" methods defined in <xref target="RFC2616">RFC 2616</xref> at the
        Authorization Endpoint. </t>

        <t>Clients MAY use the HTTP "GET" or "POST" method to send the
        Authorization Request to the Authorization Server. If using the HTTP
        "GET" method, the request parameters are serialized using URI <xref
        target="qss">query string serialization</xref>. If using the HTTP "POST"
        method, the request parameters are serialized using 
        <xref target="form_serialization">form serialization</xref>.</t>

        <section anchor="rf_prep"
                 title="Client Prepares an Authorization Request">
          <t>The Client prepares an Authorization Request to the Authorization
          Endpoint with the request parameters using the HTTP "GET" or "POST"
          method. The scheme used in the Authorization URL MUST be HTTPS.
	  The Client MUST perform a TLS/SSL server certificate check, per
	  <xref target="RFC6125">RFC 6125</xref>.
	  </t>

          <t>The required Authorization Request parameters are as follows:</t>

          <t><list style="hanging">
              <t hangText="response_type">An OAuth 2.0 registered
              response type that determines how the Authorization
              Response is returned to the Client.  As described in
              <xref target="retrieving_code_token" >How to Get an
              Authorization Code, Access Token, and ID Token</xref> ,
              the following registered values are supported:
                <list style="symbols">
                  <t><spanx style="verb">code</spanx></t>

                  <t><spanx style="verb">code id_token</spanx></t>
                  
                  <t><spanx style="verb">id_token</spanx></t>

                  <t><spanx style="verb">token</spanx></t>

                  <t><spanx style="verb">token id_token</spanx></t>

                  <t><spanx style="verb">code token</spanx></t>

                  <t><spanx style="verb">code token id_token</spanx></t>
                </list></t>

              <t hangText="client_id">The Client identifier.</t>

              <t hangText="scope">It MUST include <spanx style="verb">openid</spanx>
              as one of the space delimited ASCII strings. Other values that MAY be included are
              <spanx style="verb">profile</spanx>, and <spanx style="verb">email</spanx>,
              <spanx style="verb">address</spanx>.
              The values specify an additive list of Claims that are returned
              by the UserInfo Endpoint as described by <xref
              target="openid_scopes">OpenID Connect Scopes</xref>.</t>

              <t hangText="redirect_uri">A redirection URI where the response
              will be sent. The Scheme, Host, and Path segments of this URI MUST 
              match one of the <spanx style="verb">redirect_uris</spanx> registered 
              for the <spanx style="verb">client_id</spanx> in the <xref
               target="OpenID.Registration">OpenID Connect Dynamic Client 
               Registration 1.0</xref> specification.</t>

              <t hangText="nonce">A string value used to associate a user agent session 
              with an ID Token, and to mitigate replay attacks. 
              The value is passed through unmodified to the ID Token.
              One method is to store a random value as a signed session cookie, and
              pass the value in the <spanx style="verb">nonce</spanx> parameter.  The <spanx style="verb">nonce</spanx> in the returned ID Token
              is compared to the signed session cookie to detect ID Token replay by third 
              parties.</t>
            </list></t>

          <t>The request can contain the following OPTIONAL parameters:</t>

          <t><list style="hanging">
              <t hangText="state">An opaque value used to maintain state
              between the request and the callback.</t>

              <t hangText="request">A <xref target="JWT">JWT</xref> encoded
              OpenID
              Request Object.</t>

              <t hangText="request_uri">A URL that points to an OpenID
              Request Object.</t>

              <t hangText="display">An ASCII string value that specifies
              how the Authorization Server displays the authentication page to
              the End-User. Refer to Sec 2.1.2 of <xref
              target="OpenID.Messages">OpenID Connect Messages 1.0</xref> for
              more information.</t>

              <t hangText="prompt">A space delimited list of ASCII strings
	      that can contain the values
              <spanx style="verb">login</spanx>, <spanx style="verb">consent</spanx>,
              <spanx style="verb">select_account</spanx>, and
	      <spanx style="verb">none</spanx>. Refer to <xref
              target="OpenID.Messages">OpenID Connect Messages 1.0</xref> for
              more information.</t>
              <t hangText="id_token">A JWT <spanx style="verb">id_token</spanx>
              passed to the Authorization server as a hint. Refer to <xref
              target="OpenID.Messages">OpenID Connect Messages 1.0</xref> for
              more information.</t>
            </list></t>

          <t>There are three methods to construct and send the request to the 
          Authorization Endpoint: 
          <list style="letters">
              <t>Simple Request Method</t>

              <t>Request Parameter Method</t>

              <t>Request File Method</t>
          </list></t>

          <t>The Simple Request Method is used in simple cases when default
          UserInfo and ID Token Claims are desired.</t>

          <t>The Request Parameter Method is used by sending an OpenID Request
          Object when the Client desires to retrieve a different set of
          UserInfo and ID Token Claims. The request parameter method also
          allows requests to be signed or encrypted. </t>

          <t>The Request File Method works similar to the Request Parameter
          Method but differs in that it sends an URL as a reference to the
          OpenID Request Object. It enables large requests to be sent
          securely and compactly even on user agents with limited capabilities.
          Clients SHOULD use the Request File Method to minimize the request
          size.</t>

          <section title="Simple Request Method">
            <t>The Client prepares an Authorization Request to the
            Authorization Endpoint using the appropriate parameters. If using 
            the HTTP "GET" method, the request parameters are serialized using
            URI <xref target="qss">query string serialization</xref>. If using
            the HTTP "POST" method, the request parameters are serialized using 
            <xref target="form_serialization">form serialization</xref>.</t>

            <t><figure>
                <preamble>The following is a non-normative example of an
                Authorization Request URL. Note that the line wraps within the
                values are for display purpose only:</preamble>

                <artwork><![CDATA[https://server.example.com/op/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj]]></artwork>
              </figure></t>

            <section anchor="norm_req"
                     title="Client sends a request to the Authorization Server">
              <t>Having constructed the Authorization Request, the Client sends it
              to the HTTPS End-User Authorization Endpoint. This
              MAY happen via HTTPS redirect, hyperlinking, or any other means
              of directing the User-Agent to the Authorization Endpoint URL.</t>

              <t>Following is a non-normative example using HTTP redirect.
              Note: Line wraps are for display purpose only.</t>

              <figure>
                <artwork><![CDATA[HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj]]></artwork>
              </figure>
            </section>
          </section>

          <section title="Request Parameter Method" anchor="req_param_method">
            <t>The Client prepares an Authorization Request to the
            Authorization Endpoint using the appropriate HTTP parameters
            serialization. The Client SHOULD construct the request using the
            HTTP "POST" method, but MAY use the HTTP "GET" method.</t>

            <t>The Authorization Request MUST include the 
            <spanx style="verb">request</spanx> parameter defined in the <xref
            target="rf_prep">Client Prepares an Authorization Request</xref>
            section. The Authorization Request MUST NOT include the 
            <spanx style="verb">request_uri</spanx> parameter.</t>

            <t>The <spanx style="verb">request</spanx> parameter is a
              <xref target="JWT">JWT</xref> encoded OpenID
              Request Object
              that contains the Authorization Request and also
              specifies the content of
              the responses returned from the UserInfo and Check ID
              Endpoints. The JWT object MAY be signed or signed and encrypted via
              <xref target="JWS">JWS</xref> and <xref target="JWE">JWE</xref>
              respectively, thereby providing authentication, integrity,
              non-repudiation and/or confidentiality.</t>

            <t>All Authorization Request parameters that are part of the
            Authorization Request excluding the <spanx style="verb">request</spanx>,
            <spanx style="verb">request_uri</spanx>,
            <spanx style="verb">redirect_uri</spanx>, <spanx style="verb">state</spanx>,
            <spanx style="verb">client_id</spanx>, and <spanx style="verb">nonce</spanx>
            parameters MUST also be JSON
            Serialized into the 
            OpenID Request Object with the same values.  This allows
            the Client to send signed and/or encrypted requests to the
            Authorization Server and maintain conformance to OAuth 2.0.</t>
            
            <t>The <spanx style="verb">client_id</spanx>
            , <spanx style="verb">redirect_uri</spanx>, <spanx style="verb">state</spanx>,
            and <spanx style="verb">nonce</spanx>
            parameters MAY also be included in the 
            OpenID Request Object.</t>

            <t><figure>
                <preamble>The following is a non-normative example of an
                OpenID Request Object before JWT encoding. Note that the line 
                wraps within the values are for display purpose only:</preamble>

                <artwork><![CDATA[{
 "response_type": "code%20id_token",
 "client_id": "s6BhdRkqt3",
 "redirect_uri": "https://client.example.com/cb",
 "scope": "openid profile",
 "state": "af0ifjsldkj",
 "nonce": "n-0S6_WzA2Mj",
 "userinfo":
   {
     "claims":
       {
         "name": null,
         "nickname": {"optional": true},
         "email": null,
         "verified": null,
         "picture": {"optional": true}
       }
   },
 "id_token":
   {
     "max_age": 86400,
     "claims:{"acr": {"values":["2"]}}
   }
}]]></artwork>
              </figure> <figure>
                <preamble>The following is a non-normative example of a <xref
                target="JWT">JWT</xref> encoded OpenID Request Object. Note
                that the line wraps within the values are for display purpose
                only:</preamble>

                <artwork><![CDATA[JWT algorithm = HS256
HMAC HASH Key = 'aaa'

JSON Encoded Header = "{"alg":"HS256","typ":"JWT"}"
JSON Encoded Payload = "{"response_type":"code id_token",
    "client_id":"s6BhdRkqt3",
    "redirect_uri":"https://client.example.com/cb",
    "scope":"openid profile",
    "state":"af0ifjsldkj",
    "nonce":"n-0S6_WzA2Mj",
    "userinfo":{"claims":{"name":null,"nickname":{"optional":true},
        "email":null,"verified":null,
        "picture":{"optional":true}}},
    "id_token":{"max_age":86400,"claims":{"acr":{"values":["2"]}}}

JWT = eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZ
    SBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiO
    iJodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkI
    HByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl9XekEyT
    WoiLCJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6bnVsbCwibmlja25hbWUiOnsib
    3B0aW9uYWwiOnRydWV9LCJlbWFpbCI6bnVsbCwidmVyaWZpZWQiOm51bGwsInBpY3R1c
    mUiOnsib3B0aW9uYWwiOnRydWV9fX0sImlkX3Rva2VuIjp7Im1heF9hZ2UiOjg2NDAwL
    CJjbGFpbXMiOnsiYWNyIjp7InZhbHVlcyI6WyIyIl19fX19.ou2Yc1B9a5iZLqbzBxE9
    5aNS0pSfRClCqM77n85ehGo]]></artwork>
              </figure></t>

            <t><figure>
                <preamble>The following is a non-normative example of an
                Authorization Request with the OpenID Request Method. Note that
                the line wraps within the values are for display purpose only:
                </preamble>

                <artwork><![CDATA[https://server.example.com/authorize?
response_type=code%02id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&scope=openid
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
&request=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY2
9kZSBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOi
JodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2
ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl9XekEyTWoiLCJ1c2
VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6bnVsbCwibmlja25hbWUiOnsib3B0aW9uYWwiOn
RydWV9LCJlbWFpbCI6bnVsbCwidmVyaWZpZWQiOm51bGwsInBpY3R1cmUiOnsib3B0aW9uYW
wiOnRydWV9fX0sImlkX3Rva2VuIjp7Im1heF9hZ2UiOjg2NDAwLCJjbGFpbXMiOnsiYWNyIj
p7InZhbHVlcyI6WyIyIl19fX19.ou2Yc1B9a5iZLqbzBxE95aNS0pSfRClCqM77n85ehGo]]></artwork>
              </figure></t>

            <section anchor="request_req"
                     title="Client Sends a Request to the Authorization Server">
              <t>Having constructed the Authorization Request, the Client sends
              it to the HTTPS Authorization Endpoint. This
              MAY happen via HTTPS redirect, hyperlinking, or any other means
              of directing the User-Agent to the Authorization Endpoint.</t>

              <t>Following is a non-normative example using HTTP redirect.
              Note: Line wraps are for display purpose only.</t>

              <figure>
                <artwork><![CDATA[HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&scope=openid
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
&request=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY2
9kZSBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOi
JodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2
ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl9XekEyTWoiLCJ1c2
VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6bnVsbCwibmlja25hbWUiOnsib3B0aW9uYWwiOn
RydWV9LCJlbWFpbCI6bnVsbCwidmVyaWZpZWQiOm51bGwsInBpY3R1cmUiOnsib3B0aW9uYW
wiOnRydWV9fX0sImlkX3Rva2VuIjp7Im1heF9hZ2UiOjg2NDAwLCJjbGFpbXMiOnsiYWNyIj
p7InZhbHVlcyI6WyIyIl19fX19.ou2Yc1B9a5iZLqbzBxE95aNS0pSfRClCqM77n85ehGo]]></artwork>
              </figure>
            </section>
          </section>

          <section title="Request File Method" anchor="Request_File_Method">
            <t>The Request File Method differs from the other methods in that
            it uses a Request File that contains an
            OpenID Request Object. It then sends the Request File URL as
            part of the Authorization Request.</t>

            <t>The Client prepares an Authorization Request using the desired 
            HTTP "GET" or "POST" method. The Client SHOULD use the HTTP "GET"
            method, but MAY use the HTTP "POST" method.
	    The scheme used in the Authorization URL MUST be HTTPS.
	    The Client MUST perform a TLS/SSL server certificate check, per
	    <xref target="RFC6125">RFC 6125</xref>.
	    </t>

            <t> The Authorization Request MUST NOT include the 
            <spanx style="verb">request</spanx> parameter. The Authorization
            Request MUST include the <spanx style="verb">request_uri</spanx>
            parameter. The target of the URL is a JWT that is an
            OpenID Request Object. The scheme used in the 
            <spanx style="verb">request_uri</spanx> value MUST be HTTPS, 
            unless the target JWT is signed in a way that is verifiable by the 
            Authorization server.
            The <spanx style="verb">request_uri</spanx> value MUST be reachable by the
            Authorization Server, and SHOULD be reachable by the Client.
            </t>

            <t><figure>
                <preamble>Following is a non-normative example of a Request
                File. Note that the line wraps within the values are for
                display purpose only:</preamble>

                <artwork><![CDATA[eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZSBpZF9
0b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiOiJodHRwczp
cL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUiLCJ
zdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl9XekEyTWoiLCJ1c2VyaW5mbyI
6eyJjbGFpbXMiOnsibmFtZSI6bnVsbCwibmlja25hbWUiOnsib3B0aW9uYWwiOnRydWV9LCJ
lbWFpbCI6bnVsbCwidmVyaWZpZWQiOm51bGwsInBpY3R1cmUiOnsib3B0aW9uYWwiOnRydWV
9fX0sImlkX3Rva2VuIjp7Im1heF9hZ2UiOjg2NDAwLCJjbGFpbXMiOnsiYWNyIjp7InZhbHV
lcyI6WyIyIl19fX19.ou2Yc1B9a5iZLqbzBxE95aNS0pSfRClCqM77n85ehGo]]></artwork>
              </figure></t>

            <section anchor="rurl_create"
                     title="Client Generates the URL of the Request File">
              <t>The Client then stores the Request File either locally or remotely.
               This is the Request URI, <spanx style="verb">"request_uri"</spanx>. 
               The URI MAY be appended with the base64url encoded SHA256 [FIPS180-2] hash of the file 
               after "#" so that the Authorization Server can detect whether the file 
               has changed. </t>

              <t>It should be noted that if the Request File includes user's attribute 
              values, it MUST NOT be revealed to anybody but the Authorization Server. 
              As such, the <spanx style="verb">"request_uri"</spanx> MUST have
              appropriate entropy for its lifetime, 
              and must be removed after successful authentication or a reasonable timeout.
              </t>
              <t>The Client then records the Request File either locally or
              remotely and obtains the Request File URI, <spanx style="verb">"request_uri"</spanx>.
              </t>
              <figure>
                <preamble>Following is a non-normative example. Note: Line
                wraps are for display purpose only:</preamble>

                <artwork><![CDATA[https://client.example.com/rf.jwt
#959w6lFunlMyjSaxmW0FtqvkRsmCaAIWuwl6QKeY89g]]></artwork>
              </figure>


            </section>

            <section anchor="art_req"
                     title="Client Sends a Request to Authorization Server via HTTPS Redirect">
              <t>The Client sends the Authorization Request to the Authorization
              Endpoint.</t>

              <t>The entire URL MUST NOT exceed 512 bytes.</t>

              <figure>
                <preamble>Following is a non-normative example. Note: Line
                wraps are for display purpose only:</preamble>

                <artwork><![CDATA[HTTP/1.1 302 Found
Location: https://server.example.com/authorize
?response_type=code%20id_token
&client_id=s6BhdRkqt3
&request_uri=https%3A%2F%2Fclient.example.com%2Frf.jwt
%23959w6lFunlMyjSaxmW0FtqvkRsmCaAIWuwl6QKeY89g
&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj&scope=openid]]></artwork>
              </figure>
            </section>

            <section title="Authorization Server Fetches the Request File">
              <t>Upon receipt of the Request, the Authorization Server MUST
              send a GET request to the <spanx style="verb">request_uri</spanx>
              to retrieve the content unless it is already cached and parse it
              to recreate the Authorization Request parameters.</t>

              <t>Note that the RP SHOULD use a unique URI for each
              request utilizing distinct parameters, or otherwise
              prevent the Authorization Server from caching the <spanx style="verb">request_uri</spanx>.
              </t>

              <figure>
                <preamble>Following is a non-normative example of this fetch
                process. Note: Line wraps are for display purpose
                only:</preamble>

                <artwork><![CDATA[GET /rf.jwt HTTP/1.1
Host: client.example.com]]></artwork>
              </figure>
            </section>
          </section>
        </section>

	<section title="Authorization Server Validates Request Object">
          <t>The Authorization Server validates the request according to 
		  the Section 5.1 of <xref target="OpenID.Messages">OpenID Connect
            Messages 1.0</xref>. 
		  </t>
          
	</section>


        <section title="Authorization Server Authenticates the End-User">
          <t>The Authorization Server validates the request to ensure all
          required parameters are present and valid. If the request is valid,
          the Authorization Server MUST authenticate the End-User. The way in
          which the Authorization Server authenticates the End-User (e.g.
          username and password login, session cookies) is beyond the scope of
          this specification. An authentication user interface MAY be displayed
          by the Authorization Server depending on the authentication method
          used.</t>

          <t>The Authorization Server MUST attempt to authenticate the 
          End-User in the following cases:
          <list style="symbols">
                <t>The End-User is not already authenticated by the Authorization
                Server.</t>

                <t>The Authorization Request contains the <spanx 
                style="verb">prompt</spanx> parameter with the value
		<spanx style="verb">login</spanx>. The
                Authorization Server MUST reauthenticate the End-User
                even if the End-User is already authenticated.</t>
          </list></t>
          <t>The Authorization Server MUST NOT attempt authentication
          in the following cases:
          <list style="symbols">
                <t>The Authorization Request contains the <spanx 
                style="verb">"prompt"</spanx> parameter with the value
		<spanx style="verb">none</spanx>.
                The Authorization Server MUST return an error if the End-User is 
                unauthenticated.</t>
          </list></t>
        </section>

        <section title="Authorization Server Obtains the End-User Consent/Authorization">
          <t>Once the End-User is authenticated, the Authorization Server MUST
          obtain an authorization decision. This MAY be done by presenting the
          End-User with a dialogue that allows the End-User to recognize what he is
          consenting to and obtain his consent or by establishing consent via
          other means (for example, via previous administrative consent).</t>

          <t>The Authorization Server MUST attempt to request authorization
          from the End-User in the following cases:
          <list style="symbols">
                <t>The End-User has not pre-authorized the Client for the
                authorization request.</t>

                <t>The Authorization Request contains the <spanx 
                style="verb">prompt</spanx> parameter with the value
		<spanx style="verb">consent</spanx>. The
                Authorization Server MUST request End-User authorization even if the
                End-User has previously authorized the Client.</t>
          </list></t>
          <t>The Authorization Server MUST NOT request End-User authorization in the
          following cases:
          <list style="symbols">
                <t>The Authorization Request contains the <spanx 
                style="verb">"prompt"</spanx> parameter with the value
		<spanx style="verb">none</spanx>.
                The Authorization Server MUST return an error if the End-User has
                not pre-authorized the Client.</t>
          </list></t>
        </section>

        <section anchor="art_res"
                 title="Authorization Server Sends the End-User Back to the Client">
          <t>Once the authorization is determined, the Authorization Server
          returns a successful or error response.</t>

          <section anchor="art_res_ok" title="End-User Grants Authorization">
            <t>If the Resource Owner grants the access request, the
            Authorization Server issues an Authorization Response and delivers it
            to the Client by adding the response parameters to <spanx
            style="verb">redirect_uri</spanx> specified in the Authorization
            Request using the "application/x-www-form-urlencoded" format.</t>

            <t>If the <spanx style="verb">response_type</spanx> parameter in the
            Authorization Request includes the string value
	    <spanx style="verb">code</spanx>, the
            following response parameters are included:
              <list style="hanging">
                <t hangText="code">REQUIRED. The Authorization Code.</t>
              </list>
            Upon receipt of the <spanx style="verb">"code"</spanx>, the
            Client requests a response that includes the <spanx
            style="verb">"access_token"</spanx> and other variables. The
            requests and responses are described in the <xref 
            target="token_ep">Token Endpoint</xref> section.</t>

            <t>If the <spanx style="verb">response_type</spanx> parameter in the
            Authorization Request includes the string value
	    <spanx style="verb">token</spanx>, the
            following response parameters are included:
              <list style="hanging">
                <t hangText="access_token">REQUIRED. The Access Token.</t>

                <t hangText="token_type">REQUIRED. This specification only
                supports the <xref target="OAuth.Bearer">Bearer
                Token</xref> scheme. As such, this value MUST be set to
                "<spanx style="verb">Bearer</spanx>".</t>

                <t hangText="expires_in">OPTIONAL. The lifetime in seconds of 
                the Access Token.</t>

                <t hangText="scope">OPTIONAL. The scope values of the issued Access
                Token.</t>
              </list></t>

            <t>If the <spanx style="verb">response_type</spanx> parameter in the
            Authorization Request includes the string value
	    <spanx style="verb">id_token</spanx>, the
            following response parameters are returned:
              <list style="hanging">
                <t hangText="id_token">REQUIRED. The ID Token of the for the
                authentication session.</t>
              </list></t>

            <t>The response parameters MAY also be include:
              <list style="hanging">
                <t hangText="state">REQUIRED if the <spanx style="verb">state</spanx>
                parameter is present in the Authorization Request.
                Set it to the exact value of the <spanx
                style="verb">state</spanx> parameter received from the
                Client.</t>
              </list></t>

            <t>No other parameter SHOULD be returned.</t>

            <t>If the <spanx style="verb">response_type</spanx> parameter in the
            Authorization Request includes the string value
	    <spanx style="verb">token</spanx> or <spanx style="verb">id_token</spanx>,
	    all response parameters SHOULD be added to the fragment
            component of the redirection URI. Otherwise, the response parameters
            are added to the query component of the redirection URI.
            </t>

            <figure>
              <preamble>The following are non-normative examples of requests with
	      differing <spanx style="verb">return_type</spanx> values and their responses. Line wraps
              are for display purpose only:</preamble>
             
              <artwork><![CDATA[https://server.example.com/op/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj

              
HTTP/1.1 302 Found
Location: https://client.example.com/cb?
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&state=af0ifjsldkj]]></artwork>
            </figure>

            <figure>
              <artwork><![CDATA[https://server.example.com/op/authorize?
response_type=token%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj

              
HTTP/1.1 302 Found
Location: https://client.example.com/cb#
access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
&token_type=Bearer
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZ
XJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0c
DpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH3T1
G3liaTNOrfaeWYjuRCEPNXVtaazNQ
&state=af0ifjsldkj]]></artwork>
            </figure>

            <figure>
              <artwork><![CDATA[https://server.example.com/op/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj

              
HTTP/1.1 302 Found
Location: https://client.example.com/cb#
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZ
XJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0c
DpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH3T1
G3liaTNOrfaeWYjuRCEPNXVtaazNQ
&state=af0ifjsldkj]]></artwork>
            </figure>

            <figure>
              <artwork><![CDATA[https://server.example.com/op/authorize?
response_type=token%20code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj


HTTP/1.1 302 Found
Location: https://client.example.com/cb#
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
&token_type=Bearer
&state=af0ifjsldkj]]></artwork>
            </figure>

            <figure>
              <artwork><![CDATA[https://server.example.com/op/authorize?
response_type=token%20code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&scope=openid
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj


HTTP/1.1 302 Found
Location: https://client.example.com/cb#
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y
&token_type=Bearer
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZ
XJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0c
DpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH3T1
G3liaTNOrfaeWYjuRCEPNXVtaazNQ
&state=af0ifjsldkj]]></artwork>
            </figure>

          </section>

          <section anchor="authz_error"
                   title="End-User Denies Authorization or Invalid Request">
            <t>If the End-User denies the authorization or the user authentication
            fails, the Authorization Server MUST return the error authorization 
            response as defined in <xref target="OpenID.Messages">OpenID Connect
            Messages 1.0</xref>. The Authorization Server returns the Client to
            the redirection URI specified in the Authorization Request
            with the appropriate error parameters. No
            other parameters SHOULD be returned.</t>

            <t>The error response parameters are the following:
              <list style="hanging">
                <t hangText="error">REQUIRED. The error code.</t>

                <t hangText="error_description">OPTIONAL. A human-readable UTF-8
                encoded text description of the error.</t>

                <t hangText="error_uri">OPTIONAL. A URI to a web page that
                includes additional information about the error.</t>

                <t hangText="state">REQUIRED if the Authorization Request
                included the <spanx style="verb">state</spanx> parameter. Set
                to the exact value received from the Client.</t>
              </list></t>

            <t>If the <spanx style="verb">response_type</spanx> parameter in the
            Authorization Request includes the string value
	    <spanx style="verb">token</spanx> or <spanx style="verb">id_token</spanx>,
	    all error response parameters SHOULD be added to the 
            fragment component of the redirection URI. Otherwise, the response
            parameters are added to the query component of the redirection URI.
            </t>

            <t><figure>
                <preamble>The following is a non-normative example. Line wraps
                after the second line is for the display purpose
                only:</preamble>

                <artwork><![CDATA[HTTP/1.1 302 Found
Location: https://client.example.com/cb?
error=invalid_request
&error_description=the%20request%20is%20not%20valid%20or%20malformed
&state=af0ifjsldkj]]></artwork>
              </figure></t>
          </section>
        </section>
      </section>
    </section>

    <section anchor="token_ep" title="Token Endpoint">
      <t>The Token Endpoint handles requests for retrieving and refreshing
      Access Tokens as well as ID Token and other variables.</t>

      <t>Clients MUST use the HTTP "POST" method to make requests to the Token
      Endpoint. Request parameters are added using
      <xref target="form_serialization">form serialization</xref>.</t>

      <t>Clients MAY provide authentication parameters in the request to the
      Token Endpoint as described in section 2.2.1 of <xref
      target="OpenID.Messages">OpenID Connect Messages</xref> </t>

        <t>Authorization Servers MUST support the use of the HTTP "POST"
        method defined in <xref target="RFC2616">RFC 2616</xref> at the
        Token Endpoint. </t>

      <t>Authorization Servers MUST require the use of a transport-layer
      security mechanism. The Authorization Server MUST support TLS 1.2
      <xref target="RFC5246">RFC 5246</xref> and/or TLS 1.0
      <xref target='RFC2246' /> and MAY support
      other transport-layer mechanisms with equivalent security.</t>

      <t>All Token Endpoint responses that contain tokens, secrets, or other
      sensitive information MUST include the following HTTP response header
      fields and values:</t>

      <texttable title="HTTP Response Headers and Values">
        <ttcol>Header Name</ttcol>

        <ttcol>Header Value</ttcol>

        <c>Cache-Control</c>

        <c>no-store</c>

        <c>Pragma</c>

        <c>no-cache</c>
      </texttable>

      <section title="Requesting an Access Token">
        <t>To retrieve an Access Token, a Client MUST have an Authorization
        Code obtained via the method as described in <xref
        target="code_flow">Authorization Code Flow</xref>.</t>

        <section title="Access Token Request">
          <t>To obtain an Access Token, Refresh Token or ID Token, the Client MUST
          authenticate to the Token Endpoint using the authentication method registered for its <spanx style="verb">client_id</spanx>,
          as documented in Section 2.2.1 of <xref target="OpenID.Messages">OpenID Connect Messages 1.0</xref>
          
          The Client sends the parameters via HTTPS POST to the Token Endpoint using
          <xref target="form_serialization">form serialization</xref> as 
          specified in Section 4.1.3 of 
          <xref target="OAuth2.0">OAuth 2.0</xref>:</t>


          <figure>
            <preamble>The following is a non-normative example. Line wraps
            after line 4 are for display purpose only:</preamble>

            <artwork><![CDATA[POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb]]></artwork>
          </figure>
          <t>
            The Authorization Server MUST:
          </t>
          <t>
            <list style='symbols'>
              <t>
                Require client authentication for any Client issued
                client credentials (or with other authentication requirements),
              </t>
              <t>
                Authenticate the Client if client authentication is included and ensure the
                Authorization Code was issued to the authenticated Client,
              </t>
              <t>
                Verify that the Authorization Code is valid, and
              </t>
              <t>
                Ensure that the <spanx style='verb'>redirect_uri</spanx> parameter is present if
                the <spanx style='verb'>redirect_uri</spanx> parameter was included in the initial
                Authorization Request and that their
                values are identical.
              </t>
            </list>
          </t>
        </section>

        <section title="Access Token Response">
          <t>Upon receipt of the Token Request, the Authorization Server MUST
          return either a successful response or an error response that corresponds to
          the received Authorization Code.</t>

	  <t>A successful response returns the "<spanx style="verb">application/json</spanx>"
	  media type and the response body is the Access Token Response documented in Sec 2.2.3 of
	  <xref target="OpenID.Messages">OpenID Connect Messages
	  1.0</xref>.</t>


	  <figure>
	    <preamble>Following is a non-normative example of a
	    successful response:</preamble>

	    <artwork><![CDATA[HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOl
wvXC9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIj
oiaHR0cDpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0
vzDH3T1G3liaTNOrfaeWYjuRCEPNXVtaazNQ"
}]]></artwork>
	  </figure>
	</section>

	<section title="Access Token Error Response">
	  <t>If the Token Request is invalid or unauthorized, the
	  Authorization Server constructs the response by returning the
	  Token Error Response defined in <xref
	  target="OpenID.Messages">OpenID Connect Messages 1.0</xref> in the
	  entity body of the HTTP response using the <spanx style="verb">application/json</spanx>
	  media type with HTTP response code 400.</t>

	  <figure>
	    <preamble>Following is a non-normative example:</preamble>

	    <artwork><![CDATA[HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "error": "invalid_request"
}]]></artwork>
	  </figure>
        </section>
      </section>

      <section title="Refreshing an Access Token">
         <t>To refresh an Access Token, the Client MUST
          authenticate to the Token Endpoint using the authentication method registered for its <spanx style="verb">client_id</spanx>,
          as documented in Section 2.2.1 of <xref target="OpenID.Messages">OpenID Connect Messages 1.0</xref>
	  The Client sends the parameters via HTTPS POST to the Token Endpoint using
          <xref target="form_serialization">form serialization</xref> as 
          specified in Section 6 of 
          <xref target="OAuth2.0">OAuth 2.0</xref>:</t>
        
        <t>The Authorization Server MUST verify the validity of the Refresh
          Token.
        </t>

        <section title="Refresh Token Response">
          <t>Upon receipt of the Refresh Token Request, the Authorization Server MUST
          return either a successful response or an error response that corresponds to
          the received Refresh Token.</t>

          <t>Upon successful verification of the Refresh Token, a successful
          response returns the "<spanx style="verb">application/json</spanx>"
          media type and the response body is the Access Token Response of 
          <xref target="OpenID.Messages">Section 2.2.3 of OpenID Connect Messages
          1.0</xref> except that it MUST NOT return <spanx style="verb">id_token</spanx>.</t>
        
          <figure>
            <preamble>Following is a non-normative example of the Refresh
            Token request and response:</preamble>

            <artwork><![CDATA[POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

client_id=s6BhdRkqt3
&client_secret=some_secret12345
&grant_type=refresh_token
&refresh_token=8xLOxBtZp8
&scope=openid profile


HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "access_token": "TlBN45jURg",
 "token_type": "Bearer",
 "refresh_token": "9yNOxJtZa5",
 "expires_in": 3600
}]]></artwork>
          </figure>
        </section>

	<section title="Refresh Token Error Response">
	  <t>If the Refresh Token Request is invalid or unauthorized, the
	  Authorization Server returns the 
	  Token Error Response as defined in Section 5.2 of <xref
	  target="OAuth2.0">OAuth 2.0</xref>.</t>
	</section>
      </section>
    </section>

    <section anchor="check_id_ep" title="Check ID Endpoint">
      <t>
	The Check ID Endpoint validates the ID Token and returns a
	text <xref target="RFC4627">JSON</xref> object containing the
	Claims in the ID Token.  This endpoint is used by Clients that
	are not able to or do not wish to directly process ID Tokens.
	In this case, Clients MAY treat ID Tokens as opaque values.
      </t>
      <t>
	Check ID Endpoints MUST require the use of a transport-layer
	security mechanism.  The endpoint MUST support TLS 1.2
	<xref target="RFC5246">RFC 5246</xref>
	and/or TLS 1.0 <xref target='RFC2246' />; when TLS
	is used, the Client MUST perform a TLS/SSL server certificate
	check, per <xref target="RFC6125">RFC 6125</xref>.  Check ID
	Endpoints MAY support other transport-layer mechanisms with
	equivalent security.
      </t>

      <section title="Check ID Request">

          <t>To request the information about the authentication performed on
          the End-User, a request is made to the Check ID Endpoint sending 
          the ID Token as the <spanx style="verb">access_token</spanx> 
          by using the <xref target="OAuth.Bearer">OAuth 2.0
		  Bearer</xref> scheme.</t>

          <t>Clients MAY send requests with the following parameter to the
             Check ID Endpoint:</t>
             
            <t><list style="hanging">
            <t hangText="access_token">REQUIRED. The ID Token obtained
            from an OpenID Connect Authorization Request. This parameter
            MUST NOT be sent if the Access Token is sent in the HTTP
            Authorization header as described in Section 7.1 of <xref
            target="OAuth2.0">OAuth 2.0</xref>. Access Tokens sent in the
            authorization header MUST be <xref
            target="OAuth.Bearer">Bearer Tokens</xref>.</t>
            </list></t>
	

	<figure>
	  <preamble>The Following is a non-normative example of a Check
	  ID request:</preamble>

	  <artwork><![CDATA[POST /check_id HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC
9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaH
R0cDpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzDH
3T1G3liaTNOrfaeWYjuRCEPNXVtaazNQ]]></artwork>
	</figure>

	<t>
	  The Client MUST ensure that the Check ID Endpoint being
	  used is the trusted Check ID Endpoint for the Entity via
	  pre-configuration meta-data or discovery.
	</t>
	<t>
	  A request to the Check ID Endpoint MAY alternatively be made
	  with the HTTP "GET" method, when using GET the <spanx style="verb">access_token</spanx> 
	  MUST be passed in the header.
	</t>
        <t>
         The Authorization Server MUST verify the request in accordance 
         with the section 5.3 of the 
         <xref target="OpenID.Messages">Messages</xref> specification. 
        </t> 
        
        <t>Authorization Servers SHOULD support the use of 
      <xref target="CORS">Cross Origin Resource Sharing (CORS)</xref> and
      or other methods as appropriate to enable Java Script Clients to access the endpoint.</t>
      </section>

      <section anchor="intro_res" title="Check ID Response">
        <t>The Check ID Endpoint MUST return the JSON serialized Claims
        associated with the ID Token as described in Check ID Response
        section of <xref target="OpenID.Messages">OpenID Messages</xref> in
        the HTTP response body. The content-type of the HTTP response MUST be
        set to <spanx style="verb">application/json</spanx>.</t>

        <figure>
          <preamble>The following is a non-normative example of a
          response from a Check ID Endpoint:</preamble>

          <artwork><![CDATA[HTTP/1.1 200 OK
Content-Type: application/json

{
 "iss": "http://server.example.com",
 "user_id": "248289761001",
 "aud": "s6BhdRkqt3",
 "nonce": "n-0S6_WzA2Mj",
 "exp": 1311281970,
 "iat": 1311280970
}]]></artwork>
        </figure>

	<section title="Check ID Response Verification">
	  <t>To verify the validity of the Response, the Client MUST do the
	  following:</t>

	  <t><list style="numbers">
              <t>Check that the OP that responded was really the intended OP
              through a TLS/SSL server certificate check, per
              <xref target="RFC6125">RFC 6125</xref>.</t>

              <t>Follow the rules in section 5.4 of the OpenID Connect Messages.</t>

	  </list></t>
	</section>
      </section>

      <section title="Check ID Error Response">
	<t>When an error condition occurs, the Check ID Endpoint returns
	an Error Response as defined in Section 3 of
	<xref target="OAuth.Bearer">OAuth 2.0 Bearer Tokens</xref>.</t>

	<t><figure>
	    <preamble>Following is a non-normative example of an error
	    response:</preamble>

	    <artwork><![CDATA[HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example.com",
                     error="invalid_token",
                     error_description="The ID token expired"]]></artwork>
	  </figure></t>
      </section>
    </section>

    <section anchor="userinfo_ep" title="UserInfo Endpoint">
      <t>To obtain the requested Claims about the End-User, the Client
      makes a GET or POST request to the UserInfo Endpoint as in <xref
      target="OpenID.Messages">OpenID Connect Messages 1.0</xref>.</t>

      <t>Authorization Servers MUST require the use of a transport-layer
      security mechanism. The Authorization Server MUST support TLS 1.2
      <xref target="RFC5246">RFC 5246</xref> and/or TLS 1.0
      <xref target='RFC2246' /> and MAY support
      other transport-layer mechanisms with equivalent security.</t>

      <t>Authorization Servers MUST support the use of the HTTP "GET" and HTTP
      "POST" methods defined in <xref target="RFC2616">RFC 2616</xref> at the
      UserInfo Endpoint. </t>

      <t>Authorization Servers MUST accept Access Tokens as
      <xref target="OAuth.Bearer">Bearer Tokens</xref>.</t>
      
      <t>Authorization Servers SHOULD support the use of 
      <xref target="CORS">Cross Origin Resource Sharing (CORS)</xref> and
      or other methods as appropriate to enable Java Script Clients to access the endpoint.</t>

      <section title="UserInfo Request">
        <t>Client SHOULD send the UserInfo Request defined in section 2.4.1 of
        the <xref target="OpenID.Messages">OpenID Connect Messages 1.0</xref>
        either in HTTP GET or POST request.</t>
        
        <t>The Access Token obtained
            from an OpenID Connect Authorization Request MUST be sent as a Bearer Token.
            Section 2 of the <xref target="OAuth.Bearer">OAuth 2.0 Bearer Tokens</xref>
            specification documents the permissible methods of sending the Access Token.</t> 
            <t>It is RECOMMENDED that the Client use the authorization header method for all 
            requests using GET.</t>
            
            
        <figure>
          <preamble>The following is a non-normative example. Line wraps are
          for display purpose only:</preamble>

          <artwork><![CDATA[GET /userinfo?schema=openid HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X]]></artwork>
        </figure>
      </section>

      <section anchor="id_res" title="UserInfo Response">
        <t>The <spanx style="verb">user_id</spanx> Claim in the UserInfo Endpoint response MUST exactly match the 
        <spanx style="verb">user_id</spanx> Claim in the ID Token, before using additional UserInfo Endpoint Claims.</t>
        
        <t>Upon receipt of the UserInfo request, the UserInfo Endpoint MUST
        return the JSON Serialization of the UserInfo response as in <xref
        target="OpenID.Messages">OpenID Messages</xref> in the HTTP response
        body. The content-type of the HTTP response MUST be set to <spanx
        style="verb">application/json</spanx> if the response body is a text
        JSON structure. If the JSON response is <xref target="JWS">JWS</xref>
        signed or <xref target="JWE">JWE</xref> encrypted, then the
        content-type MUST be set to <spanx style="verb">application/jwt</spanx>.</t>

        <t>Upon receipt of the UserInfo Response, the Client MUST verify 
        the response in accordance with Section 5.5 (UserInfo Response Verification)
        of <xref target="OpenID.Messages">OpenID Connect Messages 1.0</xref>.
        </t>

        <figure>
          <preamble>Following is a non-normative example of such
          response:</preamble>

          <artwork><![CDATA[HTTP/1.1 200 OK
Content-Type: application/json

{
 "user_id": "248289761001",
 "name": "Jane Doe"
 "given_name": "Jane",
 "family_name": "Doe",
 "email": "janedoe@example.com",
 "picture": "http://example.com/janedoe/me.jpg"
}]]></artwork>
        </figure>
      </section>

      <section title="UserInfo Error Response">
	<t>When an error condition occurs, the UserInfo Endpoint returns
	an Error Response as defined in Section 3 of
	the <xref target="OAuth.Bearer">OAuth 2.0 Bearer Tokens</xref> specification
	utilizing an error code as specified in Section 2.4.3 of <xref
	target="OpenID.Messages">OpenID Connect Messages 1.0</xref>.</t>

	<figure>
	    <preamble>Following is a non-normative example of an error
	    response:</preamble>

	    <artwork><![CDATA[HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example.com",
                     error="invalid_token",
                     error_description="The access token expired"]]></artwork>
        </figure>
      </section>
    </section>

    <section anchor="disco_reg" title="Discovery and Registration">
      <t>Some OpenID Connect installations can use a pre-configured set of
      OpenID Providers and/or Relying Parties. In those cases, it may not be
      necessary to support dynamic discovery of information about identities
      or services or dynamic registration of Clients.</t>

      <t>However, if installations choose to support unanticipated
      interactions between Relying Parties and OpenID Providers that do not
      have pre-configured relationships, they SHOULD accomplish this by
      implementing the facilities defined in the <xref
      target="OpenID.Discovery">OpenID Connect Discovery 1.0</xref> and <xref
      target="OpenID.Registration">OpenID Connect Dynamic Client Registration
      1.0</xref> specifications.</t>
    </section>

    <section anchor="Serializations" title="Serializations">
      <t>A request message MAY be serialized using one of the following methods:
        <list style="numbers">
            <t>Query String Serialization</t>
            <t>Form Serialization</t>
        </list>
      </t>

      <section anchor="qss" title="Query String Serialization">
        <t>In order to serialize the parameters using the query string
        serialization, the Client constructs the string by adding the
        parameters and values to the query component of a URL using the <spanx
        style="verb">application/x-www-form-urlencoded</spanx> format as
        defined by <xref target="W3C.REC-html401-19991224"></xref>. Query string
        serialization is typically used in HTTP GET requests.</t>

        <figure>
          <preamble>Following is a non-normative example of such
          serialization:</preamble>

          <artwork><![CDATA[GET /authorize?scope=openid&response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb HTTP/1.1
Host: server.example.com]]></artwork>
        </figure>
      </section>

      <section anchor="form_serialization" title="Form Serialization">
        <t>Parameters and their values are form serialized by adding the 
        parameter names and values to the entity body of the HTTP request using
        the <spanx style="verb">application/x-www-form-urlencoded</spanx> format
        as defined by <xref target="W3C.REC-html401-19991224"></xref>. Form
        serialization is typically used in HTTP POST requests.</t>

        <figure>
          <preamble>Following is a non-normative example of such
          serialization:</preamble>

          <artwork><![CDATA[POST /authorize HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

scope=openid&response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb]]></artwork>
        </figure>
      </section>
    </section>

    <section anchor="security_considerations" title="Security Considerations">
      <t>This specification references the security considerations defined in
      <xref target="OpenID.Messages">OpenID Connect Messages 1.0</xref>.</t>

      <t>In addition, the following list of attack vectors and remedies are
      also considered.</t>

      <section title="Implicit Grant Flow Threats">
        <t>In the implicit grant flow, the Access Token is returned in the
        fragment part of the Client's <spanx style="verb">redirect_uri</spanx> through HTTPS, thus it is
        protected between the OP and the User-Agent, and User-Agent and the
        RP. The only the place it can be captured is the User-Agent where the
        TLS session is terminated, and is possible if the User-Agent is
        infested by malware.</t>
      </section>
    </section>

    <section anchor="privacy_considerations" title="Privacy Considerations">
      <t>The UserInfo response typically contains Personally Identifiable
      Information. As such, End-User consent for the release of the information
      for the specified purpose SHOULD be obtained at or prior to the
      authorization time in accordance with relevant regulations. The purpose
      of use is typically registered in association with the <spanx
      style="verb">redirect_uri</spanx>.</t>

      <t>Only necessary UserInfo data should be stored at the Client and the
      Client SHOULD associate the received data with the purpose of use
      statement.</t>

      <t>The Resource Server SHOULD make the UserInfo access log available to 
      the End-User so that the End-User can monitor who accessed his data.</t>

      <t>To protect the End-User from a possible correlation among Clients, the
      use of a Pairwise Pseudonymous Identifier (PPID) as the <spanx
      style="verb">user_id</spanx> SHOULD be considered.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <section anchor="oauth_params" title="OAuth Parameters Registry">

        <section title="Authorization Request Parameter (display)">
          <t>The following is the parameter registration request for the
          Authorization Request in this specification:</t>

          <t><list style="symbols">
              <t>Parameter name: display</t>

              <t>Parameter usage location: Authorization Request</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[ this document ]]</t>

              <t>Related information: None</t>
            </list></t>
        </section>

        <section title="Authorization Request Parameter (prompt)">
          <t>The following is the parameter registration request for the
          Authorization Request in this specification:</t>

          <t><list style="symbols">
              <t>Parameter name: prompt</t>

              <t>Parameter usage location: Authorization Request</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[ this document ]]</t>

              <t>Related information: None</t>
            </list></t>
        </section>

        <section title="Authorization Request Parameter (nonce)">
          <t>The following is the parameter registration request for the
          Authorization Request in this specification:</t>

          <t><list style="symbols">
              <t>Parameter name: nonce</t>

              <t>Parameter usage location: Authorization Request</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[ this document ]]</t>

              <t>Related information: None</t>
            </list></t>
        </section>

        <section title="Authorization Request Parameter (request)">
          <t>The following is the parameter registration request for the
          Authorization Request in this specification:</t>

          <t><list style="symbols">
              <t>Parameter name: request</t>

              <t>Parameter usage location: Authorization Request</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[ this document ]]</t>

              <t>Related information: None</t>
            </list></t>
        </section>

        <section title="Authorization Request Parameter (request_uri)">
          <t>The following is the parameter registration request for the
          Authorization Request in this specification:</t>

          <t><list style="symbols">
              <t>Parameter name: request_uri</t>

              <t>Parameter usage location: Authorization Request</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[ this document ]]</t>

              <t>Related information: None</t>
            </list></t>
        </section>

        <section title="ID Token Response Parameters">
          <t>The following is the parameter registration request for the ID
          Token Response in this specification:</t>

          <t><list style="symbols">
              <t>Parameter name: id_token</t>

              <t>Parameter usage location: Authorization Response, Access Token
              Response</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[ this document ]]</t>

              <t>Related information: None</t>
            </list></t>
        </section>
      </section>
      <section title="OAuth Extensions Error Registry">
        <t></t>

        <section title="Authorization Endpoint Error (invalid_redirect_uri)">
          <t>The following is the parameter value registration request for the
          <spanx style="verb">scope</spanx> parameter as defined in this specification:</t>

          <t><list style="symbols">
              <t>Error name: invalid_redirect_uri </t>

              <t>Error usage location: Authorization Endpoint</t>

              <t>Related protocol extension:</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[this document ]]</t>
            </list></t>
        </section>

        <section title="Authorization Endpoint Error (interaction_required)">
          <t>The following is the parameter value registration request for the
          <spanx style="verb">scope</spanx> parameter as defined in this specification:</t>

          <t><list style="symbols">
              <t>Error name: interaction_required </t>

              <t>Error usage location: Authorization Endpoint</t>

              <t>Related protocol extension:</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[this document ]]</t>
            </list></t>
        </section>

        <section title="Authorization Endpoint Error (login_required)">
          <t>The following is the parameter value registration request for the
          <spanx style="verb">scope</spanx> parameter as defined in this specification:</t>

          <t><list style="symbols">
              <t>Error name: login_required </t>

              <t>Error usage location: Authorization Endpoint</t>

              <t>Related protocol extension:</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[this document ]]</t>
            </list></t>
        </section>

        <section title="Authorization Endpoint Error (session_selection_required)">
          <t>The following is the parameter value registration request for the
          <spanx style="verb">scope</spanx> parameter as defined in this specification:</t>

          <t><list style="symbols">
              <t>Error name: session_selection_required </t>

              <t>Error usage location: Authorization Endpoint</t>

              <t>Related protocol extension:</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[this document ]]</t>
            </list></t>
        </section>

        <section title="Authorization Endpoint Error (consent_required)">
          <t>The following is the parameter value registration request for the
          <spanx style="verb">scope</spanx> parameter as defined in this specification:</t>

          <t><list style="symbols">
              <t>Error name: consent_required </t>

              <t>Error usage location: Authorization Endpoint</t>

              <t>Related protocol extension:</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[this document ]]</t>
            </list></t>
        </section>

        <section title="Authorization Endpoint Error (invalid_request_uri)">
          <t>The following is the parameter value registration request for the
          <spanx style="verb">scope</spanx> parameter as defined in this specification:</t>

          <t><list style="symbols">
              <t>Error name: invalid_request_uri </t>

              <t>Error usage location: Authorization Endpoint</t>

              <t>Related protocol extension:</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[this document ]]</t>
            </list></t>
        </section>
        
        <section title="Authorization Endpoint Error (invalid_openid_request_object)">
          <t>The following is the parameter value registration request for the
          <spanx style="verb">scope</spanx> parameter as defined in this specification:</t>

          <t><list style="symbols">
              <t>Error name: invalid_openid_request_object </t>

              <t>Error usage location: Authorization Endpoint</t>

              <t>Related protocol extension:</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[this document ]]</t>
            </list></t>
        </section>

        <section title="UserInfo Endpoint Error (invalid_schema)">
          <t>The following is the parameter value registration request for the
          <spanx style="verb">scope</spanx> parameter as defined in this specification:</t>

          <t><list style="symbols">
              <t>Error name: invalid_schema </t>

              <t>Error usage location: UserInfo Endpoint</t>

              <t>Related protocol extension:</t>

              <t>Change controller: IETF</t>

              <t>Specification document(s): [[this document ]]</t>
            </list></t>
        </section>
      </section>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4627"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125"?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-html401-19991224.xml' ?>

      <reference anchor="JWT">
        <front>
          <title>JSON Web Token</title>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <author fullname="Dirk Balfanz" initials="D." surname="Balfanz">
            <organization>Google</organization>
          </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Protoviti">Protoviti Government
            Services</organization>
          </author>

          <author fullname="Yaron Goland" initials="Y." surname="Goland">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <author fullname="John Panzer" initials="J." surname="Panzer">
            <organization>Google</organization>
          </author>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NRI">Nomura Research Institute,
            Ltd.</organization>
          </author>

          <author fullname="Paul Tarjan" initials="P." surname="Tarjan">
            <organization abbrev="Facebook">Facebook</organization>
          </author>

          <date day="12" month="March" year="2012" />
        </front>

        <format target="http://tools.ietf.org/html/draft-jones-json-web-token"
                type="HTML" />
      </reference>

      <reference anchor="JWS">
        <front>
          <title>JSON Web Signature</title>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Protoviti">Protoviti Government
            Services</organization>
          </author>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NRI">Nomura Research Institute,
            Ltd.</organization>
          </author>

          <date day="16" month="January" year="2012" />
        </front>

        <format target="http://tools.ietf.org/html/draft-ietf-jose-json-web-signature"
                type="HTML" />
      </reference>

      <reference anchor="JWE">
        <front>
          <title>JSON Web Encryption (JWE)</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization>Microsoft</organization>
	  </author>

	  <author fullname="Eric Rescorla" initials="E." surname="Rescorla">
	    <organization>RTFM, Inc.</organization>
	  </author>

	  <author fullname="Joe Hildebrand" initials="J." surname="Hildebrand">
	    <organization>Cisco Systems, Inc.</organization>
	  </author>

	  <date day="16" month="January" year="2012" />
        </front>
        <format target="http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption" type="HTML" />
      </reference>

      <reference anchor="OpenID.Messages">
        <front>
          <title>OpenID Connect Messages 1.0</title>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NRI">Nomura Research Institute,
            Ltd.</organization>
          </author>

    <author fullname="David Recordon" initials="D." surname="Recordon">
      <organization abbrev="Facebook">Facebook</organization>
    </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization>Independent</organization>
          </author>

          <author fullname="Breno de Medeiros" initials="B."
                  surname="de Medeiros">
            <organization abbrev="Google">Google</organization>
          </author>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <author fullname="Edmund Jay" initials="E." surname="Jay">
            <organization abbrev="Illumila">Illumila</organization>
          </author>

          <date day="9" month="April" year="2012" />
        </front>

        <format target="http://openid.net/specs/openid-connect-messages-1_0.html"
                type="HTML" />
      </reference>

      <reference anchor="OpenID.Registration">
        <front>
          <title abbrev="Abbreviated-Title">OpenID Connect Dynamic Client
          Registration 1.0</title>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NRI">Nomura Research Institute,
            Ltd.</organization>
          </author>

          <author fullname="John Bradley" initials="J."
                  surname="Bradley">
            <organization>Independent</organization>
          </author>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <date day="27" month="February" year="2012" />
        </front>

        <format target="http://openid.net/specs/openid-connect-registration-1_0.html"
                type="HTML" />
      </reference>

      <reference anchor="OpenID.Discovery">
        <front>
          <title>OpenID Connect Discovery 1.0</title>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NRI">Nomura Research Institute,
            Ltd.</organization>
          </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization>Independent</organization>
          </author>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <author fullname="Edmund Jay" initials="E." surname="Jay">
            <organization abbrev="Illumila">Illumila</organization>
          </author>

          <date day="9" month="April" year="2012" />
        </front>

        <format target="http://openid.net/specs/openid-connect-discovery-1_0.html"
                type="HTML" />
      </reference>

      <reference anchor="OAuth2.0">
        <front>
          <title>OAuth 2.0 Authorization Protocol</title>

          <author fullname="Eran Hammer" initials="E." role="editor"
                  surname="Hammer">
            <organization></organization>
          </author>

          <author fullname="David Recordon" initials="D." surname="Recordon">
            <organization abbrev="Facebook">Facebook</organization>
          </author>

          <author fullname="Dick Hardt" initials="D." surname="Hardt">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <date day="8" month="March" year="2012" />
        </front>

        <format target="http://tools.ietf.org/html/draft-ietf-oauth-v2"
                type="HTML" />
      </reference>

      <reference anchor="OAuth.Bearer">
        <front>
          <title>OAuth 2.0 Protocol: Bearer Tokens</title>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <author fullname="Dick Hardt" initials="D." surname="Hardt">
            <organization>Independent</organization>
          </author>

          <author fullname="David Recordon" initials="D." surname="Recordon">
            <organization>Facebook</organization>
          </author>

          <date day="12" month="March" year="2012" />
        </front>

        <format target="http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer"
                type="HTML" />
      </reference>
    
      <reference anchor="OAuth.Responses">
        <front>
           <title>OAuth 2.0 Multiple Response Type Encoding Practices</title>
           <author fullname="Breno" initials="B." surname="de Medeiros">
             <organization abbrev="Google">Google, Inc.</organization>
           </author>
           <author fullname="Marius" initials="M." surname="Scurtescu">
             <organization abbrev="Google">Google, Inc.</organization>
           </author>
           <author fullname="Paul" initials="P." surname="Tarjan">
             <organization abbrev="Facebook"> Facebook</organization>
           </author>
           <date day="9" month="April" year="2012"></date>
        </front>
      <format target="http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html"
              type="HTML" />
      </reference>
    </references>

    <references title="Informative References"> 

       <reference anchor="CORS">
        <front>
           <title>Cross-Origin Resource Sharing</title>
           <author fullname="Anne" initials="" surname="van Kestern">
             <organization abbrev="Opera">Opera Software ASA</organization>
           </author>
           <date day="27" month="July" year="2010"></date>
        </front>
      <format target="http://www.w3.org/TR/access-control/"
              type="HTML" />
      </reference>
    </references>

    <section title="Footnotes">
      <t></t>

      <section title="Example JWT Values">
        <t>The JWT values used in the non-normative examples of this
        specification are only place holders for actual JWT values. The
        examples use "jwt_header.jwt_part2.jwt_part3" as the place holder
        value. For an example of an actual JWT, refer to the <xref
        target="JWT">JWT</xref> specification.</t>
      </section>
    </section>

    <section title="Acknowledgements">
      <t>The OpenID Community would like to thank the following people for the
      work they've done in the drafting and editing of this specification.</t>

      <t><list style="empty">
          <t>Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom</t>

          <t>Breno de Medeiros (breno@gmail.com), Google</t>

          <t>George Fletcher (gffletch@aol.com), AOL</t>

          <t>Hideki Nara (hideki.nara@gmail.com), Takt Communications</t>

          <t>John Bradley (ve7jtb@ve7jtb.com), Independent</t>

          <t>Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute,
          Ltd.</t>

          <t>Michael B. Jones (mbj@microsoft.com), Microsoft</t>

          <t>Ryo Itou (ritou@yahoo-corp.jp), Yahoo! Japan</t>
        </list></t>
    </section>

    <section title="Notices">
      <t>Copyright (c) 2012 The OpenID Foundation.</t>
      <t>
	The OpenID Foundation (OIDF) grants to any Contributor, developer, 
	implementer, or other interested party a non-exclusive, royalty free, 
	worldwide copyright license to reproduce, prepare derivative works from, 
	distribute, perform and display, this Implementers Draft or 
	Final Specification solely for the purposes of (i) developing 
	specifications, and (ii) implementing Implementers Drafts and 
	Final Specifications based on such documents, provided that attribution 
	be made to the OIDF as the source of the material, but that such attribution 
	does not indicate an endorsement by the OIDF.
      </t>
      <t>
	The technology described in this specification was 
	made available from contributions from various sources, 
	including members of the OpenID Foundation and others.  
	Although the OpenID Foundation has taken steps to help ensure 
	that the technology is available for distribution, it takes 
	no position regarding the validity or scope of any intellectual 
	property or other rights that might be claimed to  pertain to 
	the implementation or use of the technology described in 
	this specification or the extent to which any license under 
	such rights might or might not be available; neither does it 
	represent that it has made any independent effort to identify 
	any such rights.  The OpenID Foundation and the contributors 
	to this specification make no (and hereby expressly disclaim any) 
	warranties (express, implied, or otherwise), including implied 
	warranties of merchantability, non-infringement, fitness for 
	a particular purpose, or title, related to this specification, 
	and the entire risk as to implementing this specification is 
	assumed by the implementer.  The OpenID Intellectual 
	Property Rights policy requires contributors to offer 
	a patent promise not to assert certain patent claims against 
	other contributors and  against implementers.  The OpenID Foundation invites 
	any interested party to bring to its attention any copyrights, 
	patents, patent applications, or other proprietary rights 
	that may cover technology that may be required to practice 
	this specification.
      </t>
    </section>

    <section title="Document History">
      <t>[[ To be removed from the final specification ]]</t>

      <t>-09<list style="symbols">
	  <t>Added error interaction_required and removed
	  user_mismatched, per issue #523.</t>
	  <t>Changed invalid_request_request_uri to invalid_request_uri and
	  invalid_request_redirect_uri to invalid_redirect_uri, per issue #553.</t>
	  <t>Updated references.</t>
	  <t>Added id_token to authorization request parameters.</t>
	  <t>Removed use of non-existent scope parameters registry, per issue #558.</t>
	  <t>Updated Notices</t>
	</list></t>

      <t>-08<list style="symbols"> 
      <t>Updated version number and date</t>
      <t>Fix #543 Section 2.3.1.3 Request file requiring all request params to be included is false</t>
      <t>Fix Section 5.1 to reference Messages 2.4.1 rather than 3.3</t>
      <t>Added reference to CORS for JS clients to user_info and check_id endpoints</t>
        </list></t>
           
      <t>-07<list style="symbols">
	  <t>Removed definition and usage for assertion and claim object</t>
	  <t>Removed Request File Registration Service</t>
	  <t>Consistent use of End-User</t>
	  <t>email scope allows access to the 'verified' claim</t>
	  <t>Removed language pertaining to custom userinfo schemas</t>
	  <t>Updated error section for refreshing access token</t>
	  <t>Remove 'audience' parameter from Authorization Request</t>
	  <t>Moved display=none to prompt=none</t>
	  <t>Moved IANA considerations from Messages</t>
	  <t>Check ID Endpoint returns only JSON</t>
	  <t>Removed PPID scope value</t>
	  <t>Reference Messages for validation of request object encryption and signature</t>
	  <t>Redefined 'nonce' in Authorization Request. Changed to REQUIRED parameter.</t>
	  <t>Changed usage of "approval" to "consent"</t>
	  <t>Use RFC 6125 to verify TLS endpoints</t>
	  <t>Added Privacy considerations</t>
	  <t>Changed 'request_uri' to require HTTPS unless the referenced content is signed
	    and only needs to be reachable by AS</t>
	  <t>Added hash and entropy considerations to 'request_uri'</t>
	  <t>Added requirement to compare user_id from userinfo endpoint to id_token</t>
	  <t>Check ID Endpoint SHOULD use POST</t>
	  <t>Changed UserInfo Error Response to augment and return OAuth 2.0 Bearer Token Error Response</t>
	  <t>Added section about string comparison rules needed</t>
	  <t>Added Response Encoding according to Multiple Response Types spec</t>
	  <t>Allows only 'id_token' for 'response_type' parameter in Authorization Request</t>
	  <t>Clarified redirect_uris matching</t>
	  <t>Added explanation of select_account</t>
	  <t>Changed Security Considerations to refer to corresponding section in Messages</t>
	  <t>Check ID Endpoint uses ID Token as Access Token according to Bearer Token spec</t>
      <t>Update John Bradley email and affiliation for Implementer's Draft</t>
	  <t>Removed invalid_authorization_code, invalid_id_token error codes</t>
        </list></t>
        
      <t>-06<list style="symbols">
          <t>Reworked return type wording in section 4.4.1 per ticket #174.</t>

          <t>Added reference to registered return types.</t>

          <t>Bumped Version number and date.</t>
          
          <t>Make clear the server passes the value of nonce through untouched. Ticket #97.</t>
          <t>Prevent caching of request_uri. Ticket #148.</t>
          <t>Add nonce to request examples. Ticket #147.</t>
          <t>Fixed 4.3.1.3 per ticket #150.</t>
          <t>Fixed 4.3.2 to remove display scopes per ticket #172.</t>
          <t>Make scope optional for refresh in 5.2.</t>
          <t>Reference messages 3.2.2 for field definitions in section 5.2.1 per ticket #159.</t>
          <t>Removed scopes from display value in 4.3.1 per ticket #172.</t>
          <t>Make "code" and "id_token token" response types mandatory for Authorization Servers to support.</t>
          
        </list></t>

      <t>-05<list style="symbols">
          <t>Changed check_session to check_id.</t>

          <t>schema=openid now required when requesting UserInfo.</t>

          <t>Removed display values popup, touch, and mobile, since not well defined.</t>

          <t>Resolve issue #135, clarifying that the access_token MAY
          be sent in the message body.</t>

        </list></t>

      <t>-04 <list style="symbols">
          <t>Changes associated with renaming "Lite" to "Basic Client"
          and replacing "Core" and "Framework" with "Messages" and
          "Standard".</t>

          <t>Numerous cleanups, including updating references.</t>
        </list></t>

      <t>-03 <list style="symbols">
          <t>Added secret_type to the Token Endpoint.</t>

          <t>Minor edits to the samples.</t>
        </list></t>

      <t>-02 <list style="symbols">
          <t>Incorporates feedback from Nat Sakimura.</t>
        </list></t>

      <t>-01 <list style="symbols">
          <t>First Draft that incorporates the merge of the Core and Framework
          specs.</t>
        </list></t>
    </section>
  </back>
</rfc>
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.