Determining if an RP is a member of a trust federation

[David W Chadwick]

The user’s wallet may operate in an open environment and operate with RPs from multiple different trust federations. Simply verifying the X.509 TLS cert of an RP may be insufficient to tell the user/wallet whether the RP is trusted or not.

Assumptions: The wallet has a configurable list of trusted trust federations. The wallet has an API (or other library) that it can call:

• given the name of the trust federation and the authenticated name of the RP, the API will return a response indicating if this RP is a member of the asserted trust federation or not.

Q. How does the client/RP pass the name(s) of the trust federations that it asserts that it is a member of, to the wallet for validation.

[Giuseppe De Marco]

Using OIDC Federation a verifier needs only two elements

• subject identitier of the requester
• identifier of the Trust Anchor (that corrisponds to a Federation)

a RP (requester/verifier) may belongs to many federations. In its Entity Configuration it has one or more authority hints (authority_hints claims) that exposes the superior entities where to establish the trust, along the path to the Trust Anchor.

The Federation may allow any or one or more federation intermediaries (max_path_length claim) defining this information in the Trust Anchor’s Entity Configuration (TA). The TA may also apply some metadata policy to modify a participant metadata (RP or OP), this means that a RP may belongs to many federations without the need to change its metadata for each of them, the Federation where it can be resolved defines the policies and the entity that validates the trust chains applies these to the final metadata of the requester.

---

Using instead x509 PKI we may need some custom attributes (ASN values) to be checked by a wallet/verifier. Anyway using x509 we assume that the trust can be established with a Root CA, that corresponds to a single federation, and the requestor should use one or more x5c if it want to be validated to a federation or another.

In this issue https://bitbucket.org/openid/connect/issues/1482/static-trust-negotiation-in-a-scenario we investigate if we may adopts a kind of Badge (signed JWT) to be included in the requester metadata to have a type of trust negotiation based on a static verification that works, as well as for x5c, even for offline scenarios

[David W Chadwick]

The same two conceptual pieces of information are needed for the TRAIN API as for OIDC Federation. The syntaxes however may be different (subject ID would be a URL, and trust anchor ID would be a DNS name). However, I don't want to burden the wallet with retrieving RP meta data if it can be avoided. So my question was about dynamically obtaining this info from the RP in the initial message exchange. The RPs URL can be obtained from its X509 PKC. But where can we get the trust anchor id from?

[Giuseppe De Marco]

@David Chadwick CN (commonName) should contain the trust anchor id, considering that x5c would have a list of certificates and not only the RP's certificate. This is why a x509 chain is very huge in the real world, due to its size.

[David W Chadwick]

I don’t think so. The CN parameter is for the common name of the RP. The name of the trust federation bears no relation to the name of the RP. The TRAIN design intentionally separates the names of the trusted entities from the name of the trust federation that they are members of. These names bear no relation to each other. e.g. A and B can both be members of trust federation C. Furthermore one RP can be a member of several trust federations. So the name/id of the trust federation needs to be sent as a separate parameter to the wallet.

‌

[Giuseppe De Marco]

I meant the CN of the certificate of the trust anchor, the relation must be found in the x509 chain

and I agree with you, a chain can resolve to a single trust anchor, both TRAIN and OIDC Federation gives more flexibility for participants that may be resolved to many trust anchors

[David W Chadwick]

Are you saying that the X509 chain provided by the RP can contain two (or more) completely separate root CAs, with different subordinate CAs below them? If this is the case, then CAs are performing the function of trust federation membership managers. I don't think this is the correct model. The manager of a trust federation should not need to run CA software and act as a CA in order to add an RP to the trust federation. But your model is forcing this by requiring the RP to get a PKC from this second CA, and return PKI chains to the wallet. Rather the trust federation manager manages an ETSI trust list, and adds members to this. It signs the trust list. So the RP needs to be able to send the name of the trust list to the wallet.

‌

[Giuseppe De Marco]

A trust mark would expose all the trust frameworks adopted by a participant.

I created this issue in Federation to get an additional paramenter to suggest to a OP the trust path to follow during the metadata discovery process

https://bitbucket.org/openid/connect/issues/1533/federation-trust-path-hint-in-the-authz

Considering in addition any other infrastructure, not based on oidc fed, I think that a similar approach to Trust Mark may be adopted and that this “mark” may be also added in the authz request to be highlited to an holder. This could be adopted with RAR, for example or in the metadata available in the SIOPv2 registration paramenter

[Giuseppe De Marco]

These are two ways I like

1. a Trust Mark or any other signed object, by a trusted party or authority for a specific framework, available in the request or in the metadata (that should be made available in the request, as SIOPv2 registration) to be usable also in the offline scenarios. The IDP should have the public key of all the trusted parties that may sign these trust marks

2. a new JWT header called signed_jwk, that is a JWT, signed by a trusted party (as before) containing the jwks. This signed_jwk claim may be used in both authz request object or private_key_jwt

the third way above I don’t like too much, because I prefer the solution #2 to achieve the same feature. However the x5c is compliant to eIDAS qualified signature, so we can’t ignore this solution that works out of the box without adding/touching anything:

3. a x5c header in the authz request object (or private_key_jwt in token endpoint). We saw a PR of @Torsten Lodderstedt on this. I don’t like this solution because a real PKI costs, compliant to eIDAS, costs more than the previous solutions and I’d prefer the solution when are smart and costs less

[David W Chadwick]

I have proposed two alternatives in issue 1551

[Michael Jones]

Closing favor of #1551, per discussions on the 14-Jul-22 working group call.