Support for "immediate" exclusion of an entity from a federation

[Roland Hedberg]

Every trust chain has an expiration time. Depending on choices by the members involved in building a trust chain that expiration time can be minutes, hours or even days. What if the federation wants to be able to better control the timeliness of exclusions of entities from the federation? This is a proposal for how to accomplish that. The proposal is build on two things:

• A specific trust mark that marks an entity as member of a federation and
• that the trust mark issuer has an introspection endpoint (RFC7662) that members of the federation can use to verify if an entity is still a member of the federation.

If this is used in a federation, an entity is a member of that federation if:

• There is a verifiable trust path from the entity to the trust anchor
• The federation trust mark is still active.

In order to use the introspection endpoint the requestor must authenticate. This could be done by using private_key_jwt (section 9 of OIDC Core) with the entity_id of the requestor as the issuer. To sign the JWT the requestor may use the key it uses to sign its self-signed entity statement.

The special trust mark would have id=federation_entity and iss=entity_id of trust anchor.

[David W Chadwick]

The Fraunhoffer TRAIN project has already implemented something similar to this feature, using the DNS to point to the trust lists that are dynamically updated by the Trust Service Operator (the trust mark issuer in your notation). It has been released as open source code. It could be worth considering

[Giuseppe De Marco]

I believe that a token introspection endpoint, served by the trust mark issuer (trust anchor) can still be useful and should be included in the specifications.

However, by minimising the number of interactions between systems and the number of endpoints to be considered as necessary, we could consider this token introspection as optional and not required.

An entity can be excluded from the federation simply by removing its entity statement from the trust anchor’s federation_api endpoint, or by reducing the timestamp of its claim exp as less than utc.now(). timestamp().

in this way rather than sending an http request to the trust anchor endpoint introspection token, the verifier would directly query the trust anchor endpoint federation_api.

consider that the verifier is already in possession of a trust chain that solves the path to the trust anchor that issued the trust mark

However, I believe that it is still necessary to define an introspection endpoint for trust marks, this would be a useful source of additional information that a trust anchor would issue in relation to the marks issued

[David W Chadwick]

Guiseppe this is also how TRAIN works. The verifier contacts the TRAIN API and it tells the verifier whether the entity is still a trusted member of the federation or not.

[Roland Hedberg]

Is TRAIN described in a standard somewhere ?

Code is fine but it’s nothing one can point to in a standard.

[Roland Hedberg]

And a token introspection endpoint for trust marks would be usable to more trust marks the then ‘member-of-federation’ trust mark.

[Roland Hedberg]

It’s definitely optional for a trust mark issuer to provide a token introspection endpoint.

[Giuseppe De Marco]

I found this
https://tcwiki.azurewebsites.net/index.php?title=Federation_Trust_Registry

[David W Chadwick]

https://essif-lab.eu/essif-train-by-fraunhofer-gesellschaft/

