Source

connect / openid-connect-registration-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
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml.resource.org/authoring/rfc2629.dtd">
<rfc category="exp" docName="draft-openid-connect-registration-1_0"
     ipr="trust200902">
  <?rfc toc="yes" ?>

  <?rfc tocdepth="4" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc strict="no" ?>

  <?rfc iprnotified="no" ?>

  <?rfc private="Draft" ?>

  <front>
    <title abbrev="OpenID Connect Registration 1.0 draft 10">OpenID Connect
    Dynamic Client Registration 1.0 - draft 10</title>

    <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
      <organization abbrev="NRI">Nomura Research Institute,
      Ltd.</organization>

      <address>
        <email>n-sakimura@nri.co.jp</email>
      </address>
    </author>

    <author fullname="John Bradley" initials="J."
            surname="Bradley">
      <organization>Independent</organization>

      <address>
        <email>ve7jtb@ve7jtb.com</email>
      </address>
    </author>

    <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
      <organization abbrev="Microsoft">Microsoft</organization>

      <address>
        <email>mbj@microsoft.com</email>
      </address>
    </author>

    <date day="9" month="April" year="2012" />

    <abstract>
      <t>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
      protocol. It allows Clients to verify the identity of the End-User based
      on the authentication performed by an Authorization Server, as well as to
      obtain basic profile information about the End-User in an interoperable and 
      RESTful manner.</t>

      <t>This specification describes how an OpenID Client can obtain the necessary
       client credentials required by the OpenID Connect protocol suite.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>In order for an OpenID Connect Client to utilize OpenID services for
      a user, the Client needs to register with the OpenID Provider to acquire
      a Client ID and shared secret. This document describes how a new Client
      can register with the provider, and how a Client already in possession
      of a <spanx style="verb">client_id</spanx> can retrieve updated registration information.</t>

      <t>The Client Registration Endpoint may be co-resident with the token
      endpoint as an optimization in some deployments.</t>

      <section anchor="rnc" title="Requirements Notation and Conventions">
	<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>

	<t>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 anchor="terminology" title="Terminology">
	<t>This specification uses the terms "Access Token", "Refresh Token",
	"Authorization Code", "Authorization Grant", "Authorization Server",
	"Authorization Endpoint", "Client", "Client Identifier", "Client
	Secret", "Protected Resource", "Resource Owner", "Resource Server", and
	"Token Endpoint" defined by
	<xref target="OAuth2.0">OAuth 2.0</xref>,
	and the terms defined by
	<xref target="OpenID.Messages">OpenID Connect Messages 1.0</xref>.
	It defines no additional terms.</t>
      </section>
    </section>

    <section title="Client Registration Endpoint">
      <t>The Client Registration Endpoint is an OAuth 2.0 Protected Resource that returns registration information for
      the Client to configure itself for the OpenID Provider.</t>

      <t>The OpenID Provider may require an Access Token that is
      provisioned out-of-band (in a manner that is out of scope for
      this specification) in order to restrict registration requests
      to only authorized Clients.</t>

      <t>In order to support open registration, the Client
      Registration Endpoint SHOULD accept requests without OAuth 2.0
      Access Tokens.</t>

      <t>If an Access Token is required for Client registration, the Client Registration Endpoint
      MUST be able to accept Access Tokens in the manner described in the
      <xref target="OAuth.Bearer">Bearer Tokens</xref>
      specification.</t>

      <section title="Client Registration Request">
        <t>Clients MUST send requests encoded as a POST with the following
        parameters added to the HTTP request entity-body using
        "application/x-www-form-urlencoded" format:</t>

        <t><list style="hanging">
            
            <t hangText="type">REQUIRED.  Values <spanx style="verb">client_associate</spanx>
             (New Registrations),
            <spanx style="verb">client_update</spanx> (Updating parameters for an existing
            <spanx style="verb">client_id</spanx>).</t>

            <t hangText="client_id">OPTIONAL.  
            The registered parameters for this <spanx style="verb">client_id</spanx> 
            are updated. Used with <spanx style="verb">client_update</spanx>.</t>

            <t hangText="client_secret">OPTIONAL.  The <spanx style="verb">client_secret</spanx>
            used to authenticate requests that have 
            <spanx style="verb">client_update</spanx> as the value of the 
            <spanx style="verb">type</spanx> parameter.</t>
            
            <t hangText="access_token">OPTIONAL. An Access Token obtained
            out of band to authorize the registrant. This parameter is only used if the
            Client is provided the Access Token out of band.  This parameter
            MUST NOT be sent if the Access Token is sent in the HTTP
            Authorization header as described in Section 7.1 of <xref
            target="OAuth2.0">OAuth 2.0</xref>. Access Tokens sent in the
            authorization header must be <xref
            target="OAuth.Bearer">Bearer Tokens</xref>.</t>

            <t hangText="contacts">OPTIONAL.  Space delimited list of email
            addresses for people allowed to administer the information for this Client.
            This is used by some providers to enable a web UI to modify the 
            Client information.</t>

            <t hangText="application_type">OPTIONAL.  <spanx style="verb">native</spanx>
            or <spanx style="verb">web</spanx>.</t>

            <t hangText="application_name">OPTIONAL.  Name of the Client
            to be presented to the user.</t>

            <t hangText="logo_url">OPTIONAL. The URL that references the logo for the 
            client application</t>

            <t hangText="redirect_uris">RECOMMENDED for Clients using the <spanx style="verb">code</spanx> flow with
            a query parameter encoded response.
            REQUIRED for Clients requesting implicit flow 
            fragment encoded responses as 
            defined in <xref target="OAuth2.0">OAuth 2.0</xref>. 
            A space-delimited list of redirect URIs.
            One of the URL MUST match the Scheme, Host, and Path segments of the 
            <spanx style="verb">redirect_uri</spanx> in the authorization request.</t>

            <t hangText="token_endpoint_auth_type">OPTIONAL.  The requested authentication
            type for the Token Endpoint. The options are <spanx style="verb">client_secret_post</spanx>, 
            <spanx style="verb">client_secret_basic</spanx>, <spanx style="verb">client_secret_jwt</spanx>, and <spanx style="verb">private_key_jwt</spanx>, as described in
            Section 2.2.1 of <xref
	        target="OpenID.Messages">OpenID Connect Messages 1.0</xref>.
            Other Authentication methods may be defined by extension. If unspecified or
             omitted, the default is <spanx style="verb">client_secret_basic</spanx> HTTP Basic Authentication 
             Scheme as specified in
            section 2.3.1 of <xref target="OAuth2.0">OAuth 2.0</xref>.</t>

            <t hangText="policy_url">OPTIONAL.  A URL location that the Relying 
            Party Client provides to the End-User to read about the how the
            profile data will be used. The OpenID Provider SHOULD display this
            URL to the End-User if it is given.</t>

            <t hangText="jwk_url">OPTIONAL.  URL for the Client's <xref
            target="JWK">JSON Web Key</xref> document
	    that is used for <xref target="JWS">JWS</xref>
            signing of Token Endpoint Requests and OpenID Request Objects.
            If <spanx style="verb">jwk_encryption_url</spanx> is not 
            provided it is also used for <xref target="JWE">JWE</xref> encryption 
            of ID Token and User Info Endpoint Responses to the Client.
            If the Client registers both <spanx style="verb">x509_url</spanx>
	    and <spanx style="verb">jwk_url</spanx>,
	    the keys contained in both formats SHOULD be the same.</t>

            <t hangText="jwk_encryption_url">OPTIONAL.  URL for the Client's <xref
            target="JWK">JSON Web Key</xref>
	    that is used for <xref target="JWE">JWE</xref> encryption
	    of ID Token and User Info Endpoint Responses to the Client.
            If the Client registers both <spanx style="verb">jwk_encryption_url</spanx>
	    and <spanx style="verb">x509_encryption_url</spanx>,
            the keys contained in both formats SHOULD be the same.</t>

            <t hangText="x509_url">OPTIONAL.  URL for the Client's PEM encoded X.509
            Certificate or Certificate chain
	    that is used for <xref target="JWE">JWS</xref> 
            signing of Token Endpoint Requests and OpenID Request Objects.
            If <spanx style="verb">x509_encryption_url</spanx> is not 
            provided, <spanx style="verb">x509_url</spanx>
	    it is also used for <xref target="JWE">JWE</xref> encryption 
            of ID Token and User Info Endpoint Responses to the Client.
            If the Client registers both <spanx style="verb">x509_url</spanx>
	    and <spanx style="verb">jwk_url</spanx>,
	    the keys contained in both formats SHOULD be the same.</t>
            
	    <t hangText="x509_encryption_url">OPTIONAL.  URL for the Client's PEM encoded X.509
            Certificate or Certificate chain
	    that is used for <xref target="JWE">JWE</xref> encryption 
            of ID Token and User Info Endpoint Responses to the Client. 
            If the Client registers both <spanx style="verb">jwk_encryption_url</spanx>
	    and <spanx style="verb">x509_encryption_url</spanx>,
            the keys contained in both formats SHOULD be the same.</t>
            
            <t hangText="sector_identifier_url">OPTIONAL. A HTTPS scheme URL to be used in
            calculating Pseudonymous Identifiers by the OP. The URL contains a
            file with a single JSON array of <spanx style="verb">redirect_uri</spanx> values.
            Please see <xref target="sector.identifier.url.verification" />.
	    </t>
            
            <t hangText="user_id_type">OPTIONAL. The <spanx style="verb">user_id_type</spanx> requested for 
            responses to this <spanx style="verb">client_id</spanx>. The
	    <spanx style="verb">user_id_types_supported</spanx> element of discovery 
            contains a list of the supported <spanx style="verb">user_id_type</spanx>
	    values for this server. Valid types include
	    <spanx style="verb">pairwise</spanx> and
	    <spanx style="verb">public</spanx>.</t>
            
            <t hangText="require_signed_request_object">OPTIONAL.  The <xref target="JWS">JWS</xref> <spanx style="verb">alg</spanx>
             algorithm that MUST be required by the Authorization Server.
             The valid values are listed in <xref target="JWA">JWA Section 3, Table 1.</xref> 
             All OpenID Request Objects from
             this <spanx style="verb">client_id</spanx> MUST be rejected if not signed by this algorithm.</t>
              
             <t hangText="userinfo_signed_response_alg">OPTIONAL.  The <xref target="JWS">JWS</xref> <spanx style="verb">alg</spanx>
             algorithm required for UserInfo responses. 
             The valid values are listed in <xref target="JWA">JWA Section 3, Table 1.</xref> 
             If this is specified the response will be 
             <xref target="JWT">JWT</xref> serialized, and signed using <xref target="JWS">JWS</xref>.</t>
             
             <t hangText="userinfo_encrypted_response_alg">OPTIONAL. The <xref target="JWE">JWE</xref> 
             <spanx style="verb">alg</spanx> 
             algorithm required for UserInfo responses. 
             The valid values are listed in <xref target="JWA">JWA Section 4, Table 2.</xref> 
             If this is requested in combination with signing the response 
             will be signed then encrypted. If this is specified the response will be 
             <xref target="JWT">JWT</xref> serialized, and encrypted using <xref target="JWE">JWE</xref>.</t>
             
             <t hangText="userinfo_encrypted_response_enc">OPTIONAL.  The <xref target="JWE">JWE</xref> 
			<spanx style="verb">enc</spanx>
             algorithm required for symmetric encryption of UserInfo responses.
             The valid values are listed in <xref target="JWA">JWA Section 4, Table 3.</xref> 
             If <spanx style="verb">"userinfo_encrypted_response_alg"</spanx> is specified 
             the default for this value is <spanx style="verb">A128CBC</spanx>.
             If this is requested in combination with signing the response 
             will be signed then encrypted. If this is specified the response will be 
             <xref target="JWT">JWT</xref> serialized, and encrypted using <xref target="JWE">JWE</xref>.</t>
             
             <t hangText="userinfo_encrypted_response_int">OPTIONAL.  The <xref target="JWE">JWE</xref> 
			<spanx style="verb">int</spanx>
             algorithm required for integrity of UserInfo responses.
             The valid HMAC values are listed in <xref target="JWA">JWA Section 3, Table 1.</xref> 
             If <spanx style="verb">"userinfo_encrypted_response_alg"</spanx> is specified 
             and the <spanx style="verb">"userinfo_encrypted_response_enc"</spanx> 
             is not a AEAD algorithm,
             the default for this value is <spanx style="verb">HS256</spanx>.
             If this is requested in combination with signing the response 
             will be signed then encrypted. If this is specified the response will be 
             <xref target="JWT">JWT</xref> serialized, and encrypted using <xref target="JWE">JWE</xref>.</t>
             
             <t hangText="id_token_signed_response_alg">OPTIONAL.  The <xref target="JWS">JWS</xref> <spanx style="verb">alg</spanx>
             algorithm required for the ID Token issued to this
	     <spanx style="verb">client_id</spanx>.
	     The valid values are listed in <xref target="JWA">JWA Section 3, Table 1.</xref> 
	     The default if not specified is <spanx style="verb">HS256</spanx>
	     using the provided <spanx style="verb">client_secret</spanx>.</t>
             
             <t hangText="id_token_encrypted_response_alg">OPTIONAL.  The <xref target="JWE">JWE</xref> 
             <spanx style="verb">alg</spanx> 
             algorithm required for the ID Token issued to this <spanx style="verb">client_id</spanx>.
             The valid values are listed in <xref target="JWA">JWA Section 4, Table 2.</xref> 
             If this is requested the response will be signed then encrypted. 
             The default if not specified is no encryption.</t>
             
             <t hangText="id_token_encrypted_response_enc">OPTIONAL.  The <xref target="JWE">JWE</xref> 
			<spanx style="verb">enc</spanx>
             algorithm required for symmetric encryption of ID Token issued to this <spanx style="verb">client_id</spanx>. 
             The valid values are listed in <xref target="JWA">JWA Section 4, Table 3.</xref>
             If <spanx style="verb">"id_token_encrypted_response_alg"</spanx> is specified 
             the default for this value is <spanx style="verb">A128CBC</spanx>.
             If this is requested in combination with signing the response 
             will be signed then encrypted. If this is specified the response will be 
             <xref target="JWT">JWT</xref> serialized, and encrypted using <xref target="JWE">JWE</xref>.</t>
             
             <t hangText="id_token_encrypted_response_int">OPTIONAL.  The <xref target="JWE">JWE</xref> 
			<spanx style="verb">int</spanx>
             algorithm required for integrity of ID Token issued to this <spanx style="verb">client_id</spanx>.
             The valid HMAC values are listed in <xref target="JWA">JWA Section 3, Table 1.</xref> 
             If <spanx style="verb">"id_token_encrypted_response_alg"</spanx> is specified 
             and the <spanx style="verb">"id_token_encrypted_response_enc"</spanx> 
             is not a AEAD algorithm,
             the default for this value is <spanx style="verb">HS256</spanx>.
             If this is requested in combination with signing the response 
             will be signed then encrypted. If this is specified the response will be 
             <xref target="JWT">JWT</xref> serialized, and encrypted using <xref target="JWE">JWE</xref>.</t>
             
             <t hangText="default_max_age">OPTIONAL. (default max authentication age):  
                  Type: Integer 
                  - Specifies that the End-User must be actively authenticated if
                  any present authentication is older than the specified
                  number of seconds. (The <spanx style="verb">max_age</spanx> request parameter
                  corresponds to the OpenID 2.0
                  PAPE <spanx style="verb">max_auth_age</spanx>
                  request parameter.) The <spanx style="verb">max_age</spanx> claim in the 
                  request object overrides this default value.</t>
            
            <t hangText="require_auth_time">OPTIONAL. (default max authentication age):  
                  Type: Logical 
                  -  If the value is true, then the <spanx style="verb">auth_time</spanx> 
                  claim in the <spanx style="verb">id_token</spanx> is REQUIRED. 
                  The returned Claim Value is the number of seconds from 
                  1970-01-01T0:0:0Z as measured in UTC until the date/time that the 
                  End-User authentication occurred. (The auth_time Claim semantically 
                  corresponds to the OpenID 2.0 PAPE auth_time response parameter.) 
                  The auth_time claim request in the request object overrides this setting.</t>
                  
            <t hangText="default_acr">OPTIONAL. (default authentication context class reference):  
                  Type: String 
                  - Specifies the default value that the Authorization server must use 
                  for processing requests from this client.  The <spanx style="verb">
                  acrs_supported</spanx> element of discovery 
                  contains a list of the supported <spanx style="verb">acr</spanx>
	              values for this server.
                  The <spanx style="verb">acr</spanx> claim in the 
                  request object overrides this default value.</t>

          </list></t>
          
          <t>Following is a non-normative example request:</t>
          
          <t><figure>
            <artwork><![CDATA[POST /connect/register HTTP/1.1
Accept: application/x-www-form-urlencoded
Host: server.example.com

type=client_associate
&redirect_uris=https://client.example.com/callback%20https://client.example.com/callback2
&logo_url=https://client.example.com/logo.png
&user_id_type=pairwise
&sector_identifier_url=https://othercompany.com/file_of_redirect_uris_for_our_sites.js
&token_endpoint_auth_type=client_secret_basic
&jwk_url=https://client.example.com/my_rsa_public_key.jwk
&userinfo_encrypted_response_algs=RSA1_5%20A128CBC]]></artwork>
          </figure></t>

	<section anchor="sector.identifier.url.verification" title="sector_identifier_url Verification">
	  <t>Providers who use pairwise <spanx style="verb">user_id</spanx> values SHOULD support this element.</t>
	  <t>It provides a way for a group of websites under a single administrative control
	  to have consistent pairwise <spanx style="verb">user_id</spanx> values independent of the individual domain names.
	  It also provides a way for Clients to change <spanx style="verb">redirect_uri</spanx> domains without having to 
	  reregister all of their users.</t>

	  <t>This is further described in Section 2.5.1 of <xref target="OpenID.Messages">OpenID Connect Messages 1.0</xref>.</t>

	  <t>The value of the <spanx style="verb">sector_identifier_url</spanx>
	  must be a HTTPS scheme URL that identifies
	  a JSON file containing an array containing <spanx style="verb">redirect_uri</spanx> values.
	  The Registration Server MUST perform a TLS/SSL server certificate check, per
	  <xref target="RFC6125">RFC 6125</xref>.
	  </t>

	  <t>The values of the registered <spanx style="verb">redirect_uris</spanx>
	  must be included in the elements of the array,
	  or registration MUST fail.</t>

	  <t><figure>
	    <artwork><![CDATA[GET /connect/sector_identifier.js HTTP/1.1
Accept: application/json
Host: client.example.com

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

[ "https://client.example.com/callback",
  "https://client.example.com/callback2",
  "https://client.other_company.com/callback" ]]]></artwork>
	  </figure></t>
	</section>
      </section>

      <section title="Client Registration Response">
        <t>The response is returned as a JSON object with all the parameters
        as top level elements.</t>

        <t><list style="hanging">
            <t hangText="client_id">REQUIRED. The unique Client
            identifier.</t>

            <t hangText="client_secret">REQUIRED. The Client secret. This
            should change with each response.</t>

            <t hangText="expires_at">REQUIRED. The number of
            seconds from 1970-01-01T0:0:0Z as measured in UTC that the <spanx style="verb">client_id</spanx>
            and <spanx style="verb">client_secret</spanx> will expire or <spanx style="verb">0</spanx> if
            they do not expire. See <xref target="RFC3339">RFC 3339</xref>
            for details regarding date/times in general and UTC in particular.</t>
          </list></t>

        <t>Following is a non-normative example response:</t>

        <t><figure>
            <artwork><![CDATA[HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
 "client_id":"s6BhdRkqt3",
 "client_secret":"cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c93f31185e5885805d",
 "expires_at":2893276800
}]]></artwork>
          </figure></t>
      </section>

      <section title="Client Registration Error Response">
      <t>When an error condition occurs, the Client Registration Endpoint returns
	      an Error Response as defined in Section 3 of
	      the <xref target="OAuth.Bearer">OAuth 2.0 Bearer Tokens</xref> specification.</t>
      
      <t>In addition to the error codes defined in Section 3.1 of <xref
          target="OAuth.Bearer">OAuth 2.0 Bearer Tokens</xref>, this specification defines the
          following error codes:</t>

          <t><list style="hanging">
          
          <t hangText="invalid_type">The value of <spanx style="verb">type</spanx> is invalid or not supported.</t>
          
          <t hangText="invalid_client_id">The value of <spanx style="verb">client_id</spanx> is invalid.</t>
          
          <t hangText="invalid_client_secret">The <spanx style="verb">client_secret</spanx> provided for a 
            <spanx style="verb">client_update</spanx> is not valid for the provided <spanx style="verb">client_id</spanx>.</t>
            
           <t hangText="invalid_configuration_parameter">The value of one of the configuration parameters is invalid.</t>
	       </list></t>
	        

	<t><figure>
	    <preamble>Following is a non-normative example of an error
	    response:</preamble>

	    <artwork><![CDATA[HTTP/1.1 400 Bad Request
WWW-Authenticate: Bearer realm="example.com",
  error="invalid_client_secret",
  error_description="The client_secret is wrong for this client_id"]]></artwork>
	</figure></t>
      </section>
    </section>

    <section anchor="stringops" title="String Operations">

      <t>
	Processing some OpenID Connect messages requires comparing
	values in the messages to known values. For example, the
	member names in the Client registration response might be
	compared to specific member names such as <spanx
	style="verb">client_id</spanx>.  Comparing Unicode strings,
	however, has significant security implications.
       </t>
      <t>
	Therefore, comparisons between JSON strings and other Unicode
	strings MUST be performed as specified below:

	<list style="numbers">

          <t>
	    Remove any JSON applied escaping to produce an array of
	    Unicode code points.
	  </t>
          <t>
	    <xref target="USA15">Unicode Normalization</xref> MUST NOT
	    be applied at any point to either the JSON string or to
	    the string it is to be compared against.
	  </t>
          <t>
	    Comparisons between the two strings MUST be performed as a
	    Unicode code point to code point equality comparison.
	  </t>

        </list>
      </t>
      <t>
	In several places, this specification uses space delimited
	lists of strings.  In all such cases, only the ASCII space
	character (0x20) MAY be used for this purpose.
      </t>

    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no requests of IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Since requests to the Client Registration Endpoint result in the
      transmission of clear-text credentials (in the HTTP request and
      response), the server MUST require the use of a transport-layer security
      mechanism when sending requests to the Registration Endpoint. The server MUST
      support TLS 1.2 <xref target="RFC5246">RFC 5246</xref> and/or
      TLS 1.0 <xref target='RFC2246' />
      and MAY support additional transport-layer mechanisms meeting its security
      requirements.
      When using TLS, the Client MUST perform a TLS/SSL server certificate check, per
      <xref target="RFC6125">RFC 6125</xref>.
      </t>
      <t>Requests to the Registration Endpoint for <spanx style="verb">client_update</spanx> MUST have some rate 
      limiting on failures to prevent the Client secret from being disclosed though
      repeated access attempts.</t>
      
      <t>In a situation where the Authorization Server is supporting open Client 
      registration, 
      it must be extremely careful with any URL provided by the Client that will 
      be displayed to the user (e.g. <spanx style="verb">logo_url</spanx> and
      <spanx style="verb">policy_url</spanx>). A rogue Client could 
      specify a registration request with a reference to a drive-by download in the 
      <spanx style="verb">policy_url</spanx>. The Authorization Server should check to see if the
      <spanx style="verb">logo_url</spanx> and <spanx style="verb">policy_url</spanx> have the 
      same host as the hosts defined in the array of <spanx style="verb">redirect_uris</spanx>.</t>
      
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125"?>

      <reference anchor="USA15">
        <front>
          <title>Unicode Normalization Forms</title>

          <author fullname="Mark Davis" initials="M." surname="Davis">
            <address>
              <email>markdavis@google.com</email>
            </address>
          </author>

          <author fullname="Ken Whistler" initials="K." surname="Whistler">
            <address>
              <email>ken@unicode.org</email>
            </address>
          </author>

          <author fullname="Martin D&uuml;rst" initials="M."
                  surname="D&uuml;rst"></author>

          <date day="03" month="09" year="2009" />
        </front>

        <seriesInfo name="Unicode Standard Annex" value="15" />
      </reference>

      <reference anchor="OpenID.Messages">
        <front>
          <title>OpenID Connect Messages 1.0</title>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NRI">Nomura Research Institute,
            Ltd.</organization>
          </author>

          <author fullname="David Recordon" initials="D." surname="Recordon">
            <organization abbrev="Facebook">Facebook</organization>
          </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization>Independent</organization>
          </author>

          <author fullname="Breno de Medeiros" initials="B."
                  surname="de Medeiros">
            <organization abbrev="Google">Google</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="27" month="February" year="2012" />
        </front>

        <format target="http://openid.net/specs/openid-connect-messages-1_0.html"
                type="HTML" />
      </reference>

      <reference anchor="JWA">
        <front>
          <title>JSON Web Algorithms</title>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <date day="12" month="March" year="2012" />
        </front>

        <format target="http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms"
                type="HTML" />
      </reference>
      
      <reference anchor="JWT">
        <front>
          <title>JSON Web Token</title>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <author fullname="Dirk Balfanz" initials="D." surname="Balfanz">
            <organization>Google</organization>
          </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Protoviti">Protoviti Government
            Services</organization>
          </author>

          <author fullname="Yaron Goland" initials="Y." surname="Goland">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <author fullname="John Panzer" initials="J." surname="Panzer">
            <organization>Google</organization>
          </author>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NRI">Nomura Research Institute,
            Ltd.</organization>
          </author>

          <author fullname="Paul Tarjan" initials="P." surname="Tarjan">
            <organization abbrev="Facebook">Facebook</organization>
          </author>

          <date day="12" month="March" year="2012" />
        </front>

        <format target="http://tools.ietf.org/html/draft-jones-json-web-token"
                type="HTML" />
      </reference>

      <reference anchor="JWS">
        <front>
          <title>JSON Web Signature</title>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Protoviti">Protoviti Government
            Services</organization>
          </author>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NRI">Nomura Research Institute,
            Ltd.</organization>
          </author>

          <date day="12" month="March" year="2012" />
        </front>

        <format target="http://tools.ietf.org/html/draft-ietf-jose-json-web-signature"
                type="HTML" />
      </reference>

      <reference anchor="JWE">
        <front>
          <title>JSON Web Encryption (JWE)</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization>Microsoft</organization>
	  </author>

	  <author fullname="Eric Rescorla" initials="E." surname="Rescorla">
	    <organization>RTFM, Inc.</organization>
	  </author>

	  <author fullname="Joe Hildebrand" initials="J." surname="Hildebrand">
	    <organization>Cisco Systems, Inc.</organization>
	  </author>

	  <date day="12" month="March" year="2012" />
        </front>

        <format target="http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption" type="HTML" />
      </reference>

      <reference anchor="JWK">
        <front>
	  <title>JSON Web Key (JWK)</title>

	  <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	    <organization>Microsoft</organization>
	  </author>

	  <date day="12" month="March" year="2012" />
        </front>

        <format target="http://tools.ietf.org/html/draft-ietf-jose-json-web-key" type="HTML" />
      </reference>

      <reference anchor="OAuth2.0">
        <front>
          <title>OAuth 2.0 Authorization Protocol</title>

          <author fullname="Eran Hammer" initials="E." role="editor"
                  surname="Hammer">
            <organization></organization>
          </author>

          <author fullname="David Recordon" initials="D." surname="Recordon">
            <organization abbrev="Facebook">Facebook</organization>
          </author>

          <author fullname="Dick Hardt" initials="D." surname="Hardt">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <date day="8" month="March" year="2012" />
        </front>

        <format target="http://tools.ietf.org/html/draft-ietf-oauth-v2"
                type="HTML" />
      </reference>
      
      <reference anchor="OAuth.Bearer">
        <front>
          <title>OAuth 2.0 Protocol: Bearer Tokens</title>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <author fullname="Dick Hardt" initials="D." surname="Hardt">
            <organization>Independent</organization>
          </author>

          <author fullname="David Recordon" initials="D." surname="Recordon">
            <organization>Facebook</organization>
          </author>

          <date day="12" month="March" year="2012" />
        </front>

        <format target="http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer"
                type="HTML" />
      </reference>
    </references>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t></t>
    </section>

    <section title="Notices">
      <t>Copyright (c) 2012 The OpenID Foundation.</t>
      <t>
	The OpenID Foundation (OIDF) grants to any Contributor, developer, 
	implementer, or other interested party a non-exclusive, royalty free, 
	worldwide copyright license to reproduce, prepare derivative works from, 
	distribute, perform and display, this Implementers Draft or 
	Final Specification solely for the purposes of (i) developing 
	specifications, and (ii) implementing Implementers Drafts and 
	Final Specifications based on such documents, provided that attribution 
	be made to the OIDF as the source of the material, but that such attribution 
	does not indicate an endorsement by the OIDF.
      </t>
      <t>
	The technology described in this specification was 
	made available from contributions from various sources, 
	including members of the OpenID Foundation and others.  
	Although the OpenID Foundation has taken steps to help ensure 
	that the technology is available for distribution, it takes 
	no position regarding the validity or scope of any intellectual 
	property or other rights that might be claimed to  pertain to 
	the implementation or use of the technology described in 
	this specification or the extent to which any license under 
	such rights might or might not be available; neither does it 
	represent that it has made any independent effort to identify 
	any such rights.  The OpenID Foundation and the contributors 
	to this specification make no (and hereby expressly disclaim any) 
	warranties (express, implied, or otherwise), including implied 
	warranties of merchantability, non-infringement, fitness for 
	a particular purpose, or title, related to this specification, 
	and the entire risk as to implementing this specification is 
	assumed by the implementer.  The OpenID Intellectual 
	Property Rights policy requires contributors to offer 
	a patent promise not to assert certain patent claims against 
	other contributors and  against implementers.  The OpenID Foundation invites 
	any interested party to bring to its attention any copyrights, 
	patents, patent applications, or other proprietary rights 
	that may cover technology that may be required to practice 
	this specification.
      </t>
    </section>

    <section title="Document History">
      <t>[[ To be removed from the final specification ]]</t>

      <t>-10<list style="symbols">
	  <t>Updated references.</t>
	  <t>Split encrypted response into two parameters and remove extra s from signed response</t>
	  <t>Add config paramater for encryption integrity algorithm</t>
	  <t>fixed Grammer in logo URL</t>
	  <t>Add reference to JWA</t>
	  <t>Updated Notices</t>
	</list></t>

      <t>-09<list style="symbols">
          <t>Removed erroneous spanx declarations from example</t>
          <t>Fixed example in Sec 2.2 to show expires_at</t>
          <t>Fixed Sec 2.1.1 to clarify it is the registration server doing the certificate check</t>
          <t>Fixed Sec 2.1.1 example to include http portion of response</t>
          <t>Fixed #542 Sec 2.1 userinfo_signed_response_algs fixed to say signature. Clarify response is signed.</t>
          <t>Fixed Sec 2.1 userinfo_encrypted_response_algs Clarify response is JWE containing JWT</t>
          <t>Fixes #529 Sec 2.3 Clarify error response is Bearer and fix example</t>
          <t>Add default_max_age registration parameter</t>
          <t>Add default_acr registration parameter</t>
          <t>Add require_auth_time registration parameter</t>
        </list></t>

      <t>-08<list style="symbols">
          <t>Replaced token_endpoint with a defined term Token Endpoint [OAuth 2.0]</t>
	  <t>Added policy_url parameter</t>
	  <t>Renamed expires_in but expires_at</t>
	  <t>Registration Endpoint can be OAuth Protected</t>
	  <t>Added parameters for requiring encryption and/or signing of OpenID Request Object, UserInfo and ID Token</t>
	  <t>Added token_endpoint_auth_type and list of valid authentication types</t>
	  <t>Added JWK and X509 URLs for signature and encryption</t>
	  <t>Added user_id_type </t>
	  <t>Changed sector_identifier to sector_identifier_url and added URL verification</t>
	  <t>Use RFC 6125 to verify TLS endpoints</t>
	  <t>Changed 'contact' to 'contacts', 'redirect_uri' to 'redirect_uris'</t>
	  <t>Changed redirect_uris to RECOMMENDED for code flow and REQUIRED for implicit flow Clients</t>
	  <t>Removed js_origin_uri</t>
	  <t>Added section about string comparison rules needed</t>
	  <t>Clarified redirect_uris matching</t>
          <t>Update John Bradley email and affiliation for Implementer's Draft</t>
        </list></t>

      <t>-07<list style="symbols">
          <t>Changed request from posting a JSON object to being HTTP
          Form encoded.</t>

          <t>Added x509_url to support optional encryption.</t>
        </list></t>

      <t>-06 <list style="symbols">
          <t>Changes associated with renaming "Lite" to "Basic Client" and
          replacing "Core" and "Framework" with "Messages" and "Standard".</t>

          <t>Numerous cleanups, including updating references.</t>
        </list></t>

      <t>-05 <list style="symbols">
          <t>Changed <spanx style="verb">redirect_url</spanx> to <spanx
          style="verb">redirect_uri</spanx> and <spanx style="verb">js_origin_url</spanx>
          to <spanx style="verb">js_origin_uri</spanx>.</t>
        </list></t>

      <t>-04 <list style="symbols">
          <t>Correct issues raised by Johnny Bufu and discussed on the
          7-Jul-11 working group call.</t>
        </list></t>

      <t>-03 <list style="symbols">
          <t>Incorporate working group decisions from 5-Jul-11 spec call.</t>

          <t>Consistency and cleanup pass, including removing unused
          references.</t>
        </list></t>

      <t>-02 <list style="symbols">
          <t>Incorporate working group decisions from 23-Jun-11 spec call.</t>
        </list></t>

      <t>-01 <list style="symbols">
          <t>Initial version.</t>
        </list></t>
    </section>
  </back>
</rfc>