This repository has been archived by the owner on Mar 20, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 732
/
openid-authentication-2_0.html
4172 lines (3544 loc) · 174 KB
/
openid-authentication-2_0.html
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Final: OpenID Authentication 2.0 - Final</title>
<meta http-equiv="Expires" content="Wed, 05 Dec 2007 17:38:41 +0000">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Authentication 2.0 - Final">
<meta name="generator" content="xml2rfc v1.32 (http://xml.resource.org/)">
<style type="text/css"><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style></head><body>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<table summary="layout" border="0" cellpadding="0" cellspacing="0" width="66%"><tbody><tr><td><table summary="layout" border="0" cellpadding="2" cellspacing="1" width="100%">
<tbody><tr><td class="header">Final</td><td class="header"> specs@openid.net</td></tr>
<tr><td class="header"> </td><td class="header">December 5, 2007</td></tr>
</tbody></table></td></tr></tbody></table>
<h1><br>OpenID Authentication 2.0 - Final</h1>
<h3>Abstract</h3>
<p>
OpenID Authentication provides a way to prove that an end user
controls an Identifier. It does this without the Relying Party
needing access to end user credentials such as a password or
to other sensitive information such as an email address.
</p>
<p>
OpenID is decentralized. No central authority must approve or
register Relying Parties or OpenID Providers. An end user
can freely choose which OpenID Provider to use, and can
preserve their Identifier if they switch OpenID Providers.
</p>
<p>
While nothing in the protocol requires JavaScript or modern
browsers, the authentication scheme plays nicely with
"AJAX"-style setups. This means an end user can prove their
Identity to a Relying Party without having to leave their
current Web page.
</p>
<p>
OpenID Authentication uses only standard HTTP(S) requests and
responses, so it does not require any special capabilities of
the User-Agent or other client software. OpenID is not tied to
the use of cookies or any other specific mechanism of Relying
Party or OpenID Provider session management. Extensions to
User-Agents can simplify the end user interaction, though are
not required to utilize the protocol.
</p>
<p>
The exchange of profile information, or the exchange of other
information not covered in this specification, can be addressed
through additional service types built on top of this
protocol to create a framework. OpenID Authentication is
designed to provide a base service to enable portable,
user-centric digital identity in a free and decentralized manner.
</p><a name="toc"></a><br><hr>
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Requirements Notation and Conventions<br>
<a href="#terminology">2.</a>
Terminology<br>
<a href="#anchor2">3.</a>
Protocol Overview<br>
<a href="#anchor3">4.</a>
Data Formats<br>
<a href="#anchor4">4.1.</a>
Protocol Messages<br>
<a href="#btwoc">4.2.</a>
Integer Representations<br>
<a href="#anchor6">5.</a>
Communication Types<br>
<a href="#direct_comm">5.1.</a>
Direct Communication<br>
<a href="#indirect_comm">5.2.</a>
Indirect Communication<br>
<a href="#generating_signatures">6.</a>
Generating Signatures<br>
<a href="#anchor11">6.1.</a>
Procedure<br>
<a href="#sign_algos">6.2.</a>
Signature Algorithms<br>
<a href="#anchor12">7.</a>
Initiation and Discovery<br>
<a href="#initiation">7.1.</a>
Initiation<br>
<a href="#normalization">7.2.</a>
Normalization<br>
<a href="#discovery">7.3.</a>
Discovery<br>
<a href="#associations">8.</a>
Establishing Associations<br>
<a href="#anchor17">8.1.</a>
Association Session Request<br>
<a href="#anchor20">8.2.</a>
Association Session Response<br>
<a href="#assoc_types">8.3.</a>
Association Types<br>
<a href="#assoc_sess_types">8.4.</a>
Association Session Types<br>
<a href="#requesting_authentication">9.</a>
Requesting Authentication<br>
<a href="#anchor27">9.1.</a>
Request Parameters<br>
<a href="#realms">9.2.</a>
Realms<br>
<a href="#anchor28">9.3.</a>
Immediate Requests<br>
<a href="#responding_to_authentication">10.</a>
Responding to Authentication Requests<br>
<a href="#positive_assertions">10.1.</a>
Positive Assertions<br>
<a href="#negative_assertions">10.2.</a>
Negative Assertions<br>
<a href="#verification">11.</a>
Verifying Assertions<br>
<a href="#verify_return_to">11.1.</a>
Verifying the Return URL<br>
<a href="#verify_disco">11.2.</a>
Verifying Discovered Information<br>
<a href="#verify_nonce">11.3.</a>
Checking the Nonce<br>
<a href="#verifying_signatures">11.4.</a>
Verifying Signatures<br>
<a href="#identifying">11.5.</a>
Identifying the end user<br>
<a href="#extensions">12.</a>
Extensions<br>
<a href="#rp_discovery">13.</a>
Discovering OpenID Relying Parties<br>
<a href="#compat_mode">14.</a>
OpenID Authentication 1.1 Compatibility<br>
<a href="#anchor34">14.1.</a>
Changes from OpenID Authentication 1.1<br>
<a href="#anchor38">14.2.</a>
Implementing OpenID Authentication 1.1 Compatibility<br>
<a href="#security_considerations">15.</a>
Security Considerations<br>
<a href="#anchor41">15.1.</a>
Preventing Attacks<br>
<a href="#anchor43">15.2.</a>
User-Agents<br>
<a href="#anchor44">15.3.</a>
User Interface Considerations<br>
<a href="#anchor45">15.4.</a>
HTTP and HTTPS URL Identifiers<br>
<a href="#anchor46">15.5.</a>
Denial of Service Attacks<br>
<a href="#anchor47">15.6.</a>
Protocol Variants<br>
<a href="#anchor48">Appendix A.</a>
Examples<br>
<a href="#normalization_example">Appendix A.1.</a>
Normalization<br>
<a href="#anchor49">Appendix A.2.</a>
OP-Local Identifiers<br>
<a href="#XRDS_Sample">Appendix A.3.</a>
XRDS<br>
<a href="#anchor50">Appendix A.4.</a>
HTML Identifier Markup<br>
<a href="#anchor51">Appendix A.5.</a>
XRI CanonicalID<br>
<a href="#pvalue">Appendix B.</a>
Diffie-Hellman Key Exchange Default Value<br>
<a href="#anchor52">Appendix C.</a>
Acknowledgements<br>
<a href="#rfc.references1">16.</a>
Normative References<br>
<a href="#rfc.authors">§</a>
Author's Address<br>
</p>
<br clear="all">
<a name="anchor1"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.1"></a><h3>1.
Requirements Notation and Conventions</h3>
<p>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <a class="info" href="#RFC2119">[RFC2119]<span> (</span><span class="info">Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .</span><span>)</span></a>.
</p>
<p>
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.
</p>
<a name="terminology"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.2"></a><h3>2.
Terminology</h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>Identifier:</dt>
<dd>
An Identifier is either a "http" or "https" URI, (commonly
referred to as a "URL" within this document), or an <a class="info" href="#XRI_Syntax_2.0">XRI<span> (</span><span class="info">Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .</span><span>)</span></a> [XRI_Syntax_2.0]. This document defines
various kinds of Identifiers, designed for use in different
contexts.
</dd>
<dt>User-Agent:</dt>
<dd>
The end user's Web browser which implements HTTP/1.1 <a class="info" href="#RFC2616">[RFC2616]<span> (</span><span class="info">Fielding,
R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T.
Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .</span><span>)</span></a>.
</dd>
<dt>Relying Party:</dt>
<dd>
RP. A Web application that wants proof that the end user
controls an Identifier.
</dd>
<dt>OpenID Provider:</dt>
<dd>
OP. An OpenID Authentication server on which a Relying
Party relies for an assertion that the end user controls
an Identifier.
</dd>
<dt>OP Endpoint URL:</dt>
<dd>
The URL which accepts OpenID Authentication protocol messages,
obtained by performing discovery on the User-Supplied
Identifier. This value MUST be an absolute HTTP or HTTPS URL.
</dd>
<dt>OP Identifier:</dt>
<dd>
An Identifier for an OpenID Provider.
</dd>
<dt>User-Supplied Identifier:</dt>
<dd>
An Identifier that was presented by the end user to the
Relying Party, or selected by the user at the OpenID
Provider. During the initiation phase of the protocol,
an end user may enter either their own Identifier or an OP
Identifier. If an OP Identifier is used, the OP may then
assist the end user in selecting an Identifier to share with
the Relying Party.
</dd>
<dt>Claimed Identifier:</dt>
<dd>
An Identifier that the end user claims to own; the overall
aim of the protocol is verifying this claim. The Claimed
Identifier is either:
<ul class="text">
<li>
The Identifier obtained by <a class="info" href="#normalization">normalizing<span> (</span><span class="info">Normalization</span><span>)</span></a> the User-Supplied Identifier, if it
was an URL.
</li>
<li>
The <a class="info" href="#canonicalid">CanonicalID<span> (</span><span class="info">XRI and the CanonicalID Element</span><span>)</span></a>, if it
was an XRI.
</li>
</ul>
</dd>
<dt>OP-Local Identifier:</dt>
<dd>
An alternate Identifier for an end user that is local to a
particular OP and thus not necessarily under the end user's
control.
</dd>
</dl></blockquote><p>
</p>
<a name="anchor2"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.3"></a><h3>3.
Protocol Overview</h3>
<p>
</p>
<ol class="text">
<li>
The end user <a class="info" href="#initiation">initiates
authentication<span> (</span><span class="info">Initiation</span><span>)</span></a> by presenting a User-Supplied Identifier
to the Relying Party via their User-Agent.
</li>
<li>
After <a class="info" href="#normalization">normalizing<span> (</span><span class="info">Normalization</span><span>)</span></a> the
User-Supplied Identifier, the Relying Party <a class="info" href="#discovery">performs discovery<span> (</span><span class="info">Discovery</span><span>)</span></a> on it and
establishes the OP Endpoint URL that the end user uses for
authentication. It should be noted that the User-Supplied
Identifier may be an OP Identifier, as discussed in <a class="info" href="#discovered_info">Section 7.3.1<span> (</span><span class="info">Discovered Information</span><span>)</span></a>, which allows selection of a
Claimed Identifier at the OP or for the protocol to
proceed without a Claimed Identifier if something else
useful is being done via an <a class="info" href="#extensions">extension<span> (</span><span class="info">Extensions</span><span>)</span></a>.
</li>
<li>
(optional)
The Relying Party and the OP establish an <a class="info" href="#associations">association<span> (</span><span class="info">Establishing Associations</span><span>)</span></a> -- a shared
secret established using <a class="info" href="#RFC2631">Diffie-Hellman Key Exchange<span> (</span><span class="info">Rescorla, E., “Diffie-Hellman Key Agreement Method,” .</span><span>)</span></a> [RFC2631]. The
OP uses an association to sign subsequent messages and the
Relying Party to verify those messages; this removes the
need for subsequent direct requests to verify the
signature after each authentication request/response.
</li>
<li>
The Relying Party redirects the end user's User-Agent to
the OP with an OpenID <a class="info" href="#requesting_authentication">Authentication
request<span> (</span><span class="info">Requesting Authentication</span><span>)</span></a>.
</li>
<li>
The OP establishes whether the end user is authorized to
perform OpenID Authentication and wishes to do so. The
manner in which the end user authenticates to their OP and
any policies surrounding such authentication is out of
scope for this document.
</li>
<li>
The OP redirects the end user's User-Agent back to the
Relying Party with either an assertion that <a class="info" href="#positive_assertions">authentication is
approved<span> (</span><span class="info">Positive Assertions</span><span>)</span></a> or a message that <a class="info" href="#negative_assertions">authentication failed<span> (</span><span class="info">Negative Assertions</span><span>)</span></a>.
</li>
<li>
The Relying Party <a class="info" href="#verification">verifies<span> (</span><span class="info">Verifying Assertions</span><span>)</span></a> the information received from the OP including
checking the Return URL, verifying the discovered
information, checking the nonce, and verifying the
signature by using either the shared key established
during the association or by sending a direct request
to the OP.
</li>
</ol><p>
</p>
<a name="anchor3"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4"></a><h3>4.
Data Formats</h3>
<a name="anchor4"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4.1"></a><h3>4.1.
Protocol Messages</h3>
<p>
The OpenID Authentication protocol messages are
mappings of plain-text keys to plain-text values. The keys and
values permit the full Unicode character set (UCS). When the
keys and values need to be converted to/from bytes, they
MUST be encoded using <a class="info" href="#RFC3629">UTF-8<span> (</span><span class="info">Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .</span><span>)</span></a> [RFC3629].
</p>
<p>
Messages MUST NOT contain multiple parameters with the same name.
</p>
<p>
Throughout this document, all OpenID message parameters are
REQUIRED, unless specifically marked as OPTIONAL.
</p>
<a name="kvform"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4.1.1"></a><h3>4.1.1.
Key-Value Form Encoding</h3>
<p>
A message in Key-Value form is a sequence of lines. Each
line begins with a key, followed by a colon, and the value
associated with the key. The line is terminated by a
single newline (UCS codepoint 10, "\n"). A key or value
MUST NOT contain a newline and a key also MUST NOT contain
a colon.
</p>
<p>
Additional characters, including whitespace, MUST NOT be
added before or after the colon or newline. The message
MUST be encoded in UTF-8 to produce a byte string.
</p>
<p>
Key-Value Form encoding is used for signature calculation
and for <a class="info" href="#direct_response">direct
responses<span> (</span><span class="info">Direct Response</span><span>)</span></a> to Relying Parties.
</p>
<a name="http_encoding"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4.1.2"></a><h3>4.1.2.
HTTP Encoding</h3>
<p>
When a message is sent to an HTTP server, it MUST be encoded
using a form encoding specified in Section 17.13.4 of
<a class="info" href="#HTML401">[HTML401]<span> (</span><span class="info">W3C, “HTML 4.01 Specification,” .</span><span>)</span></a>. Likewise, if the "Content-Type"
header is included in the request headers, its value MUST
also be such an encoding.
</p>
<p>
All of the keys in the request message MUST be prefixed
with "openid.". This prefix prevents interference with
other parameters that are passed along with the OpenID
Authentication message. When a message is sent as a POST,
OpenID parameters MUST only be sent in, and extracted
from, the POST body.
</p>
<p>
All messages that are sent as HTTP requests (GET or POST)
MUST contain the following fields:
</p>
<ul class="text">
<li>
openid.ns
<blockquote class="text">
<p>
Value: "http://specs.openid.net/auth/2.0"
</p>
<p>
This particular value MUST be present for the
request to be a valid OpenID Authentication 2.0
request. Future versions of the specification may
define different values in order to allow message
recipients to properly interpret the request.
</p>
<p>
If this value is absent or set to one of
"http://openid.net/signon/1.1" or
"http://openid.net/signon/1.0", then this message
SHOULD be interpreted using <a class="info" href="#compat_mode">OpenID Authentication 1.1
Compatibility mode<span> (</span><span class="info">OpenID Authentication 1.1 Compatibility</span><span>)</span></a>.
</p>
</blockquote>
</li>
<li>
openid.mode
<blockquote class="text">
<p>
Value: Specified individually for each message
type.
</p>
<p>
The "openid.mode" parameter allows the recipient
of the message to know what kind of message it is
processing. If "openid.mode" is absent, the party
processing the message SHOULD assume that the
request is not an OpenID message.
</p>
</blockquote>
</li>
</ul><p>
</p>
<p>
This model applies to messages from the User-Agent to both
the Relying Party and the OP, as well as messages from the
Relying Party to the OP.
</p>
<a name="anchor5"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4.1.3"></a><h3>4.1.3.
Example</h3>
<p>
Non-normative
</p>
<p>
The following examples encode the following information:
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>Key | Value
--------+---------------------------
mode | error
error | This is an example message
</pre></div>
<p>
Key-Value Form encoded:
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>mode:error
error:This is an example message
</pre></div>
<p>
x-www-urlencoded, as in a HTTP POST body or in a URL's
query string (<a class="info" href="#RFC3986">[RFC3986]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> section 3):
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>openid.mode=error&openid.error=This%20is%20an%20example%20message</pre></div>
<a name="btwoc"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4.2"></a><h3>4.2.
Integer Representations</h3>
<p>
Arbitrary precision integers MUST be encoded as big-endian
signed two's complement binary strings. Henceforth, "btwoc"
is a function that takes an arbitrary precision integer and
returns its shortest big-endian two's complement
representation. All integers that are used with
Diffie-Hellman Key Exchange are positive. This means that
the left-most bit of the two's complement representation
MUST be zero. If it is not, implementations MUST add a zero
byte at the front of the string.
</p>
<p>Non-normative example:
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>Base 10 number | btwoc string representation
---------------+----------------------------
0 | "\x00"
127 | "\x7F"
128 | "\x00\x80"
255 | "\x00\xFF"
32768 | "\x00\x80\x00"
</pre></div>
<a name="anchor6"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.5"></a><h3>5.
Communication Types</h3>
<a name="direct_comm"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.5.1"></a><h3>5.1.
Direct Communication</h3>
<p>
Direct communication is initiated by a Relying Party to an
OP endpoint URL. It is used for <a class="info" href="#associations">establishing associations<span> (</span><span class="info">Establishing Associations</span><span>)</span></a> and
<a class="info" href="#check_auth">verifying authentication
assertions<span> (</span><span class="info">Verifying Directly with the OpenID Provider</span><span>)</span></a>.
</p>
<a name="direct_request"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.5.1.1"></a><h3>5.1.1.
Direct Request</h3>
<p>
The message MUST be encoded as a POST body, as specified
by <a class="info" href="#http_encoding">Section 4.1.2<span> (</span><span class="info">HTTP Encoding</span><span>)</span></a>.
</p>
<p>
All direct requests are HTTP POSTs, and so
contain the required fields listed in <a class="info" href="#http_encoding">Section 4.1.2<span> (</span><span class="info">HTTP Encoding</span><span>)</span></a>.
</p>
<a name="direct_response"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.5.1.2"></a><h3>5.1.2.
Direct Response</h3>
<p>
The body of a response to a <a class="info" href="#direct_request">Direct Request<span> (</span><span class="info">Direct Request</span><span>)</span></a> consists of
an HTTP Response body in <a class="info" href="#kvform">Key-Value
Form<span> (</span><span class="info">Key-Value Form Encoding</span><span>)</span></a>. The content-type of the response SHOULD be
"text/plain".
</p>
<p>
All Key-Value form message MUST contain the following field:
</p>
<ul class="text">
<li>
ns
<blockquote class="text">
<p>
Value: "http://specs.openid.net/auth/2.0"
</p>
<p>
This particular value MUST be present for the
response to be a valid OpenID 2.0 response. Future
versions of the specification may define different
values in order to allow message recipients to
properly interpret the request.
</p>
<p>
If this value is absent or set to one of
"http://openid.net/signon/1.1" or
"http://openid.net/signon/1.0", then this message
SHOULD be interpreted using <a class="info" href="#compat_mode">OpenID Authentication 1.1
Compatibility mode<span> (</span><span class="info">OpenID Authentication 1.1 Compatibility</span><span>)</span></a>.
</p>
</blockquote>
</li>
</ul><p>
</p>
<a name="anchor7"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.5.1.2.1"></a><h3>5.1.2.1.
Successful Responses</h3>
<p>
A server receiving a valid request MUST send a
response with an HTTP status code of 200.
</p>
<a name="anchor8"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.5.1.2.2"></a><h3>5.1.2.2.
Error Responses</h3>
<p>
If a request is malformed or contains invalid arguments,
the server MUST send a response with a status code of
400. The response body MUST be a <a class="info" href="#kvform">Key-Value Form<span> (</span><span class="info">Key-Value Form Encoding</span><span>)</span></a> message with the
following fields:
</p>
<p>
</p>
<ul class="text">
<li>
ns
<blockquote class="text">
<p>
As specified in <a class="info" href="#direct_response">Section 5.1.2<span> (</span><span class="info">Direct Response</span><span>)</span></a>.
</p>
</blockquote>
</li>
<li>
error
<blockquote class="text">
<p>
Value: A human-readable message indicating the cause
of the error.
</p>
</blockquote>
</li>
<li>
contact
<blockquote class="text">
<p>
Value: (optional) Contact address for the
administrator of the sever. The contact address
may take any form, as it is intended to be
displayed to a person.
</p>
</blockquote>
</li>
<li>
reference
<blockquote class="text">
<p>
Value: (optional) A reference token, such
as a support ticket number or a URL to a news
blog, etc.
</p>
</blockquote>
</li>
</ul><p>
The OP MAY add additional fields to this response.
</p>
<a name="indirect_comm"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.5.2"></a><h3>5.2.
Indirect Communication</h3>
<p>
In indirect communication, messages are passed through the
User-Agent. This can be initiated by either the Relying
Party or the OP. Indirect communication is used for <a class="info" href="#requesting_authentication">authentication
requests<span> (</span><span class="info">Requesting Authentication</span><span>)</span></a> and <a class="info" href="#responding_to_authentication">authentication
responses<span> (</span><span class="info">Responding to Authentication Requests</span><span>)</span></a>.
</p>
<p>
There are two methods for indirect communication: HTTP
redirects and HTML form submission.
Both form submission and redirection require that the sender
know a recipient URL and that the recipient URL expect
indirect messages, as specified in <a class="info" href="#http_encoding">Section 4.1.2<span> (</span><span class="info">HTTP Encoding</span><span>)</span></a>. The initiator of the communication chooses which method
of indirect communication is appropriate depending on
capabilities, message size, or other external factors.
</p>
<p>
All indirect messages arrive as HTTP requests, and so
contain the required fields listed in <a class="info" href="#http_encoding">Section 4.1.2<span> (</span><span class="info">HTTP Encoding</span><span>)</span></a>.
</p>
<a name="anchor9"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.5.2.1"></a><h3>5.2.1.
HTTP Redirect</h3>
<p>
Data can be transferred by issuing a 302, 303, or 307 HTTP
Redirect to the end user's User-Agent. The redirect URL is
the URL of the receiver with the OpenID Authentication
message appended to the query string, as specified in
<a class="info" href="#http_encoding">Section 4.1.2<span> (</span><span class="info">HTTP Encoding</span><span>)</span></a>.
</p>
<a name="anchor10"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.5.2.2"></a><h3>5.2.2.
HTML FORM Redirection</h3>
<p>
A mapping of keys to values can be transferred by
returning an HTML page to the User-Agent that contains an
HTML form element. Form submission MAY be automated,
for example by using JavaScript.
</p>
<p>
The <form> element's "action" attribute value MUST
be the URL of the receiver. Each Key-Value pair MUST be
included in the form as an <input> element. The key
MUST be encoded as the "name" attribute and the value as
the "value" attribute, such that the User-Agent will
generate a message as specified in <a class="info" href="#http_encoding">Section 4.1.2<span> (</span><span class="info">HTTP Encoding</span><span>)</span></a> when the form is submitted. The
form MUST include a submit button.
</p>
<a name="indirect_error"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.5.2.3"></a><h3>5.2.3.
Indirect Error Responses</h3>
<p>
In the case of a malformed request, or one that contains
invalid arguments, the OpenID Provider MUST redirect the
User-Agent to the "openid.return_to" URL value if the
value is present and it is a valid URL.
</p>
<p>
</p>
<ul class="text">
<li>
openid.ns
<blockquote class="text">
<p>
As specified in <a class="info" href="#http_encoding">Section 4.1.2<span> (</span><span class="info">HTTP Encoding</span><span>)</span></a>.
</p>
</blockquote>
</li>
<li>
openid.mode
<blockquote class="text">
<p>
Value: "error"
</p>
</blockquote>
</li>
<li>
openid.error
<blockquote class="text">
<p>
Value: A human-readable message indicating the cause
of the error.
</p>
</blockquote>
</li>
<li>
openid.contact
<blockquote class="text">
<p>
Value: (optional) Contact address for the
administrator of the sever. The contact address
may take any form, as it is intended to be
displayed to a person.
</p>
</blockquote>
</li>
<li>
openid.reference
<blockquote class="text">
<p>
Value: (optional) A reference token, such as a
support ticket number or a URL to a news blog,
etc.
</p>
</blockquote>
</li>
</ul><p>
The server MAY add additional keys to this response.
</p>
<p>
If the malformed or invalid message is received by the Relying
Party, or "openid.return_to" is not present or its value is not
a valid URL, the server SHOULD return a response to the
end user indicating the error and that it is unable to continue.
</p>
<a name="generating_signatures"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.6"></a><h3>6.
Generating Signatures</h3>
<p>
The most common usage of an association is as a Message
Authentication Code (MAC) key used to sign OpenID
Authentication messages.
</p>
<p>
When generating MAC keys, the recommendations in <a class="info" href="#RFC1750">[RFC1750]<span> (</span><span class="info">Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” .</span><span>)</span></a> SHOULD be followed.