Introduce entity_id_alternative_names Parameter for OpenID Federation

[peppelinux]

I propose the introduction of a new optional parameter, entity_id_alternative_names [ARRAY[str]], in the OpenID Federation Entity Configuration.

This parameter has an informative nature and enables the use of multiple unique entity identifiers, including EBSI and other DIDs, alongside the HTTPS identifiers currently used in OpenID Federation.

This parameter reinforces the role of the Federation Entity Configuration as a key point for discovery, while also providing flexibility. By allowing multiple identifiers, it can accommodate various identification systems, thereby enhancing interoperability.

[tweeddalex]

Strongly support this! This change would also allow more flexibility in OIDF implementation profiles, allowing DID-based ecosystems such as EBSI, Swiss eID, GAN and Bhutan to map to OIDF as an overall framework.

[selfissued]

Security question, including for @ve7jtb: I understand that putting an alternative identifier in an Entity Statement asserts that the Entity controls the alternative identifier. But any attacker with an Entity can also say that. What mechanism is proposed so that the alternative identifiers can make the reverse statement - that the Federation Entity controls that identifier - in a way that the reverse statement is verifiable?

[peppelinux]

Alternative identifiers and trust evaluation mechanisms should use the same cryptographic material as specified in the federation's Entity Configuration and Trust Chain.

Example 1:

Entity A publishes its cryptographic keys in its Entity Configuration, along with alternative entity IDs. One such ID, "AB," allows for trust evaluation via a distributed ledger using a DID resolution method. The cryptographic material from the DID document on the ledger can verify the signature of A's Entity Configuration. This make also possible to use a federation trust chain to validate any other external document or statement, even outside of the openid federation (such as a selfissued diddocument) using the same cryptographic binding.

This approach maintains security and federation principles while allowing multiple trust evaluation methods. It treats the federation entity configuration as a flexible entity manifest, supporting various identifiers and trust mechanisms.

[selfissued]

Anyone can copy the public keys from the Entity Configuration and put them in another data structure associated with the alternate ID. That doesn't demonstrate that the owner of the alternate ID also controls the Entity.

What would demonstrate control is for the alternate ID to sign something with the same private key used to sign the Entity Configuration. What concretely are you proposing be signed for the alternate IDs you want to use?

[peppelinux]

I fully agree with you @selfissued, the point is that additional proofs outside of the federation trust chain should be kept out of the scopes of this draft

this draft may introduce alternative entity identifiers leaving to other specifications and trust evaluation mechanisms to create the cryptographic binding mechanisms

if this discussion for this additional and optional parameter will go ahead, will for sure include the security considerations about the use of alternative eids.

I might propose several example of what could be signed and also how it could be provided, but it would end in an infinite list, such the infinite list of trust evaluation mechanisms that there might be out there

[peppelinux]

The evidence suggests that it is up to the entity to decide which alternative entity IDs to include in its entity configuration, and therefore, which alternative trust evaluation mechanisms might be used in addition to OpenID Federation.
If the alternative sub ID points to a fake ledger or a weak trust evaluation method, the responsibility lies solely with the entity that publishes its own entity configuration using such a weak reference.

[rs59]

@selfissued @peppelinux Interesting discussion! I wanted to follow up with two quick questions:

1. Would it be conformant to the standard to use a DID URL in place of a URL? (i.e. a completely DID-based implementation)?
2. Could we solve the problem of having multiple keys associated to a single entity configuration by providing two separate entity configurations in the subordinate list, one identified by the subordinate entity's URL, and the other identified by the subordinate entity's DID URL?

[selfissued]

Answering @rs59's question:

1. Would it be conformant to the standard to use a DID URL in place of a URL? (i.e. a completely DID-based implementation)?

No, it would not be conformant. The most straightforward place to see this is in the Entity Identifier definition, which is:

A globally unique URL that is bound to one Entity. This URL MUST use the https scheme, have a host component, and MAY contain port and path components. It MUST NOT contain query parameter or fragment components.

There's lots of other places in the spec that depend upon it using https, such as Obtaining Federation Entity Configuration Information.

What @peppelinux is proposing is verifiable cross-references between the EC and another data structure A, where EC makes the statement that A is authoritative for it and A makes the statement that EC is authoritative for it, and the cross-references are always checked before being used.

Note that this was discussed on the 12-Dec-24 working group call.

[lj-raidiam]

There's lots of other places in the spec that depend upon it using https, such as Obtaining Federation Entity Configuration Information.

It is also worth to mention the https client identifier scheme in OpenID4VP (the second bullet) in this context.

[jcmelati]

The inclusion of alternative entity identifiers raises a fundamental question about trust requirements.

If these identifiers must be trusted, they need equivalent trust validation to OpenID Federation's core mechanisms standards - specifically HTTPS URLs validated by Certificate Authorities through domain control validation. This means Entity A must cryptographically prove control over any alternative identifier it claims.

Without cryptographic verification at the same trust level as OpenID Federation's primary mechanisms, alternative identifiers become unverified and arguably unverifiable claims. Consider: if I say "I am Superman", what does that really mean? Will you bother to go try somehow find and ask Superman for confirmation? And if you can get a satisfiable confirmation from Superman, shouldn't that then be part of the alternative name entry?

If these identifiers don't require trust verification, we must question their utility in a federation trust framework. Having an entity_id_alternative_names attribute in a signed statement might, to the untrained eye, convey a trust that this list does not deserve if the cryptographic proof issue is not present. Unverified alternative names add complexity without clearly contributing to the trust model's integrity, from my current perspective.

[rs59]

@jcmelati Interesting point, is there somewhere in the OIDF spec that mentions that the Trust Anchor needs to be "validated by Certificate Authorities through domain control validation"? My understanding was that the following text implied that the Trust Anchor isn't supposed to be validated that way (Section 2.1):

Note that this cryptographic trust mechanism intentionally does not rely on Web PKI / TLS certificates for signing keys. Which TLS certificates are considered trusted can vary considerably between systems depending upon which certificate authorities are considered trusted and there are have been notable examples of ostensibly trusted certificates being compromised. For those reasons, this specification explicitly eschews reliance on Web PKI in favor of self-managed public keys, in this case, keys represented as JSON Web Keys (JWKs) [RFC7517].

In particular the decision not to rely on domain control seems to offer the opportunity for different entities to store their Entity Statements on the same domain.

[surfnet-niels]

I'd say this is ultimately just a choice the TA has to make. Everything in an Entity configuration is self asserted. It only becomes trusted once a TA makes statemetns about that entity.
If an entity publishes e.g. a logo URL in its entity config, do we assume the TA at registration time actually checked if that logo belongs to the entities organisation? I think it is likely there could be a registration policy to do so, but I can also see how some TAs might not actually check. I think we should simply leave it up to the TA (policy) to decide if they allow entity_id_alternative_names at all or perhaps just specific values, which they feel comfortable with.