[Additional feature] A more detailed "Entity Listing Response"

[peppelinux]

Actually in 6.3.2. Entity Listing Response we have a result like this

200 OK
Last-Modified: Wed, 22 Jul 2018 19:15:56 GMT
Content-Type: application/json

[
  "https://ntnu.andreas.labs.uninett.no/",
  "https://blackboard.ntnu.no/openid/callback",
  "https://serviceprovider.andreas.labs.uninett.no/application17"
]

What do you think to have also additional attributes, something to deal with expiration time and last modification time? expiration can be usefull to predict when that metadata MUST be updated (a http request in the future to /federation_api with that subject). iat claim would be used to determine when a new metadata for this issues have been issued, it would match the update datetime. This will help to known which metadata would be updated (calling /federation_api with those subject).

Something like this example

200 OK
Last-Modified: Wed, 22 Jul 2018 19:15:56 GMT
Content-Type: application/json

{
  "https://ntnu.andreas.labs.uninett.no/": {"exp": 1619991866, "iat": 1588455866},
  "https://blackboard.ntnu.no/openid/callback" : {"exp": 1619991866, "iat": 1588455866},
  "https://serviceprovider.andreas.labs.uninett.no/application17: {"exp": 1619991866, "iat": 1588455866}"
}

regardless of the choice of which claim to use, this kind of structure would allow us a better "expandability" of the preview attributes.

[peppelinux]

In https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims we have also the claim "updated_at"

[rohe]

The whole idea around Entity Listing is not very well worked out. It was something that Andreas wanted in there and I can see the usage but I'm not sure anyone has cared to implement it. Which of course makes it easy to amend if we want to.

Now, one of the things it brakes in the overall model of the specification is that the response is unprotected. If we really wanted to keep to the overall model then the response should be something like a list of signed JWTs.

[peppelinux]

I can understand well, we can optionally protect the endpoint with a self issued bearer token (private_key_jwt, rfc7523 ...) but this would be an option that we handle in the specs.

Regarding the response, I'm ok for implementing a HTTP Response with Content-type application/jwt (jose) with a signature. Let's assume that a Client would first connect to /.well-known/openid-federation then get the jwks, then do a request to /federation_api_endpoint?operation=listing&iss=https%3A%2F%2Fopenid.sunet.se%2Ffederation, then validate the signature of JWT.

regarding the response I'd have some proposals, and these comes with the following assumptions:

1. The result MUST be paginated, no too many entries in the response would be allowed
2. A costant value (or a dynamic one) could be involved in sizing how many entities should be included in each page. Probably an immutable default value to 100 would be good enough
3. the default sorting of the result, I'd purpose an ordering based on updated_at DESCendant, the most recent will stay on top

For this reason I'd add this parameter in the www-form-urlencoded if you agree

page

    OPTIONAL. Integer, if left out the default value is 1.

The response would be something like the following:

200 OK
Last-Modified: Wed, 22 Jul 2018 19:15:56 GMT
Content-Type: application/jose

