# A Dynamic Federated Identity Management Using OpenID Connect
## 4 Experimental Environment and Implementation
### Dynamic OIDC RP Registration  
In order for [PERSON] to be able to sign in to FlyerIt using his company's credentials, FlyerIt should dynamically register with [PERSON] company's AdvertiseMe IdP in order to complete the login. Before initiating the OAuth 2.0 protocol, and in order to utilize all services for an end-user, the RP should register with the OP. The process of dynamic RP registration (known as dynamic client registration) is a protocol defined by both OAuth 2.0 [20] and OIDC [9]. The main concern is to allow RPs to register with the OPs dynamically at runtime to allow OAuth 2.0 authorization and OIDC authentication. Figure 2 illustrates the abstract flow of the dynamic client registration process between an RP (or client) and an OP (or authorization server). 1. To register a new client, the client sends a registration request, which is an HTTP message to the authorization server with the important client metadata parameters. 2. The authorization server validates the client metadata and assigns a new client with the provided metadata in the request parameters. Then, the authorization server sends a registration response, which is also an HTTP message. The registration response contains information about the newly created client. It also sometimes includes a client secret that allows the client to authenticate itself while initiating an OAuth 2.0 authorization flow. The registration response depends solely on the information provided by the client. Figure 2: OIDC Dynamic Client Registration. Figure 2 shows back and forth communication between the RP and the identity provider. The nature of this communication might vary from one identity provider to another. Some identity providers require more security on their registration endpoints. Our proposed model for dynamic client registration requires all registration endpoints to be over TLS. In addition, we add an extra layer of security that allows the identity provider to establish a trust with the RP. This trust is important to establish a federation between the two entities. We discuss our trust establishment model in Section 4.3. For now, we illustrate the basic communication between an RP and an identity provider to enable dynamic client registration. Figure 3 illustrates the complete flow of dynamic client registration;  
1. The dynamic discovery process allows FlyerIt as an RP to identify the location of the IdP for AdvertiseMe. After knowing the location, FlyerIt attempts to request metadata information of AdvertiseMe via a configuration endpoint defined by AdvertiseMe. OIDC defines a configuration endpoint /.well-known/openid-configuration that must be implemented in all OPs, to allow clients to retrieve information about OPs including the registration endpoints. Thus, FlyerIt as an RP prepares the following HTTP request. GET /.well-known/openid-configuration HTTP/1.1 Host:advertiseme.com
2. After FlyerIt sends the configuration metadata request, OP AdvertiseMe returns all metadata configuration information in a metadata response in terms of a JSON response. The configuration metadata contain a registration endpoint, which is the registration URL that allows clients to register with the server. Other metadata, such as the authorization endpoint and token endpoint, are URLs needed for end-user authorization and access_token retrieval. In addition, the OP server also provides a JWKS URL, which contains all the signing keys used to sign access tokens and identity tokens. Providing the signing keys allows relying parties to validate the integrity and authenticity of tokens created by the OP server.