-
Notifications
You must be signed in to change notification settings - Fork 1
/
openid-connect-federation-1_0.xml
1079 lines (1027 loc) · 42.8 KB
/
openid-connect-federation-1_0.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://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd">
<!--
NOTE: This XML file is input used to produce the authoritative copy of an
OpenID Foundation specification. The authoritative copy is the HTML output.
This XML source file is not authoritative. The statement ipr="none" is
present only to satisfy the document compilation tool and is not indicative
of the IPR status of this specification. The IPR for this specification is
described in the "Notices" section. This is a public OpenID Foundation
document and not a private document, as the private="..." declaration could
be taken to indicate.
-->
<rfc category="info" docName="openid-connect-federation-1_0" ipr="none">
<?rfc toc="yes" ?>
<?rfc tocdepth="5" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc private="Draft" ?>
<front>
<title abbrev="OpenID Connect Federation">OpenID Connect Federation 1.0 - draft 00</title>
<author fullname="Roland Hedberg" role="editor" surname="Hedberg"
initials="R.">
<organization>independent</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Rebecka Gulliksson" surname="Gulliksson"
initials="R.">
<organization abbrev="UmU">Umea University</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
<address>
<email>[email protected]</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity</organization>
<address>
<email>[email protected]</email>
<uri>http://www.thread-safe.com/</uri>
</address>
</author>
<date day="23" month="July" year="2016"/>
<workgroup>OpenID Connect Working Group</workgroup>
<keyword>OIDC</keyword>
<abstract>
<t>The OpenID Connect standard specifies how a Relying Party (RP)
can discover metadata about an OpenID Provider (OP), and then
register to obtain client credentials. During registration,
the RP provides metadata about its services. There is no
automated mechanism for the OP or the RP to verify the
information exchanged during this process. All the information
is self-asserted.
</t>
<t>
This document describes how a trusted third party can enhance
the security between the OP and RP by providing additional
integrity about their respective metadata. Using this approach,
an attacker would have to obtain the private keys of the
trusted third party, which would
mitigate the risk of a compromised SSL connection.
</t>
</abstract>
</front>
<middle>
<section anchor='Introduction' title="Introduction">
<t>The original specification of OpenID Connect defines how a
Relaying Party and an OpenID Connect Provider dynamically can
exchange information necessary for successful communication.
</t>
<t>One problem with using dynamic discovery and registration is that
the information that is exchanged can not be easily verified as
it is self-asserted.
</t>
<t>
Software statements, as introduced by RFC 7591, is a possible
choice for transferring verified data and trust in the data by
using a trusted third party (that verifies and enforces some
common policy) between clients and servers.
</t>
<t>
This document describes how software statements can be used in
dynamic client registration and provider discovery
to transfer verified data and to create a trust in the
information passed between the RP and OP that is independent
on the usage of
SSL.
</t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in<xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section title="Trust model">
<t>
The trust model is based on chains of trust, linking together
signing keys, represented as<xref target="RFC7517">
JWK Sets</xref>,
using<xref target="RFC7515">JSON Web Signatures</xref>.
The signature chain is rooted in the trusted third party's
signature, and then built upon by the respective entity.
By verifying such signature chains, the entities can establish
trust in the data verified by the trusted third party.
</t>
<t>
Handling RP client registration is slightly more complex then
dealing with OP configuration information and is therefor
chosen as an example here.
Players:
<list style="symbols">
<t>Federation operator</t>
<t>Developer</t>
<t>Relying Party Admin</t>
</list>
</t>
<section title="Federation operator">
<t>
The Federation Operator (FO) acting as the trusted third
part. The FO must have a globally unique identifier.
It will publish a JWK Set, containing the signing keys
that the FO will use for signing developer metadata,
at a HTTPS URL which server certificate MUST appear in a well-known
<xref target="RFC6962">Certificate Transparency log</xref>.
The FO will if the federation policy allows it sign
a partial client registration request provided by the
developer. There are several ways that the developer can use to make
the registration request available to the. One that we recommend is
that the developer publishes the request at an URLa where the FO
can fetch it.
The FO can add claims, representing federation policies,
to the registration request before constructing a software statement
and signing it. The signed software statement is returned to the
developer.
</t>
</section>
<section title="Developer">
<t>
The developer represents the organization responsible
for the relying party (RP). The developer will create a client
registration request that as an example can contain information
pertaining to the organization. To the request it will add
an extra parameter<spanx style="verb">signing_key</spanx>,
that will contain a JWK representation of the public key
that corresponds to the private key it will use to sign
the registration request that the relying part admin
constructs.
</t>
</section>
<section title="Relying Party Admin">
<t>
The Relying Party Admin (RPA) is the entity responsible for
a specific RP. This entity will construct a client
registration request containing claims specific to the RP.
To this registration request it will add an extra
parameter<spanx style="verb">signing_key</spanx>,
that will contain a JWK representation of the public key
that corresponds to the private key it will use to sign
the JWK Set that represents the keys it will use in the
OpenID Connect communication. The registration request
will be sent to the developer who will add the, by the FO
constructed, software statement before
signing the RPs registration request.
</t>
</section>
<section title="Signing Key Chain">
<t>
The key chain from top to bottom:
<list style="symbols">
<t>the federations key,</t>
<t>the developers key signed by the federation and</t>
<t>the RP's key signed by the developers key</t>
</list>
</t>
</section>
<section
title="Dealing with the OpenID Provider Configuration Information">
<t>
It is assumed that an organization will only run one
OpenID Connect Provider (OP). We can therefor dispens
of the intermediate, the developer, from the schema
described above.
This leaves us with the FO and the OP Admin.
The OP Admin (OPA) will create a Provider configuration and
notify the FO about where and when it can be fetched.
The Provider configuration is extended with one parameter
<spanx style="verb">signing_key</spanx>
where the OPA will publish the key it will use to sign
the JWK Set used in the OIDC communication.
The FO will if the federation policy allows it sign
the Provider Configuration information.
The FO can add claims, representing federation policies,
to the Provider Configuration informaion before constructing the
software statement, signing it and returning the software statement
to the OPA.
This software statement will later be part of a Provider Configuration
response.
</t>
</section>
</section>
<section title="OpenID Connect communication">
<figure>
<preamble>
The trust between the entities is established using the
above described extensions in the first tree steps of the
communication between an RP and an OP.
How, the RP found the OP in the first place is out of scope
for this document.
</preamble>
<artwork><![CDATA[
------ ------
| | <--- 1) Discovery --------> | |
| RP | <--- 2) Registration -----> | OP |
| | <--- 3) Authentication ---> | |
------ ------
]]>
</artwork>
<postamble>
After the discovery and registration is completed a first
time, those steps SHOULD only be repeated if any changes
occur (see notes in respective sections below).
</postamble>
</figure>
<section title="Extra metadata parameters">
<t>
These extra metadata parameters appear in both Provider
Configuration Discovery and Client Registration:
</t>
<t>
<list style="hanging">
<t hangText="signed_jwks_uri">
<vspace/>
OPTIONAL.
Location of the entity's signed JWKS, SHOULD return
the Content-Type "application/jose" to
indicate that the JWKS is in the form of a JWS using
the JWS Compact Serialization.
</t>
<t hangText="signing_key">
<vspace/>
OPTIONAL.
A JWS representing the public part of the entity's
key.
</t>
<t hangText="software_statements">
<vspace/>
OPTIONAL.
A list of software statements.
</t>
<t hangText="software_statement_uris">
<vspace/>
OPTIONAL.
A JSON object where the member names are the issuer
identifiers of the entity that has signed the
software statement and the values are URLs
pointing to the corresponding software
statements.
</t>
</list>
</t>
<t>
<figure>
<preamble>The following is a non-normative example of a RP
registration request after that the developer has added links
to the relevant software statements:
</preamble>
<artwork><![CDATA[
{
"contacts": ["[email protected]"],
"redirect_uris": ["https://example.com/rp2/callback"],
"application_type": "web",
"response_types": ["code"],
"scopes": ["openid", "email", "phone"],
"signed_jwks_uri": "https://example.com/rp2/jwks.jws",
"signing_key": {
"e": "AQAB",
"kid": "6ISnabkWzVnPELHmJKdUps1kYcXL17dCO6bBAsosjxk",
"kty": "RSA",
"n": "sftOcA3_GHxNMjNri40WAnilClJkDXLVukUqKduwd3e_IoMR7kRMcBKuz
FRr6k9pdXlB5TfMrtmtKd-pe3CZ1mah44ICtJ0ya8LsK_nFwiWP82EpZ0Au73k2K3PP
ZbCyCJS55uR3dyVU28nlm2VgYETdYPlNP9KCtXs_fBQTDqF945qKa53YLdBLLgNL4KF
JM8XZs-TbzElSrmE-5iwCtgAAhz-KgieXKBiCskjpOI2_eNx-mNCTzzoT3ay0xtM7St
EoGaKHZpdJBowGUpNqI7k_H_XAMWaj-y1lJDhxLyzt3Ve00THFYf5ie9tDKZFaFAokj
mjwkibm1xhns1VkJQ",
"use": "sig"
},
"software_statement_uris": {
"https://www.sunet.se/swamid":
"https://example.com/idfed/swamid.jws",
"https://www.incommon.org":
"https://example.com/idfed/incommon.jws"
}
} ]]></artwork>
</figure>
</t>
<t>
For the pairs:
software_statements/software_statements_uri and
signed_metadata/signed_metadata_uri
one and only one parameter from the pair MUST be present.
</t>
<t>
Along the same lines if both
<spanx style="verb">jwks_uri</spanx>
and
<spanx style="verb">signed_jwks_uri</spanx>
are present, which they
might be for backward compatibility reasons, then
<spanx style="verb">signed_jwks_uri</spanx>
SHOULD be preferred.
</t>
</section>
<section title="Federation policy">
<t>
Any parameters that the federation adds to the software
statement that
also appears in the Provider Configuration response
<xref target="OpenID.Discovery">(OpenID Connect Discovery
1.0
</xref>
or in a Client Registration request
<xref target="OpenID.Registration">(OpenID Connect Dynamic
Client Registration 1.0)
</xref>
will override what ever value the same
parameter has in the transferred metadata.
The only exception is when the information provided by the
RP/OP is a subset of what the developer/FO has specified.
</t>
</section>
<section title="Provider Discovery">
<t>
The OP MUST publish its provider metadata as specified by
<xref target="OpenID.Discovery">OpenID Connect Discovery
1.0</xref>.
The RP makes a standard OpenID Provider Configuration Request.
The OP responds with its provider configuration and the
additional metadata parameters specified above.
</t>
</section>
<section title="Client Registration">
<t>
The OP MUST support dynamic client registration
as described in
<xref target="OpenID.Registration">OpenID Connect Dynamic Client
Registration 1.0
</xref>. The RP makes a Client Registration Request including
the additional metadata specified above.
</t>
</section>
</section>
<section title="Belonging to several federation">
<section title="Developer">
<t>
A developer may be a member of more the one federation and the
RPs it is responsible for may be members of one or more of these.
</t>
<t>
This is then how to deal with this.
The developer registers and gets metadata signed by each federation.
One extreme is that it will mint a new key pair for each federation,
the other is that it will use the same key pair for all
federations. It really doesn't matter which it chooses but the end
result must be that there is one signed RP registration request per
signing key.
This is then published using
<spanx style="verb">software_statement_uris</spanx>
or
<spanx style="verb">software_statements</spanx>.
</t>
<t>
<figure>
<preamble>The following is a non-normative example of an
absolutely minimal client registration request sent to an OP:
</preamble>
<artwork><![CDATA[
{
"redirect_uris": ["https://example.com/rp2/callback"],
"software_statement_uris": {
"https://swamid.sunet.se/":
"https://dev.example.com/rp1/idfed/swamid.jws",
"https://www.incommon.org":
"https://dev.example.com/rp1/idfed/incommon.jws"
}
}
]]></artwork>
</figure>
</t>
<t>
When the OP receives a request like this it will chose which
federation it will work within and then signal that by only
return that entry in the software_statements/software_statement_uris
in the registration response.
</t>
<t>
<figure>
<preamble>The following is a non-normative example of an OPs
response on the client registration request above:
</preamble>
<artwork><![CDATA[
{
"client_id": "abcdefgh",
"client_secret": "0123456789",
"client_id_issued_at": 1462375583,
"client_secret_expires_at": 1462379183,
"redirect_uris": ["https://example.com/rp2/callback"],
"software_statement_uris": {
"https://swamid.sunet.se/":
"https://dev.example.com/rp1/idfed/swamid.jws",
}
}
]]></artwork>
</figure>
</t>
</section>
<section title="OP/AS admin">
<t>
An OP may likewise be member of several federations. As with the
developer it has the choice of whether it wants one key pair per
federation or one key pair for everyone or anything in between.
And like the RP developer it has to produce one signed metadata
statement per key used.
</t>
<t>
<figure>
<preamble>The following is a non-normative example of an OPs
response to a provider configuration request:
</preamble>
<artwork><![CDATA[
{
"issuer": "https://foo.example.org/op/fDTowvP0slEdEAcc",
"response_types_supported": ["code", "code id_token", "token"],
"grant_types_supported": ["authorization_code", "implicit",
"urn:ietf:params:oauth:grant-type:jwt-bearer"],
"subject_types_supported": ["pairwise", "public"],
"id_token_signing_alg_values_supported": ["RS256"],
"software_statement_uris": {
"https://swamid.sunet.se/":
"https://foo.example.org/op/idfed/swamid.jws",
"https://www.incommon.org":
"https://foo.example.org/op/idfed/incommon.jws"
"https://www.switch.ch":
"https://foo.example.org/op/idfed/switch.jws"
"https://www.aco.net/":
"https://foo.example.org/op/idfed/aconet.jws"
}
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Verification process">
<section title="OP as receiver">
<t>
Upon receiving metadata from an RP this is what the OP has to do:
<list style="numbers">
<t>
The OP will have to unpack the metadata such that it can get at
the software statement that is included. This is the software
statement that the FO constructed and signed based on input from
the developer.
</t>
<t>
Having the FO's JWK Set it should be able to find a key that
can be used to verify the signature on the software statement.
</t>
<t>
Once it has verified the signature of the software statement
it can use the signing key included in it to verify the signature
of the metadata.
</t>
<t>
If there is a
<spanx style="verb">signed_jwks_uri</spanx>
claim
in the metadata then when it has verified the signature of the
metadata it can use the signing key included in the metadata to
verify the signature on the JWK Set it fetched from the URL
defined in<spanx style="verb">signed_jwks_uri</spanx>.
</t>
</list>
</t>
</section>
<section title="RP as receiver">
<t>
It's easier for the RP since there is no intermediate involved in
producing the signed metadata for the OP. This means that the RP
can verify the signature of the metadata using a key in the FOs
JWK Set. If the OP' metadata contains a
<spanx style="verb">signed_jwks_uri</spanx>
claim the RP can
use the signing key included in the metadata to verify the signature
of the JWK Set found at that URL.
</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
<list style="empty">
<t>Michael Schwartz</t>
<t>Peter Schober</t>
</list>
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>
TBD
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
TBD
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<?rfc include="reference.RFC.5226"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3552"?>
<?rfc include="reference.RFC.7515"?>
<?rfc include="reference.RFC.7517"?>
<?rfc include="reference.RFC.6962"?>
<reference anchor="OpenID.Core"
target="http://openid.net/specs/openid-connect-core-1_0.html">
<front>
<title>OpenID Connect Discovery 1.0</title>
<author fullname="Nat Sakimura" initials="N."
surname="Sakimura">
<organization abbrev="NRI">Nomura Research Institute,
Ltd.
</organization>
</author>
<author fullname="John Bradley" initials="J."
surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity
</organization>
</author>
<author fullname="Michael B. Jones" initials="M.B."
surname="Jones">
<organization abbrev="Microsoft">Microsoft
</organization>
</author>
<author fullname="Breno de Medeiros" initials="B."
surname="de Medeiros">
<organization abbrev="Google">Google</organization>
</author>
<author fullname="Chuck Mortimore" initials="C."
surname="Mortimore">
<organization abbrev="Salesforce">Salesforce
</organization>
</author>
<date day="3" month="August" year="2015"/>
</front>
</reference>
<reference anchor="OpenID.Discovery"
target="http://openid.net/specs/openid-connect-discovery-1_0.html">
<front>
<title>OpenID Connect Discovery 1.0</title>
<author fullname="Nat Sakimura" initials="N."
surname="Sakimura">
<organization abbrev="NRI">Nomura Research Institute,
Ltd.
</organization>
</author>
<author fullname="John Bradley" initials="J."
surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity
</organization>
</author>
<author fullname="Michael B. Jones" initials="M.B."
surname="Jones">
<organization abbrev="Microsoft">Microsoft
</organization>
</author>
<author fullname="Edmund Jay" initials="E." surname="Jay">
<organization abbrev="Illumila">Illumila</organization>
</author>
<date day="3" month="August" year="2015"/>
</front>
</reference>
<reference anchor="OpenID.Registration"
target="http://openid.net/specs/openid-connect-registration-1_0.html">
<front>
<title>OpenID Connect Dynamic Client Registration 1.0
</title>
<author fullname="Nat Sakimura" initials="N."
surname="Sakimura">
<organization abbrev="NRI">Nomura Research Institute,
Ltd.
</organization>
</author>
<author fullname="John Bradley" initials="J."
surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity
</organization>
</author>
<author fullname="Michael B. Jones" initials="M.B."
surname="Jones">
<organization abbrev="Microsoft">Microsoft
</organization>
</author>
<date day="3" month="August" year="2015"/>
</front>
</reference>
</references>
<!-- Here we use entities that we defined at the beginning. -->
<section anchor="app-additional" title="Example">
<t>
The necessary steps for adding a Relying Party to a federation
</t>
<t>
The following JWKS represents the signing key that
the Federation Operator is using in the following example:
</t>
<figure>
<artwork><![CDATA[
{
"keys": [
{
"d": "DpFZnXz8fcKmOxFPfPdh3aZz44U2ZWm1Mxy6CiqHYcA80KVAY-wrjKFV4e
iSl9JENpoWXax4dpMcyJa2TdAXL9-4WqGNQAPRvdOfHcJM_uaBSGZwsuqAqZi_0sbNxurG
gbjKV38ra-iz42fcSXHCgNdMJjCi3VixS8iASHGU82R6mYyVeMWdX_j2RG--41PDxud4xS
YCKDuR6s2qlLVXyCZqFu_Yzl5zChiNxZJ_ggcxyL6i_hngi1oSbbVjgNKTcJNaIdOfzzcn
Ud5J9GP941-tylwg7NC3gRo1bXlUx6HFx3LkYe1PdroHhQd92RPyJdPqHDfbizJ4sjXN4c
Nq-Q",
"e": "AQAB",
"kid": "uZX0-P1-TMsZRqK1SeXpdLgsLoeUNskN2W_rwBNKAtc",
"kty": "RSA",
"n": "rqJ_CFECPF2nBD1eXkFonJo5gGcbnCvDudm_-7f1thcQqiuY2Xz0eKqQ2H
P3Nw-wP5q2hKbNVgAQSBbMp_AgNwRFmboJKF4cFEr3ZtmvO94bM6L15vUR2HNyX-4LaZ6S
9u35jSikOVJDt1BK-72w_DKeb8O8qa2dl9k7F6QZJQT6Nfh5rEALQLOZgwBgZAUpu2tQUh
3TFpwe3J_rQtCBbI3r0W1XoM1pD3EXTm9MI_aANRL82rh7_ZqLwGeBprD3F6ns9i5-psQ0
UZ-2eVjN6J1um40U6ysu3QjFUZEwb0yxNVx2D9bzOPMHwo6GAzePhJ46rI8NQ0NwJdB7lN
vrhw",
"p": "y4VcmM4QZoIjsGlTE7jvkJzYAud9Hz3uexVdeTShHnS-btLySSP70EWdvI
CkHK7Z4KikNZaD3cET978LmkoG03WZcs7iEEg7hQ0N7ePMv7P1w6X1Z2_IeWml0c4iFSMa
GPJk8a65HgBZ8fYPXFtERI7e1M--oqCrsTFikP8wYQU",
"q": "26pTV-JNgwx3LMrqEKIoIvHwLKfjFouRZXtTnOJP9G9BZ9vhAn1qX06M-x
W02G3qGzhQEpNZKMj54APNcqkg4PH1wMJmJ-cs1T44KoNhhihoHd6awT7PGNMo9I728CwY
fkM3ZW-BsgGBzQcfdI043cV3ebXzIEWwPbqTR44p8Bs",
"use": "sig"
}
]
}
]]></artwork>
</figure>
<section title="Relying Party joining a federation">
<section title="Step 1 - Developer creates its signing key pair.">
<t>
Developer creates its signing key pair.
<figure>
<artwork><![CDATA[
{
"keys": [
{
"d": "RJmqe2KiVOShoTMaZBmoMLkmeZY97PW3TOgSGDgZejL6I2qdhNlBAa3e9N
z6ggkWpxEy6IGNGetwNwS9aYA_Z6m45kaaUHXGKol_R_5s4TJryXUppxWDuHScE_dVcfzl
usm9Cq8J-U-xoaoKL36I3rakCJ_dWpsGNDpYSMenXcXuX-gJ5-HvSTETV5Bp23izUF4BH8
TSVWniD8Vk5Hv8EtWVqsqc7YmIG1zW_ctJhK7peymmNIVpcGpIxaT8agUOS-hcNxpN4AlY
rELn2twzq8tXp5bPZNiHHNXgzXANy5BgNFXXnZFqFiNiBn3agQxF2aiu4Ei5k5OidHTV8q
eGWQ",
"e": "AQAB",
"kid": "z414hVxt2-nkbqgG3VFYOZGB3Miwuhe75SfWT1BQQTc",
"kty": "RSA",
"n": "waDXGJwu9pV3gMY7rtpq3OYSAG1HZy7qilGC3ULMxJxjhSQCJ7M9PBC4uo
F_f5178FebpKBIoT3_YzqETt9Ry_6NA_mGBq6xtjEgnmNv6ktQj8hKI0tYheWRHMJIt2ay
8IwnV-3LD0Q_Nn7E3YgGaJUBlzDgJxQQcRVGFEOcFL-7TiKtVdPmPDGcSF7FivaGJO-MVq
mDkCsZVMTZoqmKeuaqbshsDjxy9GaiImQLe8tyzkhxEoG7qvovlGoV4AE8WroMinx0qWvg
lR8n041qQhrUMtoQMDCI53uLy6ZSR0jbNNEwvDBbiqD4Hm3piAwTUrGKWYLxbeicK_7A6g
F2Sw",
"p": "3SBEMBmIGztaOpCH-C9vwr80SyXm6M1uwCoKjBOiy_-kJ03jvacztd5CEO
cCvhRLVvl3rEYSP97DR_Eju-jlKWi92tbIECGvWzgszMHLdEdjvVvpJLlOSAfFMYsaPxa1
Sw2HS7RgoAwIxD5HVcdPK-3cJ5Gi0hInbz-ufrH4ru0",
"q": "4CphaFI0lSGr0HNifXJBN5JkXmCZp6WX06cI4pR_DwZAHTojc8dK1ECMHU
2oP2nPn1pmAVZj4p98vO0MfTxSgNB15EmDRkic_cmS-SenUUf7Pl3avJwpZq_qxYPqDajA
gWHuuci-2zKXRlKS_ZCz1MAmx-gV0We3AnletWV52xc",
"use": "sig"
}
]
}
]]></artwork>
</figure>
</t>
</section>
<section title="Step 2 - Developer submits registration data to FO">
<t>
The developer submits registration data to Federation Operator (FO).
</t>
<figure>
<artwork><![CDATA[
{
"contacts": [
],
"logo_uri": "https://example.com/logo.jpg",
"policy_uri": "https://example.com/policy.html",
"signing_key": {
"e": "AQAB",
"kid": "z414hVxt2-nkbqgG3VFYOZGB3Miwuhe75SfWT1BQQTc",
"kty": "RSA",
"n": "waDXGJwu9pV3gMY7rtpq3OYSAG1HZy7qilGC3ULMxJxjhSQCJ7M9PBC4uoF_
f5178FebpKBIoT3_YzqETt9Ry_6NA_mGBq6xtjEgnmNv6ktQj8hKI0tYheWRHMJIt2ay8I
wnV-3LD0Q_Nn7E3YgGaJUBlzDgJxQQcRVGFEOcFL-7TiKtVdPmPDGcSF7FivaGJO-MVqmD
kCsZVMTZoqmKeuaqbshsDjxy9GaiImQLe8tyzkhxEoG7qvovlGoV4AE8WroMinx0qWvglR
8n041qQhrUMtoQMDCI53uLy6ZSR0jbNNEwvDBbiqD4Hm3piAwTUrGKWYLxbeicK_7A6gF2
Sw",
"use": "sig"
},
"tos_uri": "https://example.com/tos.html"
}
]]></artwork>
</figure>
</section>
<section title="Step 3 - FO returns a signed software statement">
<t>
The FO returns a signed software statement containing
the submitted registration data, and any applied policy
restrictions like response_types, signing/encryption
algorithms to be used and additional specific policy parameters
like the ones specified above.
</t>
<t>
This is an example of a software statement constructed
by the FO before it is signed by the FO:
</t>
<figure>
<artwork><![CDATA[
{
"contacts": [
],
"exp": 1462438820,
"iat": 1462438820,
"iss": "https://swamid.sunet.se/",
"jti": "e920396fc2cb4ac0aaeb229674fd286a",
"kid": "uZX0-P1-TMsZRqK1SeXpdLgsLoeUNskN2W_rwBNKAtc",
"logo_uri": "https://example.com/logo.jpg",
"policy_uri": "https://example.com/policy.html",
"response_types": [
"code",
"code id_token",
"token"
],
"scopes": [
"openid",
"email",
"phone"
],
"signing_key": {
"e": "AQAB",
"kid": "z414hVxt2-nkbqgG3VFYOZGB3Miwuhe75SfWT1BQQTc",
"kty": "RSA",
"n": "waDXGJwu9pV3gMY7rtpq3OYSAG1HZy7qilGC3ULMxJxjhSQCJ7M9PBC4uoF_
f5178FebpKBIoT3_YzqETt9Ry_6NA_mGBq6xtjEgnmNv6ktQj8hKI0tYheWRHMJIt2ay8I
wnV-3LD0Q_Nn7E3YgGaJUBlzDgJxQQcRVGFEOcFL-7TiKtVdPmPDGcSF7FivaGJO-MVqmD
kCsZVMTZoqmKeuaqbshsDjxy9GaiImQLe8tyzkhxEoG7qvovlGoV4AE8WroMinx0qWvglR
8n041qQhrUMtoQMDCI53uLy6ZSR0jbNNEwvDBbiqD4Hm3piAwTUrGKWYLxbeicK_7A6gF2
Sw",
"use": "sig"
},
"token_endpoint_auth_method": "private_key_jwt",
"tos_uri": "https://example.com/tos.html"
}
]]></artwork>
</figure>
<t>
The signed version of this software statement, or a link to it, is
then expected to be included in the RPs client registration request
before being signed by the developers signing key.
</t>
</section>
<section title="Step 4 - The RP gets a signing key">
<t>
The RP gets a signing key
<figure>
<artwork><![CDATA[
{
"keys": [
{
"d": "BA0bo5OR3ht2KGDeAUpZsKv-Jjo9IKpYA2x7yQhcIH3bt9T2495pXVAHLQ
XXnZpjMenz7WPx94ajxIh96Bt59AYx4AwAEaBnPzK8vXLIP-A92NP3HV7vk0p8KWsrEdDw
xBaypqRXxz7V5vPGQVnOGg2eKSlP5F4-HoGpU6xDRo8Lptcs5VNx0a9kKVqEu-YpQkc2z2
uLRjl8urOu471sks38U03wRwWDElepUI28jEjhPydVSQw-E5w3yKhHTZeh1mVdNMp7_8LD
zScP1Ah5VCRLFfrmx1bOXxXZWHpMD6vgghmaCQGmyhgEr3XNzHVlH4bfVI_2Vrxp6cxHpe
3iYw",
"e": "AQAB",
"kid": "Tvd2gF4mcNtiYx6FyOOH83Xj_MkF-8yn_rD2Gm06RxY",
"kty": "RSA",
"n": "2kCKMUluhKV2INV3dS89WQ305J6JL8OJQ1cPk3GQ20Zvraa3DCntNns1xy
9gynGYUQzom7LYAqcmpu7xFGNXH0gN8JyXcCiWl02IuD6lwS6N2d7y6xJm8-mUBiwVrAlh
wWL1Bf8JRycRUQ51c6Y8yYrUf2pjeIFQBQEfUhcjNg13L1OUDoWJizy5QhaTe4p2uezYhK
lKtSHC7T6Brs6kWJA57j8BY5Tx4p6cyWRGsN58XXfmWg1hA1LjVIwgtSBvax7KRGUY6TXO
d5Km2MvJgBOfqAYfh1z0wZRiBdUa0RzsXavf4HGjnwPknYcSY1MwKZCzz_W0_uAiGlHFlN
wLSQ",
"p": "5279rRhB4IBf5chMgrTVwsAEKWyEsRrIVs5xLFVA5rpOKLN6qGhLO6PU9j
msD7dYEa0IA-eTxVCCuMp09KEfyrRAn0OWpWdndu8IR_n2e4zZxBXbf4WuIeZwxfM5PqKi
5LOnp442CthmzbsVD2OLmlgSViWSAP9SLFOBGfniTqs",
"q": "8WtasUyu9D9StGJkgolHjofbMnxXzRqpnA-QSV71htsQD3wof-vda8e8Jk
DLPPfAYuVYieCHeJYGsT9EHAG1Nyyr9OMzFeo73N1FdKGIGihWHSuvW6sRr6FTta12ZMN7
Jkm3l2rQoZALgvMtdYdDGJ-D3gwusW5nNS3-xJqMPds",
"use": "sig"
}
]
}
]]></artwork>
</figure>
</t>
</section>
<section title="Step 5 - RP produces a client registration request">
<t>
The RP produces a client registration request
<figure>
<artwork><![CDATA[
{
"application_type": "web",
"jwks_uri_signed": "https://example.com/rp1/jwks.jws",
"redirect_uris": [
"https://example.com/rp1/callback"
],
"response_types": [
"code"
],
"signing_key": {
"e": "AQAB",
"kid": "Tvd2gF4mcNtiYx6FyOOH83Xj_MkF-8yn_rD2Gm06RxY",
"kty": "RSA",
"n": "2kCKMUluhKV2INV3dS89WQ305J6JL8OJQ1cPk3GQ20Zvraa3DCntNns1xy9g
ynGYUQzom7LYAqcmpu7xFGNXH0gN8JyXcCiWl02IuD6lwS6N2d7y6xJm8-mUBiwVrAlhwW
L1Bf8JRycRUQ51c6Y8yYrUf2pjeIFQBQEfUhcjNg13L1OUDoWJizy5QhaTe4p2uezYhKlK
tSHC7T6Brs6kWJA57j8BY5Tx4p6cyWRGsN58XXfmWg1hA1LjVIwgtSBvax7KRGUY6TXOd5
Km2MvJgBOfqAYfh1z0wZRiBdUa0RzsXavf4HGjnwPknYcSY1MwKZCzz_W0_uAiGlHFlNwL
SQ",
"use": "sig"
}
}
]]></artwork>
</figure>
</t>
</section>
<section title="Step 6 - Developer produces software statement for RP">
<t>
Developer produces software statement based on client registration
request
<figure>
<artwork><![CDATA[
{
"application_type": "web",
"jwks_uri_signed": "https://example.com/rp1/jwks.jws",
"redirect_uris": [
"https://example.com/rp1/callback"
],
"response_types": [
"code"
],
"signing_key": {
"e": "AQAB",
"kid": "Tvd2gF4mcNtiYx6FyOOH83Xj_MkF-8yn_rD2Gm06RxY",
"kty": "RSA",
"n": "2kCKMUluhKV2INV3dS89WQ305J6JL8OJQ1cPk3GQ20Zvraa3DCntNns1xy9g
ynGYUQzom7LYAqcmpu7xFGNXH0gN8JyXcCiWl02IuD6lwS6N2d7y6xJm8-mUBiwVrAlhwW
L1Bf8JRycRUQ51c6Y8yYrUf2pjeIFQBQEfUhcjNg13L1OUDoWJizy5QhaTe4p2uezYhKlK
tSHC7T6Brs6kWJA57j8BY5Tx4p6cyWRGsN58XXfmWg1hA1LjVIwgtSBvax7KRGUY6TXOd5
Km2MvJgBOfqAYfh1z0wZRiBdUa0RzsXavf4HGjnwPknYcSY1MwKZCzz_W0_uAiGlHFlNwL
SQ",
"use": "sig"
},
"software_statements": [
"eyJraWQiOiJ1WlgwLVAxLVRNc1pScUsxU2VYcGRMZ3NMb2VVTnNrTjJXX3J3Qk5LQ
XRjIiwiYWxnIjoiUlMyNTYifQ.eyJwb2xpY3lfdXJpIjogImh0dHBzOi8vZXhhbXBsZS5j
b20vcG9saWN5Lmh0bWwiLCAidG9rZW5fZW5kcG9pbnRfYXV0aF9tZXRob2QiOiAicHJpdm
F0ZV9rZXlfand0IiwgImNvbnRhY3RzIjogWyJkZXZfYWRtaW5AZXhhbXBsZS5jb20iXSwg
ImxvZ29fdXJpIjogImh0dHBzOi8vZXhhbXBsZS5jb20vbG9nby5qcGciLCAic2NvcGVzIj
ogWyJvcGVuaWQiLCAiZW1haWwiLCAicGhvbmUiXSwgImlhdCI6IDE0NjI0Mzg4MjAsICJp
c3MiOiAiaHR0cHM6Ly9zd2FtaWQuc3VuZXQuc2UvIiwgImtpZCI6ICJ1WlgwLVAxLVRNc1
pScUsxU2VYcGRMZ3NMb2VVTnNrTjJXX3J3Qk5LQXRjIiwgImp0aSI6ICJlOTIwMzk2ZmMy
Y2I0YWMwYWFlYjIyOTY3NGZkMjg2YSIsICJyZXNwb25zZV90eXBlcyI6IFsiY29kZSIsIC
Jjb2RlIGlkX3Rva2VuIiwgInRva2VuIl0sICJzaWduaW5nX2tleSI6IHsiZSI6ICJBUUFC
IiwgImtpZCI6ICJ6NDE0aFZ4dDItbmticWdHM1ZGWU9aR0IzTWl3dWhlNzVTZldUMUJRUV
RjIiwgImt0eSI6ICJSU0EiLCAidXNlIjogInNpZyIsICJuIjogIndhRFhHSnd1OXBWM2dN
WTdydHBxM09ZU0FHMUhaeTdxaWxHQzNVTE14SnhqaFNRQ0o3TTlQQkM0dW9GX2Y1MTc4Rm
VicEtCSW9UM19ZenFFVHQ5UnlfNk5BX21HQnE2eHRqRWdubU52Nmt0UWo4aEtJMHRZaGVX
UkhNSkl0MmF5OEl3blYtM0xEMFFfTm43RTNZZ0dhSlVCbHpEZ0p4UVFjUlZHRkVPY0ZMLT
dUaUt0VmRQbVBER2NTRjdGaXZhR0pPLU1WcW1Ea0NzWlZNVFpvcW1LZXVhcWJzaHNEanh5
OUdhaUltUUxlOHR5emtoeEVvRzdxdm92bEdvVjRBRThXcm9NaW54MHFXdmdsUjhuMDQxcV
FoclVNdG9RTURDSTUzdUx5NlpTUjBqYk5ORXd2REJiaXFENEhtM3BpQXdUVXJHS1dZTHhi
ZWljS183QTZnRjJTdyJ9LCAidG9zX3VyaSI6ICJodHRwczovL2V4YW1wbGUuY29tL3Rvcy
5odG1sIiwgImV4cCI6IDE0NjI0Mzg4MjB9.ZVnHkrdGqQTP36UXwZhb9hhcIc1hgkYNd8d
GsyS-uHojrr4lYqkAyDjCr39fJnGvRnJvm_-LQDBfaKFHyGjSCi97uQAN72lWC-FRs-wuE
D0abhgSEyrpDBSG0enNvIyOP_BEbo5xx950MJrlcmOT9s2MCI2KPKV4Rt8ZIJUdLO5kWPl
fzaHkRZenCnob7sKYY4mbFosrslT0ny51yFSbZLtvnc04dmR0Q8ccAYJkMfL4t-IIGrrKR
bDB6x52_gqJ8REgbhfiN6StM6jwiv_UydOjLXvFpsl5_5AZWWubNaIzj-4eCIpPFYjxBaO
Gcs0FsmD1irBDIAIQodidYoI6aA"
]
}
]]></artwork>
</figure>
and signs it.
We now have the signed software statement aka the metadata
that the RP will present to the OP
</t>
</section>
<section
title="Step 7 - RP sends a client registration request to an OP">
<t>
The RP sends a client registration request to the OP
<figure>
<artwork><![CDATA[
{
"redirect_uris": [
"https://example.com/rp1/callback"
],
"software_statement_uris": {
"https://swamid.sunet.se/":
"https://dev.example.com/rp1/idfed/swamid.jws",
}
}
]]></artwork>
</figure>
</t>
</section>
<section title="Step 8 - OP handles software statement">
<t>
The OP fetches the software statement from the URI
'https://dev.example.com/rp1/idfed/swamid.jws' and then goes about
unpacking the metadata. At this point in time the OP doesn't have
the necessary key to verify the signature of the metadata.