-
Notifications
You must be signed in to change notification settings - Fork 17
/
openid-authentication.html
3545 lines (2549 loc) · 179 KB
/
openid-authentication.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 - 最終版</title>
<meta http-equiv="Expires" content="Thu, 14 Jan 2010 06:20:59 +0000">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Authentication 2.0 - 最終版">
<meta name="generator" content="xml2rfc v1.34 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Final</td><td class="header"> specs@openid.net</td></tr>
<tr><td class="header"> </td><td class="header">December 2007</td></tr>
</table></td></tr></table>
<h1><br />OpenID Authentication 2.0 - 最終版</h1>
<h3>Abstract</h3>
<p>
OpenID 認証は、エンドユーザが識別子 (Identifier) を管理していることを証明する方法を提供するものである。OpenID 認証を利用すれば、リライングパーティー (Relying Party、以下 RP) はエンドユーザのパスワードやメールアドレスなどにアクセスする必要がなくなる。
</p>
<p>
OpenID は、分散方式であり、RP や OpenID プロバイダ (OpenID Provider 、以下 OP) の承認・登録を行なう中央集権的な機関は存在しない。エンドユーザは利用する OP を自由に選択することができ、OP を変更しても自身の識別子をそのまま継続して利用することができる。
</p>
<p>
プロトコル自体は JavaScript や最新ブラウザを必要としないが、AJAX を利用しても認証 (authentication) の仕組みは上手く機能する。つまり、エンドユーザは、現在のウェブページから離れずに、RP に自らの身元を証明できるのである。
</p>
<p>
OpenID 認証は、HTTP(S) の標準的な要求／応答だけを用いているため、ユーザエージェント (User-Agent) やクライアントソフトウェアが特別な機能を備えている必要はない。OpenID は、cookie をはじめ、RP や OP 特有のセッション管理方法には全く依存していない。ユーザエージェントの機能拡張により、エンドユーザの操作を簡素化できるが、プロトコル利用上は必ずしも必要ではない。
</p>
<p>
プロファイル情報の交換や、本仕様に記されていないその他の情報の交換については、本プロトコル上にサービスタイプを追加し、仕組みを構築することで実現可能である。OpenID 認証は、ポータブル (環境に依存せずに使用可能) でユーザセントリックなデジタルアイデンティティを、自由かつ分散的な方式で実現するための基盤サービスを提供するために設計された。
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
要求記法および規則<br />
<a href="#terminology">2.</a>
用語<br />
<a href="#anchor2">3.</a>
プロトコルの概要<br />
<a href="#anchor3">4.</a>
データフォーマット<br />
<a href="#anchor4">4.1.</a>
プロトコルメッセージ<br />
<a href="#btwoc">4.2.</a>
整数表現<br />
<a href="#anchor6">5.</a>
通信形式<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>
署名の生成<br />
<a href="#anchor11">6.1.</a>
署名の生成手順<br />
<a href="#sign_algos">6.2.</a>
署名アルゴリズム<br />
<a href="#anchor12">7.</a>
開始とディスカバリ<br />
<a href="#initiation">7.1.</a>
開始<br />
<a href="#normalization">7.2.</a>
正規化<br />
<a href="#discovery">7.3.</a>
ディスカバリ<br />
<a href="#associations">8.</a>
アソシエーションの確立<br />
<a href="#anchor17">8.1.</a>
アソシエーションセッション要求<br />
<a href="#anchor20">8.2.</a>
アソシエーションセッション応答<br />
<a href="#assoc_types">8.3.</a>
アソシエーション形式<br />
<a href="#assoc_sess_types">8.4.</a>
アソシエーションセッション形式<br />
<a href="#requesting_authentication">9.</a>
認証要求<br />
<a href="#anchor27">9.1.</a>
要求パラメータ<br />
<a href="#realms">9.2.</a>
レルム<br />
<a href="#anchor28">9.3.</a>
即時要求<br />
<a href="#responding_to_authentication">10.</a>
認証要求に対する応答<br />
<a href="#positive_assertions">10.1.</a>
肯定アサーション<br />
<a href="#negative_assertions">10.2.</a>
否定アサーション<br />
<a href="#verification">11.</a>
アサーションの検証<br />
<a href="#verify_return_to">11.1.</a>
戻り URL の検証<br />
<a href="#verify_disco">11.2.</a>
ディスカバリによって得られた情報の検証<br />
<a href="#verify_nonce">11.3.</a>
ノンスのチェック<br />
<a href="#verifying_signatures">11.4.</a>
署名の検証<br />
<a href="#identifying">11.5.</a>
エンドユーザの識別<br />
<a href="#extensions">12.</a>
拡張仕様<br />
<a href="#rp_discovery">13.</a>
OpenID リライングパーティーのディスカバリ<br />
<a href="#compat_mode">14.</a>
OpenID Authentication 1.1 との互換性<br />
<a href="#anchor34">14.1.</a>
OpenID Authentication 1.1 からの変更点<br />
<a href="#anchor38">14.2.</a>
OpenID Authentication 1.1 互換性の実装<br />
<a href="#security_considerations">15.</a>
セキュリティに関する考慮事項<br />
<a href="#anchor41">15.1.</a>
アタック（攻撃）からの防御<br />
<a href="#anchor43">15.2.</a>
ユーザエージェント<br />
<a href="#anchor44">15.3.</a>
ユーザインタフェースに関する考慮事項<br />
<a href="#anchor45">15.4.</a>
HTTP および HTTPS URL 識別子<br />
<a href="#anchor46">15.5.</a>
サービス妨害攻撃 （DoS 攻撃）<br />
<a href="#anchor47">15.6.</a>
プロトコルの可変項目<br />
<a href="#anchor48">Appendix A.</a>
使用例<br />
<a href="#normalization_example">Appendix A.1.</a>
正規化<br />
<a href="#anchor49">Appendix A.2.</a>
OP ローカル識別子<br />
<a href="#XRDS_Sample">Appendix A.3.</a>
XRDS<br />
<a href="#anchor50">Appendix A.4.</a>
HTML 識別子のマークアップ<br />
<a href="#anchor51">Appendix A.5.</a>
XRI 正準化 ID<br />
<a href="#pvalue">Appendix B.</a>
Diffie-Hellman 鍵交換のデフォルト値<br />
<a href="#anchor52">Appendix C.</a>
謝辞<br />
<a href="#rfc.references1">16.</a>
参考文献<br />
<a href="#rfc.authors">§</a>
Author's Address<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
要求記法および規則</h3>
<p>
本文書で用いられる各キーワード「MUST (しなければならない)」、「MUST NOT (してはならない)」、「REQUIRED (必須である)」、「SHALL (するものとする)」、「SHALL NOT (しないものとする)」、「SHOULD (すべきである)」、「SHOULD NOT (すべきではない)」、「RECOMMENDED (推奨される)」、「MAY (してもよい)」、「OPTIONAL (任意である)」は <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>
本文書では、書いてあるままに解釈されるべき値は引用符 ("") で囲んで示している。プロトコルメッセージの中でこれらの値を使用する場合は、値の一部として引用符を用いてはならない (MUST NOT)。
</p>
<a name="terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
用語</h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>識別子 (Identifier):</dt>
<dd>
識別子は、"http" または "https" URI (本文書では、通例に従い "URL" と表記)、もしくは <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] のいずれかである。本文書では、様々な種類の識別子を定義するが、それぞれ異なるコンテキストでの使用を目的としている。
</dd>
<dt>ユーザエージェント (User-Agent):</dt>
<dd>
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。エンドユーザが識別子を管理しているという証明を要求するウェブアプリケーション。
</dd>
<dt>OpenID プロバイダ (OpenID Provider):</dt>
<dd>
略語は OP。エンドユーザが識別子を管理しているというアサーション (assertion) を得るために RP が依存する OpenID 認証サーバ。
</dd>
<dt>OP エンドポイントURL (OP Endpoint URL):</dt>
<dd>
OpenID 認証プロトコルメッセージを受け入れる URL で、ユーザ入力識別子 (User-Supplied Identifier) のディスカバリ (discovery) を実行することにより得られる。この値は、HTTP または HTTPS の絶対 URL でなければならない (MUST)。
</dd>
<dt>OP 識別子 (OP Identifier):</dt>
<dd>
OP の識別子。
</dd>
<dt>ユーザ入力識別子 (User-Supplied Identifier):</dt>
<dd>
エンドユーザが RP に提示する識別子、または OP においてユーザが選択した識別子。プロトコルの開始 (initiation) フェーズでは、エンドユーザは、自らの識別子、OP 識別子のどちらを入力してもよい。OP 識別子を用いる場合、OP は、エンドユーザが RP に提示する識別子の選択を支援してもよい。
</dd>
<dt>主張識別子 (Claimed Identifier):</dt>
<dd>
エンドユーザが自らのものであると主張する識別子。プロトコル全体の狙いは、この主張を検証することにある。主張識別子は、以下のいずれかである。
<ul class="text">
<li>
URL の場合、ユーザ入力識別子を<a class='info' href='#normalization'>正規化<span> (</span><span class='info'>正規化</span><span>)</span></a>することで得られる識別子。
</li>
<li>
XRI の場合、<a class='info' href='#canonicalid'>正準化 ID (CanonicalID)<span> (</span><span class='info'>XRI および正準化 ID エレメント</span><span>)</span></a>。
</li>
</ul>
</dd>
<dt>OP ローカル識別子 (OP-Local Identifier):</dt>
<dd>
特定の OP でエンドユーザを識別するためにローカルに用いられる代替の識別子。必ずしもエンドユーザが管理しているものではない。
</dd>
</dl></blockquote><p>
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
プロトコルの概要</h3>
<p>
</p>
<ol class="text">
<li>
エンドユーザは、ユーザエージェントを通じて RP にユーザ入力識別子を提示することによって、<a class='info' href='#initiation'>認証を開始<span> (</span><span class='info'>開始</span><span>)</span></a>する。
</li>
<li>
ユーザ入力識別子を<a class='info' href='#normalization'>正規化<span> (</span><span class='info'>正規化</span><span>)</span></a>した後、RP はその<a class='info' href='#discovery'>ディスカバリを実行<span> (</span><span class='info'>ディスカバリ</span><span>)</span></a>し、エンドユーザが認証に用いる OP エンドポイント URL を確定する。ユーザ入力識別子は、OP 識別子である可能性があることに留意する必要があるが、この点については <a class='info' href='#discovered_info'>Section 7.3.1<span> (</span><span class='info'>ディスカバリによって得られる情報</span><span>)</span></a> で述べる。OP 識別子のときは、OP で主張識別子を選択することができる。また、<a class='info' href='#extensions'>拡張仕様<span> (</span><span class='info'>拡張仕様</span><span>)</span></a>を利用して実用的な代替手段が取られている場合は、主張識別子を用いずにプロトコルを続行することもできる。
</li>
<li>
(オプション)
RP と OP の間の<a class='info' href='#associations'>アソシエーション (association)<span> (</span><span class='info'>アソシエーションの確立</span><span>)</span></a> の確立は、<a class='info' href='#RFC2631'>Diffie-Hellman 鍵交換<span> (</span><span class='info'>Rescorla, E., “Diffie-Hellman Key Agreement Method,” .</span><span>)</span></a> [RFC2631]を用いた共有秘密鍵の発行をもって行う。OP はその後のメッセージに署名するためにアソシエーションを用い、RP はこれらのメッセージを検証するためにアソシエーションを用いる。その結果、それぞれの認証要求／応答に続く署名検証のための直接要求を行なう必要がなくなる。
</li>
<li>
RP は、エンドユーザのユーザエージェントを、OpenID <a class='info' href='#requesting_authentication'>認証要求<span> (</span><span class='info'>認証要求</span><span>)</span></a>とともに OP にリダイレクトする。
</li>
<li>
OP は、エンドユーザが OpenID 認証の実行を許可されているかどうか、さらにエンドユーザが認証の実行を求めているかどうかを確定する。OP におけるエンドユーザの認証方法およびそのような認証に関わるポリシーは全て、本文書の対象範囲外である。
</li>
<li>
OP は、エンドユーザのユーザエージェントを、<a class='info' href='#positive_assertions'>認証が承認された<span> (</span><span class='info'>肯定アサーション</span><span>)</span></a>ことを示すアサーション、<a class='info' href='#negative_assertions'>認証が失敗した<span> (</span><span class='info'>否定アサーション</span><span>)</span></a>ことを示すメッセージのどちらかとともに RP へリダイレクトする。
</li>
<li>
RP は、OP から受け取った情報を<a class='info' href='#verification'>検証<span> (</span><span class='info'>アサーションの検証</span><span>)</span></a>し、戻り URL (Return URL) のチェック、ディスカバリによって得られた情報の検証、ノンス (nonce) のチェックなどを行なう。また、アソシエーション確立時に発行した共有鍵、あるいは OP への直接要求のいずれかを用いて、署名を検証する。
</li>
</ol><p>
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
データフォーマット</h3>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1"></a><h3>4.1.
プロトコルメッセージ</h3>
<p>
OpenID 認証プロトコルメッセージは、プレーンテキストのキーとプレーンテキストの値とをマッピングしたものである。キーおよび値には、Unicode 文字セット (UCS) を全て使用することができる。キーおよび値とバイト形式との間の変換が必要な場合は、<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] を用いてエンコードしなければならない (MUST)。
</p>
<p>
メッセージは、同じ名前のパラメータを複数含んではならない (MUST NOT)。
</p>
<p>
本文書に記されている OpenID メッセージのパラメータは、全て必須である (REQUIRED)。ただし、任意である (OPTIONAL) と明示されている場合は、その限りではない。
</p>
<a name="kvform"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1.1"></a><h3>4.1.1.
キー・バリュー形式エンコーディング</h3>
<p>
キー・バリュー形式のメッセージは、一連の行からなる。各行の最初はキーで、その後ろにコロンを付加し、キーと関連する値が続く。各行は、一個の改行文字 (UCS 文字コード番号 10, "\n") で終わる。キーまたは値は、改行文字を含んではならない (MUST NOT)。また、キーは、コロンを含んではならない (MUST NOT)。
</p>
<p>
空白を含む追加文字は、コロンまたは改行文字の前後に追加してはならない (MUST NOT)。メッセージからバイト文字列を生成するときは、UTF-8 でエンコードしなければならない (MUST)。
</p>
<p>
キー・バリュー形式エンコーディングは、署名計算および RP への<a class='info' href='#direct_response'>直接応答<span> (</span><span class='info'>直接応答 (Direct Response)</span><span>)</span></a>に利用される。
</p>
<a name="http_encoding"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1.2"></a><h3>4.1.2.
HTTP エンコーディング</h3>
<p>
HTTP サーバにメッセージを送るときは、<a class='info' href='#HTML401'>[HTML401]<span> (</span><span class='info'>W3C, “HTML 4.01 Specification,” .</span><span>)</span></a> の Section 17.13.4 に定められるフォームエンコーディングを用いてエンコードしなければならない (MUST)。同様に、要求のヘッダに "Content-Type" ヘッダが含まれている場合は、その値も <a class='info' href='#HTML401'>[HTML401]<span> (</span><span class='info'>W3C, “HTML 4.01 Specification,” .</span><span>)</span></a> の Section 17.13.4 に定められたエンコーディングでなければならない (MUST)。
</p>
<p>
要求メッセージの全てのキーは、その前に "openid." プレフィックスを付加しなければならない (MUST)。このプレフィックスを付加することにより、OpenID 認証メッセージとともに受け渡される他のパラメータとの干渉を回避できる。メッセージを POST で送るとき、OpenID パラメータは常に POST ボディに格納して送り、POST ボディから抽出しなければならない (MUST)。
</p>
<p>
HTTP 要求 (GET または POST) として送られるメッセージは全て、以下のフィールドを含んでいなければならない (MUST)。
</p>
<ul class="text">
<li>
openid.ns
<blockquote class="text">
<p>
値: "http://specs.openid.net/auth/2.0"
</p>
<p>
要求が OpenID Authentication 2.0 として有効な要求であるためには、上記の値が存在していなければならない (MUST)。仕様の将来版においては、メッセージ受信者が要求を適切に解釈できるように、異なる値が定義される場合もある。
</p>
<p>
この値が存在しない、あるいは "http://openid.net/signon/1.1" 、"http://openid.net/signon/1.0" のどちらかの値が設定されている場合、そのメッセージの解釈には、<a class='info' href='#compat_mode'>OpenID Authentication 1.1 互換モード<span> (</span><span class='info'>OpenID Authentication 1.1 との互換性</span><span>)</span></a>を用いるべきである (SHOULD)。
</p>
</blockquote>
</li>
<li>
openid.mode
<blockquote class="text">
<p>
値: メッセージタイプごとに個別に指定。
</p>
<p>
"openid.mode" パラメータを用いることによって、メッセージ受信者は、処理中のメッセージの種類を知ることができる。"openid.mode" がない場合、メッセージ処理側は、その要求が OpenID メッセージではないと見なすべきである (SHOULD)。
</p>
</blockquote>
</li>
</ul><p>
</p>
<p>
このモデルは、ユーザエージェントから RP に送られるメッセージ、ユーザエージェントから OP に送られるメッセージ、そして RP から OP に送られるメッセージにも適用される。
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1.3"></a><h3>4.1.3.
用例</h3>
<p>
参考
</p>
<p>
下記は、次の情報のエンコード例である。
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
キー | 値
--------+---------------------------
mode | error
error | This is an example message
</pre></div>
<p>
エンコードされたキー・バリュー形式：
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>mode:error
error:This is an example message
</pre></div>
<p>
HTTP POST ボディまたは URL のクエリ文字列に含まれるときなど x-www-urlencoded の場合 (<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: 0; 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" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.2"></a><h3>4.2.
整数表現</h3>
<p>
任意精度整数は、ビッグエンディアン符号付き 2 の補数表現バイナリ文字列にエンコードしなければならない (MUST)。以後 "btwoc" は、任意精度整数を引数とし、最も短いビッグエンディアン 2 の補数表現を返す関数とする。Diffie-Hellman 鍵交換で用いる整数は全て、正の数とする。つまり、2 の補数表現の最上位ビットはゼロでなければならない (MUST)。そうでない場合、文字列の先頭にゼロバイトを付加する実装をしなければならない (MUST)。
</p>
<p> 参考例:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
10 進数表現 | btwoc文字列表現
---------------+----------------------------
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" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
通信形式</h3>
<a name="direct_comm"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1.
直接通信 (Direct Communication)</h3>
<p>
直接通信は、OP エンドポイント URL に対し、RP 側から開始され、<a class='info' href='#associations'>アソシエーションの確立<span> (</span><span class='info'>アソシエーションの確立</span><span>)</span></a>および<a class='info' href='#check_auth'>認証アサーションの検証<span> (</span><span class='info'>OpenID プロバイダを通じた直接検証</span><span>)</span></a>のために用いられる。
</p>
<a name="direct_request"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1.1"></a><h3>5.1.1.
直接要求 (Direct Request)</h3>
<p>
メッセージは、<a class='info' href='#http_encoding'>Section 4.1.2<span> (</span><span class='info'>HTTP エンコーディング</span><span>)</span></a> で指定した通り、POST ボディとしてエンコードしなければならない (MUST)。
</p>
<p>
直接要求は全て HTTP POST であり、そのため、<a class='info' href='#http_encoding'>Section 4.1.2<span> (</span><span class='info'>HTTP エンコーディング</span><span>)</span></a> で示した必須フィールドを含む。
</p>
<a name="direct_response"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1.2"></a><h3>5.1.2.
直接応答 (Direct Response)</h3>
<p>
<a class='info' href='#direct_request'>直接要求<span> (</span><span class='info'>直接要求 (Direct Request)</span><span>)</span></a>への応答のボディは、<a class='info' href='#kvform'>キー・バリュー形式<span> (</span><span class='info'>キー・バリュー形式エンコーディング</span><span>)</span></a>の中の HTTP 応答ボディで構成される。応答の content-type は、"text/plain" とすべきである (SHOULD)。
</p>
<p>
キー・バリュー形式のメッセージは全て、以下のフィールドを含まなければならない (MUST)。
</p>
<ul class="text">
<li>
ns
<blockquote class="text">
<p>
値: "http://specs.openid.net/auth/2.0"
</p>
<p>
応答が OpenID 2.0 として有効な応答であるためには、上記の値が存在していなければならない (MUST)。仕様の将来版においては、メッセージ受信者が応答を適切に解釈できるように、異なる値が定義される場合もある。
</p>
<p>
この値が存在しない、あるいは "http://openid.net/signon/1.1"、"http://openid.net/signon/1.0" のどちらかの値が設定されている場合、そのメッセージの解釈には、<a class='info' href='#compat_mode'>OpenID Authentication 1.1 互換モード<span> (</span><span class='info'>OpenID Authentication 1.1 との互換性</span><span>)</span></a>を用いるべきである (SHOULD)。
</p>
</blockquote>
</li>
</ul><p>
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1.2.1"></a><h3>5.1.2.1.
成功時の応答 (Successful Responses)</h3>
<p>
サーバが有効な要求を受け取ったときは、HTTP ステータスコード 200 の応答を送らなければならない (MUST)。
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1.2.2"></a><h3>5.1.2.2.
エラー時の応答 (Error Responses)</h3>
<p>
不正な要求があった場合や無効な引数が含まれていた場合、サーバは、HTTP ステータスコード 400 を含む応答を送らなければならない (MUST)。応答のボディは、以下のフィールドを含む<a class='info' href='#kvform'>キー・バリュー形式<span> (</span><span class='info'>キー・バリュー形式エンコーディング</span><span>)</span></a>メッセージでなければならない (MUST):
</p>
<p>
</p>
<ul class="text">
<li>
ns
<blockquote class="text">
<p>
<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>
値: 人間が解読可能なメッセージ。エラーの原因を示す。
</p>
</blockquote>
</li>
<li>
contact
<blockquote class="text">
<p>
値: (オプション) サーバ管理者の連絡先。連絡先は、人間に対して表示するためのものなので、どのような形で記述してもよい。
</p>
</blockquote>
</li>
<li>
reference
<blockquote class="text">
<p>
値: (オプション) サポートチケット番号やニュースブログへの URL などの参照トークン。
</p>
</blockquote>
</li>
</ul><p>
OP は、この応答に追加フィールドを追加してもよい (MAY)。
</p>
<a name="indirect_comm"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2.
間接通信 (Indirect Communication)</h3>
<p>
間接通信では、ユーザエージェントを経由してメッセージの受け渡しを行う。間接通信は、RP、OP のいずれからでも開始することができる。間接通信は、<a class='info' href='#requesting_authentication'>認証要求<span> (</span><span class='info'>認証要求</span><span>)</span></a>および<a class='info' href='#responding_to_authentication'>認証応答<span> (</span><span class='info'>認証要求に対する応答</span><span>)</span></a>のために用いられる。
</p>
<p>
間接通信には、HTTP リダイレクトと HTML フォーム送信の二つの方法がある。フォーム送信もリダイレクトも、送信側が受信側の URL を知っていること、そして受信側の URL が <a class='info' href='#http_encoding'>Section 4.1.2<span> (</span><span class='info'>HTTP エンコーディング</span><span>)</span></a> で指定されているような、間接メッセージの受信を想定していることが求められる。通信を開始する側が、機能、メッセージサイズ、その他の外部要因に応じて適切な間接通信の方法を選択する。
</p>
<p>
全ての間接メッセージは HTTP 要求として受信され、そのため、<a class='info' href='#http_encoding'>Section 4.1.2<span> (</span><span class='info'>HTTP エンコーディング</span><span>)</span></a> で示した必須フィールドを含む。
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2.1"></a><h3>5.2.1.
HTTP リダイレクト</h3>
<p>
データは、302、303 または 307 HTTP リダイレクトを発行することによって、エンドユーザのユーザエージェントに転送できる。リダイレクト URL は受信側の URL で、<a class='info' href='#http_encoding'>Section 4.1.2<span> (</span><span class='info'>HTTP エンコーディング</span><span>)</span></a> で指定されている通り、クエリ文字列に OpenID 認証メッセージが付加されている。
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2.2"></a><h3>5.2.2.
HTML フォームリダイレクト</h3>
<p>
キーと値とのマッピングを転送するには、HTML フォームエレメントを含む HTML ページをユーザエージェントに戻す。フォーム送信は、JavaScript を用いるなどして自動化してもよい (MAY)。
</p>
<p>
<form> エレメントの "action" 属性値は、受信側の URL でなければならない (MUST)。それぞれのキー・バリューのペアは、<input> エレメントとしてフォームに含まれていなければならない (MUST)。フォーム送信を行なうとき、<a class='info' href='#http_encoding'>Section 4.1.2<span> (</span><span class='info'>HTTP エンコーディング</span><span>)</span></a> で指定されている通りにユーザエージェントがメッセージを生成するように、キーは "name" 属性として、値は "value" 属性としてエンコードしなければならない (MUST)。フォームは送信ボタンを含まなければならない (MUST)。
</p>
<a name="indirect_error"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2.3"></a><h3>5.2.3.
エラー時の間接応答</h3>
<p>
不正な要求があった場合や無効な引数が含まれていた場合、OP は、ユーザエージェントを "openid.return_to" URL 値にリダイレクトしなければならない (MUST)。ただし、値が存在し、その値が有効な URL である場合に限る。
</p>
<p>
</p>
<ul class="text">
<li>
openid.ns
<blockquote class="text">
<p>
<a class='info' href='#http_encoding'>Section 4.1.2<span> (</span><span class='info'>HTTP エンコーディング</span><span>)</span></a> で指定した通り。
</p>
</blockquote>
</li>
<li>
openid.mode
<blockquote class="text">
<p>
値: "error"
</p>
</blockquote>
</li>
<li>
openid.error
<blockquote class="text">
<p>
値: 人間が解読可能なメッセージ。エラーの原因を示す。
</p>
</blockquote>
</li>
<li>
openid.contact
<blockquote class="text">
<p>
値: (オプション) サーバ管理者の連絡先。連絡先は、人間に対して表示するためのものなので、どのような形で記述してもよい。
</p>
</blockquote>
</li>
<li>
openid.reference
<blockquote class="text">
<p>
値: (オプション) サポートチケット番号やニュースブログへの URL などの参照トークン。
</p>
</blockquote>
</li>
</ul><p>
サーバは、この応答に追加の鍵を追加してもよい (MAY)。
</p>
<p>
RP が不正なメッセージや無効なメッセージを受け取った場合、もしくは、"openid.return_to" が存在しなかったり、その値が有効な URL ではなかったりした場合、サーバはエンドユーザに応答を戻し、エラーが生じ、処理が継続できないことを示すべきである (SHOULD)。
</p>
<a name="generating_signatures"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
署名の生成</h3>
<p>
アソシエーションは、OpenID 認証メッセージに署名するために使用するメッセージ認証コード (MAC) 鍵として用いるのが最も一般的である。
</p>
<p>
MAC 鍵を生成するときは、<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)。
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.1"></a><h3>6.1.
署名の生成手順</h3>
<p>
署名の生成手順は、以下の通りである。
</p>
<ol class="text">
<li>
署名すべきメッセージに応じて、署名すべきキーのリストを決定する (<a class='info' href='#positive_assertions'>Section 10.1<span> (</span><span class='info'>肯定アサーション</span><span>)</span></a> 参照)。署名すべきキーのリストは、メッセージの一部でなければならない (MUST)。リストは "openid.signed" キーとともに格納される。値は、"openid." プレフィックスを削除したコンマ区切りのキーのリストである。このアルゴリズムは、"openid." で始まるキーの署名にのみ用いることができる。
</li>
<li>
"openid.signed" に示された順序で、署名すべきキーのリストそれぞれについて、メッセージ中から "openid." で始まり同じキーを持つ値を探す。
</li>
<li>
署名すべキーと値のペアのリストを、<a class='info' href='#kvform'>キー・バリュー形式エンコーディング<span> (</span><span class='info'>キー・バリュー形式エンコーディング</span><span>)</span></a>でエンコードしてオクテット文字列に変換する。
</li>
<li>
<a class='info' href='#associations'>アソシエーション形式<span> (</span><span class='info'>アソシエーションの確立</span><span>)</span></a>から<a class='info' href='#sign_algos'>署名アルゴリズム<span> (</span><span class='info'>署名アルゴリズム</span><span>)</span></a>を決定する。その署名アルゴリズムをオクテット文字列に適用する。
</li>
</ol><p>
</p>
<a name="sign_algos"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.2"></a><h3>6.2.
署名アルゴリズム</h3>
<p>
OpenID 認証は、以下のふたつの署名アルゴリズムをサポートしている。
</p>
<ul class="text">
<li>HMAC-SHA1 - 160 ビット鍵長 (<a class='info' href='#RFC2104'>[RFC2104]<span> (</span><span class='info'>Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .</span><span>)</span></a> および <a class='info' href='#RFC3174'>[RFC3174]<span> (</span><span class='info'>Eastlake, D. and P. Jones, “US Secure Hash Algorithm 1 (SHA1),” .</span><span>)</span></a>)
</li>
<li>HMAC-SHA256 - 256 ビット鍵長 (<a class='info' href='#RFC2104'>[RFC2104]<span> (</span><span class='info'>Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .</span><span>)</span></a> および <a class='info' href='#FIPS180-2'>[FIPS180‑2]<span> (</span><span class='info'>U.S. Department of Commerce and National Institute of Standards and Technology, “Secure Hash Signature Standard,” .</span><span>)</span></a>)
</li>
</ul><p>
サポートされている場合は、HMAC-SHA256 の使用を推奨する (RECOMMENDED)。
</p>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.
開始とディスカバリ</h3>
<a name="initiation"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.1"></a><h3>7.1.
開始</h3>
<p>
OpenID 認証を開始するに当り、RP は、ユーザ入力識別子の入力フォームをエンドユーザに提示すべきである (SHOULD)。
</p>
<p>
フォームが OpenID フォームであることが自動的に判断できるように、フォームフィールドの "name" 属性値は、"openid_identifier" であるべきである (SHOULD)。この属性に適切な値が設定されていないと、ブラウザの拡張機能など OpenID 認証をサポートするソフトウェアが RP のサポートを検出できないこともある。
</p>
<a name="normalization"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.2"></a><h3>7.2.
正規化</h3>
<p>
エンドユーザの入力は、識別子へと正規化されなければならない (MUST)。その手順を以下に示す。
</p>
<p>
</p>
<ol class="text">
<li>
ユーザの入力がプレフィックス "xri://" で始まる場合は、XRI が正準形式で使用されるように、その部分を削除しなければならない (MUST)。
</li>
<li>
その結果得られた文字列の最初の文字が、<a class='info' href='#XRI_Syntax_2.0'>[XRI_Syntax_2.0]<span> (</span><span class='info'>Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .</span><span>)</span></a> Section 2.2.1 で定義されている XRI グローバルコンテキストシンボル (Global Context Symbol) ("=", "@", "+", "$", "!") または "(" である場合、入力は XRI として扱うべきである (SHOULD)。
</li>
<li>
そうでない場合、入力は、http URL として扱うべきである (SHOULD)。得られた文字列に "http" または "https" スキームが含まれていない場合は、識別子の先頭に "http://" という文字列を付加しなければならない (MUST)。URL にフラグメント部分が含まれている場合、フラグメントの区切り文字 "#" も合わせて、その部分を削除しなければならない (MUST)。詳しくは、<a class='info' href='#http_s_identifiers'>Section 11.5.2<span> (</span><span class='info'>HTTP および HTTPS URL 識別子</span><span>)</span></a> 参照。
</li>
<li>
その後、コンテンツを取得するときにリダイレクトを辿り、最終的な目的の URL に対して <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 6 に記されている規則を適用することによって、URL 識別子をさらに正規化しなければならない (MUST)。この最終 URL を、RP は主張識別子として記録し、<a class='info' href='#requesting_authentication'>認証要求<span> (</span><span class='info'>認証要求</span><span>)</span></a>時に使用しなければならない (MUST)。
</li>
</ol><p>
<a class='info' href='#normalization_example'>正規化例<span> (</span><span class='info'>正規化</span><span>)</span></a>参照。