Source

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

Full commit
   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
<?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-basic-1_0" ipr="trust200902">

  <?rfc toc="yes" ?>
  <?rfc tocdepth="4" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc strict="no" ?>
  <?rfc iprnotified="no" ?>
  <?rfc private="Draft" ?>

  <front>
    <title abbrev="OpenID Connect Basic Client Profile 1.0">OpenID Connect Basic
    Client Profile 1.0 - draft 20</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 abbrev="Ping Identity">Ping Identity</organization>
      <address>
        <email>ve7jtb@ve7jtb.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="Breno de Medeiros" initials="B." surname="de Medeiros">
      <organization abbrev="Google">Google</organization>
      <address>
        <email>breno@google.com</email>
      </address>
    </author>

    <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
      <organization abbrev="Salesforce">Salesforce</organization>
      <address>
        <email>cmortimore@salesforce.com</email>
      </address>
    </author>

    <date day="23" month="June" 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 Basic Client Profile is a profile of the 
      OpenID Connect Standard 1.0 Specification
      that is designed to be easy to read and implement for basic
      web-based Relying Parties using the OAuth code grant type.
      OpenID Providers should consult the Standard specification.
      This profile omits implementation and security
      considerations for OpenID Providers.</t>
    </abstract>
  </front>

  <middle>

    <section title="Introduction">

      <t>OpenID Connect Basic Client Profile is a profile of the 
      <xref target="OpenID.Standard">OpenID Connect Standard 1.0 Specification</xref>
      that is designed to be easy to read and implement for basic
      web-based Relying Parties using the OAuth code grant type.
      See the
      <xref target="OpenID.Implicit">OpenID Connect Implicit Client Profile</xref>
      specification for a related profile for basic
      web-based Relying Parties using the OAuth implicit grant type.
      OpenID Providers and non web-based applications
      should consult the Standard specification.
      This profile omits implementation and security
      considerations for OpenID Providers.</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"/>.</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>.
	  This specification also defines the following terms: 
	  <list style="hanging">
	    <t hangText="Relying Party (RP)">
	      Application requiring Claims from an OpenID Provider
	    </t>
	    <t hangText="OpenID Provider (OP)">
	      Service capable of providing Claims to a Relying Party
	    </t>
	    <t hangText="Claim">
	      Piece of information about an Entity that a Claims Provider
	      asserts about that Entity 
	    </t>
	    <t hangText="Claims Provider">
	      Server that can return Claims about an Entity 
	    </t>
	    <t hangText="End-User">
	      Human Resource Owner
	    </t>
	    <t hangText="Entity">
	      Something that has a separate and distinct existence and that can be
	      identified in a context. An End-User is one example of an Entity 
	    </t>
	    <t hangText="Personally Identifiable Information (PII)">
	      Information that (a) can be used to identify the natural person 
	      to whom such information relates, or 
	      (b) is or might be directly or indirectly linked to a 
	      natural person to whom such information relates. 
	    </t>
	    <t hangText="Pairwise Pseudonymous Identifier (PPID)"> 
	      Identifier that identifies the Entity to a Relying Party that cannot be correlated 
	      with the Entity's PPID at another Relying Party 
	    </t>
	    <t hangText="ID Token">
	      <xref target="JWT">JSON Web Token (JWT)</xref> that contains Claims about the authentication event
	      <vspace /><vspace /><vspace />
	    </t>
	    <t hangText="Issuer">
	      Entity that issues a set of Claims. 
	    </t>
	    <t hangText="Issuer Identifier">
	      HTTPS URL that acts as a verifiable identifier for an Issuer 
	    </t>
	    <t hangText="UserInfo Endpoint">
	      Protected resource that, when presented with an Access Token by the Client, returns authorized information about the End-User represented by the corresponding 
	      Authorization Grant  
	    </t>
	  </list>
	</t>
      </section>
    </section>
    <section title="Protocol Flows">
      <t>Authorization Requests can follow one of two paths; the Implicit Flow
      or the Authorization Code Flow. 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. Clients that do not support TLS MUST
      use the Authorization Code Flow to prevent the interception of Access 
      Tokens.</t>

      <t>The OpenID Connect Basic Client profile only documents Clients using
      the Code Flow. OpenID Providers MUST support both flows.
      OpenID Providers
      should consult the <xref target="OpenID.Standard">OpenID Connect Standard
      1.0 Specification</xref>.</t>

      <section title="OpenID Connect Scopes">
        <t>OpenID Connect Clients use <spanx style="verb">scope</spanx> values as defined in 3.3 of 
        <xref target="OAuth2.0">OAuth 2.0</xref> to specify what
        access privileges are requested for Access Tokens. The scopes associated
        with Access Tokens determine what resources will be available when they are 
        used to access OAuth 2.0 protected endpoints. For OpenID Connect, scopes
	can be used to request that specific sets of information
	be made available from the UserInfo Endpoint,
        and to request an ID Token.
        OAuth 2.0 allows additional scope values to be specified, as extensions.
        This specification describes only the scope values used by OpenID Connect.</t>

        <t>OpenID Connect defines the following <spanx style="verb">scope</spanx> values:</t>
        <t>
          <list style="hanging">
            <t hangText="openid">REQUIRED. Informs the Authorization
	    Server that the Client is making an OpenID Connect request. If the
	    <spanx style="verb">openid</spanx> scope value is not present,
	    the request MUST NOT be treated as an OpenID Connect request.
	    This scope value requests access to the <spanx style="verb">user_id</spanx>
	    Claim at the UserInfo Endpoint.</t>

            <t hangText="profile">OPTIONAL. This scope value 
	    requests that access to the End-User's default <xref
	    target="ClaimTable">profile Claims</xref> at the
	    UserInfo Endpoint be granted by the issued Access Token.
	    These claims are:

	    <spanx style="verb">name</spanx>,
	    <spanx style="verb">family_name</spanx>,
	    <spanx style="verb">given_name</spanx>,
	    <spanx style="verb">middle_name</spanx>,
	    <spanx style="verb">nickname</spanx>,
	    <spanx style="verb">preferred_username</spanx>,
	    <spanx style="verb">profile</spanx>,
	    <spanx style="verb">picture</spanx>,
	    <spanx style="verb">website</spanx>,
	    <spanx style="verb">gender</spanx>,
	    <spanx style="verb">birthday</spanx>,
	    <spanx style="verb">zoneinfo</spanx>,
	    <spanx style="verb">locale</spanx>, and
	    <spanx style="verb">updated_time</spanx>.</t>

            <t hangText="email">OPTIONAL. This scope value requests that access to
	    the <spanx style="verb">email</spanx> and
	    <spanx style="verb">email_verified</spanx> Claims at the
	    UserInfo Endpoint be granted by the issued Access Token.</t>

            <t hangText="address">OPTIONAL. This scope value requests that access to
	    the <spanx style="verb">address</spanx> Claim at the
	    UserInfo Endpoint be granted by the issued Access Token.</t>

            <t hangText="phone">OPTIONAL. This scope value requests that access to
	    the <spanx style="verb">phone_number</spanx> Claim at the
	    UserInfo Endpoint be granted by the issued Access Token.</t>

          </list>
        </t>

        <t>Multiple scopes MAY be requested by creating a space delimited, case
        sensitive list of ASCII scope values.</t>

        <t>In some cases, the End-User will be given the option to
        have the OpenID Provider decline to provide some or all
        information requested by Clients.</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>
            Request.</preamble>

            <artwork><![CDATA[scope=openid profile email phone]]></artwork>
          </figure>
        </t>
      </section>

      <section title="Code Flow">
        <t>The Code Flow consists of 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
	    <spanx style="verb">code</spanx>.</t>

            <t>Client sends the <spanx style="verb">code</spanx> to the
	    Token Endpoint to receive an Access Token and ID Token in the response.</t>
          </list>
        </t>

        <section anchor="rf_prep" title="Client Prepares an Authorization Request">
          <t>When the Client 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>The scheme used in the Authorization Endpoint URL MUST be HTTPS.</t>

          <t>Clients MAY construct the request using the HTTP
          <spanx style="verb">GET</spanx> or the HTTP 
          <spanx style="verb">POST</spanx> method as defined in 
          <xref target="RFC2616">RFC 2616</xref>.</t>

          <t>If using the HTTP <spanx style="verb">GET</spanx> method, the
          parameters are serialized using <xref target="qss">Query String 
          Serialization</xref>. If using the HTTP 
          <spanx style="verb">POST</spanx> method, the request parameters are 
          added to the HTTP request entity-body using the 
          <spanx style="verb">application/x-www-form-urlencoded</spanx> format
          as defined by <xref target="W3C.REC-html401-19991224"/>.</t>

          <t>This profile further constrains the following request
          parameters:</t>
          <t>
            <list style="hanging">
              <t hangText="response_type">
                It MUST be <spanx style="verb">code</spanx>.
		This requests that both an Access Token and an ID Token be returned
		from the Token Endpoint in exchange to <spanx style="verb">code</spanx>. 
              </t>
            </list>
          </t>

          <t>Other REQUIRED parameters in the request include the
          following:</t>

          <t>
            <list style="hanging">

              <t hangText="client_id">The OAuth 2.0 Client Identifier.</t>

              <t hangText="scope">It MUST include <spanx style="verb">openid</spanx>
              as one of the space delimited ASCII strings.
	      OPTIONAL <spanx style="verb">scope</spanx> strings of
              <spanx style="verb">profile</spanx>, <spanx style="verb">email</spanx>,
              <spanx style="verb">address</spanx>, and <spanx style="verb">phone</spanx>
	      are also supported.</t>

              <t hangText="redirect_uri">A redirection URI where the response
              will be sent. This MUST be pre-registered with the provider.</t>
            </list>
          </t>

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

          <t>
            <list style="hanging">

              <t hangText="state">RECOMMENDED.  An opaque value used
              to maintain state between the request and the callback;
              serves as a protection against XSRF attacks.</t>

              <t hangText="display">An ASCII string value that specifies
              how the Authorization Server displays the authentication and
              consent user interface pages to the End-User. The following values
              are supported:

              <list style="hanging">
                <t hangText="page">The Authorization Server SHOULD display
		authentication and consent UI consistent with a full user-agent page
		view. If the display parameter is not specified this is the
		default display mode.</t>

                <t hangText="popup">The Authorization Server SHOULD display
		authentication and consent UI consistent with a popup user-agent
		window. The popup user-agent window SHOULD be 450 pixels wide
		and 500 pixels tall.</t>

                <t hangText="touch">The Authorization Server SHOULD display
		authentication and consent UI consistent with a device that
		leverages a touch interface. The Authorization Server MAY attempt
		to detect the touch device and further customize the interface.</t>

                <t hangText="wap">The Authorization Server SHOULD display
		authentication and consent UI consistent with a "feature phone"
		type display.</t>
              </list>
            </t>

            <t hangText="prompt">A space delimited, case sensitive list of
	    ASCII string values that specifies whether the Authorization Server prompts
	    the End-User for reauthentication and consent. The possible values
	    are:

	    <list style="hanging">
	      <t hangText="none">This value informs the Authorization Server
	      that it MUST NOT display any authentication or consent
	      user interface pages. An error is returned if the End-User 
	      is not already authenticated or the Client does not have 
	      pre-configured consent for the requested
	      <spanx style="verb">scopes</spanx>. This can be used as a
	      method to check for existing authentication and/or consent.</t>

	      <t hangText="login">The Authorization Server MUST prompt the
	      End-User for reauthentication.</t>

	      <t hangText="consent">The Authorization Server MUST prompt
	      the End-User for consent before returning information to the
	      Client.</t>

	      <t hangText="select_account">The Authorization Server MUST
	      prompt the End-User to select a user account.  This allows 
	      a user who has multiple accounts at the Authorization Server
	      to select amongst the multiple accounts that they may have 
	      current sessions for.</t>
	    </list>

	    The <spanx style="verb">prompt</spanx> parameter
	    can be used by the Client to make sure that the End-User is
	    still present for the current session or to bring attention to the
	    request. If this parameter contains <spanx style="verb">none</spanx>
	    with any other value, an
	    error is returned.
            </t>
            </list>
          </t>
          <figure>
            <preamble>The following is a non-normative example of an
            Authorization Request URL
	    (with line wraps for display purposes only):</preamble>

            <artwork><![CDATA[https://server.example.com/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj]]></artwork>
          </figure>
        </section>

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

          <figure>
	    <preamble>Following is a non-normative example using HTTP redirect
	    (with line wraps for display purposes only):</preamble>

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

        <section title="Authorization Server Authenticates the End-User">

          <t>The authorization server authenticates the resource owner
          to make sure that the consent is obtained from the right
          party. The exact method of how the authentication is
          performed is out of scope of this specification. </t>
        </section>

        <section title="Authorization Server Obtains the End-User Consent/Authorization">

          <t>The Authorization Server obtains an authorization decision,
	  for the requested scopes. This can 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 <spanx style="verb">openid</spanx> scope grants the RP access
	  to the user identifier of the authenticated End-User of the session.</t>

          <t>All other scopes are optional. It is up to the OpenID Provider
	  to determine if an error should be returned in the case of the End-User
	  declining to authorize scopes other than
	  <spanx style="verb">openid</spanx>.</t>
        </section>

        <section anchor="code_res"
		 title="Authorization Server Sends the End-User Back to the Client">

          <t>Once the authorization is determined, the Authorization Server
	  returns a successful response or an error response.</t>

          <section anchor="code_ok" title="End-User Grants Authorization">

            <t>If the Resource Owner grants the access request, the
	    Authorization Server issues a <spanx style="verb">code</spanx> and delivers 
	    it to the Client by adding the following query parameters to the
	    query component of the redirection URI using the
	    <spanx style="verb">application/x-www-form-urlencoded</spanx>
	    format as defined in Section 4.1.2 of
	    <xref target="OAuth2.0">OAuth 2.0</xref>.</t>

            <t>
              <list style="hanging">
                <t hangText="code">REQUIRED. The OAuth 2.0 authorization code.</t>
		
                <t hangText="state">REQUIRED if the
		<spanx style="verb">state</spanx> parameter is present in the
                client Authorization Request. Clients MUST verify that the 
                <spanx style="verb">state</spanx> value is equal to the exact 
                value of <spanx style="verb">state</spanx> parameter in the 
                Authorization Request.</t>
              </list>
            </t>

            <figure>
              <preamble>The following is a non-normative example
	      (with line wraps after the second line for the display purposes only):</preamble>

              <artwork><![CDATA[HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj]]></artwork>
            </figure>
          </section>

          <section anchor="code_authz_error"
		   title="End-User Denies Authorization or Invalid Request">

            <t>If the End-User denies the authorization or the End-User authentication
            fails, the Authorization Server MUST return the error
            authorization response as defined in 4.1.2.1 of 
            <xref target="OAuth2.0">OAuth 2.0</xref>. No other parameters 
            SHOULD be returned.</t>
          </section>
        </section>

        <section anchor="obtaining_tokens"
		 title="Client obtains ID Token and Access Token">

          <t>Once <spanx style="verb">code</spanx> is obtained, the Client
	  requests the tokens at the Token Endpoint in the following manner:</t>

          <section anchor="token_request" title="Client sends the code">

            <t>The Client makes a request to the token endpoint as described in 
	    Section 4.1.3 of <xref target="OAuth2.0">OAuth 2.0</xref>.</t>

            <figure>
	      <preamble>The following is a non-normative example of such a token request
	      (with line wraps after the second line for the display purposes only):</preamble>

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

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb]]></artwork>
            </figure>
          </section>

          <section anchor="token_ok" title="Client receives tokens">

            <t>
              <list style="hanging">
                <t hangText="access_token">REQUIRED. The Access Token for the
                UserInfo Endpoint.</t>

                <t hangText="token_type">REQUIRED. The value MUST be
                "bearer"</t>

                <t hangText="id_token">REQUIRED. The ID Token.</t>

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

                <t hangText="refresh_token">OPTIONAL. The Refresh Token.</t>
              </list>
            </t>

            <t>The Client can then use the Access Token to access protected
            resources at Resource Servers.</t>

            <figure>
              <preamble>The following is a non-normative example
	      (with line wraps after the second line for the display purposes only):</preamble>
              <artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
  "access_token":"SlAV32hkKG",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "id_token":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso"
}]]></artwork>
            </figure>
          </section>

        </section>
      </section>

      <section anchor="id_token" title="ID Token">
          <t>The ID Token is a security token that contains Claims about the
          authentication event and other requested Claims.  
          The ID Token is represented as a <xref target="JWT">JSON Web Token (JWT)</xref>.</t>

          <t>The ID Token is used to manage the authentication event and user
          identifier and is scoped to a particular Client via the <spanx
          style="verb">aud</spanx> (audience) and <spanx style="verb">nonce</spanx>
          Claims. </t>

          <t>The following Claims are REQUIRED within the ID Token:</t>

          <t><list style="hanging">
              <t hangText="iss">REQUIRED. The Issuer Identifier for the Issuer
              of the response.</t>

              <t hangText="user_id">REQUIRED. A locally unique and never
              reassigned identifier within the Issuer for the End-User, 
              which is intended to be
              consumed by the Client. e.g. <spanx style="verb">24400320</spanx>
              or <spanx style="verb">AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4</spanx>.
              It MUST NOT exceed 255 ASCII characters in length.</t>

              <t hangText="aud">REQUIRED. This member identifies the audience
              that this ID Token is intended for. It MUST be the OAuth 2.0 <spanx style="verb">client_id</spanx>
              of the Client.</t>

              <t hangText="exp">REQUIRED. Type Integer. Identifies the
              expiration time on or after which the ID Token MUST NOT be
              accepted for processing. The processing of this parameter
              requires that the current date/time MUST be before the
              expiration date/time listed in the value. Implementers MAY
              provide for some small leeway, usually no more than a few
              minutes, to account for clock skew. The value is number of
              seconds from 1970-01-01T0:0:0Z as measured in UTC until the
              desired date/time. See <xref target="RFC3339">RFC 3339</xref>
              for details regarding date/times in general and UTC in
              particular.</t>
              
              <t hangText="iat">REQUIRED. Type Integer. The <spanx style="verb">iat</spanx> 
              (issued at) Claim identifies the time at which the JWT was issued. 
              The value is number of
              seconds from 1970-01-01T0:0:0Z as measured in UTC until the
              desired date/time. See <xref target="RFC3339">RFC 3339</xref>
              for details regarding date/times in general and UTC in
              particular.</t>

              

            </list></t>
            <t>Additional optional claims may be present in the ID Token.</t>
        
        </section>
        
      <section anchor="id.token.verification" title="ID Token Verification">

	<t>To verify the validity of ID Token in the Token Endpoint Response, 
	the Client MUST first split the <spanx style="verb">id_token</spanx> at the 
	period (".") characters, take the second segment, and base64url decode it to 
	obtain a JSON object that includes the ID Token claims, which MUST be verified 
	as follows:</t>

        <t>
          <list style="numbers">

            <t> The Client MUST validate that the <spanx style="verb">client_id</spanx> in the
	    <spanx style="verb">aud</spanx> (audience) Claim is one
	    it has registered for the Issuer identified by the value in the
	    <spanx style="verb">iss</spanx> (issuer) Claim.
	    The ID Token MUST be rejected if the value of
	    <spanx style="verb">aud</spanx> (audience) is not valid for the
	    Issuer.</t>

            <t>The current time MUST be less than the value of the
	    <spanx style="verb">exp</spanx> Claim.</t>

            <t>The <spanx style="verb">iat</spanx> Claim may be used to reject tokens that
	    were issued too far away from the current time, limiting the amount of
	    time that nonces must be stored to prevent attacks.
	    The acceptable range is Client specific.</t>

            <t>If the <spanx style="verb">acr</spanx> Claim was requested, the
	    Client SHOULD check that the asserted Claim Value is appropriate.
	    The meaning and processing of
	    <spanx style="verb">acr</spanx> Claim Values is out of scope for this specification.</t>

            <t>If the <spanx style="verb">auth_time</spanx> Claim was requested, the
	    Client SHOULD check the value
	    and request re-authentication if it determines too much time has elapsed
	    since the last user authentication.</t>

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

      <section anchor="userinfo" title="UserInfo Endpoint">

        <t>To obtain the additional attributes and tokens, the Client makes a
	GET or POST request to the UserInfo Endpoint.</t>

        <t>UserInfo Endpoint Servers MUST require the use of a transport-layer
	security mechanism. The UserInfo Endpoint 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>NOTE: The UserInfo Endpoint response is not guaranteed to be about the
	Interactive user identified by the <spanx style="verb">user_id</spanx> element of the ID Token.
	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>

        <section title="UserInfo Request">

          <t>Clients MAY send requests with the following parameters to the
	  UserInfo Endpoint to obtain further information about the End-User. The
	  UserInfo Endpoint is an <xref target="OAuth2.0">OAuth 2.0</xref>
	  Protected Resource that complies with the <xref
	  target="OAuth.Bearer">OAuth 2.0 Bearer Tokens</xref> specification. As such,
	  the Access Token SHOULD be specified via the HTTP Authorization
	  header.</t>

          <t>
            <list style="hanging">
              <t hangText="access_token"> REQUIRED. The Access Token obtained
	      from an OpenID Connect Authorization Request. This parameter MUST
	      only be sent using one method through either the HTTP Authorization
	      header or a form-encoded HTTP POST body parameter.</t>

              <t hangText="schema">REQUIRED. The schema in which the
	      data is to be returned. The only defined value is <spanx
	      style="verb">openid</spanx>.</t>

              <t hangText="id">This identifier is reserved. It MUST be
	      ignored by the endpoint when the <spanx
	      style="verb">openid</spanx> schema is used.</t>
            </list>
          </t>

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

            <artwork><![CDATA[GET /userinfo?schema=openid HTTP/1.1
Host: server.example.com
Authorization: Bearer SlAV32hkKG]]></artwork>
          </figure>
        </section>

        <section anchor="id_res" title="UserInfo Response">
          <t>If the requested schema is <spanx style="verb">openid</spanx>,
	  the response MUST return a
	  JSON object that contains the full set or subset of Claims that are
	  defined below. Additional Claims (not specified below) MAY also be
	  returned.</t>

          <t>
            If a Claim is not returned, that Claim Name SHOULD be
            omitted from the JSON object representing the Claims; it
            SHOULD NOT be present with a null or empty string value.
          </t>

          <t>The members MAY be represented in multiple languages and scripts.
	  To specify the languages and scripts, <xref
	  target="RFC5646">BCP47</xref> language tags MUST be added to each
	  member names delimited by a <spanx style="verb">#</spanx>, e.g.,
	  <spanx style="verb">family_name#ja-Kana-JP</spanx> for expressing
	  Family Name in Katakana in Japanese, which is commonly used to index
	  and represent the phonetics of the Kanji representation of the same
	  represented as <spanx style="verb">family_name#ja-Hani-JP</spanx>.</t>

          <texttable anchor="ClaimTable" title="Reserved Member Definitions">

            <ttcol align="left">Member</ttcol>
            <ttcol align="left">Type</ttcol>
            <ttcol align="left">Description</ttcol>

            <c>user_id</c>
            <c>string</c>
            <c>REQUIRED Identifier for the End-User at the Issuer.</c>

            <c>name</c>
            <c>string</c>
            <c>End-User's full name in displayable form including all name parts,
	    ordered according to End-User's locale and preferences.</c>

            <c>given_name</c>
            <c>string</c>
            <c>Given name or first name of the End-User.</c>

            <c>family_name</c>
            <c>string</c>
            <c>Surname or last name of the End-User.</c>

            <c>middle_name</c>
            <c>string</c>
            <c>Middle name of the End-User.</c>

            <c>nickname</c>
            <c>string</c>
            <c>Casual name of the End-User that may or may not be the same as the
	    <spanx style="verb">given_name</spanx>. For instance, a <spanx
	    style="verb">nickname</spanx> value of <spanx style="verb">Mike</spanx>
	    might be returned alongside a <spanx style="verb">given_name</spanx>
	    value of <spanx style="verb">Michael</spanx>.</c>
	    
	    <c>preferred_username</c>
            <c>string</c>
            <c>Shorthand name that the End-User wishes to be referred to at the RP, such as
            <spanx style="verb">janedoe</spanx> or <spanx style="verb">j.doe</spanx>. 
            This value MAY be any valid JSON string including 
            special characters such as <spanx style="verb">@</spanx>, 
            <spanx style="verb">/</spanx>, or whitespace. This value MUST NOT
            be relied upon to be unique by the RP. 
            (See <xref target="claim.stability"></xref>.)</c>

            <c>profile</c>
            <c>string</c>
            <c>URL of the End-User's profile page.</c>

            <c>picture</c>
            <c>string</c>
            <c>URL of the End-User's profile picture.</c>

            <c>website</c>
            <c>string</c>
            <c>URL of the End-User's web page or blog.</c>

            <c>email</c>
            <c>string</c>
            <c>The End-User's preferred e-mail address. 
            This value MUST NOT be relied upon to be unique by 
            the RP. (See <xref target="claim.stability"></xref>.)</c>

            <c>email_verified</c>
            <c>boolean</c>
            <c>True if the End-User's e-mail address has been verified; otherwise
	    false.</c>

            <c>gender</c>
            <c>string</c>
            <c>The End-User's gender: Values defined by this
	    specification are <spanx style="verb">female</spanx> and
	    <spanx style="verb">male</spanx>.  Other values MAY be used
	    when neither of the defined values are applicable.</c>

            <c>birthday</c>
            <c>string</c>
            <c>The End-User's birthday, represented as a date string in MM/DD/YYYY
	    format. The year MAY be <spanx style="verb">0000</spanx>, indicating
	    that it is omitted.</c>

            <c>zoneinfo</c>
            <c>string</c>
            <c>String from zoneinfo <xref target="zoneinfo"/> time zone
	    database. For example, <spanx style="verb">Europe/Paris</spanx> or
	    <spanx style="verb">America/Los_Angeles</spanx>.</c>

            <c>locale</c>
            <c>string</c>
            <c>The End-User's locale, represented as a
	    <xref target="RFC5646">BCP47</xref> language tag.
	    This is typically an <xref
	    target="ISO639-1">ISO 639-1 Alpha-2</xref> language code in
	    lowercase and an <xref target="ISO3166-1">ISO 3166-1 Alpha-2</xref>
	    country code in uppercase, separated by a dash. For example, <spanx
	    style="verb">en-US</spanx> or <spanx style="verb">fr-CA</spanx>. As
	    a compatibility note, some implementations have used an underscore
	    as the separator rather than a dash, for example, <spanx
	    style="verb">en_US</spanx>; Implementations MAY choose to accept
	    this locale syntax as well.</c>

            <c>phone_number</c>
            <c>string</c>
            <c>The End-User's preferred telephone number. <xref target="E.164">
	    E.164</xref> is RECOMMENDED as the format of this Claim. 
	    For example, <spanx style="verb">+1 (425) 555-1212</spanx>
	    or <spanx style="verb">+56 (2) 687 2400</spanx>.</c>

            <c>address</c>
            <c>JSON object</c>
            <c>The End-User's preferred address. The value of the <spanx
	    style="verb">address</spanx> member is a <xref
	    target="RFC4627">JSON</xref> structure containing some or all of
	    the members defined in <xref target="address_claim"/>.</c>

            <c>updated_time</c>
            <c>string</c>
            <c>Time the End-User's information was last updated, represented as a
	    <xref target="RFC3339">RFC 3339</xref> datetime. For example, <spanx
	    style="verb">2011-01-03T23:58:42+0000</spanx>.</c>
          </texttable>

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

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

          <t>The UserInfo Endpoint MUST return Claims in JSON format unless a
	  different format was specified during <xref target="OpenID.Registration">
	  OpenID Connect Dynamic Client Registration 1.0</xref>.
	  The UserInfo Endpoint MUST return a content-type header to indicate
	  which format is being returned. The following are accepted content
	  types:</t>

          <texttable style="all">
            <ttcol>Content-Type</ttcol>
            <ttcol>Format Returned</ttcol>

            <c>application/json</c>
            <c>plain text JSON object</c>

            <c>application/jwt</c>
            <c>JSON Web Token (JWT)</c>
          </texttable>

          <section title="Address Claim" anchor="address_claim">
            <t>
	      The components of a physical mailing address. 
	      Implementations MAY return only a subset of the
	      fields of an <spanx style="verb">address</spanx>, depending upon
	      the information available and the End-User's privacy 
	      preferences. For
	      example, the <spanx style="verb">country</spanx> and <spanx
	      style="verb">region</spanx> might be returned without returning
	      more fine-grained address information.
	    </t>
            <t>
	      Implementations MAY return just the full address 
	      as a single string in the formatted sub-field, 
	      or they MAY return just the individual component 
	      fields using the other sub-fields, 
	      or they MAY return both. 
	      If both variants are returned, 
	      they SHOULD be describing the same address, 
	      with the formatted address indicating how the 
	      component fields SHOULD be combined.
	    </t>
            <t>
              <list style="hanging">
                <t hangText="formatted">The full mailing address, 
		formatted for display or use with a mailing label. 
		This field MAY contain newlines. This is the 
		Primary Sub-Field for this field, 
		for the purposes of sorting and filtering.</t>

                <t hangText="street_address">
		The full street address component, 
		which may include house number, street name, 
		PO BOX, and multi-line extended street 
		address information. This field MAY contain newlines.</t>

                <t hangText="locality">The city or locality component.</t>

                <t hangText="region">The state, province, 
		prefecture or region component.</t>

                <t hangText="postal_code">The zip code or 
		postal code component.</t>

                <t hangText="country">The country name component.</t>
              </list>
            </t>
          </section>

	  <section anchor="claim.stability" title="Claim Stability and Uniqueness">
          
	    <t>The <spanx style="verb">user_id</spanx> claim is the only claim that a client
	    can rely upon to be stable, since the <spanx style="verb">user_id</spanx>
	    claim MUST be locally unique and never reassigned within the Issuer
	    for a particular End-User, as described in <xref target="id_token"></xref>.</t>
          
	    <t>Therefore, the only guaranteed unique identifier for a given End-User is a 
	    combination of the Issuer's identifier and the <spanx style="verb">user_id</spanx>
	    claim; other fields such as <spanx style="verb">preferred_username</spanx>
	    and <spanx style="verb">email</spanx> MUST NOT be used as unique identifiers 
	    for a given End-User.</t>
           
	    <t>All other claims carry no such guarantees across different issuers in terms of
	    stability over time or uniqueness across users, and Issuers are permitted to
	    apply local restrictions and policies. For instance, an Issuer MAY re-use a 
	    given <spanx style="verb">preferred_username</spanx> or 
	    <spanx style="verb">email</spanx> address claim across different
            End-Users at different points in time, and the claimed 
            <spanx style="verb">preferred_username</spanx> or 
            <spanx style="verb">email</spanx> address for a given End-User MAY change 
            over time.</t>
            
          </section>
        </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
	  <xref target="OAuth.Bearer">OAuth 2.0 Bearer Tokens</xref>.</t>

          <t>In addition to the error codes defined in Section 3.1 of <xref
	  target="OAuth.Bearer">OAuth 2.0 Bearer Tokens</xref>, this specification defines the
	  following error codes:</t>

          <t>
            <list style="hanging">
              <t hangText="invalid_schema">The requested schema is invalid or
	      unsupported.</t>
            </list>
          </t>
        </section>
      </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="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 using the <spanx
      style="verb">application/x-www-form-urlencoded</spanx> format as
      defined by <xref target="W3C.REC-html401-19991224"/>.</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.org%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"/>. 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.org%2Fcb]]></artwork>
      </figure>
    </section>

    <section anchor="stringops" title="String Operations">
      <t>
	Processing some OpenID Connect messages requires comparing
	values in the messages to known values. For example, the Claim
	Names returned by the UserInfo Endpoint might be compared to
	specific Claim Names such as <spanx
	style="verb">user_id</spanx>.  Comparing Unicode strings,
	however, has significant security implications.
      </t>
      <t>
	Therefore, comparisons between JSON strings and other Unicode
	strings MUST be performed as specified below:

	<list style="numbers">
	  <t>
	    Remove any JSON applied escaping to produce an array of
	    Unicode code points.
	  </t>
	  <t>
	    <xref target="USA15">Unicode Normalization</xref> MUST NOT
	    be applied at any point to either the JSON string or to
	    the string it is to be compared against.
	  </t>
	  <t>
	    Comparisons between the two strings MUST be performed as a
	    Unicode code point to code point equality comparison.
	  </t>
	</list>
      </t>
      <t>
	In several places, this specification uses space delimited
	lists of strings.  In all such cases, only the ASCII space
	character (0x20) MAY be used for this purpose.
      </t>

    </section>

    <section anchor="security_considerations" title="Security Considerations">

      <t>For security considerations, refer to the
      <xref target="OpenID.Standard">OpenID Connect Standard 1.0 Specification</xref>.
      </t>
    </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">
      <t>This document makes no requests of IANA.</t>
    </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.3339"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4627"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5646"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246"?>

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

      <reference anchor="USA15">
        <front>
          <title>Unicode Normalization Forms</title>

          <author fullname="Mark Davis" initials="M." surname="Davis">
            <address>
	      <email>markdavis@google.com</email>
	    </address>
          </author>

          <author fullname="Ken Whistler" initials="K." surname="Whistler">
            <address>
	      <email>ken@unicode.org</email>
	    </address>
          </author>

          <author fullname="Martin D&uuml;rst" initials="M." surname="D&uuml;rst">
          </author>

          <date day="03" month="09" year="2009"/>
	</front>

        <seriesInfo name="Unicode Standard Annex" value="15"/>
      </reference>

      <reference anchor="OAuth2.0">
        <front>
          <title>The OAuth 2.0 Authorization Framework</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="19" month="June" year="2012"/>
        </front>

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

      <reference anchor="OAuth.Bearer">
        <front>
          <title>The OAuth 2.0 Authorization Framework: Bearer Token Usage</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="19" month="June" year="2012"/>
        </front>

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

      <reference anchor="ISO639-1">
        <front>
          <title>ISO 639-1:2002. Codes for the representation of names of
          languages -- Part 1: Alpha-2 code</title>

          <author fullname="International Organization for Standardization"
		  initials="" surname="">
            <organization abbrev="ISO">International Organization for
            Standardization</organization>
          </author>

          <date year="2002"/>
        </front>
      </reference>

      <reference anchor="ISO3166-1">
        <front>
          <title>ISO 3166-1:1997. Codes for the representation of names of
          countries and their subdivisions -- Part 1: Country codes</title>

          <author fullname="International Organization for Standardization"
		  initials="" surname="">
            <organization abbrev="ISO">International Organization for
            Standardization</organization>
          </author>

          <date year="1997"/>
        </front>

        <format target="http://www.w3.org/WAI/ER/IG/ert/iso639.htm"
		type="HTML"/>
      </reference>

      <reference anchor="E.164">
        <front>
          <title>E.164: The international public telecommunication numbering plan</title>

          <author fullname="International Telecommunication Union"
		  initials="" surname="">
            <organization abbrev="ITU">International Telecommunication Union</organization>
          </author>

          <date year="2010"/>
        </front>

        <format target="http://www.itu.int/rec/T-REC-E.164-201011-I/en"
		type="HTML"/>
      </reference>

      <reference anchor="zoneinfo">
        <front>
          <title>The tz database</title>

          <author fullname="" initials="" surname="">
            <organization abbrev="Public">Public Domain</organization>
          </author>

          <date month="June" year="2011"/>
        </front>

        <format target="http://www.twinsun.com/tz/tz-link.htm" type="HTML"/>
      </reference>

      <reference anchor="OpenID.Standard">
        <front>
          <title>OpenID Connect Standard 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 abbrev="Ping Identity">Ping Identity</organization>
          </author>

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

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

          <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
            <organization abbrev="Salesforce">Salesforce</organization>
          </author>

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

          <date day="23" month="June" year="2012"/>
        </front>

        <format target="http://openid.net/specs/openid-connect-standard-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>Ping Identiity</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="25" month="May" year="2012"/>
        </front>

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

      <reference anchor="OpenID.Registration">
        <front>
          <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 abbrev="Ping Identity">Ping Identity</organization>
          </author>

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

          <date day="25" month="May" year="2012"/>
        </front>

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

      <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="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Ping Identity">Ping Identity</organization>
          </author>

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

          <date day="22" month="May" year="2012"/>
        </front>

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

    </references>
    <references title="Informative References">

      <reference anchor="OpenID.Implicit">
        <front>
          <title>OpenID Connect Implicit Client Profile 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 abbrev="Ping Identity">Ping Identity</organization>
          </author>

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

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

          <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
            <organization abbrev="Salesforce">Salesforce</organization>
          </author>

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

          <date day="23" month="June" year="2012" />
        </front>

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

    </references>

    <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>Andreas Akre Solberg (andreas.solberg@uninett.no), UNINET</t>
          <t>Anthony Nadalin (tonynad@microsoft.com), Microsoft</t>
          <t>Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom</t>
          <t>Breno de Medeiros (breno@gmail.com), Google</t>
          <t>Casper Biering (cb@peercraft.com), Peercraft</t>
          <t>Chuck Mortimore (cmortimore@salesforce.com), Salesforce</t>
          <t>David Recordon (dr@fb.com), Facebook</t>
          <t>Edmund Jay (ejay@mgi1.com), Illumila</t>
          <t>George Fletcher (george.fletcher@corp.aol.com), AOL</t>
          <t>Hideki Nara (hideki.nara@gmail.com), Takt Communications</t>
          <t>John Bradley (ve7jtb@ve7jtb.com), Ping Identity</t>
          <t>Johnny Bufu (jbufu@janrain.com), Janrain</t>
          <t>Justin Richer (jricher@mitre.org), Mitre</t>
          <t>Luke Shepard (lshepard@fb.com), Facebook</t>
          <t>Michael B. Jones (mbj@microsoft.com), Microsoft</t>
          <t>Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd. </t>
          <t>Nov Matake (nov@matake.jp), Independent</t>
          <t>Pamela Dingle (pdingle@pingidentity.com), Ping Identity</t>
          <t>Paul Tarjan (pt@fb.com), Facebook</t>
          <t>Roland Hedberg (roland.hedberg@adm.umu.se), Independent</t>
          <t>Ryo Ito (ryo.ito@mixi.co.jp), mixi, Inc.</t>
          <t>Torsten Lodderstedt (t.lodderstedt@telekom.de), Deutsche Telekom</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>-20
        <list style="symbols">
        <t>Added <spanx style="verb">preferred_username</spanx> claim
	under <spanx style="verb">profile</spanx> scope</t>
        <t>Added ID Token section to describe required claims</t>
        <t>Added section on claim stability</t>
        </list></t>

      <t>-19
        <list style="symbols">
	  <t>Fixed Section 2.2.5.1 to return code in a query paramater rather than a fragment</t>
	  <t>Removed <spanx style="verb">claims_in_id_token</spanx> scope value,
	  per decision on June 15, 2012 special working group call</t>
      </list></t>

      <t>-18
        <list style="symbols">
	  <t>Use "code" response_type instead of "token id_token" in Basic Profile,
	  per issue #567</t>
          <t>Changed <spanx style="verb">verified</spanx> to
	  <spanx style="verb">email_verified</spanx>, per issue #564</t>
          <t>Removed Check ID Endpoint, per issue #570</t>
	  <t>Removed requirement for ID Token signature validation from Basic Profile,
	  per issue #568</t>
	  <t>Removed use of <spanx style="verb">nonce</spanx> from Basic Profile,
	  per issue #569</t>
          <t>Changed client.example.com to client.example.org, per issue #251</t>
	  <t>Added claims_in_id_token scope definition to Basic and Implicit,
	  per issue #594</t>
	  <t>Use standards track version of JSON Web Token spec
	  (draft-ietf-oauth-json-web-token)</t>
      </list></t>

      <t>-17<list style="symbols">
	  <t>Removed "embedded" display type, since its semantics were
	  not well defined, per issue #514</t>
	  <t>Add hash and hash check of access_token and code to id_token, per issue #510</t>
	  <t>Add example JS code for client</t>
	  <t>Updated Notices</t>
	  <t>Updated References</t>
	</list></t>

      <t>-16<list style="symbols">
      <t>Added iat as a required claim in ID Tokens</t>
      <t>Enumerated claims requested by the "profile" scope value</t>
      <t>Added text about implicit flow to Abstract</t>
      </list></t>
      
      <t>-15<list style="symbols">
	  <t>Removed definition and usage for assertion and claim object</t>
	  <t>email scope allows access to the 'verified' claim</t>
	  <t>Removed language pertaining to custom userinfo schemas</t>
	  <t>Moved display=none to prompt=none</t>
	  <t>Added additional 'display' parameter options</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>Allow other gender strings in UserInfo schema</t>
	  <t>ID Token MUST be JWT</t>
	  <t>RECOMMENDED E.164 format for UserInfo 'phone_number' claim</t>
	  <t>Changed UserInfo Error Response to augment and return OAuth 2.0 Bearer Token Error Response</t>
	  <t>Check ID Endpoint SHOULD use POST</t>
	  <t>Added section about string comparison rules needed</t>
	  <t>Added Response Encoding according to Multiple Response Types spec</t>
	  <t>Make openid scope provide <spanx style="verb">user_id</spanx> from userinfo endpoint</t>
	  <t>Changed Security Considerations to refer to corresponding section in Standard</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_id_token error codes</t>
	  <t>Replace queryString with postBody variable in example JS</t>
        </list></t>

       <t>-14<list style="symbols">
          <t>Changed section 3.2.1 to refer to access_token ticket #134.</t>
           <t>Bumped version + date.</t>
           <t>Changed 7.4 in security considerations to show none is REQUIRED.</t>
           <t>Changed 3.2.4.1 User Info to UserInfo per Ticket #137.</t>
           <t>Changed formatting of 7.1 per ticket #140.</t>
        </list></t>

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

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

          <t>Removed issued_to, since not well defined.</t>

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

      <t>-12<list style="symbols">
          <t>Ticket #48 Changed Check Session to take the id_token as a
          parameter.</t>
        </list></t>

      <t>-11 <list style="symbols">
          <t>Renamed from "Lite" to "Basic Client".</t>

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

      <t>-10 <list style="symbols">
          <t>Add back id_token to the response type per issue 27.</t>

          <t>Changed endpoint name in example from id_token to
          check_session.</t>

          <t>Added token_type to the response and explanations of the optional
          parameters.</t>
        </list></t>

      <t>-09 <list style="symbols">
          <t>Clean up typos.</t>

          <t>Clean up scope explanation.</t>

          <t>Fix 3.2.4.1 to include id_token in response.</t>
        </list></t>

      <t>-08 <list style="symbols">
          <t>Added note about OP needing to read the full spec.</t>

          <t>Reverted back to GET for introspection based on Google
          feedback.</t>

          <t>Changed scopes to <spanx style="verb">openid</spanx>, <spanx
          style="verb">profile</spanx>, <spanx style="verb">address</spanx>,
          and <spanx style="verb">email</spanx> to make them additive.</t>

          <t>Changed introspection to Check Session Endpoint to be consistent
          with session management.</t>

          <t>Changed validation rules, the Check session endpoint will return
          an error for expired or invalid tokens, so the Client doesn't need
          to check expiration.</t>

          <t>Added explanation of why an id_token is used to verify identity
          rather than the userinfo Access Token.</t>
        </list></t>

      <t>-07 <list style="symbols">
          <t>Changed introspection to post</t>

          <t>Changed userinfo from <spanx style="verb">id</spanx> to <spanx
          style="verb">user_id</spanx> to be consistent with introspection
          endpoint.</t>

          <t>Fixed introspection example to use id_token rather than access
          token.</t>

          <t>Removed asking for id_token in response type.</t>

          <t>Fixed Section 3 to be clear it is client secret that is maintained
          between the client and the OP.</t>
        </list></t>

      <t>-06 <list style="symbols">
          <t>Only require the <spanx style="verb">token</spanx> flow in Lite.
          Removed <spanx style="verb">code</spanx> flow.</t>

          <t>Make <spanx style="verb">id_token</spanx> required. The <spanx
          style="verb">id_token</spanx> is treated as opaque.</t>

          <t>Rearranged sections for readability.</t>

          <t>Dropped the <spanx style="verb">schema</spanx> parameter to the
          Introspection endpoint, which was formerly a string with the value
          <spanx style="verb">user_id</spanx>. This is unnecessary since the
          <spanx style="verb">id_token</spanx> parameter already can be used
          to disambiguate the intended uses(s) of the endpoint.</t>

          <t>Dropped the requested audience from the Lite spec, which was
          formerly the identifier of the target audience of the response. This
          could be part of the Standard spec, but is an advanced scenario, and
          so not appropriate for Lite.</t>

          <t>Reference the Discovery and Registration specs, since they're
          needed for interaction between non-pre-configured parties (so that
          OpenID Connect installations can be Open).</t>
        </list></t>

      <t>-05 <list style="symbols">
          <t>Corrected issues raised by Casper Biering.</t>

          <t>Created the OpenID Connect Lite specification.</t>
        </list></t>

      <t>-04 <list style="symbols">
          <t>Correct issues raised by Pam Dingle and discussed on the mailing
          list after the 7-Jul-11 working group call.</t>

          <t>Adopted long_names.</t>
        </list></t>

      <t>-03 <list style="symbols">
          <t>Correct issues raised by Johnny Bufu and discussed on the
          7-Jul-11 working group call.</t>
        </list></t>

      <t>-02 <list style="symbols">
          <t>Consistency and cleanup pass, including removing unused
          references.</t>
        </list></t>

      <t>-01 <list style="symbols">
          <t>Initial draft</t>
        </list></t>
    </section>
  </back>
</rfc>