eyJhbGciOiJSUzI1NiIsImtpZCI6IlV6TlhSV3RsYTJac1lrUkVZWEJ0VmxWTFpsbEJSM0p3VFVWUE1qbFpZelZPYWpGdlJXdHNWa295VVEifQ.eyJpc3MiOiAiaHR0cHM6Ly9vcGVuaWQuc3VuZXQuc2UiLCAiaWF0IjogMTYyMDA1MDk3MiwgImV4cCI6IDE2MjAwNzI1MTUsICJlbnRpdGllcyI6IHsiaHR0cHM6Ly9udG51LmFuZHJlYXMubGFicy51bmluZXR0Lm5vLyI6IHsiaWF0IjogMTU4ODQ1NTg2NiwgInVwZGF0ZWRfYXQiOiAxNTg4NDU1ODY2fSwgImh0dHBzOi8vYmxhY2tib2FyZC5udG51Lm5vL29wZW5pZC9jYWxsYmFjayI6IHsiaWF0IjogMTU4ODQ1NTg1NiwgInVwZGF0ZWRfYXQiOiAxNTg4NDU1ODU2fSwgImh0dHBzOi8vc2VydmljZXByb3ZpZGVyLnNheS5uby8iOiB7ImlhdCI6IDE1ODgzNTU4NjYsICJ1cGRhdGVkX2F0IjogMTU4ODM1NTg2Nn19LCAib3BlcmF0aW9uIjogImxpc3RpbmciLCAicGFnZSI6IDEsICJuZXh0X3BhZ2VfcGF0aCI6ICIvZmVkZXJhdGlvbl9hcGlfZW5kcG9pbnQ_b3BlcmF0aW9uPWxpc3RpbmcmaXNzPWh0dHBzJTNBJTJGJTJGb3BlbmlkLnN1bmV0LnNlJTJGZmVkZXJhdGlvbiZwYWdlMiJ9.F0wJZf6vsg-rc9tugrZKUvARfezb0Sk62gFzw74SSJg9D-Ga5mCNhHsPKXQquovCn3hyqJAcA9Br7_3nmbeoLzl9RQND7PnuJWtp5sEUaVImhGQZg3mtDSZ9Z5yRR_W4g-irNbnj32InCZDOQ6ijYXd8HlSBmHVSJu15p97uey1UK-g5kwE2iDtoFBS87HiB26BkENHZiz9ezZV5FSZ5Ye0r951pjXrTozHH4vdqVtv5vHCka927qaX01b5-IPpBr9Usw9BKy6Ih0uQasd2PEJxdGeM0VnXgI_kjNgm4_JzALtCWnqh_NjppZWK4MnxbxwZ06eJ_0B4cANXuheL7bQ

The JWT payload would be something like this

{
 'iss': 'https://openid.sunet.se',
 'iat': 1620050972,
 'exp': 1620072515,
 'entities': {
   'https://ntnu.andreas.labs.uninett.no/': {
        'iat': 1588455866,
        'updated_at': 1588455866
   },
   'https://blackboard.ntnu.no/openid/callback': {
        'iat': 1588455856,
        'updated_at': 1588455856
   },
  'https://serviceprovider.say.no/': {
        'iat': 1588355866,
        'updated_at': 1588355866
    }
  },
 'operation': 'listing',
 'page': 1,
 'next_page_path': '/federation_api_endpoint?operation=listing&iss=https%3A%2F%2Fopenid.sunet.se%2Ffederation&page2'
}

[rohe]

I'd like to see a very compelling use case before I support this. I'm not convinced we need it.

[peppelinux]

Let's assume that:

