OpenID Federation 1.0 for HAIP

[peppelinux]

OpenID Federation 1.0 provides:

• a consolidated approach to build an infrastructure of trust;
• a secure way to establish trust among different parties;
• automatic mechanisms to evaluates the reliability and the compliance of each party to the common set of rules, and automatic mechanisms to remove the anomalies (policy language);
• a flexible design where multiple technologies and protocol may exists (OAuth 2.0, OpenID Connect, other) where their metadata are described in a consolidated .well-known endpoint;
• a secure way to create trust attestations, not repudiable over time, even when the cryptographic key changes.

Federations are groups of OAuth 2.0 Authorization Servers, OAuth 2.0 Resource Server, OpenID Providers (OPs), Relying Parties (RPs), Wallet Provider, OpenID Credential Issuers, anyother entity type, that have agreed to work together under a common set of rules and trust anchors (trusted third parties above all the other parties).

The High Assurance Interoperability Profile (HAIP) should support OpenID Federation 1.0 for the following reasons:

1. Scalability: OpenID Federation 1.0 allows for the creation of large federations of providers and relying parties belonging to different organizations and domains. This can be beneficial for HAIP as it can potentially scale to support a large number of entities in large ecosystems where unilateral contracts and agreement between the entities would not be feasible.

2. Security: OpenID Federation 1.0 includes security features such as the use of signed JSON Web Tokens (JWTs) for federation metadata, and their attestability through trusted third parties, which can help to ensure the integrity and authenticity of data and claims contained in it. It includes Trust Chain to guarranty that more than one entity confirms a truth about a subject, where the compromission of a single entity or statement within the trust chain would invalidate the trust evaluation.

3. Transparency: The Federation API makes the Trust relationships transparent and navigable online by providing a standardized way to share and access trust information, enhancing trust in the ecosystem with a real-time navigation of the federation.

4. Flexibility:

   • The new wallet ecosystems may adopt a progressive approach where X.509 and Federation may exists together, offering the possibility of using X.509 and publishing the X.509 certificates issued by each subject and to each subject via the Federation API; at the same time the possibility, in the future, to abandon X.509 by continuing using only the Federation Trust Chains.
   • Multiple roles and metadata may coexist in the same entity and verified within the same trust chain
   • administrative properties pertaining the trust framework used or other compliance profile can be defined in the form of trust marks (verifiable attestations)
   • metadata should be provided by each entity and they may be overloaded by superiors entities, in particular when metadata values are replaced or when the federation policy language applies arbitrary changes to the metadata.

By supporting OpenID Federation 1.0, HAIP can leverage this trust management mechanism, which is important in a high assurance environment where trust and security are paramounts.

Impacts on the current text

The text that needs to be extended by including a reference to OpenID Federation is the following

client_id_scheme value MUST be either x509_san_dns or verifier_attestation. The Wallet MUST support both. The Verifier MUST support at least one.

To obtain the issuer's public key for verification, verifiers MUST support Web-based key resolution, as defined in Section 5 of [I-D.ietf-oauth-sd-jwt-vc]. The JOSE header kid MUST be used to identify the respective key.

therefore, client_id_scheme MUST be one of: x509_san_dns, verifier_attestation AND entity_id; where entity_id refers to OpenID Federation. We may merge entity_id with x509_san_dns where a federation entity discovery process, aiming to build a federation trust chain, can be built starting from the https url used with the FQDN of the subject (contained in both x509_san_dns and entity_id). Using the FQDN contained in the certificate SAN the public key would be attested using X.509 and federation may be used to obtain trust marks and policies and metadata.

Note: even the verifier_attestation alone could led to a federation entity discovery about its issuer, where the iss parameter contained in the attestation correspond to a https url of a federation entity.

The Web-based key resolution can the modular and extended with the federation entity discovery. A Federation Entity Discovery illustration here.

