-
Notifications
You must be signed in to change notification settings - Fork 17
/
openid-connect-4-identity-assurance-1_0.html
2019 lines (1934 loc) · 134 KB
/
openid-connect-4-identity-assurance-1_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 XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>OpenID Connect for Identity Assurance 1.0</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* 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.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents">
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction">
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Terminology">
<link href="#rfc.section.2" rel="Chapter" title="2 Scope and Requirements">
<link href="#rfc.section.3" rel="Chapter" title="3 Claims">
<link href="#rfc.section.3.1" rel="Chapter" title="3.1 Additional Claims about End-Users">
<link href="#rfc.section.3.2" rel="Chapter" title="3.2 txn Claim">
<link href="#rfc.section.4" rel="Chapter" title="4 Verified Data Representation">
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 verification Element">
<link href="#rfc.section.4.1.1" rel="Chapter" title="4.1.1 Evidence">
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 claims Element">
<link href="#rfc.section.5" rel="Chapter" title="5 Requesting Verified Claims">
<link href="#rfc.section.5.1" rel="Chapter" title="5.1 Requesting End-User Claims">
<link href="#rfc.section.5.2" rel="Chapter" title="5.2 Requesting Verification Data">
<link href="#rfc.section.5.3" rel="Chapter" title="5.3 Defining constraints on Verification Data">
<link href="#rfc.section.6" rel="Chapter" title="6 Examples">
<link href="#rfc.section.6.1" rel="Chapter" title="6.1 id_document">
<link href="#rfc.section.6.2" rel="Chapter" title="6.2 id_document + utility bill">
<link href="#rfc.section.6.3" rel="Chapter" title="6.3 Notified eID system (eIDAS)">
<link href="#rfc.section.6.4" rel="Chapter" title="6.4 Verified Claims in UserInfo Response">
<link href="#rfc.section.6.4.1" rel="Chapter" title="6.4.1 Request">
<link href="#rfc.section.6.4.2" rel="Chapter" title="6.4.2 UserInfo Response">
<link href="#rfc.section.6.5" rel="Chapter" title="6.5 Verified Claims in ID Tokens">
<link href="#rfc.section.6.5.1" rel="Chapter" title="6.5.1 Request">
<link href="#rfc.section.6.5.2" rel="Chapter" title="6.5.2 ID Token">
<link href="#rfc.section.6.6" rel="Chapter" title="6.6 Aggregated Claims">
<link href="#rfc.section.6.7" rel="Chapter" title="6.7 Distributed Claims">
<link href="#rfc.section.7" rel="Chapter" title="7 OP Metadata">
<link href="#rfc.section.8" rel="Chapter" title="8 Transaction-specific Purpose">
<link href="#rfc.section.9" rel="Chapter" title="9 Privacy Consideration">
<link href="#rfc.section.10" rel="Chapter" title="10 Security Considerations">
<link href="#rfc.section.11" rel="Chapter" title="11 Predefined Values">
<link href="#rfc.section.11.1" rel="Chapter" title="11.1 Trust Frameworks">
<link href="#rfc.section.11.2" rel="Chapter" title="11.2 Identity Documents">
<link href="#rfc.section.11.3" rel="Chapter" title="11.3 Verification Methods">
<link href="#rfc.section.12" rel="Chapter" title="12 JSON Schema">
<link href="#rfc.references" rel="Chapter" title="13 References">
<link href="#rfc.references.1" rel="Chapter" title="13.1 Normative References">
<link href="#rfc.references.2" rel="Chapter" title="13.2 Informative References">
<link href="#rfc.references.3" rel="Chapter" title="13.3 翻訳プロジェクト">
<link href="#rfc.appendix.A" rel="Chapter" title="A Acknowledgements">
<link href="#rfc.appendix.B" rel="Chapter" title="B Notices">
<link href="#rfc.appendix.C" rel="Chapter" title="C Document History">
<link href="#rfc.appendix.D" rel="Chapter" title="D 翻訳者">
<link href="#rfc.authors" rel="Chapter">
<meta name="generator" content="xml2rfc version 2.37.3 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Lodderstedt, T. and D. Fett" />
<meta name="dct.identifier" content="urn:ietf:id:openid-connect-4-identity-assurance-1_0-07" />
<meta name="dct.issued" scheme="ISO8601" content="2019-08-15" />
<meta name="dct.abstract" content="This specification defines an extension of OpenID Connect for providing Relying Parties with verified Claims about End-Users. This extension is intended to be used to verify the identity of a natural person in compliance with a certain law." />
<meta name="description" content="This specification defines an extension of OpenID Connect for providing Relying Parties with verified Claims about End-Users. This extension is intended to be used to verify the identity of a natural person in compliance with a certain law." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">connect</td>
<td class="right">T. Lodderstedt</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">D. Fett</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">yes.com</td>
</tr>
<tr>
<td class="left">Expires: February 16, 2020</td>
<td class="right">August 15, 2019</td>
</tr>
</tbody>
</table>
<p class="title">OpenID Connect for Identity Assurance 1.0<br />
<span class="filename">openid-connect-4-identity-assurance-1_0-07</span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>This specification defines an extension of OpenID Connect for providing Relying Parties with verified Claims about End-Users. This extension is intended to be used to verify the identity of a natural person in compliance with a certain law.</p>
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on February 16, 2020.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a>
</li>
<ul><li>1.1. <a href="#rfc.section.1.1">Terminology</a>
</li>
</ul><li>2. <a href="#rfc.section.2">Scope and Requirements</a>
</li>
<li>3. <a href="#rfc.section.3">Claims</a>
</li>
<ul><li>3.1. <a href="#rfc.section.3.1">Additional Claims about End-Users</a>
</li>
<li>3.2. <a href="#rfc.section.3.2">txn Claim</a>
</li>
</ul><li>4. <a href="#rfc.section.4">Verified Data Representation</a>
</li>
<ul><li>4.1. <a href="#rfc.section.4.1">verification Element</a>
</li>
<ul><li>4.1.1. <a href="#rfc.section.4.1.1">Evidence</a>
</li>
</ul><li>4.2. <a href="#rfc.section.4.2">claims Element</a>
</li>
</ul><li>5. <a href="#rfc.section.5">Requesting Verified Claims</a>
</li>
<ul><li>5.1. <a href="#rfc.section.5.1">Requesting End-User Claims</a>
</li>
<li>5.2. <a href="#rfc.section.5.2">Requesting Verification Data</a>
</li>
<li>5.3. <a href="#rfc.section.5.3">Defining constraints on Verification Data</a>
</li>
</ul><li>6. <a href="#rfc.section.6">Examples</a>
</li>
<ul><li>6.1. <a href="#rfc.section.6.1">id_document</a>
</li>
<li>6.2. <a href="#rfc.section.6.2">id_document + utility bill</a>
</li>
<li>6.3. <a href="#rfc.section.6.3">Notified eID system (eIDAS)</a>
</li>
<li>6.4. <a href="#rfc.section.6.4">Verified Claims in UserInfo Response</a>
</li>
<ul><li>6.4.1. <a href="#rfc.section.6.4.1">Request</a>
</li>
<li>6.4.2. <a href="#rfc.section.6.4.2">UserInfo Response</a>
</li>
</ul><li>6.5. <a href="#rfc.section.6.5">Verified Claims in ID Tokens</a>
</li>
<ul><li>6.5.1. <a href="#rfc.section.6.5.1">Request</a>
</li>
<li>6.5.2. <a href="#rfc.section.6.5.2">ID Token</a>
</li>
</ul><li>6.6. <a href="#rfc.section.6.6">Aggregated Claims</a>
</li>
<li>6.7. <a href="#rfc.section.6.7">Distributed Claims</a>
</li>
</ul><li>7. <a href="#rfc.section.7">OP Metadata</a>
</li>
<li>8. <a href="#rfc.section.8">Transaction-specific Purpose</a>
</li>
<li>9. <a href="#rfc.section.9">Privacy Consideration</a>
</li>
<li>10. <a href="#rfc.section.10">Security Considerations</a>
</li>
<li>11. <a href="#rfc.section.11">Predefined Values</a>
</li>
<ul><li>11.1. <a href="#rfc.section.11.1">Trust Frameworks</a>
</li>
<li>11.2. <a href="#rfc.section.11.2">Identity Documents</a>
</li>
<li>11.3. <a href="#rfc.section.11.3">Verification Methods</a>
</li>
</ul><li>12. <a href="#rfc.section.12">JSON Schema</a>
</li>
<li>13. <a href="#rfc.references">References</a>
</li>
<ul><li>13.1. <a href="#rfc.references.1">Normative References</a>
</li>
<li>13.2. <a href="#rfc.references.2">Informative References</a>
</li>
<li>13.3. <a href="#rfc.references.3">翻訳プロジェクト</a>
</li>
</ul><li>Appendix A. <a href="#rfc.appendix.A">Acknowledgements</a>
</li>
<li>Appendix B. <a href="#rfc.appendix.B">Notices</a>
</li>
<li>Appendix C. <a href="#rfc.appendix.C">Document History</a>
</li>
<li>Appendix D. <a href="#rfc.appendix.D">翻訳者</a>
</li>
<li><a href="#rfc.authors">Authors' Addresses</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> <a href="#Introduction" id="Introduction">Introduction</a>
</h1>
<p id="rfc.section.1.p.1">この仕様では, OpenID Connect <a href="#OpenID" class="xref">[OpenID]</a> の拡張機能を定義して, 特定の法律に従って自然人の強力な identity verification のユースケースに対処している. 例には, マネーロンダリング防止法, 電気通信法, テロ対策法, eIDAS <a href="#eIDAS" class="xref">[eIDAS]</a> などの信託サービスに関する規制が含まれる.</p>
<p id="rfc.section.1.p.2">そのようなユースケースでは, 依拠当事者 (RPs) は, OpenID Connect プロバイダー (OPs) またはその他の信頼できるソースによって証明されたエンドユーザーに関する Claim の保証レベルと, identity verification プロセスに関連するエビデンスを知る必要がある.</p>
<p id="rfc.section.1.p.3">OpenID Connect 仕様 <a href="#OpenID" class="xref">[OpenID]</a> の Section 2 で定義されている <samp>acr</samp> Claim は, OpenID Connect トランザクションで実行される認証に関する情報を証明するのに適している. ただし, identity assurance には次の理由で異なる表現が必要である: 認証は OpenID Connect トランザクションの側面であり, identity assurance は特定の Claim または Claim のグループのプロパティであり, それらのいくつかは通常, OpenID Connect トランザクションの結果として RP に伝えられる.</p>
<p id="rfc.section.1.p.4">たとえば, 通常, OP が電子メールアドレスを証明できるという保証は「自己表明」または「オプトインまたは同様のメカニズムによって検証」される. 対照的にユーザーの姓は, OP オペレーターの訓練を受けた従業員に ID カードを提示することにより, それぞれのマネーロンダリング防止法に従って検証された可能性がある.</p>
<p id="rfc.section.1.p.5">したがって, identity assurance には, エンドユーザーに関する各 Claim とともに保証データを伝達する方法が必要である. この仕様は, RP がエンドユーザーに関する検証済み Claim を identity assurance データとともに要求し, OP がこれらの検証済み Claim と付随する identity assurance データを表すために利用する適切な表現とメカニズムを提案する.</p>
<h1 id="rfc.section.1.1">
<a href="#rfc.section.1.1">1.1.</a> <a href="#terminology" id="terminology">Terminology</a>
</h1>
<p id="rfc.section.1.1.p.1">このセクションでは, NIST SP 800-63A <a href="#NIST-SP-800-63a" class="xref">[NIST-SP-800-63a]</a> に大きな影響を受けた, このドキュメントで扱われているトピックに関連するいくつかの用語を定義する.</p>
<p></p>
<ul><li>Identity Proofing - ユーザーが OP または自分自身を確実に識別する Claim プロバイダーにエビデンスを提供することにより, OP が有用な identity assurance レベルで識別できるようにするプロセス.</li></ul>
<p> </p>
<p></p>
<ul><li>Identify Verification - ユーザーの身元を確認するために OP または Claim プロバイダーによって実行されるプロセス.</li></ul>
<p> </p>
<p></p>
<ul><li>Identity Assurance - OP または Claim プロバイダーが, RP に対してある一定の確からしさをもって特定のユーザーの Identity データを証明するプロセス. 通常は identity assurance レベルで表される. 法的要件に応じて, OP は identity verification プロセスのエビデンスを RP に提供する必要がある場合もある.</li></ul>
<p> </p>
<p></p>
<ul><li>Verified Claims - 特定のユーザーアカウントへのバインドが identity verification プロセスの過程で検証されたエンドユーザー (通常は自然人) に関する Claim.</li></ul>
<p> </p>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#scope-and-requirements" id="scope-and-requirements">Scope and Requirements</a>
</h1>
<p id="rfc.section.2.p.1">本仕様のスコープは, 検証された Claim をアサートするメカニズムを定義し, identity assurance スペースで必要とされるエンドユーザに関する新しい Claim を導入することである; 例の一つとして出生地がある.</p>
<p id="rfc.section.2.p.2">RP は必要とする最小限のデータセットを要求し (データの最小化) , このデータと OP で利用されるエビデンス, および identity verification プロセスに関する要件を表すことができる.</p>
<p id="rfc.section.2.p.3">この拡張機能は, eIDAS 公認 eID システムなどの identity assurance に関連する特定の規制の下で動作する OP, および他の OP で使用できる. 厳密に規制された OP は, はっきりと定義された責任を伴う明確に定義されたルールに従って動作することを承認されているため, さらなるエビデンスを提出することなく identity データを証明することができる.</p>
<p id="rfc.section.2.p.4">例えば eIDAS のケースでは, ピアレビューが eIDAS のコンプライアンスを保証し, それぞれのメンバー国は公認 eID システムによる identity の主張に対して責任を負う. そのような明確に定義された条件下にない他のすべての OP は, 一般的に, RP が独自のリスク評価を実施し, OP から取得したデータを他の法律にマッピングできるように, identity evidence に加えて, RP に identity verification プロセスに関するデータを提供する必要がある. 例えば eIDAS で定義された要件を満たすために, マネーロンダリング防止法に従って維持されている identity データを使用することができる.</p>
<p id="rfc.section.2.p.5">技術的な観点から, この仕様は OP が各トラストフレームワーク(と assurance レベル)についての情報に加えて, 検証済み Claim の証明を許可することを意味するが, identity verification プロセスに関する情報の表出化のサポートも行う.</p>
<p id="rfc.section.2.p.6">この仕様で定義された表現方式は, 適切なチャネルを介してエンドユーザに関する検証済 Claim を RP に提供するために利用できる. OpenID Connect のコンテキストでは, 検証済 Claim は ID Token か UserInfo response の一部として証明することができる. また OAuth Token Introspection response (<a href="#RFC7662" class="xref">[RFC7662]</a> 及び <a href="#I-D.ietf-oauth-jwt-introspection-response" class="xref">[I-D.ietf-oauth-jwt-introspection-response]</a> を参照)で説明されている形式を利用して, 検証済 Claim をリソースサーバに提供することも可能である.</p>
<p id="rfc.section.2.p.7">この拡張は真に国際的なものであり, 異なる管轄の identity assurance もサポートさせる予定である. そのためこの拡張機能は追加のトラストフレームワーク, 検証メソッド, identity evidenceをサポートするために拡張することができる.</p>
<p id="rfc.section.2.p.8">実装者に可能な限りの柔軟性を与えるために, この拡張は既存の OpenID Connect の Claim および同じ OpenID Connect のアサーション(例えば, ID Token や UserInfo)内の他の拡張と組み合わせて使うことができる.</p>
<p id="rfc.section.2.p.9">例えば, OpenID Connect <a href="#OpenID" class="xref">[OpenID]</a> は検証ステータスのないユーザの姓と名を表す Claim を定義している. これらの Claim はこの拡張に従って表現される検証済み Claim とともに同じ OpenID Connect のアサーションで使うことができる.</p>
<p id="rfc.section.2.p.10">同じように, RP に <samp>phone_number</samp> と <samp>email</samp> Claim の検証ステータスを通知する既存 Claim もこの拡張とともに使うことができる.</p>
<p id="rfc.section.2.p.11">検証済み Claim を主張する場合でも, この拡張は可能かつ妥当であれば既存の OpenID Connect の Claim を利用する. しかしながら, 拡張は RP が未検証 Claim を検証済 Claim として(誤って)解釈できないようにする.</p>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#claims" id="claims">Claims</a>
</h1>
<h1 id="rfc.section.3.1">
<a href="#rfc.section.3.1">3.1.</a> <a href="#userclaims" id="userclaims">Additional Claims about End-Users</a>
</h1>
<p id="rfc.section.3.1.p.1">identity assurance に関する一部の権限の要件を満たすために, この仕様では OpenID仕様 <a href="#OpenID" class="xref">[OpenID]</a> に定義されている Claim にユーザデータを伝達するための以下の追加の Claim を定義する:</p>
<p></p>
<ul>
<li>
<samp>place_of_birth</samp>: エンドユーザの出生地を示す構造化された Claim. 次のフィールドで構成される: <ul>
<li>
<samp>country</samp>: 必須 (REQUIRED). <a href="#ISO3166-1" class="xref">[ISO3166-1]</a> Alpha-2 (例えば, DE) または <a href="#ISO3166-3" class="xref">[ISO3166-3]</a>
</li>
<li>
<samp>region</samp>: State, province, prefecture, または他の地域コンポーネント. 一部の管轄区域ではこのフィールドは必須かもしれない.</li>
<li>
<samp>locality</samp>: 必須 (REQUIRED). city, または別の地域.</li>
</ul>
</li>
<li>
<samp>nationalities</samp>: ユーザの国籍を表す ICAO 2-letter codes <a href="#ICAO-Doc9303" class="xref">[ICAO-Doc9303]</a> の文字配列. 例えば "US" や "DE". "EUE" のように対応する 2-letter code がない場合, 3-letter codes を利用してもよい (MAY).</li>
<li>
<samp>birth_family_name</samp>: 彼または彼女が生まれたとき, あるいは少なくとも子供の時から持っている姓. この用語は人生の途中に何らかの理由で姓を変更した人が利用できる.</li>
<li>
<samp>birth_given_name</samp>: 彼または彼女が生まれたとき, あるいは少なくとも子供の時から持っている名前. この用語は人生の途中に何らかの理由で名前を変更した人が利用できる.</li>
<li>
<samp>birth_middle_name</samp>: 彼または彼女が生まれたとき, あるいは少なくとも子供の時から持っているミドルネーム. この用語は人生の途中に何らかの理由でミドルネームを変更した人が利用できる.</li>
<li>
<samp>salutation</samp>: エンドユーザの敬称, 例えば “Mr.”</li>
<li>
<samp>title</samp>: エンドユーザの肩書, 例えば “Dr.”</li>
</ul>
<p> </p>
<h1 id="rfc.section.3.2">
<a href="#rfc.section.3.2">3.2.</a> <a href="#txn-claim" id="txn-claim">txn Claim</a>
</h1>
<p id="rfc.section.3.2.p.1">一般的に, 強固な identity verification は参加者がプロセス全体の監査証跡を保持する必要がある.</p>
<p><a href="#RFC8417" class="xref">[RFC8417]</a> で定義されている <samp>txn</samp> Claim はこの拡張のコンテキストで使用され, OpenID Connect トランザクションに関わるの関係者全体の監査証跡を構築する.</p>
<p id="rfc.section.3.2.p.3">OP が <samp>txn</samp> を発行する場合, 対応する監査証跡を維持する必要があり (MUST), 少なくとも次の詳細で構成される.</p>
<p></p>
<ul>
<li>transaction id,</li>
<li>採用されている authentication methods, および</li>
<li>transaction type (scope 値など).</li>
</ul>
<p> </p>
<p id="rfc.section.3.2.p.5">このトランザクションデータは, それぞれの規定による監査目的のためにトランザクションデータを保存する必要がある限り保存し続けなければならない (MUST).</p>
<p id="rfc.section.3.2.p.6">RP はこの Claim を <samp>claims</samp> パラメータを介して, または scope 値によって識別されるデフォルトの Claim の一部として, 他の Claim と同様に要求する.</p>
<p><samp>txn</samp> 値は必要に応じて RP がこれらのトランザクションを参照できるようにしなければならない (MUST).</p>
<p id="rfc.section.3.2.p.8">注：トランザクションの詳細を, OP および, それらのフォーマットから取得するメカニズムはこの仕様の範囲外である.</p>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#verified-data-representation" id="verified-data-representation">Verified Data Representation</a>
</h1>
<p id="rfc.section.4.p.1">OpenID Connect のこの拡張は, RP が検証済みの Claim と未検証の Claim を混在させ, 検証済みの Claim として未検証の Claim を偶発的に処理できないようにすることを目的としている.</p>
<p id="rfc.section.4.p.2">それ故, 提案された表現は <samp>verified_claims</samp> コンテナ要素内で検証済み Claim を RP に提供することである. このコンテナは特定の検証プロセスに関連する検証のエビデンスとこのプロセスで検証されたエンドユーザについての該当 Claim で構成されている.</p>
<p id="rfc.section.4.p.3">このセクションでは <samp>verified_claims</samp> の構造と意味について詳しく説明する. 機械可読な構文定義は <a href="#json_schema" class="xref">Section 12</a> で JSON スキーマとして提供される. <samp>verified_claims</samp> 要素を含む JSON ドキュメントを自動的に検証するために使用できる.</p>
<p><samp>verified_claims</samp> は以下のサブ要素で構成される:</p>
<p></p>
<ul>
<li>
<samp>verification</samp>: 必須 (REQUIRED). 検証プロセスに関するすべてのデータを含むオブジェクト.</li>
<li>
<samp>claims</samp>: 必須 (REQUIRED). エンドユーザに関するの検証済 Claim のためのコンテナであるオブジェクト.</li>
</ul>
<p> </p>
<p id="rfc.section.4.p.6">注: 実装は, この仕様またはこの仕様の拡張で定義されていないサブ要素を無視しなければならない (MUST).</p>
<h1 id="rfc.section.4.1">
<a href="#rfc.section.4.1">4.1.</a> <a href="#verification" id="verification">verification Element</a>
</h1>
<p id="rfc.section.4.1.p.1">この要素には, 個人の身元を確認し, それぞれの個人データをユーザーアカウントにバインドするために実行されたプロセスに関する情報が含まれる.</p>
<p><samp>verification</samp> 要素は以下の要素を含む:</p>
<p><samp>trust_framework</samp>: 必須 (REQUIRED). OP の identity verification プロセスと, identity assurance レベルを管理する trust framework を定める文字列.</p>
<p id="rfc.section.4.1.p.4">例としては <samp>eidas_ial_high</samp> で, これは eIDAS <a href="#eIDAS" class="xref">[eIDAS]</a> 公認 eID システムを示し, assurance レベル "high" の identity assurance を提供する.</p>
<p id="rfc.section.4.1.p.5">標準化された値の初期リストは, <a href="#predefined_values_tf">Trust Frameworks</a> で定義されている. 追加の trust framework identifiers も導入できる [how？]. RP は理解できない trust framework identifiers を含む <samp>verified_claims</samp> Claim を無視しなければならない (SHOLUD).</p>
<p><samp>trust_framework</samp> は, <samp>verification</samp> 要素の中で RP に提供される追加のデータを決定する. たとえば, eIDAS 公認 eID システムは, データを追加する必要はないが, eIDAS に管理されていない OP は RP が法的義務を果たすために verification evidence を提供する必要がある. 後者の例としては, ドイツのマネーロンダリング防止法 (<samp>de_aml</samp>) に基づいて行動する OP である.</p>
<p><samp>time</samp>: ID の検証が行われた日時を示す ISO 8601:2004 [ISO8601-2004] <samp>YYYY-MM-DDThh:mm:ss±hh</samp> フォーマットのタイムスタンプ. 特定のトラストフレームワークでは, この要素の存在が必要になる場合がある.</p>
<p><samp>verification_process</samp>: OP によって実行される identity verification プロセスへの一意の参照. 紛争(ないしは紛争解決)または監査の場合のバックトレースに使用される.特定のトラストフレームワークでは, この要素の存在が必要になる場合がある.</p>
<p id="rfc.section.4.1.p.9">注：<samp>verification_process</samp> は OP での identity verification プロセスを指すが, <samp>txn</samp> Claim は OP が RP に対してユーザ検証済 identity データを証明した特定の OpenID Connect トランザクションを指す.</p>
<p><samp>evidence</samp>: OP がユーザの identity を個別の JSON オブジェクトとして検証するために使用した <samp>evidence</samp> に関する情報を含む JSON 配列. すべてのオブジェクトには, エビデンスのタイプを決定する <samp>type</samp> プロパティが含まれている. RP はこの情報を <samp>evidence</samp> プロパティを適切に処理するために利用する.</p>
<p id="rfc.section.4.1.p.11">重要:実装はこの仕様またはこの仕様の拡張で定義されていないサブ要素を無視しなければならない (MUST).</p>
<h1 id="rfc.section.4.1.1">
<a href="#rfc.section.4.1.1">4.1.1.</a> <a href="#evidence" id="evidence">Evidence</a>
</h1>
<p id="rfc.section.4.1.1.p.1">次のエビデンスのタイプが定義されている:</p>
<p></p>
<ul>
<li>
<samp>id_document</samp>: あらゆる種類の政府発行の身分証明書に基づく検証</li>
<li>
<samp>utility_bill</samp>: 公共料金の支払に基づく検証</li>
<li>
<samp>qes</samp>: eIDAS 認定電子署名に基づく検証</li>
</ul>
<p> </p>
<h1 id="rfc.section.4.1.1.1">
<a href="#rfc.section.4.1.1.1">4.1.1.1.</a> <a href="#id-document" id="id-document">id_document</a>
</h1>
<p id="rfc.section.4.1.1.1.p.1">次の種類の属性が <samp>id_document</samp> エビデンスのサブ要素として含まれる.</p>
<p><samp>method</samp>: 必須 (REQUIRED). id document を検証するために使われるメソッド. 事前に定義された値は <a href="#predefined_values_vm">Verification Methods</a> で定義されている.</p>
<p><samp>verifier</samp>: オプション (OPTIONAL). OP に代わって identity verification を実行した法人を示す JSON オブジェクト. このオブジェクトは, OP が identity verification を実行しなかった場合にのみ含める必要がある (SHOULD). このオブジェクトは次のプロパティで構成される:</p>
<p></p>
<ul>
<li>
<samp>organization</samp>: OP に代わって検証を行った組織を表す文字列.</li>
<li>
<samp>txn</samp>: identity verification のトランザクションを参照する識別子. このトランザクション識別子は, 監査中のトランザクションの詳細を分析できる.</li>
</ul>
<p> </p>
<p><samp>time</samp>: この id document が検証された日付を表す ISO 8601:2004 [ISO8601-2004] <samp>YYYY-MM-DDThh:mm:ss±hh</samp> フォーマットのタイムスタンプ.</p>
<p><samp>document</samp>: ID 検証に使用される id document を表す JSON オブジェクト. 次のプロパティで構成される:</p>
<p></p>
<ul>
<li>
<samp>type</samp>: 必須 (REQUIRED). id document のタイプを示す文字列. 標準化された値は <a href="#predefined_values_idd">Identity Documents</a> で定義される. OP は事前に定義されていない値を使用するかもしれず (MAY), その場合, RP はアサーションを処理できないか, 監査目的でこの値を保存するだけか, またはそれに言及されたビジネスロジックであることを表す.</li>
<li>
<samp>number</samp>: identity document の番号を表す文字列.</li>
<li>
<samp>issuer</samp>: この identity document の発行者の情報を含む JSON オブジェクト. このオブジェクトは次のプロパティで構成される: <ul>
<li>
<samp>name</samp>:必須 (REQUIRED). identity document の発行者の名称.</li>
<li>
<samp>country</samp>: ドキュメントを ICAO 2-letter-code <a href="#ICAO-Doc9303" class="xref">[ICAO-Doc9303]</a> として発行した国または組織を示す文字列 (例： "JP") . ICAO 3-letter codes は, "UNO" など, 対応する ISO 2-letter codes がない場合に使用できる.</li>
</ul>
</li>
<li>
<samp>date_of_issuance</samp>: 特定の種類のドキュメント用にこの属性が存在する場合は必須 (REQUIRED). ISO 8601:2004 YYYY-MM-DD フォーマットでドキュメントが発行された日付.</li>
<li>
<samp>date_of_expiry</samp>: 特定の種類のドキュメント用にこの属性が存在する場合は必須 (REQUIRED). ISO 8601:2004 YYYY-MM-DD フォーマットのドキュメントの有効期限.</li>
</ul>
<p> </p>
<h1 id="rfc.section.4.1.1.2">
<a href="#rfc.section.4.1.1.2">4.1.1.2.</a> <a href="#utility-bill" id="utility-bill">utility_bill</a>
</h1>
<p id="rfc.section.4.1.1.2.p.1">次の種類の要素が <samp>utility_bill</samp> エビデンスのサブ要素として含まれる.</p>
<p><samp>provider</samp>: 必須 (REQUIRED). 請求書を発行した各プロバイダを識別する JSON オブジェクト. オブジェクトは次のプロパティで構成される:</p>
<p></p>
<ul>
<li>
<samp>name</samp>: プロバイダを指定する文字列.</li>
<li>OpenID Connect の <samp>address</samp> Claim (<a href="#OpenID" class="xref">[OpenID]</a>) のすべての要素</li>
</ul>
<p> </p>
<p><samp>date</samp>: この請求書が発行された日時を含む ISO 8601:2004 YYYY-MM-DD フォーマットの文字列.</p>
<h1 id="rfc.section.4.1.1.3">
<a href="#rfc.section.4.1.1.3">4.1.1.3.</a> <a href="#qes" id="qes">qes</a>
</h1>
<p id="rfc.section.4.1.1.3.p.1">次の種類の要素が <samp>qes</samp> エビデンスのサブ要素として含まれる.</p>
<p><samp>issuer</samp>: 必須 (REQUIRED). 署名者の証明書を発行した証明機関を示す文字列.</p>
<p><samp>serial_number</samp>:必須 (REQUIRED). 署名に使用される証明書のシリアルナンバーを含む文字列.</p>
<p><samp>created_at</samp>: 必須 (REQUIRED). ISO 8601:2004 YYYY-MM-DDThh:mm:ss±hh フォーマットの署名が作られた時間.</p>
<h1 id="rfc.section.4.2">
<a href="#rfc.section.4.2">4.2.</a> <a href="#claimselement" id="claimselement">claims Element</a>
</h1>
<p><samp>claims</samp> 要素にはプロセスによって検証され, 対応する <samp>verification</samp> 要素によって決定されたポリシーに従って検証されたエンドユーザについての Claim が含まれる.</p>
<p><samp>claims</samp> 要素には OpenID Connect specification <a href="#OpenID" class="xref">[OpenID]</a> の Section 5.1 で定義されている以下の Claim が一つ以上含まれるかもしれない (MAY)</p>
<p></p>
<ul>
<li><samp>name</samp></li>
<li><samp>given_name</samp></li>
<li><samp>middle_name</samp></li>
<li><samp>family_name</samp></li>
<li><samp>birthdate</samp></li>
<li><samp>address</samp></li>
</ul>
<p> </p>
<p id="rfc.section.4.2.p.4">または <a href="#userclaims" class="xref">Section 3.1</a> で定義されている Claim を含むかもしれない.</p>
<p><samp>claims</samp> 要素は, 兄弟要素の <samp>verification</samp> で提示された検証プロセスでそれぞれの Claim の値が検証された場合, 他の Claim も含むかもしれない (MAY).</p>
<p id="rfc.section.4.2.p.6">Claim 名は, OpenID Connect 仕様 <a href="#OpenID" class="xref">[OpenID]</a> の Section 5.2 で指定されている言語タグで注釈を付けてもよい (MAY).</p>
<h1 id="rfc.section.5">
<a href="#rfc.section.5">5.</a> <a href="#requesting-verified-claims" id="requesting-verified-claims">Requesting Verified Claims</a>
</h1>
<h1 id="rfc.section.5.1">
<a href="#rfc.section.5.1">5.1.</a> <a href="#req_claims" id="req_claims">Requesting End-User Claims</a>
</h1>
<p id="rfc.section.5.1.p.1">Verified Claims は OpenID Connect specification <a href="#OpenID" class="xref">[OpenID]</a> の Section 5.5. に定義されている <samp>claims</samp> parameter を利用することで, End-User について 個々の Claims のレベルで要求できる.</p>
<p><samp>verified_claims</samp> は <samp>claims</samp> パラメーターの <samp>userinfo</samp> か <samp>id_token</samp> 要素に追加される.</p>
<p><samp>verified_claims</samp> にはネストされた <samp>claims</samp> 要素の中に End-User についての有効な Claims が含まれるため, syntax は次のようにネストされた要素の式を含むように拡張される. <samp>verified_claims</samp> 要素は <samp>claims</samp> 要素を含み, <samp>null</samp> 値を持つキーとして要求する Claims を含む. 以下に例を示す.</p>
<pre>{
"userinfo":{
"verified_claims":{
"claims":{
"given_name":null,
"family_name":null,
"birthdate":null
}
}
}
}
</pre>
<p><samp>claims</samp> パラメータを使用すると, RP はユースケースに必要な End-User に関する Claims を正確に選択できる. したがって, この拡張は RPs はデータ最小化の要件を満たすことができる.</p>
<p id="rfc.section.5.1.p.5">RPs は, OpenID Connect specification <a href="#OpenID" class="xref">[OpenID]</a> の Section 5.5.1 で定義されている <samp>essential</samp> フィールドを利用することにより, 特定の Claim がユーザージャーニーの正常な完了に不可欠であることを示すことができる. 次の例では, 姓と名の両方を必須として指定している.</p>
<pre>{
"userinfo":{
"verified_claims":{
"claims":{
"given_name":{"essential": true},
"family_name":{"essential": true},
"birthdate":null
}
}
}
}
</pre>
<p id="rfc.section.5.1.p.6">この仕様では, RP が要求する特定の End-User Claim の移転の目的を説明できるようにするために, 追加のフィールド <samp>purpose</samp> を導入する. <samp>purpose</samp> フィールドは, 個々に要求された各 Claim のメンバー値にすることができるが, 1つの Claim には複数の関連する目的を含めることはできない.</p>
<p><samp>purpose</samp> OPTIONAL. OP から特定の End-User Claim を取得する目的を説明する文字列. <samp>purpose</samp> は 3 文字未満か 300 文字以上となってはならない (MUST NOT). もしこのルールに違反した場合, authentication request は失敗し, OP は <samp>invalid_request</samp> エラーを RP にに返さなければならない (MUST). 移転されるデータの利用目的や承認しようとしている認可内容をユーザーに明示するため, OP は各同意画面にこの purpose を表示しなければならない (MUST). <samp>purpose</samp> パラメーターがリクエストに存在しない場合, OP は RP ごとに事前設定された値を表示できる (MAY). UI ローカリゼーションの詳細については, <a href="#purpose" class="xref">Section 8</a> 参照.</p>
<p id="rfc.section.5.1.p.8">例:</p>
<pre>{
"userinfo":{
"verified_claims":{
"claims":{
"given_name":{
"essential":true,
"purpose":"To make communication look more personal"
},
"family_name":{
"essential":true
},
"birthdate":{
"purpose":"To send you best wishes on your birthday"
}
}
}
}
}
</pre>
<p id="rfc.section.5.1.p.9">注: 値が <samp>null</samp> の <samp>claims</samp> サブ要素は, 考えられるすべての Claims に対するリクエストとして解釈される. 以下に例を示す:</p>
<pre>{
"userinfo":{
"verified_claims":{
"claims":null
}
}
}
</pre>
<p id="rfc.section.5.1.p.10">注: <samp>claims</samp> サブ要素は省略でき, これは, 値が <samp>null</samp> である <samp>claims</samp> 要素と同等である.</p>
<p id="rfc.section.5.1.p.11">注: <samp>claims</samp> サブ要素が空か, <a href="#claimselement" class="xref">Section 4.2</a> に定義されている要件を満たなさい Claims を含む場合, OP は <samp>invalid_request</samp> エラーでトランザクションを中断するだろう.</p>
<h1 id="rfc.section.5.2">
<a href="#rfc.section.5.2">5.2.</a> <a href="#req_verification" id="req_verification">Requesting Verification Data</a>
</h1>
<p><samp>verification</samp> 要素内容は, 基本的にそれぞれの <samp>trust_framework</samp> と Claim source のポリシーによって決定される.</p>
<p id="rfc.section.5.2.p.2">この仕様は RP が特定のデータを <samp>verification</samp> 要素に明示的に要求する方法も定義する. 構文は <a href="#req_claims" class="xref">Section 5.1</a> で指定されたルールに基づいており, <samp>verification</samp> 要素の構造へのナビゲーションのためにそれらを拡張する.</p>
<p id="rfc.section.5.2.p.3">次の例で示すように, <samp>verification</samp> 内の要素としてそれぞれの要素を追加することで, <a href="#req_claims" class="xref">Section 5.1</a> に定義されているのと同じ方法でリクエストできる.</p>
<pre>{
"verified_claims":{
"verification":{
"date":null,
"evidence":null
},
"claims":null
}
}
</pre>
<p id="rfc.section.5.2.p.4">これは, 発行されたアサーションに検証の日付と利用可能な証拠が存在することを要求する.</p>
<p id="rfc.section.5.2.p.5">注: <samp>verified_claims</samp> Claim の必須要素であるため, RP は明示的に <samp>trust_framework</samp> フィールドを要求する必要はない.</p>
<p id="rfc.section.5.2.p.6">RP は, 構造を1段深く掘り下げ, 特定のデータがすべての <samp>evidence</samp> 内に存在することを要求する場合もある. result array 内のすべてのエントリのプロトタイプとして, 単一のエントリが使用される.</p>
<pre>{
"verified_claims":{
"verification":{
"date":null,
"evidence":[
{
"method":null,
"document":null
}
]
},
"claims":null
}
}
</pre>
<p id="rfc.section.5.2.p.7">この例では, 特定のユーザーアカウントで利用可能なすべての証拠について, <samp>method</samp> 要素と <samp>document</samp> 要素を要求する.</p>
<p id="rfc.section.5.2.p.8">注: <samp>evidence</samp> エントリの必須要素であるため, RP は明示的に <samp>type</samp> フィールドを要求する必要はない.</p>
<p id="rfc.section.5.2.p.9">RP は, <samp>document</samp> 要素内に特定のデータが存在することを要求する場合もある. これも, 上記で使用した構文規則に従う.</p>
<pre>{
"verified_claims":{
"verification":{
"date":null,
"evidence":[
{
"method":null,
"document":{
"issuer":null,
"number":null,
"date_of_issuance":null
}
}
]
},
"claims":null
}
}
</pre>
<p id="rfc.section.5.2.p.10">注: <samp>document</samp> エントリの必須要素であるため, RP は明示的に <samp>type</samp> フィールドを要求する必要はない.</p>
<p id="rfc.section.5.2.p.11">RP に要求された検証データを提供するか決定するのは, Claim source の裁量である.</p>
<h1 id="rfc.section.5.3">
<a href="#rfc.section.5.3">5.3.</a> <a href="#constraintedclaims" id="constraintedclaims">Defining constraints on Verification Data</a>
</h1>
<p id="rfc.section.5.3.p.1">RP は <samp>verification</samp> サブ要素の要素に関する要件を表現できる (MAY).</p>
<p id="rfc.section.5.3.p.2">ここでも再び, <samp>verified_claims</samp> claim のネストされた性質によって, OpenID Connect specification <a href="#OpenID" class="xref">[OpenID]</a> の Section 5.5. で定義されている構文の拡張が必要である.</p>
<p id="rfc.section.5.3.p.3">OpenID Connect specification <a href="#OpenID" class="xref">[OpenID]</a> の Section 5.5.1 は, Claim の 追加情報/制約を持つ JSON object を要求するような Claim のメンバー値であることを許す構文を定義する. そのために, 特別なクエリの意味を持つ3つのメンバー (<samp>essential</samp>, <samp>value</samp>, および <samp>values</samp>) を定義し, 他の特別なメンバーを定義できるようにする (理解されていないメンバーは無視しなければならない).</p>
<p id="rfc.section.5.3.p.4">この仕様はそのメカニズムを再利用し, 新しいそのような <samp>max_age</samp> メンバーを導入する (下記参照).</p>
<p id="rfc.section.5.3.p.5">まず, <samp>value</samp> か <samp>values</samp> フィールドを利用して, <samp>trust_framework</samp>, <samp>evidence/type</samp>, <samp>evidence/method</samp>, 及び <samp>evidence/document/type</samp> の利用可能な値を制限することができる (MAY).</p>
<p id="rfc.section.5.3.p.6">次の例は, RP が AML(訳注: Anti-Money Laundering) に基づいて, 政府発行のIDドキュメントを使用して, 銀行の支店で直接本人確認を行った人に限定したユーザーの証明を取得したいことを示している.</p>
<pre>{
"userinfo":{
"verified_claims":{
"verification":{
"trust_framework":{
"value":"de_aml"
},
"evidence":[
{
"type":{
"value":"id_document"
},
"method":{
"value":"pipp"
},
"document":{
"type":{
"values":[
"idcard",
"passport"
]
}
}
}
]
},
"claims":null
}
}
}
</pre>
<p id="rfc.section.5.3.p.7">RP は, 検証データの経過時間, すなわち <samp>verification</samp> 要素で主張された検証プロセスが実行されてからの経過時間に関する要件も表現できる (MAY).</p>
<p id="rfc.section.5.3.p.8">したがって, この仕様では新しいメンバー <samp>max_age</samp> を定義している.</p>
<p><samp>max_age</samp>: OPTIONAL. 日付またはタイムスタンプを含む Claims にのみ適用可能な JSON 数値. 日付/タイムスタンプの値からリクエストの時点までの経過を許可する最大時間 (秒) を定義する. OP は, 日付値の最後の有効な秒から開始した経過時間の計算を行わなければならない. 以下は, データの検証プロセスが 63113852 秒以前であることを認めない Claims のリクエストの例である.</p>
<p id="rfc.section.5.3.p.10">以下に例を示す:</p>
<pre>{
"userinfo":{
"verified_claims":{
"verification":{
"date":{
"max_age":63113852
}
},
"claims":null
}
}
}
</pre>
<p id="rfc.section.5.3.p.11">OP はこの要件を満たそうとしなければならない (SHOULD). ユーザーの検証データがリクエストされた <samp>max_age</samp> よりも古い場合, OP はユーザーにオンラインでの identity verification プロセスを介して, ユーザーの確認を更新しようとするかもしれない (MAY). 例えば 電子IDカードまたはビデオ識別アプローチを利用することによって.</p>
<p id="rfc.section.5.3.p.12">OP が要件を満たすことができない場合 (<samp>essential</samp> とマークされている場合でも), RP に利用可能なデータを提供し, RP はデータの使用方法を決定できる. OP は, 必須 Claims として要求されたすべての Claims を返すことができない場合にエラーを返してはならない (MUST NOT).</p>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#examples" id="examples">Examples</a>
</h1>
<p id="rfc.section.6.p.1">以下のセクションでは <samp>verified_claims</samp> に関する例を示す.</p>
<p id="rfc.section.6.p.2">最初と 2つ目のセクションでは, 一般的な identity assurance のケースの JSON snippets を示し, RP には End-User に関する実際の Claims と一緒に, 様々な検証方法による verification evidence が提供される.</p>
<p id="rfc.section.6.p.3">3つ目のセクションでは, OP が RP に対して identity verification プロセスのエビデンスを提供する必要がない eIDAS 公認 eID システムの場合, どのようにこのオブジェクトのコンテンツが見えるかを説明している.</p>
<p id="rfc.section.6.p.4">後続のセクションでは, 異なる経路で <samp>verified_claims</samp> Claim を使用し, 他の (unverified) Claims と組み合わせて使用する例を含む.</p>
<h1 id="rfc.section.6.1">
<a href="#rfc.section.6.1">6.1.</a> <a href="#id-document-1" id="id-document-1">id_document</a>
</h1>
<pre>{
"verified_claims":{
"verification":{
"trust_framework":"de_aml",