OpenID Connect Federation 1.0 - draft 00

Abstract

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.

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.

Table of Contents

1.  Introduction
2.  Requirements Language
3.  Trust model
    3.1.  Federation operator
    3.2.  Developer
    3.3.  Relying Party Admin
    3.4.  Signing Key Chain
    3.5.  Dealing with the OpenID Provider Configuration Information
4.  OpenID Connect communication
    4.1.  Extra metadata parameters
    4.2.  Federation policy
    4.3.  Provider Discovery
    4.4.  Client Registration
5.  Belonging to several federation
    5.1.  Developer
    5.2.  OP/AS admin
6.  Verification process
    6.1.  OP as receiver
    6.2.  RP as receiver
7.  Acknowledgements
8.  IANA Considerations
9.  Security Considerations
10.  Normative References
Appendix A.  Example
    A.1.  Relying Party joining a federation
        A.1.1.  Step 1 - Developer creates its signing key pair.
        A.1.2.  Step 2 - Developer submits registration data to FO
        A.1.3.  Step 3 - FO returns a signed software statement
        A.1.4.  Step 4 - The RP gets a signing key
        A.1.5.  Step 5 - RP produces a client registration request
        A.1.6.  Step 6 - Developer produces software statement for RP
        A.1.7.  Step 7 - RP sends a client registration request to an OP
        A.1.8.  Step 8 - OP handles software statement
Appendix B.  Notices
Appendix C.  Document History
§  Authors' Addresses

1.  Introduction

The original specification of OpenID Connect defines how a Relaying Party and an OpenID Connect Provider dynamically can exchange information necessary for successful communication.

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.

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.

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.

2.  Requirements Language

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 inRFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

3.  Trust model

The trust model is based on chains of trust, linking together signing keys, represented asJWK Sets (Jones, M., “JSON Web Key (JWK),” May 2015.) [RFC7517], usingJSON Web Signatures (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [RFC7515]. 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.

Handling RP client registration is slightly more complex then dealing with OP configuration information and is therefor chosen as an example here. Players:

• Federation operator
• Developer
• Relying Party Admin

3.1.  Federation operator

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 Certificate Transparency log (Laurie, B., Langley, A., and E. Kasper, “Certificate Transparency,” June 2013.) [RFC6962]. 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.

3.2.  Developer

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 parametersigning_key, 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.

3.3.  Relying Party Admin

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 parametersigning_key, 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.

3.4.  Signing Key Chain

The key chain from top to bottom:

• the federations key,
• the developers key signed by the federation and
• the RP's key signed by the developers key

3.5.  Dealing with the OpenID Provider Configuration Information

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 signing_key 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.

4.  OpenID Connect communication

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.

------                             ------
|    | <--- 1) Discovery --------> |    |
| RP | <--- 2) Registration -----> | OP |
|    | <--- 3) Authentication ---> |    |
------                             ------

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).

4.1.  Extra metadata parameters

These extra metadata parameters appear in both Provider Configuration Discovery and Client Registration:

signed_jwks_uri

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.

signing_key

OPTIONAL. A JWS representing the public part of the entity's key.

software_statements

OPTIONAL. A list of software statements.

software_statement_uris

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.

The following is a non-normative example of a RP registration request after that the developer has added links to the relevant software statements:

    {
      "contacts": ["dev_admin@example.com"],
      "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"
      }
    }

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.

Along the same lines if both jwks_uri and signed_jwks_uri are present, which they might be for backward compatibility reasons, then signed_jwks_uri SHOULD be preferred.

4.2.  Federation policy

Any parameters that the federation adds to the software statement that also appears in the Provider Configuration response (OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” August 2015.) [OpenID.Discovery] or in a Client Registration request (OpenID Connect Dynamic Client Registration 1.0) (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” August 2015.) [OpenID.Registration] 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.

4.3.  Provider Discovery

The OP MUST publish its provider metadata as specified by OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” August 2015.) [OpenID.Discovery]. The RP makes a standard OpenID Provider Configuration Request. The OP responds with its provider configuration and the additional metadata parameters specified above.

4.4.  Client Registration

The OP MUST support dynamic client registration as described in OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” August 2015.) [OpenID.Registration]. The RP makes a Client Registration Request including the additional metadata specified above.

5.  Belonging to several federation

5.1.  Developer

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.

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 software_statement_uris or software_statements.

The following is a non-normative example of an absolutely minimal client registration request sent to an OP:

{
  "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"
  }
}

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.

The following is a non-normative example of an OPs response on the client registration request above:

{
  "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",
  }
}

5.2.  OP/AS admin

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.

The following is a non-normative example of an OPs response to a provider configuration request:

  {
    "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"
  }

6.  Verification process

6.1.  OP as receiver

Upon receiving metadata from an RP this is what the OP has to do:

1. 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.
2. 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.
3. 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.
4. If there is a signed_jwks_uri 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 insigned_jwks_uri.

6.2.  RP as receiver

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 signed_jwks_uri claim the RP can use the signing key included in the metadata to verify the signature of the JWK Set found at that URL.

7.  Acknowledgements

Michael Schwartz

Peter Schober

8.  IANA Considerations

TBD

9.  Security Considerations

TBD

10. Normative References

Appendix A.  Example

The necessary steps for adding a Relying Party to a federation

The following JWKS represents the signing key that the Federation Operator is using in the following example:

{
  "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"
    }
  ]
}

A.1.  Relying Party joining a federation

A.1.1.  Step 1 - Developer creates its signing key pair.

Developer creates its signing key pair.

{
  "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"
    }
  ]
}

A.1.2.  Step 2 - Developer submits registration data to FO

The developer submits registration data to Federation Operator (FO).

{
  "contacts": [
    "dev_admin@example.com"
  ],
  "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"
}

A.1.3.  Step 3 - FO returns a signed software statement

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.

This is an example of a software statement constructed by the FO before it is signed by the FO:

{
  "contacts": [
    "dev_admin@example.com"
  ],
  "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"
}

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.

A.1.4.  Step 4 - The RP gets a signing key

The RP gets a signing key

{
  "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"
    }
  ]
}

A.1.5.  Step 5 - RP produces a client registration request

The RP produces a client registration request

{
  "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"
  }
}

A.1.6.  Step 6 - Developer produces software statement for RP

Developer produces software statement based on client registration request

{
  "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"
  ]
}

and signs it. We now have the signed software statement aka the metadata that the RP will present to the OP

A.1.7.  Step 7 - RP sends a client registration request to an OP

The RP sends a client registration request to the OP

{
  "redirect_uris": [
    "https://example.com/rp1/callback"
  ],
  "software_statement_uris": {
    "https://swamid.sunet.se/":
      "https://dev.example.com/rp1/idfed/swamid.jws",
  }
}

A.1.8.  Step 8 - OP handles software statement

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. Therefor it has to unpack the JWT without verifying the signature. It will then get a JSON document looking like whats listed in step 6 above. From this document it can extract the software statement which should be signed by a key belonging to the FO. The OP should have the fetched the public version of that key from the FO at some time prior to this. It can now verify the signature of the software statement and unpack the JWT. The JSON document it then gets is the one listed in step 3. The signing key specified in that document can now be extracted and used to verify the signature of the metadata.

What's remaining now for the OP is to put all the pieces of the client registration request together. It will have one piece from the developer augmented with the federation policy and then another piece from the RP.

Appendix B.  Notices

Copyright (c) 2016 The OpenID Foundation.

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.

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.

Appendix C.  Document History

[[ To be removed from the approved specification ]]

-00

• Created openid-connect-federation-1_0-00 from draft-hedberg-oidc-fed-01.

Authors' Addresses