Skip to content

Commit 4e3757e

Browse files
PothercaPotherca
committed
Add Enum class representing accepted values for OIDC Dynamic Client Registration.
1 parent 70283ec commit 4e3757e

1 file changed

Lines changed: 327 additions & 0 deletions

File tree

‎src/Enum/OpenId/DynamicClientRegistration.php‎

Lines changed: 327 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,327 @@
1+
<?php
2+
3+
namespace Pdsinterop\Solid\Auth\Enum\OpenId;
4+
5+
/**
6+
* Client Metadata
7+
*
8+
* As described in Section 2 of OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration]
9+
*
10+
* Only the `REDIRECT_URIS` value is required, all other values are optional.
11+
*
12+
* @see https://openid.net/specs/openid-connect-registration-1_0.html
13+
*/
14+
class DynamicClientRegistration
15+
{
16+
/**
17+
* Kind of the application. The default, if omitted, is web. The defined
18+
* values are native or web. Web Clients using the OAuth Implicit Grant Type
19+
* MUST only register URLs using the https scheme as redirect_uris; they
20+
* MUST NOT use localhost as the hostname. Native Clients MUST only register
21+
* redirect_uris using custom URI schemes or URLs using the http: scheme
22+
* with localhost as the hostname. Authorization Servers MAY place
23+
* additional constraints on Native Clients. Authorization Servers MAY
24+
* reject Redirection URI values using the http scheme, other than the
25+
* localhost case for Native Clients. The Authorization Server MUST verify
26+
* that all the registered redirect_uris conform to these constraints. This
27+
* prevents sharing a Client ID across different types of Clients.
28+
*/
29+
public const APPLICATION_TYPE = 'application_type';
30+
31+
/**
32+
* Name of the Client to be presented to the End-User. If desired,
33+
* representation of this Claim in different languages and scripts is
34+
* represented as described in Section 2.1.
35+
*/
36+
public const CLIENT_NAME = 'client_name';
37+
38+
/**
39+
* URL of the home page of the Client. The value of this field MUST point to
40+
* a valid Web page. If present, the server SHOULD display this URL to the
41+
* End-User in a followable fashion. If desired, representation of this
42+
* Claim in different languages and scripts is represented as described in
43+
* Section 2.1.
44+
*/
45+
public const CLIENT_URI = 'client_uri';
46+
47+
/**
48+
* URL of the home page of the Client. The value of this field MUST point to
49+
* a valid Web page. If present, the server SHOULD display this URL to the
50+
* End-User in a followable fashion. If desired, representation of this
51+
* Claim in different languages and scripts is represented as described in
52+
* Section 2.1.
53+
*/
54+
public const CONTACTS = 'contacts';
55+
56+
/**
57+
* Default requested Authentication Context Class Reference values. Array of strings that specifies the default acr values that the OP is being requested to use for processing requests from this Client, with the values appearing in order of preference. The Authentication Context Class satisfied by the authentication performed is returned as the acr Claim Value in the issued ID Token. The acr Claim is requested as a Voluntary Claim by this parameter. The acr_values_supported discovery element contains a list of the supported acr values supported by this server. Values specified in the acr_values request parameter or an individual acr Claim request override these default values.
58+
*/
59+
public const DEFAULT_ACR_VALUES = 'default_acr_values';
60+
61+
/**
62+
* Default Maximum Authentication Age. Specifies that the End-User MUST be actively authenticated if the End-User was authenticated longer ago than the specified number of seconds. The max_age request parameter overrides this default value. If omitted, no default Maximum Authentication Age is specified.
63+
*/
64+
public const DEFAULT_MAX_AGE = 'default_max_age';
65+
66+
/**
67+
* JSON array containing a list of the OAuth 2.0 Grant Types that the Client
68+
* is declaring that it will restrict itself to using. The Grant Type values
69+
* used by OpenID Connect are:
70+
*
71+
* - authorization_code: The Authorization Code Grant Type described in OAuth 2.0 Section 4.1.
72+
* - implicit: The Implicit Grant Type described in OAuth 2.0 Section 4.2.
73+
* - refresh_token: The Refresh Token Grant Type described in OAuth 2.0 Section 6.
74+
*
75+
* The following table lists the correspondence between response_type values
76+
* that the Client will use and grant_type values that MUST be included in
77+
* the registered grant_types list:
78+
*
79+
* - code : authorization_code
80+
* - id_token : implicit
81+
* - token id_token : implicit
82+
* - code id_token : authorization_code, implicit
83+
* - code token : authorization_code, implicit
84+
* - code token id_token : authorization_code, implicit
85+
*
86+
* If omitted, the default is that the Client will use only the authorization_code Grant Type.
87+
*/
88+
public const GRANT_TYPES = 'grant_types';
89+
90+
/**
91+
* JWE alg algorithm [JWA] REQUIRED for encrypting the ID Token issued to
92+
* this Client. If this is requested, the response will be signed then
93+
* encrypted, with the result being a Nested JWT, as defined in [JWT].
94+
* The default, if omitted, is that no encryption is performed.
95+
*/
96+
public const ID_TOKEN_ENCRYPTED_RESPONSE_ALG = 'id_token_encrypted_response_alg';
97+
98+
/**
99+
* JWE enc algorithm [JWA] REQUIRED for encrypting the ID Token issued to
100+
* this Client. If id_token_encrypted_response_alg is specified, the default
101+
* for this value is A128CBC-HS256. When id_token_encrypted_response_enc is
102+
* included, id_token_encrypted_response_alg MUST also be provided.
103+
*/
104+
public const ID_TOKEN_ENCRYPTED_RESPONSE_ENC = 'id_token_encrypted_response_enc';
105+
106+
/**
107+
* JWS alg algorithm [JWA] REQUIRED for signing the ID Token issued to this
108+
* Client. The value none MUST NOT be used as the ID Token alg value unless
109+
* the Client uses only Response Types that return no ID Token from the
110+
* Authorization Endpoint (such as when only using the Authorization Code
111+
* Flow). The default, if omitted, is RS256. The public key for validating
112+
* the signature is provided by retrieving the JWK Set referenced by the
113+
* jwks_uri element from OpenID Connect Discovery 1.0 [OpenID.Discovery].
114+
*/
115+
public const ID_TOKEN_SIGNED_RESPONSE_ALG = 'id_token_signed_response_alg';
116+
117+
/**
118+
* URI using the https scheme that a third party can use to initiate a login
119+
* by the RP, as specified in Section 4 of OpenID Connect Core 1.0 [OpenID.Core].
120+
*
121+
* The URI MUST accept requests via both GET and POST. The Client MUST
122+
* understand the login_hint and iss parameters and SHOULD support the
123+
* target_link_uri parameter.
124+
*/
125+
public const INITIATE_LOGIN_URI = 'initiate_login_uri';
126+
127+
/**
128+
* Client's JSON Web Key Set [JWK] document, passed by value. The semantics
129+
* of the jwks parameter are the same as the jwks_uri parameter, other than
130+
* that the JWK Set is passed by value, rather than by reference. This
131+
* parameter is intended only to be used by Clients that, for some reason,
132+
* are unable to use the jwks_uri parameter, for instance, by native
133+
* applications that might not have a location to host the contents of the
134+
* JWK Set. If a Client can use jwks_uri, it MUST NOT use jwks. One
135+
* significant downside of jwks is that it does not enable key rotation
136+
* (which jwks_uri does, as described in Section 10 of OpenID Connect Core
137+
* 1.0 [OpenID.Core]). The jwks_uri and jwks parameters MUST NOT be used
138+
* together.
139+
*/
140+
public const JWKS = 'jwks';
141+
142+
/**
143+
* URL for the Client's JSON Web Key Set [JWK] document. If the Client signs
144+
* requests to the Server, it contains the signing key(s) the Server uses to
145+
* validate signatures from the Client. The JWK Set MAY also contain the
146+
* Client's encryption keys(s), which are used by the Server to encrypt
147+
* responses to the Client. When both signing and encryption keys are made
148+
* available, a use (Key Use) parameter value is REQUIRED for all keys in
149+
* the referenced JWK Set to indicate each key's intended usage. Although
150+
* some algorithms allow the same key to be used for both signatures and
151+
* encryption, doing so is NOT RECOMMENDED, as it is less secure. The JWK
152+
* x5c parameter MAY be used to provide X.509 representations of keys
153+
* provided. When used, the bare key values MUST still be present and MUST
154+
* match those in the certificate.
155+
*/
156+
public const JWKS_URI = 'jwks_uri';
157+
158+
/**
159+
* URL that references a logo for the Client application. If present, the
160+
* server SHOULD display this image to the End-User during approval. The
161+
* value of this field MUST point to a valid image file. If desired,
162+
* representation of this Claim in different languages and scripts is
163+
* represented as described in Section 2.1.
164+
*/
165+
public const LOGO_URI = 'logo_uri';
166+
167+
168+
/**
169+
* URL that the Relying Party Client provides to the End-User to read about
170+
* the how the profile data will be used. The value of this field MUST point
171+
* to a valid web page. The OpenID Provider SHOULD display this URL to the
172+
* End-User if it is given. If desired, representation of this Claim in
173+
* different languages and scripts is represented as described in Section 2.1.
174+
*/
175+
public const POLICY_URI = 'policy_uri';
176+
177+
/**
178+
* Array of Redirection URI values used by the Client. One of these
179+
* registered Redirection URI values MUST exactly match the redirect_uri
180+
* parameter value used in each Authorization Request, with the matching
181+
* performed as described in Section 6.2.1 of [RFC3986] (Simple String
182+
* Comparison).
183+
*/
184+
public const REDIRECT_URIS = 'redirect_uris';
185+
186+
/**
187+
* JWE [JWE] alg algorithm [JWA] the RP is declaring that it may use for
188+
* encrypting Request Objects sent to the OP. This parameter SHOULD be
189+
* included when symmetric encryption will be used, since this signals to
190+
* the OP that a client_secret value needs to be returned from which the
191+
* symmetric key will be derived, that might not otherwise be returned. The
192+
* RP MAY still use other supported encryption algorithms or send
193+
* unencrypted Request Objects, even when this parameter is present. If both
194+
* signing and encryption are requested, the Request Object will be signed
195+
* then encrypted, with the result being a Nested JWT, as defined in [JWT].
196+
* The default, if omitted, is that the RP is not declaring whether it might
197+
* encrypt any Request Objects.
198+
*/
199+
public const REQUEST_OBJECT_ENCRYPTION_ALG = 'request_object_encryption_alg';
200+
201+
/**
202+
* JWE enc algorithm [JWA] the RP is declaring that it may use for
203+
* encrypting Request Objects sent to the OP. If
204+
* request_object_encryption_alg is specified, the default for this value is
205+
* A128CBC-HS256. When request_object_encryption_enc is included,
206+
* request_object_encryption_alg MUST also be provided.
207+
*/
208+
public const REQUEST_OBJECT_ENCRYPTION_ENC = 'request_object_encryption_enc';
209+
210+
/**
211+
* JWS [JWS] alg algorithm [JWA] that MUST be used for signing Request
212+
* Objects sent to the OP. All Request Objects from this Client MUST be
213+
* rejected, if not signed with this algorithm. Request Objects are
214+
* described in Section 6.1 of OpenID Connect Core 1.0 [OpenID.Core].
215+
* This algorithm MUST be used both when the Request Object is passed by
216+
* value (using the request parameter) and when it is passed by reference
217+
* (using the request_uri parameter). Servers SHOULD support RS256. The
218+
* value none MAY be used. The default, if omitted, is that any algorithm
219+
* supported by the OP and the RP MAY be used.
220+
*/
221+
public const REQUEST_OBJECT_SIGNING_ALG = 'request_object_signing_alg';
222+
223+
/**
224+
* Array of request_uri values that are pre-registered by the RP for use at
225+
* the OP. Servers MAY cache the contents of the files referenced by these
226+
* URIs and not retrieve them at the time they are used in a request. OPs
227+
* can require that request_uri values used be pre-registered with the
228+
* require_request_uri_registration discovery parameter.
229+
*
230+
* If the contents of the request file could ever change, these URI values
231+
* SHOULD include the base64url encoded SHA-256 hash value of the file
232+
* contents referenced by the URI as the value of the URI fragment. If the
233+
* fragment value used for a URI changes, that signals the server that its
234+
* cached value for that URI with the old fragment value is no longer valid.
235+
*/
236+
public const REQUEST_URIS = 'request_uris';
237+
238+
/**
239+
* Boolean value specifying whether the auth_time Claim in the ID Token is
240+
* REQUIRED. It is REQUIRED when the value is true. (If this is false, the
241+
* auth_time Claim can still be dynamically requested as an individual Claim
242+
* for the ID Token using the claims request parameter described in Section
243+
* 5.5.1 of OpenID Connect Core 1.0 [OpenID.Core].) If omitted, the default
244+
* value is false.
245+
*/
246+
public const REQUIRE_AUTH_TIME = 'require_auth_time';
247+
248+
/**
249+
* JSON array containing a list of the OAuth 2.0 response_type values that
250+
* the Client is declaring that it will restrict itself to using. If omitted,
251+
* the default is that the Client will use only the code Response Type.
252+
*/
253+
public const RESPONSE_TYPES = 'response_types';
254+
255+
/**
256+
* URL using the https scheme to be used in calculating Pseudonymous
257+
* Identifiers by the OP. The URL references a file with a single JSON array
258+
* of redirect_uri values. Please see Section 5. Providers that use pairwise
259+
* sub (subject) values SHOULD utilize the sector_identifier_uri value
260+
* provided in the Subject Identifier calculation for pairwise identifiers.
261+
*/
262+
public const SECTOR_IDENTIFIER_URI = 'sector_identifier_uri';
263+
264+
/**
265+
* subject_type requested for responses to this Client. The
266+
* subject_types_supported Discovery parameter contains a list of the
267+
* supported subject_type values for this server. Valid types include
268+
* pairwise and public.
269+
*/
270+
public const SUBJECT_TYPE = 'subject_type';
271+
272+
/**
273+
* Requested Client Authentication method for the Token Endpoint. The
274+
* options are client_secret_post, client_secret_basic, client_secret_jwt,
275+
* private_key_jwt, and none, as described in Section 9 of OpenID Connect
276+
* Core 1.0 [OpenID.Core]. Other authentication methods MAY be defined by
277+
* extensions. If omitted, the default is client_secret_basic -- the HTTP
278+
* Basic Authentication Scheme specified in Section 2.3.1 of OAuth 2.0
279+
* [RFC6749].
280+
*/
281+
public const TOKEN_ENDPOINT_AUTH_METHOD = 'token_endpoint_auth_method';
282+
283+
/**
284+
* JWS [JWS] alg algorithm [JWA] that MUST be used for signing the JWT [JWT]
285+
* used to authenticate the Client at the Token Endpoint for the
286+
* private_key_jwt and client_secret_jwt authentication methods. All Token
287+
* Requests using these authentication methods from this Client MUST be
288+
* rejected, if the JWT is not signed with this algorithm. Servers SHOULD
289+
* support RS256. The value none MUST NOT be used. The default, if omitted,
290+
* is that any algorithm supported by the OP and the RP MAY be used.
291+
*/
292+
public const TOKEN_ENDPOINT_AUTH_SIGNING_ALG = 'token_endpoint_auth_signing_alg';
293+
294+
/**
295+
* URL that the Relying Party Client provides to the End-User to read about
296+
* the Relying Party's terms of service. The value of this field MUST point
297+
* to a valid web page. The OpenID Provider SHOULD display this URL to the
298+
* End-User if it is given. If desired, representation of this Claim in
299+
* different languages and scripts is represented as described in Section 2.1.
300+
*/
301+
public const TOS_URI = 'tos_uri';
302+
303+
/**
304+
* JWE [JWE] alg algorithm [JWA] REQUIRED for encrypting UserInfo Responses.
305+
* If both signing and encryption are requested, the response will be signed
306+
* then encrypted, with the result being a Nested JWT, as defined in [JWT].
307+
* The default, if omitted, is that no encryption is performed.
308+
*/
309+
public const USERINFO_ENCRYPTED_RESPONSE_ALG = 'userinfo_encrypted_response_alg';
310+
311+
/**
312+
* JWE enc algorithm [JWA] REQUIRED for encrypting UserInfo Responses. If
313+
* userinfo_encrypted_response_alg is specified, the default for this value
314+
* is A128CBC-HS256. When userinfo_encrypted_response_enc is included,
315+
* userinfo_encrypted_response_alg MUST also be provided.
316+
*/
317+
public const USERINFO_ENCRYPTED_RESPONSE_ENC = 'userinfo_encrypted_response_enc';
318+
319+
/**
320+
* JWS alg algorithm [JWA] REQUIRED for signing UserInfo Responses. If this
321+
* is specified, the response will be JWT [JWT] serialized, and signed using
322+
* JWS. The default, if omitted, is for the UserInfo Response to return the
323+
* Claims as a UTF-8 encoded JSON object using the application/json
324+
* content-type.
325+
*/
326+
public const USERINFO_SIGNED_RESPONSE_ALG = 'userinfo_signed_response_alg';
327+
}

0 commit comments

Comments
 (0)