[Federation] Request: more scenarios/use-cases/examples for federation

[Nikola Kramaric]

The idea of identity federation as described by the federation document is very compelling. However, when it comes to examples and real-world use cases, it might be useful to have some more documented.

The example given in the Appendix, which is great for describing the trust chain and associated validation, only describes the scenario for login. After the login step if entities in a federation all conform to certain API specification and scopes could this be modelled in the federation metadata? I am thinking about the Open Banking or Healthcare domains which might have existing conventions for APIs. This, to me, feels like a compelling use-case to define from a federation standpoint. If that is out of the scope of this document that is understandable.

‌

[Giuseppe De Marco]

Hi Nikola, OIDC Federation defines how an infrastructure of trust can be built and defines commons roles and metadata for RP, OP,but also OAuth2 AS and Client and Resource Servers, following well known standards and specifications.

Probabily you’re looking for some examples for oauth2_resource (https://openid.net/specs/openid-connect-federation-1_0.html#name-oauth-protected-resource).
OIDC Federation allows the definition of any kind of new metadata, for example openid_credential_issuer.

For the Italian Attribute Authorities we have used OIDC Federation and oauth resource servers that uses also OpenAPI Specification v3. This interop document (OAS3) is not exposed in the federation metadata, because it lives by its own.

As for oidc federation, this latter gives the trust to a particular entity. Do you need to include the API specification document in the federation metadata?

Generally this aspect is out of scope for the specs, but if it help here you can find how we managed the protected resource server in the federation metadata
https://italia.github.io/spid-cie-oidc-docs/en/metadata_aa.html

and here an example of OAS3
https://github.com/italia/spid-cie-oidc-schemas/blob/master/sgd/sgd-aa-oas3.yml

[Nikola Kramaric]

Thank you for the detailed response Giuseppe. This helps my understanding.

The hypothetical use-case I am thinking about, as an example, is if we have a federation and each IDP in that federation supports a particular version of the FDX API. I am thinking about how this could be defined in the metadata to enable RPs to easily integrate with any IDP beyond just the scope of login. As an example of this additional OP metadata could be:

supported_apis: [{
  api_specification: 'FDX',
  version: '5.1',
  resource_base_url: 'https://idp.fi.com/api/v5.1/',
  data_clusters_supported: ['accounts', 'transactions']
}]

Knowing this, the RP can recognize and interact with this OP more closely.

I was curious if there was an intent to outline, in the specification, use-cases beyond login like the above?

[Giuseppe De Marco]

I suggest the use of Trust Mark for that

An authority that onboards the service, with their API schemas may issue trust mark of compliances to a specific version/schems/specs
At the same time an OP may issue by itself a Trust Mark that self attests the compliance to a particular API version/specs

if self-issued or issued by a well-known authority may depends by your trust framework

[Nikola Kramaric]

OK thank you for the follow ups. This has provided good guidance. A little more insight into this type of use-case in the specification might be useful however if this is not the intention of the specification then feel free to close the ticket. The description of this use-case is “How does an OP specify the resources, scopes and API conformance levels they support within a federation?”. I also might be the only person asking for this so feel free to ignore!

[Giuseppe De Marco]

A Federation Entity may be also an AS and a RS, using these metadata type in its Entity Configuration (so, it is out the one from OIDC Provider)

the conformance to something might be defined in a trust mark

the federation (Trust Anchor) defines the well known Trust Marks and their issuers (compliances authorities)

the presence of a RS might point to OAS or anyother WSDL or GraphQL spec document, hosted in the domain of that RS. Nothing prevent you to have the entire interop scheme in a trust mark .. but it would be huge, it would be better a verifiable reference to that

[Michael Jones]

We discussed this on the 23-Mar-23 working group call. Unless specific proposals for additions to the spec are made, we plan to close this in a week.