rohe / oidcfederation

A document that described how to do a multi lateral federation with OpenID Connect.
10 stars 5 forks source link

[Additional feature] Fetch MANY Entity Statements with a single HTTP Request through federation_api endpoint #66

Closed peppelinux closed 3 years ago

peppelinux commented 3 years ago

I believe it may be more flexible and efficient to allow the acquisition of multiple entity metadata through a single request to / federation_api_endpoint. I would like to propose to change the sections 6.1.1 and 6.1.2 to get this possibile.

This will not affect the previous behavior but will only result in introducing what I would consider to be an useful generalization of the request and response parameters.

In some cases this solution could reduce the number of HTTP calls or alternatively adapt federation_api for additional trust mechanism, as it is as it currently already happens through an MDQ server used in Saml2 Federations.

Overall, the changes I would like to propose are concentrated in the following sections.

[6.1.1. Fetch Entity Statements Request]

sub OPTIONAL. The entity identifier of the subject for which you would like an entity statement issued. If this parameter is left out it is considered to be the same as the issuer and would indicate a request for a self-issued statement

... "the statements of all the entities will be issued".

[6.1.2. Fetch Entity Statements Response]

sub claim would be removed in the response, as defined in rfc7519 sub is OPTIONAL

metadata is now a dictionary that contains at a signle entity's metadata, rather it will become a list of dictionaries with meny entities in it. Example:

200 OK
Last-Modified: Mon, 17 Dec 2018 11:15:56 GMT
Content-Type: application/jose

{
  "iss": "https://openid.sunet.se",
  "iat": 1516239022,
  "exp": 1516298022,
  "metadata": [{
    "https://openid.sunet.se": {
        "openid_relying_party": {
          "application_type": "web",
          "redirect_uris": [
            "https://openid.sunet.se/rp/callback"
          ],
          "organization_name": "SUNET",
          "logo_uri": "https://www.sunet.se/sunet/images/32x32.png",
          "grant_types": [
            "authorization_code",
            "implicit"
          ],
          "jwks_uri": "https://openid.sunet.se/rp/jwks.json"
        }
        "jwks": {
            "keys": [
              {
                "alg": "RS256",
                "e": "AQAB",
                "key_ops": [
                  "verify"
                ],
                "kid": "key1",
                "kty": "RSA",
                "n": "pnXBOusEANuug6ewezb9J_...",
                "use": "sig"
              }
            ]
          },
      }
  }],
  "authority_hints": [
    "https://edugain.org/federation"
  ]
}
rohe commented 3 years ago

I don't think this is a good idea. One of the basic ideas of the specification is that you get the information you need when you need it. Not these massive data files that the present SAML2 federation are moving around. In fact the SAML2 federations are moving away from metadata files by introducing md query.

peppelinux commented 3 years ago

I knew that mentioning MDQ would be inconvenient, but I couldn't resist!

I think that the design principle you've mentioned is something that's good to me.

I just have to do something more about this https://github.com/rohe/oidcfederation/issues/67

In a way to have a diff of the metadata that would be updated overtime, this will allow us to avoid the monolithic single file and at the same time to avoid thousands of HTTP requests even for entities that do not require updating