In conclusion, it would be formally correct using the client_id_scheme set to entity_id to explicitly indicate the use of OpenID Federation. At the same time an OpenID Federation can be used with X.509 and verifier_attestation as extension.

Metadata resolution

OpenID Federation Entity Configuration available at the .well-known/openid-federation endpoint should contain the metadata for each protocol/role supported by an entity. However, the metadata.$protocol-role may be an empty json object, enabling the possibility to obtain the metadata from a superior entity or using other .well-known endpoints. This enables a modular approach.

Consideration about the verifier attestations

A verifier attestation must indicates within the iss claim the entity id of its issuer. The issuer MUST be identified and recognized as part of the federation/ecosystem in the role of verifier attester (accreditation body). the verifier_attestation should include an OpenID Trust Chain in its JWT headers, giving the evidence of the issuer state, roles and grants, at the issuance time. The federation trust chain is recommended, while a X.509 certificate chain is possible (even with less proofs and features, then requiring custom extentions).

Additional security considerations

It is a good practice to not relying only on TLS. For this reasons there are ecosystem that uses public keys published in at least two different places to let the participant of the ecosystem to double check the keys. Examples are eduGAIN SAML2 federation or the use of the eIDAS Trusted Lists. It would be required to cite in the HAIP seccons the recommendation to provide trust anchors/CAs public keys in central registries. Using Federation for the wallet ecosystem the recommendation is to provide trust anchors entity ids and public keys using the trusted lists and at the same time obtain the public keys from the TA's entity configuration, then check and confirm/use only the public keys that matches between the two.

Reference to other issues

• https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/41#issuecomment-1558801814

[tlodderstedt]

I'm in favor of incorporating OpenID Federation in HAIP as a modular extension to the existing key management mechanisms to manage trust. I'm hesitant to add it as another key management mechanism.

This means (in my opinion) implementers could use OpenID Federation:

• in addition to the Web-based key resolution to manage the trust in SD-JWT VC issuers. This means the respective issuer would place an openid-federation file in its .well-known location besides the jwt-issuer file. The iss claim value in the SD-JWT VC would be the OpenID Federation entity id in this case.
• in addition to x.509 certificates to manage the trust in SD-JWT VC issuers. This means the verifier must be able to determine the issuer's OpenID Federation entity from the dNSName attribute in the certificate and obtain its entity configuration based on this entity id.
• in addition to the verifier_attestation RP authentication method to manage trust in the issuer of the respective JWT (verifier attestation). Technically, this mean to place an 'openid-federation' file in the .well-known location besides the jwt-issuer file of the RP attestation issuer.
• in addition to the x509_san_dns RP authentication method to manage the trust in the issuer of the respective x509 cert.

For the x509 based approaches, I would like to understand what that mean with respect to x509 chains (e.g. whether the root of an x509 cert chain would be the leaf element in an OpenID Federation or which one it would be).

[selfissued]

I'm in favor of adding entity_id as a client_id_scheme value.

[surfnet-niels]

OpenID Fed allows for expressing capabilities of Leafs via metadata. Should we standerdize the way a Leaf can express the fact that it is implementing HAIP so this capability becomes discoverable and can also be used as a metadata policy by IA's or TA's?

[peppelinux]

@surfnet-niels That would be something really interesting that in OpenID Federation would be implemented with a Trust Mark.

Assuming that the owner of HAIP is the OpenID Foundation, therefore the Trust Mark Issuer, the test platform asserting the compliance to HAIP would produce the evidence of the compliance in the form of a Trust Mark. According to the OpenID Federation specs, OpenID Foundation may delegate other Trust Mark issuers, as defined in its TA's Entity Configuration with the member trust_mark_issuers, making explicit the entities allowed for the issuance of the HAIP Trust Mark.

[peppelinux]

OpenID Federation is mentioned in the ARF v1.4, Annex 2 https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/9ed6250e69949e208c7f59172e7cad1324788e8d/docs/annexes/annex-2/annex-2-high-level-requirements.md?plain=1#L211