1. 6.3.1. Entity Listings Request actually would return a huge list of entities and that list SHOULD be paginated instead (as best practice)
2. Entity listing COULD be used just to get the entities which have been added/updated, and not all of them
3. Entity listing orders the result set on the modification timestamp (updated_at), the latest that have been updated/created will be on top of the result
4. on the basis of the latest updates an entity could query federation_api endpoint and only fetch the differencies (it won't iterate over a defined timestamp that matches the last update it got in the previous request)

The use case:

Fed1.0 would be used, optionally, with a complementary way to do client registration. At this time we have automatic and implicit client registration and these are both dynamic registration mechanisms.

There could be the need to approach a different client registration, completely "offline". An entity would fetch all the entities' metadata that it would register. Instead of taking all the defintions (as actually is in SAML2) it would have a way to know which one have been updated, iterating on these entities (id) it will do request to federation_api (operation=fetch).

This approach would have a feedback in 9.1.1.2.1. Processing the Authentication Request, here

... the incoming Client ID is a valid URL, the OP does not have the Client ID registered as a known client and the OP supports the request authentication method used then the OP should try to resolve and fetch trust chains starting with the RP's entity statement as described in Section 7.1.

Introducing a way to deal with an offline client registration the OP could have a client id registered without doing a dynamic registration in place. This is a choice that could relax the just-in-time-dynamic-only-approach. At the same time this will let the federation to be driven with more options by organization side, without changin the lead approach at the base.

The same dynamic registration operations of the clients are performed at a predetermined time and not at the occurrence of a new request. The two approaches don't collide with each other, I just see one more option for organizations. This could facilitate its adoption within organizations that need to have an overall feedback on the population of the requesting clients in the future.

[rohe]

Well, you could argue that implicit client registration is a sort of static registration since the client never sends a registration request to the OP and the OP has no way of modifying the client configuration. Making sure the clients configuration adhere to the federation policy instead falls to the federation operator. In the beginning we played around with a system where an organisation could register entities by sending its metadata to the federation operator who would verify and sign it and then publish it. This was a PUSH model not a PULL as you are proposing. The party responsible for the entity would NOT publish the entity statement the federation operator would. I guess you can still use this model. The signing server that are part of the fedservice example basically does this.

The only reason I really can see for allowing entity listing is for parties that are building WAYF functions.

[peppelinux]

So, we could just face these options:

1. 6.3.2. Entity Listing Response: the response must be JWS/JWE? I agree, let's do that :)
2. what about the paginator? Let's assume we have 12000 entities ... and a poor JS table would have to represent them
3. what about the possibility to add custom claims to the entities, so that the response would be a list of dictionaries instead of strings?

[rohe]

1) I guess JWS would be sufficient 2) Sure we can have a paginator. Though I have a hard time coming up with a reasonable use case when someone would be responsible for 12000 entities and there was a valid reason for someone else to list them. If that where the case there are other protocols they could use (eg. event notification).

3) adding custom claims are always possible. Changing syntax on standard claims, absolutely not!

[peppelinux]

Ok, let's suppose we have as many JWSs for as many pages. Each page would be something like this

{
 'iss': 'https://openid.sunet.se',
 'iat': 1620050972,
 'entities': {
   'https://ntnu.andreas.labs.uninett.no/': {
         'exp': 1620072515,
   },
   'https://blackboard.ntnu.no/openid/callback': {
         'exp': 1620072515,
   },
  'https://serviceprovider.say.no/': {
         'exp': 1620072515,
    }
  },
 'operation': 'listing',
 'page': 1,
 'next_page_path': '/federation_api_endpoint?operation=listing&iss=https%3A%2F%2Fopenid.sunet.se%2Ffederation&page2'
}

Any modification of the "exp" claim in an entity attribute dictionary would let the requester know whether to update the chain of trust for that entity, if indeed the definition of this previously collected entity were to differ for the exp attribute.

Each provider configures the desired number of elements per page, in the example we have only two but they can be 50 or 100 or more per page.

elements that have changed their EXPiration attribute MUST stay on top, so the result would be sorted by the exp declaration. Do you think that we can make a proposal for integration in the current draft to achieve this result?

[peppelinux]

regarding 2.

Federation 1.0 could be also adopted even by single federations (not multilateral!). Scenarios where a single federation authority (belonging to a national digital identity system) acts as single trust anchor, issuing entity statements for more that 60000 relying-parties. Whitout any intermediaries

[rohe]

Sure, that’s always been a use case.

On 10 Oct 2021, at 18:19, Giuseppe De Marco @.***> wrote:

regarding 2.

Federation 1.0 could be also adopted even by single federations (not multilateral!). Scenarios where a single federation authority (belonging to a national digital identity system) acts as single trust anchor, issuing entity statements for more that 60000 relying-parties. Whitout any intermediaries

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rohe/oidcfederation/issues/67#issuecomment-939510349, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAYMPCNX4UWU36WS3WDCTDUGG4I3ANCNFSM437ZYSQA.

— Roland

Were it left to me to decide whether we should have a government without newspapers, or newspapers without a government, I should not hesitate a moment to prefer the latter. -Thomas Jefferson, third US president, architect, and author (1743-1826)