We are half way through implementing TRAIN in our VC eco-system (we have the issuer and verifier and need to update our wallet). I defined the VC terms of use for incorporating TRAIN in VCs. TRAIN uses the ETSI Technical Specification “Electronic Signatures and Infrastructures (ESI); Trusted Lists: TS 119 612 V2.1.1 (2015-07)”, and evolved from the EC Lightest project (https://www.lightest.eu/) which pre-dated it.

[Torsten Lodderstedt]

Hi Roland,

I’m wondering why we not just use the federation API for fetching the status of a certain entity. It could either be another value in the Entity Statements Response or provided in response to a new operation, e.g. “fetch_status”.

[Roland Hedberg]

Hi Torsten,

we could do that. Would that mean that the one you ask is the trust anchor, no one else is involved right? And that you as an argument specifies the entity_id of the entity you’re interested in.

Or would you expect to be able to ask anyone that has an subordinate whether the subordinate still is among the active players?

[Roland Hedberg]

David, if we can find a simple solution that doesn’t involve including TRAIN I’d definitely prefer that.

[David W Chadwick]

If can specify the interface at a sufficiently generic level e.g. the verifier calls the trust service passing it the name/id of the trusted federation and the name/id of the unknown entity and gets back an OK/not OK then what is implemented behind this could be TRAIN or something as simple as a list of trusted entities.

[Giuseppe De Marco]

+1 on fetching the active trust marks via federation_api

the issuer of the trust mark for a subject MUST expose the trust marks of the subject in the entity statement related to it.
If the trust mark is absent in the entity statement, or expired, this must be considered not valid anymore by verifiers

[Roland Hedberg]

Another operator for the Fed API. Either we need to split the different operations into separate endpoints or we need to add a metadata attribute like fed_api_operations_supported. Such that an entity can publish which of the operations it supports.

[Giuseppe De Marco]

Completely agree for better granularity of operations through different, specialized, endpoints.
Anyway, regarding the revokation of trust marks, instead of having another endpoint I think that the entity statement published by a trust anchor for its descendants must expose the trust marks. If these are revoked we may have:

• expiration claim in the past
• absence of the trust mark

eg

{
  "authority_hints": [
    "https://registry.agid.gov.it"
  ],
  "exp": 1568397247,
  "iat": 1568310847,
  "iss": "https://registry.agid.gov.it",
  "sub": "https://rp.example.it/spid",
  "trust_marks": [
    # these are signed JWT ... here in json fror human readability
    {
      "iss": "https://registry.agid.gov.it",
      "sub": "https://rp.example.it",
      "iat": 1579621160,
      "id": "https://www.spid.gov.it/openid-federation/assessment/spid-saml-check/v.1.8.2"
    },
    {
      "iss": "https://registry.agid.gov.it",
      "sub": "https://rp.example.it",
      "iat": 1579621160,
      "exp": 1579623160, # revoked
      "id": "https://www.spid.gov.it/openid-federation/agreement/sp-private/v.1"
    }
  ],
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "kid": "endwNUZrNTJsX2NyQlp4bjhVcTFTTVltR2gxV2RV...",
        "kty": "RSA",
        "n": "vXdXzZwQo0hxRSmZEcDIsnpg-CMEkor50SOG-1XUlM..."
      }
    ]
  },
  "metadata_policy": {
    "openid_relying_party": {
      "contacts": {
        "add": "[e-mail]"
      }
    }
  }
}

‌

[Roland Hedberg]

Trust anchors may issue trust marks but they are far from the only entity that does so.

Also, if you have a deeper structure (with intermediates) then the trust anchor is not expected to publish entity statements for leafs. Leafs can still be assigned trust marks.

So, having superiors include trust marks in an entity statement describing an subordinate may work in some cases but definitely not in all.

[Giuseppe De Marco]

Got it, in general speaking we can’t verify the trust marks using a metadata discovery procedure, we need a direct query to the issuer of the mark, regardless of where this may be within a chain of trust

[Roland Hedberg]

Right !

[Roland Hedberg]

Regarding having several endpoints (one for each of fetch, list, search, status, …) or one endpoint with several operations I’m staring to lean towards the 1st option.

One reason for that is that some of these operation are going to be protected.

You may not want anyone to be able to search among your subordinates.

While at least one ‘fetch’ MUST be open for anyone.

As an implementor I find it easier to manage access control per endpoint rather then per operation.

[Giuseppe De Marco]

Ok, may I ask where to start to develop this proposal, can you do, Roland, a PR where to start our contributions or does anyone can do a PR, with these four endpoints, for your kindly revision?

[Roland Hedberg]

I can do a PR. The PR will appear in the GitHub repo.

https://github.com/rohe/oidcfederation

[Michael Jones]

This was discussed on the 16-Dec-21 call. Giuseppe will write a pull request adding this feature for review.

[Giuseppe De Marco]

We coordinated with Roland, who as promised will open a PR for this.

With respect to the contents discussed during the meeting I opened this issue, decidedly delicate, to which our analysis and possible approval in whole or in part would allow us the opening of a PR

https://bitbucket.org/openid/connect/issues/1382/proposal-of-an-improved-federation-api

[Michael Jones]

Roland, if you’ve written it, can you point us to the PR?

[Giuseppe De Marco]

Here the PR that closes this issue
https://bitbucket.org/openid/connect/pull-requests/104

[Roland Hedberg]

The PR (#104) was accepted.