-
Notifications
You must be signed in to change notification settings - Fork 4
/
openid-authentication.xml
4650 lines (4358 loc) · 251 KB
/
openid-authentication.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="info" ipr="full3978" docName="openid-authentication-2_0.xml">
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc private="Final" ?>
<front>
<title>OpenID Authentication 2.0 - 最終版</title>
<author initials="" surname="[email protected]" fullname="[email protected]">
<organization />
</author>
<date month="December" year="2007"/>
<abstract>
<t>
OpenID 認証は、エンドユーザが識別子 (Identifier) を管理していることを証明する方法を提供するものである。OpenID 認証を利用すれば、リライングパーティー (Relying Party、以下 RP) はエンドユーザのパスワードやメールアドレスなどにアクセスする必要がなくなる。
<!--
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.
-->
</t>
<t>
OpenID は、分散方式であり、RP や OpenID プロバイダ (OpenID Provider 、以下 OP) の承認・登録を行なう中央集権的な機関は存在しない。エンドユーザは利用する OP を自由に選択することができ、OP を変更しても自身の識別子をそのまま継続して利用することができる。
<!--
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.
-->
</t>
<t>
プロトコル自体は JavaScript や最新ブラウザを必要としないが、AJAX を利用しても認証 (authentication) の仕組みは上手く機能する。つまり、エンドユーザは、現在のウェブページから離れずに、RP に自らの身元を証明できるのである。
<!--
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.
-->
</t>
<t>
OpenID 認証は、HTTP(S) の標準的な要求／応答だけを用いているため、ユーザエージェント (User-Agent) やクライアントソフトウェアが特別な機能を備えている必要はない。OpenID は、cookie をはじめ、RP や OP 特有のセッション管理方法には全く依存していない。ユーザエージェントの機能拡張により、エンドユーザの操作を簡素化できるが、プロトコル利用上は必ずしも必要ではない。
<!--
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.
-->
</t>
<t>
プロファイル情報の交換や、本仕様に記されていないその他の情報の交換については、本プロトコル上にサービスタイプを追加し、仕組みを構築することで実現可能である。OpenID 認証は、ポータブル (環境に依存せずに使用可能) でユーザセントリックなデジタルアイデンティティを、自由かつ分散的な方式で実現するための基盤サービスを提供するために設計された。
<!--
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.
-->
</t>
</abstract>
</front>
<middle>
<section title="要求記法および規則">
<!-- section title="Requirements Notation and Conventions" -->
<t>
本文書で用いられる各キーワード「MUST (しなければならない)」、「MUST NOT (してはならない)」、「REQUIRED (必須である)」、「SHALL (するものとする)」、「SHALL NOT (しないものとする)」、「SHOULD (すべきである)」、「SHOULD NOT (すべきではない)」、「RECOMMENDED (推奨される)」、「MAY (してもよい)」、「OPTIONAL (任意である)」は <xref target="RFC2119"/> で述べられている通りに解釈されるべきものである。
<!--
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>
本文書では、書いてあるままに解釈されるべき値は引用符 ("") で囲んで示している。プロトコルメッセージの中でこれらの値を使用する場合は、値の一部として引用符を用いてはならない (MUST NOT)。
<!--
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 title="用語" anchor="terminology">
<!--
<section title="Terminology" anchor="terminology">
-->
<t>
<list style="hanging">
<!-- t hangText="Identifier:" -->
<t hangText="識別子 (Identifier):">
識別子は、"http" または "https" URI (本文書では、通例に従い "URL" と表記)、もしくは <xref target="XRI_Syntax_2.0" >XRI</xref> のいずれかである。本文書では、様々な種類の識別子を定義するが、それぞれ異なるコンテキストでの使用を目的としている。
<!--
An Identifier is either a "http" or "https" URI, (commonly
referred to as a "URL" within this document), or an <xref
target="XRI_Syntax_2.0" >XRI</xref>. This document defines
various kinds of Identifiers, designed for use in different
contexts.
-->
</t>
<!-- t hangText="User-Agent:" -->
<t hangText="ユーザエージェント (User-Agent):">
HTTP/1.1 <xref target="RFC2616"/> を実装したエンドユーザのウェブブラウザ。
<!--
The end user's Web browser which implements HTTP/1.1 <xref
target="RFC2616"/>.
-->
</t>
<!-- t hangText="Relying Party:" -->
<t hangText="リライングパーティー (Relying Party):">
略語は RP。エンドユーザが識別子を管理しているという証明を要求するウェブアプリケーション。
<!--
RP. A Web application that wants proof that the end user
controls an Identifier.
-->
</t>
<!-- t hangText="OpenID Provider:" -->
<t hangText="OpenID プロバイダ (OpenID Provider):">
略語は OP。エンドユーザが識別子を管理しているというアサーション (assertion) を得るために RP が依存する OpenID 認証サーバ。
<!--
OP. An OpenID Authentication server on which a Relying
Party relies for an assertion that the end user controls
an Identifier.
-->
</t>
<!-- t hangText="OP Endpoint URL:" -->
<t hangText="OP エンドポイントURL (OP Endpoint URL):">
OpenID 認証プロトコルメッセージを受け入れる URL で、ユーザ入力識別子 (User-Supplied Identifier) のディスカバリ (discovery) を実行することにより得られる。この値は、HTTP または HTTPS の絶対 URL でなければならない (MUST)。
<!--
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.
-->
</t>
<!-- t hangText="OP Identifier:" -->
<t hangText="OP 識別子 (OP Identifier):">
OP の識別子。
<!--
An Identifier for an OpenID Provider.
-->
</t>
<!-- t hangText="User-Supplied Identifier:" -->
<t hangText="ユーザ入力識別子 (User-Supplied Identifier):">
エンドユーザが RP に提示する識別子、または OP においてユーザが選択した識別子。プロトコルの開始 (initiation) フェーズでは、エンドユーザは、自らの識別子、OP 識別子のどちらを入力してもよい。OP 識別子を用いる場合、OP は、エンドユーザが RP に提示する識別子の選択を支援してもよい。
<!--
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.
-->
</t>
<!-- t hangText="Claimed Identifier:" -->
<t hangText="主張識別子 (Claimed Identifier):">
エンドユーザが自らのものであると主張する識別子。プロトコル全体の狙いは、この主張を検証することにある。主張識別子は、以下のいずれかである。
<!--
An Identifier that the end user claims to own; the overall
aim of the protocol is verifying this claim. The Claimed
Identifier is either:
-->
<list style="symbols">
<t>
URL の場合、ユーザ入力識別子を<xref target="normalization">正規化</xref>することで得られる識別子。
<!--
The Identifier obtained by <xref target="normalization">
normalizing</xref> the User-Supplied Identifier, if it
was an URL.
-->
</t>
<t>
XRI の場合、<xref target="canonicalid">正準化 ID (CanonicalID)</xref>。
<!--
The <xref target="canonicalid">CanonicalID</xref>, if it
was an XRI.
-->
</t>
</list>
</t>
<!-- t hangText="OP-Local Identifier:" -->
<t hangText="OP ローカル識別子 (OP-Local Identifier):">
特定の OP でエンドユーザを識別するためにローカルに用いられる代替の識別子。必ずしもエンドユーザが管理しているものではない。
<!--
An alternate Identifier for an end user that is local to a
particular OP and thus not necessarily under the end user's
control.
-->
</t>
</list>
</t>
</section>
<!-- section title="Protocol Overview" -->
<section title="プロトコルの概要">
<t>
<list style="numbers">
<t>
エンドユーザは、ユーザエージェントを通じて RP にユーザ入力識別子を提示することによって、<xref target="initiation">認証を開始</xref>する。
<!--
The end user <xref target="initiation">initiates
authentication</xref> by presenting a User-Supplied Identifier
to the Relying Party via their User-Agent.
-->
</t>
<t>
ユーザ入力識別子を<xref target="normalization">正規化</xref>した後、RP はその<xref target="discovery">ディスカバリを実行</xref>し、エンドユーザが認証に用いる OP エンドポイント URL を確定する。ユーザ入力識別子は、OP 識別子である可能性があることに留意する必要があるが、この点については <xref target="discovered_info" /> で述べる。OP 識別子のときは、OP で主張識別子を選択することができる。また、<xref target="extensions">拡張仕様</xref>を利用して実用的な代替手段が取られている場合は、主張識別子を用いずにプロトコルを続行することもできる。
<!--
After <xref target="normalization">normalizing</xref> the
User-Supplied Identifier, the Relying Party <xref
target="discovery">performs discovery</xref> 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 <xref
target="discovered_info" />, 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 <xref
target="extensions">extension</xref>.
-->
</t>
<t>
(オプション)
RP と OP の間の<xref target="associations">アソシエーション (association)</xref> の確立は、<xref target="RFC2631">Diffie-Hellman 鍵交換</xref>を用いた共有秘密鍵の発行をもって行う。OP はその後のメッセージに署名するためにアソシエーションを用い、RP はこれらのメッセージを検証するためにアソシエーションを用いる。その結果、それぞれの認証要求／応答に続く署名検証のための直接要求を行なう必要がなくなる。
<!--
(optional)
The Relying Party and the OP establish an <xref
target="associations">association</xref> -- a shared
secret established using <xref
target="RFC2631">Diffie-Hellman Key Exchange</xref>. 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.
-->
</t>
<t>
RP は、エンドユーザのユーザエージェントを、OpenID <xref target="requesting_authentication">認証要求</xref>とともに OP にリダイレクトする。
<!--
The Relying Party redirects the end user's User-Agent to
the OP with an OpenID <xref
target="requesting_authentication">Authentication
request</xref>.
-->
</t>
<t>
OP は、エンドユーザが OpenID 認証の実行を許可されているかどうか、さらにエンドユーザが認証の実行を求めているかどうかを確定する。OP におけるエンドユーザの認証方法およびそのような認証に関わるポリシーは全て、本文書の対象範囲外である。
<!--
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.
-->
</t>
<t>
OP は、エンドユーザのユーザエージェントを、<xref target="positive_assertions">認証が承認された</xref>ことを示すアサーション、<xref target="negative_assertions">認証が失敗した</xref>ことを示すメッセージのどちらかとともに RP へリダイレクトする。
<!--
The OP redirects the end user's User-Agent back to the
Relying Party with either an assertion that <xref
target="positive_assertions">authentication is
approved</xref> or a message that <xref
target="negative_assertions">authentication failed</xref>.
-->
</t>
<t>
RP は、OP から受け取った情報を<xref target="verification">検証</xref>し、戻り URL (Return URL) のチェック、ディスカバリによって得られた情報の検証、ノンス (nonce) のチェックなどを行なう。また、アソシエーション確立時に発行した共有鍵、あるいは OP への直接要求のいずれかを用いて、署名を検証する。
<!--
The Relying Party <xref target="verification">verifies
</xref> 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.
-->
</t>
</list>
</t>
</section>
<!-- section title="Data Formats" -->
<section title="データフォーマット">
<!-- section title="Protocol Messages" -->
<section title="プロトコルメッセージ">
<t>
OpenID 認証プロトコルメッセージは、プレーンテキストのキーとプレーンテキストの値とをマッピングしたものである。キーおよび値には、Unicode 文字セット (UCS) を全て使用することができる。キーおよび値とバイト形式との間の変換が必要な場合は、<xref target="RFC3629">UTF-8</xref> を用いてエンコードしなければならない (MUST)。
<!--
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 <xref target="RFC3629">UTF-8</xref>.
-->
</t>
<t>
メッセージは、同じ名前のパラメータを複数含んではならない (MUST NOT)。
<!--
Messages MUST NOT contain multiple parameters with the same name.
-->
</t>
<t>
本文書に記されている OpenID メッセージのパラメータは、全て必須である (REQUIRED)。ただし、任意である (OPTIONAL) と明示されている場合は、その限りではない。
<!--
Throughout this document, all OpenID message parameters are
REQUIRED, unless specifically marked as OPTIONAL.
-->
</t>
<!-- section title="Key-Value Form Encoding" anchor="kvform" -->
<section title="キー・バリュー形式エンコーディング" anchor="kvform">
<t>
キー・バリュー形式のメッセージは、一連の行からなる。各行の最初はキーで、その後ろにコロンを付加し、キーと関連する値が続く。各行は、一個の改行文字 (UCS 文字コード番号 10, "\n") で終わる。キーまたは値は、改行文字を含んではならない (MUST NOT)。また、キーは、コロンを含んではならない (MUST NOT)。
<!--
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.
-->
</t>
<t>
空白を含む追加文字は、コロンまたは改行文字の前後に追加してはならない (MUST NOT)。メッセージからバイト文字列を生成するときは、UTF-8 でエンコードしなければならない (MUST)。
<!--
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.
-->
</t>
<t>
キー・バリュー形式エンコーディングは、署名計算および RP への<xref target="direct_response">直接応答</xref>に利用される。
<!--
Key-Value Form encoding is used for signature calculation
and for <xref target="direct_response">direct
responses</xref> to Relying Parties.
-->
</t>
</section>
<!-- section title="HTTP Encoding" anchor="http_encoding" -->
<section title="HTTP エンコーディング" anchor="http_encoding">
<t>
HTTP サーバにメッセージを送るときは、<xref target="HTML401" /> の Section 17.13.4 に定められるフォームエンコーディングを用いてエンコードしなければならない (MUST)。同様に、要求のヘッダに "Content-Type" ヘッダが含まれている場合は、その値も <xref target="HTML401" /> の Section 17.13.4 に定められたエンコーディングでなければならない (MUST)。
<!--
When a message is sent to an HTTP server, it MUST be encoded
using a form encoding specified in Section 17.13.4 of
<xref target="HTML401" />. Likewise, if the "Content-Type"
header is included in the request headers, its value MUST
also be such an encoding.
-->
</t>
<t>
要求メッセージの全てのキーは、その前に "openid." プレフィックスを付加しなければならない (MUST)。このプレフィックスを付加することにより、OpenID 認証メッセージとともに受け渡される他のパラメータとの干渉を回避できる。メッセージを POST で送るとき、OpenID パラメータは常に POST ボディに格納して送り、POST ボディから抽出しなければならない (MUST)。
<!--
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.
-->
</t>
<t>
HTTP 要求 (GET または POST) として送られるメッセージは全て、以下のフィールドを含んでいなければならない (MUST)。
<!--
All messages that are sent as HTTP requests (GET or POST)
MUST contain the following fields:
-->
<list style='symbols'>
<t>
openid.ns
<list style='empty'>
<t>
<!-- Value -->値: "http://specs.openid.net/auth/2.0"
</t>
<t>
要求が OpenID Authentication 2.0 として有効な要求であるためには、上記の値が存在していなければならない (MUST)。仕様の将来版においては、メッセージ受信者が要求を適切に解釈できるように、異なる値が定義される場合もある。
<!--
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.
-->
</t>
<t>
この値が存在しない、あるいは "http://openid.net/signon/1.1" 、"http://openid.net/signon/1.0" のどちらかの値が設定されている場合、そのメッセージの解釈には、<xref target="compat_mode">OpenID Authentication 1.1 互換モード</xref>を用いるべきである (SHOULD)。
<!--
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 <xref
target="compat_mode">OpenID Authentication 1.1
Compatibility mode</xref>.
-->
</t>
</list>
</t>
<t>
openid.mode
<list style='empty'>
<t>
値: メッセージタイプごとに個別に指定。
<!-- Value: Specified individually for each message type. -->
</t>
<t>
"openid.mode" パラメータを用いることによって、メッセージ受信者は、処理中のメッセージの種類を知ることができる。"openid.mode" がない場合、メッセージ処理側は、その要求が OpenID メッセージではないと見なすべきである (SHOULD)。
<!--
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.
-->
</t>
</list>
</t>
</list>
</t>
<t>
このモデルは、ユーザエージェントから RP に送られるメッセージ、ユーザエージェントから OP に送られるメッセージ、そして RP から OP に送られるメッセージにも適用される。
<!--
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.
-->
</t>
</section>
<!-- section title="Example" -->
<section title="用例">
<t>
<!-- Non-normative -->
参考
</t>
<figure>
<preamble>
下記は、次の情報のエンコード例である。
<!--
The following examples encode the following information:
-->
</preamble>
<!-- artwork><![CDATA[
Key | Value
--------+---------------------------
mode | error
error | This is an example message
]]>
</artwork -->
<artwork><![CDATA[
キー | 値
--------+---------------------------
mode | error
error | This is an example message
]]>
</artwork>
</figure>
<figure>
<preamble>
エンコードされたキー・バリュー形式：
<!--
Key-Value Form encoded:
-->
</preamble>
<artwork><![CDATA[mode:error
error:This is an example message
]]>
</artwork>
</figure>
<figure>
<preamble>
HTTP POST ボディまたは URL のクエリ文字列に含まれるときなど x-www-urlencoded の場合 (<xref target="RFC3986" /> Section 3) ：
<!--
x-www-urlencoded, as in a HTTP POST body or in a URL's
query string (<xref target="RFC3986" /> section 3):
-->
</preamble>
<artwork>openid.mode=error&openid.error=This%20is%20an%20example%20message</artwork>
</figure>
</section>
</section>
<!-- section title="Integer Representations" anchor="btwoc" -->
<section title="整数表現" anchor="btwoc">
<t>
任意精度整数は、ビッグエンディアン符号付き 2 の補数表現バイナリ文字列にエンコードしなければならない (MUST)。以後 "btwoc" は、任意精度整数を引数とし、最も短いビッグエンディアン 2 の補数表現を返す関数とする。Diffie-Hellman 鍵交換で用いる整数は全て、正の数とする。つまり、2 の補数表現の最上位ビットはゼロでなければならない (MUST)。そうでない場合、文字列の先頭にゼロバイトを付加する実装をしなければならない (MUST)。
<!--
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.
-->
</t>
<figure>
<preamble><!-- Non-normative example --> 参考例:</preamble>
<!--
Base 10 number | btwoc string representation
-->
<artwork><![CDATA[
10 進数表現 | btwoc文字列表現
---------------+----------------------------
0 | "\x00"
127 | "\x7F"
128 | "\x00\x80"
255 | "\x00\xFF"
32768 | "\x00\x80\x00"
]]>
</artwork>
</figure>
</section>
</section>
<!-- section title="Communication Types" -->
<section title="通信形式">
<!-- section title="Direct Communication"
anchor="direct_comm" -->
<section title="直接通信 (Direct Communication)"
anchor="direct_comm">
<t>
直接通信は、OP エンドポイント URL に対し、RP 側から開始され、<xref target="associations">アソシエーションの確立</xref>および<xref target="check_auth">認証アサーションの検証</xref>のために用いられる。
<!--
Direct communication is initiated by a Relying Party to an
OP endpoint URL. It is used for <xref
target="associations">establishing associations</xref> and
<xref target="check_auth">verifying authentication
assertions</xref>.
-->
</t>
<!-- section title="Direct Request" anchor="direct_request" -->
<section title="直接要求 (Direct Request)" anchor="direct_request">
<t>
メッセージは、<xref target="http_encoding" /> で指定した通り、POST ボディとしてエンコードしなければならない (MUST)。
<!--
The message MUST be encoded as a POST body, as specified
by <xref target="http_encoding" />.
-->
</t>
<t>
直接要求は全て HTTP POST であり、そのため、<xref target="http_encoding" /> で示した必須フィールドを含む。
<!--
All direct requests are HTTP POSTs, and so
contain the required fields listed in <xref
target="http_encoding" />.
-->
</t>
</section>
<!-- section title="Direct Response" anchor="direct_response" -->
<section title="直接応答 (Direct Response)" anchor="direct_response">
<t>
<xref target="direct_request">直接要求</xref>への応答のボディは、<xref target="kvform">キー・バリュー形式</xref>の中の HTTP 応答ボディで構成される。応答の content-type は、"text/plain" とすべきである (SHOULD)。
<!--
The body of a response to a <xref
target="direct_request">Direct Request</xref> consists of
an HTTP Response body in <xref target="kvform">Key-Value
Form</xref>. The content-type of the response SHOULD be
"text/plain".
-->
</t>
<t>
キー・バリュー形式のメッセージは全て、以下のフィールドを含まなければならない (MUST)。
<!--
All Key-Value form message MUST contain the following field:
-->
<list style='symbols'>
<t>
ns
<list style='empty'>
<t>
<!-- Value -->値: "http://specs.openid.net/auth/2.0"
</t>
<t>
応答が OpenID 2.0 として有効な応答であるためには、上記の値が存在していなければならない (MUST)。仕様の将来版においては、メッセージ受信者が応答を適切に解釈できるように、異なる値が定義される場合もある。
<!--
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.
-->
</t>
<t>
この値が存在しない、あるいは "http://openid.net/signon/1.1"、"http://openid.net/signon/1.0" のどちらかの値が設定されている場合、そのメッセージの解釈には、<xref target="compat_mode">OpenID Authentication 1.1 互換モード</xref>を用いるべきである (SHOULD)。
<!--
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 <xref
target="compat_mode">OpenID Authentication 1.1
Compatibility mode</xref>.
-->
</t>
</list>
</t>
</list>
</t>
<!-- section title="Successful Responses" -->
<section title="成功時の応答 (Successful Responses)">
<t>
サーバが有効な要求を受け取ったときは、HTTP ステータスコード 200 の応答を送らなければならない (MUST)。
<!--
A server receiving a valid request MUST send a
response with an HTTP status code of 200.
-->
</t>
</section>
<!-- section title="Error Responses" -->
<section title="エラー時の応答 (Error Responses)">
<t>
不正な要求があった場合や無効な引数が含まれていた場合、サーバは、HTTP ステータスコード 400 を含む応答を送らなければならない (MUST)。応答のボディは、以下のフィールドを含む<xref target="kvform">キー・バリュー形式</xref>メッセージでなければならない (MUST):
<!--
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 <xref
target="kvform">Key-Value Form</xref> message with the
following fields:
-->
</t>
<t>
<list style='symbols'>
<t>
ns
<list style='empty'>
<t>
<xref target="direct_response" /> で指定した通り。
<!--
As specified in <xref target="direct_response" />.
-->
</t>
</list>
</t>
<t>
error
<list style='empty'>
<t>
<!--
Value: A human-readable message indicating the cause
of the error.
-->
値: 人間が解読可能なメッセージ。エラーの原因を示す。
</t>
</list>
</t>
<t>
contact
<list style='empty'>
<t>
値: (オプション) サーバ管理者の連絡先。連絡先は、人間に対して表示するためのものなので、どのような形で記述してもよい。
<!--
Value: (optional) Contact address for the
administrator of the server. The contact address
may take any form, as it is intended to be
displayed to a person.
-->
</t>
</list>
</t>
<t>
reference
<list style='empty'>
<t>
値: (オプション) サポートチケット番号やニュースブログへの URL などの参照トークン。
<!--
Value: (optional) A reference token, such
as a support ticket number or a URL to a news
blog, etc.
-->
</t>
</list>
</t>
</list>
OP は、この応答に追加フィールドを追加してもよい (MAY)。
<!--
The OP MAY add additional fields to this response.
-->
</t>
</section>
</section>
</section>
<!-- section title="Indirect Communication"
anchor="indirect_comm" -->
<section title="間接通信 (Indirect Communication)"
anchor="indirect_comm">
<t>
間接通信では、ユーザエージェントを経由してメッセージの受け渡しを行う。間接通信は、RP、OP のいずれからでも開始することができる。間接通信は、<xref target="requesting_authentication">認証要求</xref>および<xref target="responding_to_authentication">認証応答</xref>のために用いられる。
<!--
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 <xref
target="requesting_authentication">authentication
requests</xref> and <xref
target="responding_to_authentication">authentication
responses</xref>.
-->
</t>
<t>
間接通信には、HTTP リダイレクトと HTML フォーム送信の二つの方法がある。フォーム送信もリダイレクトも、送信側が受信側の URL を知っていること、そして受信側の URL が <xref target="http_encoding"/> で指定されているような、間接メッセージの受信を想定していることが求められる。通信を開始する側が、機能、メッセージサイズ、その他の外部要因に応じて適切な間接通信の方法を選択する。
<!--
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 <xref target="http_encoding"
/>. The initiator of the communication chooses which method
of indirect communication is appropriate depending on
capabilities, message size, or other external factors.
-->
</t>
<t>
全ての間接メッセージは HTTP 要求として受信され、そのため、<xref target="http_encoding"/> で示した必須フィールドを含む。
<!--
All indirect messages arrive as HTTP requests, and so
contain the required fields listed in <xref
target="http_encoding" />.
-->
</t>
<!-- section title="HTTP Redirect" -->
<section title="HTTP リダイレクト">
<t>
データは、302、303 または 307 HTTP リダイレクトを発行することによって、エンドユーザのユーザエージェントに転送できる。リダイレクト URL は受信側の URL で、<xref target="http_encoding" /> で指定されている通り、クエリ文字列に OpenID 認証メッセージが付加されている。
<!--
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
<xref target="http_encoding" />.
-->
</t>
</section>
<!-- section title="HTML FORM Redirection" -->
<section title="HTML フォームリダイレクト">
<t>
キーと値とのマッピングを転送するには、HTML フォームエレメントを含む HTML ページをユーザエージェントに戻す。フォーム送信は、JavaScript を用いるなどして自動化してもよい (MAY)。
<!--
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.
-->
</t>
<t>
<form> エレメントの "action" 属性値は、受信側の URL でなければならない (MUST)。それぞれのキー・バリューのペアは、<input> エレメントとしてフォームに含まれていなければならない (MUST)。フォーム送信を行なうとき、<xref target="http_encoding"/> で指定されている通りにユーザエージェントがメッセージを生成するように、キーは "name" 属性として、値は "value" 属性としてエンコードしなければならない (MUST)。フォームは送信ボタンを含まなければならない (MUST)。
<!--
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 <xref
target="http_encoding"/> when the form is submitted. The
form MUST include a submit button.
-->
</t>
</section>
<!-- section title="Indirect Error Responses" anchor="indirect_error" -->
<section title="エラー時の間接応答" anchor="indirect_error">
<t>
不正な要求があった場合や無効な引数が含まれていた場合、OP は、ユーザエージェントを "openid.return_to" URL 値にリダイレクトしなければならない (MUST)。ただし、値が存在し、その値が有効な URL である場合に限る。
<!--
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.
-->
</t>
<t>
<list style='symbols'>
<t>
openid.ns
<list style='empty'>
<t>
<!-- As specified in <xref target="http_encoding" />. -->
<xref target="http_encoding" /> で指定した通り。
</t>
</list>
</t>
<t>
openid.mode
<list style='empty'>
<t>
<!-- Value -->値: "error"
</t>
</list>
</t>
<t>
openid.error
<list style='empty'>
<t>
値: 人間が解読可能なメッセージ。エラーの原因を示す。
<!--
Value: A human-readable message indicating the cause
of the error.
-->
</t>
</list>
</t>
<t>
openid.contact
<list style='empty'>
<t>
値: (オプション) サーバ管理者の連絡先。連絡先は、人間に対して表示するためのものなので、どのような形で記述してもよい。
<!--
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.
-->
</t>
</list>
</t>
<t>
openid.reference
<list style='empty'>
<t>
値: (オプション) サポートチケット番号やニュースブログへの URL などの参照トークン。
<!--
Value: (optional) A reference token, such as a
support ticket number or a URL to a news blog,
etc.
-->
</t>
</list>
</t>
</list>
サーバは、この応答に追加の鍵を追加してもよい (MAY)。
<!-- The server MAY add additional keys to this response. -->
</t>
<t>
RP が不正なメッセージや無効なメッセージを受け取った場合、もしくは、"openid.return_to" が存在しなかったり、その値が有効な URL ではなかったりした場合、サーバはエンドユーザに応答を戻し、エラーが生じ、処理が継続できないことを示すべきである (SHOULD)。
<!--
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.
-->
</t>
</section>
</section>
</section>
<section title="署名の生成" anchor="generating_signatures">
<!-- section title="Generating Signatures" anchor="generating_signatures" -->
<t>
アソシエーションは、OpenID 認証メッセージに署名するために使用するメッセージ認証コード (MAC) 鍵として用いるのが最も一般的である。
<!--
The most common usage of an association is as a Message
Authentication Code (MAC) key used to sign OpenID
Authentication messages.
-->
</t>
<t>
MAC 鍵を生成するときは、<xref target="RFC1750" /> に記されている勧告に従うべきである (SHOULD)。
<!--
When generating MAC keys, the recommendations in <xref
target="RFC1750" /> SHOULD be followed.
-->
</t>
<section title="署名の生成手順">
<!-- section title="Procedure" -->
<t>
署名の生成手順は、以下の通りである。
<!-- To generate a message signature: -->
<list style="numbers">
<t>
署名すべきメッセージに応じて、署名すべきキーのリストを決定する (<xref target="positive_assertions" /> 参照)。署名すべきキーのリストは、メッセージの一部でなければならない (MUST)。リストは "openid.signed" キーとともに格納される。値は、"openid." プレフィックスを削除したコンマ区切りのキーのリストである。このアルゴリズムは、"openid." で始まるキーの署名にのみ用いることができる。
<!--
Determine the list of keys to be signed, according to
the message to be signed (See <xref
target="positive_assertions" />). The list of keys to be
signed MUST be part of the message. The list is stored
with the key "openid.signed". The value is a
comma-separated list of keys, with the "openid." prefix
stripped. This algorithm is only capable of signing keys
that start with "openid."
-->
</t>
<t>
"openid.signed" に示された順序で、署名すべきキーのリストそれぞれについて、メッセージ中から "openid." で始まり同じキーを持つ値を探す。
<!--
Iterate through the list of keys to be signed in the
order they appear in "openid.signed" list. For each
key, find the value in the message whose key is equal to
the signed list key prefixed with "openid."
-->
</t>
<t>
署名すべキーと値のペアのリストを、<xref target="kvform">キー・バリュー形式エンコーディング</xref>でエンコードしてオクテット文字列に変換する。
<!--
Convert the list of key/value pairs to be signed to an
octet string by encoding with <xref
target="kvform">Key-Value Form Encoding</xref>.
-->
</t>
<t>
<xref target="associations">アソシエーション形式</xref>から<xref target="sign_algos">署名アルゴリズム</xref>を決定する。その署名アルゴリズムをオクテット文字列に適用する。
<!--
Determine the signature algorithm from the <xref
target="associations">association type</xref>. Apply
the <xref target="sign_algos">signature algorithm</xref>
to the octet string.
-->
</t>
</list>
</t>
</section>
<section title="署名アルゴリズム" anchor="sign_algos">
<!-- section title="Signature Algorithms" anchor="sign_algos" -->
<t>
OpenID 認証は、以下のふたつの署名アルゴリズムをサポートしている。
<!--
OpenID Authentication supports two signature algorithms:
-->
<list style="symbols">
<t>HMAC-SHA1 - 160 ビット鍵長 (<xref target="RFC2104" /> および <xref target="RFC3174" />)</t>
<t>HMAC-SHA256 - 256 ビット鍵長 (<xref target="RFC2104" /> および <xref target="FIPS180-2" />)</t>
<!--
<t>HMAC-SHA1 - 160 bit key length (<xref target="RFC2104" /> and <xref target="RFC3174" />)</t>
<t>HMAC-SHA256 - 256 bit key length (<xref target="RFC2104" /> and <xref target="FIPS180-2" /></t>
-->
</list>
サポートされている場合は、HMAC-SHA256 の使用を推奨する (RECOMMENDED)。
<!--
If supported, the use of HMAC-SHA256 is RECOMMENDED.
-->
</t>
</section>
</section>
<section title="開始とディスカバリ">
<!-- section title="Initiation and Discovery" -->
<section title="開始" anchor="initiation">
<!-- section title="Initiation" anchor="initiation" -->
<t>
OpenID 認証を開始するに当り、RP は、ユーザ入力識別子の入力フォームをエンドユーザに提示すべきである (SHOULD)。