Trust Anchor Mix-Up (Federation Integrity Property)

[SECtim]

Consider the following excerpt from the example of two Federations rooted at two different Trust Anchors as given in Section 1:

.-----------------.            .-----------------.
|  Trust Anchor A |            |  Trust Anchor B |
'------.--.-------'            '----.--.--.------'
       |  |                         |  |
    .--'  '---. .-------------------'  |
    |         | |                      |
.---v.  .-----v-v------.   .-----------'
|    |  | Intermediate |   |
'----'  '--.--.--.-----'   |
           |  |  |         |
   .-------'  |  '------.  |
   |          |         |  |
.--v-.      .-v--.     .v--v.
| RP |      |    |     | OP |
'----'      '----'     '----'

Now, suppose that RP only trusts Trust Anchor A, whereas OP only trusts Trust Anchor B. A user of RP requests to authenticate with OP, so RP initiates an automatic registration with OP (Section 12.1):

1. RP uses the process defined in Section 10 to learn OP's metadata, i.e., fetches OP's Entity Configuration and then resolving a Trust Chain, starting with OP's authority_hints (i.e., Intermediate and B). Following the Intermediate path, RP assembles a Trust Chain from OP to A, i.e., the chain [OP, Intermediate, A].
2. RP validates that Trust Chain and uses it to resolve OP's openid_provider metadata, in particular, its authorization endpoint.
3. RP sends an authentication request with a signed request object (that does not contain a Trust Chain) to OP's authentication endpoint.
4. OP processes this request as described in Section 12.1.1. I.e., among other things, OP fetches RP's Entity Configuration and, starting with RP's authority_hints, resolves a Trust Chain, say [RP, Intermediate, B].
5. OP validates that Trust Chain and uses it to resolve RP's openid_relying_party metadata, which OP then uses to automatically register RP.

I.e., both OP and RP "trust" each other without having a Trust Anchor in common (actually, RP "trusts" OP already in Step 3).

Unless we overlooked something, the Federation specification does not prevent this from happening.

Note: Such a situation may also lead to disagreement on the openid_... metadata if the different Trust Anchors employ different Federation Policies.

[SECtim]

After thinking about it for a bit, @PedramHD and I think that a possible solution to this might be the following:

• In its Entity Configuration, each Federation Entity publishes a list of Trust Anchor Entity IDs that it trusts (either directly, or via some URI, similar to jwks).
• During Trust Chain resolution (Section 10.1), the Entity that is currently constructing a Trust Chain for some subject only accepts Trust Chains that end in one of the Trust Anchors included in sub's Entity Configuration (and of course, the Entity that is constructing the Trust Chain must also trust that Trust Anchor, but that is already the case in the current spec).

However, we note that there still is the issue described in #86; the above changes only make sure that both Entities are part of at least one shared Federation and that the Trust Chain used to resolve the other Entity's metadata ends in one of the shared Trust Anchors.

[peppelinux]

I.e., both OP and RP "trust" each other without having a Trust Anchor in common (actually, RP "trusts" OP already in Step 3).

this was the impl profile got in OpenID GAIN PoC WG, allowing a more "decentralized" approach with multiple Trust Anchors and not all the participants be part of all the federations/network bound to each trust anchor.

The decision of enabling or not this approach depends by the trust framework, where implementation allowing this promiscuity it is technically possible.

I (leaf) live in my palace (federation) and follow my palace's rules. I go to a friends' dinner, in another palace, applying their rules.

It depends to me decide if I can do this or not, if I must trust only the entities that applies my same policies or if I can apply also other policies of Trust Anchors I trust without being part of their network.

[SECtim]

The decision of enabling or not this approach depends by the trust framework, where implementation allowing this promiscuity it is technically possible.

For Federation, the trust model seems to be such that two Entities trust each other if they are part of the same Federation, i.e., have trust in the same Trust Anchor. E.g., the abstract says:

An Entity in the federation must be able to trust that other Entities it interacts with belong to the same federation.

and in section 1:

This specification describes how two Entities that would like to interact can establish trust between them by means of a trusted third party called a Trust Anchor.

... which implies that there are two Entities and one Trust Anchor (otherwise, the Trust Anchor would not just be "a [...] third party"). Also in section 1:

Determining that two Entities belong to the same federation is the basis for establishing trust between them in this specification. [...] Every Entity is able to establish mutual trust with any other Entity by means of having at least one common Trust Anchor between them.

Section 12.2.1 also hints at this:

Once the RP has determined a set of Trust Anchors it has in common with the OP, it chooses the subset it wants to proceed with.

So I think that for Federation, the described scenario should not be possible (unless the trust model description all over the spec is very misleading, in which case it should be clarified).

[peppelinux]

Trust Model is related to the model only, that uses a trusted third party (Trust Anchor)

There might be more than a single Trust Anchor

according to the specs, all the entities must be linked at least to a superior entity, no matters if it is the trust anchor or its intermediate

an intermediate can be linked to one or more intermediates or trust anchors

therefore the leaf might not known how many trust anchors it is linked to, through each intermediate above it

it's up to who evaluates the trust decide which trust anchor to use.

This is the fit we havei n the current specs.

Other implementation profiles, such that obtained in OpenID GAIN POC WG, introduced a more flexible approach, as I described above. Not necessarly all the participants might found themseleves under the same trust anchor.

entity A can trust trust anchor B without be linked to it, therefore it can build a trust chain about entity B, under trust anchor B, applying trust anchor B policies and apply them.

[SECtim]

Trust Model is related to the model only, that uses a trusted third party (Trust Anchor)

... which is the model that the Federation spec says it uses (in section 1, as cited above), or am I completely misreading that section?

---

Assuming that my understanding of section 1 is indeed incorrect, what you're saying is: Entities A and B "being in the same Federation F" does NOT mean that there is a Trust Anchor (at the root of F) that is trusted by both, A and B? Then, what DOES it mean for A and B to be in the same Federation F? Or even: What does it mean for a given Entity A to be in a Federation F? What defines a Federation F if not the (single) Trust Anchor it is rooted in? Wouldn't that also imply that an Entity has no way of explicitly choosing which Federations it participates in?

In any case, if what you're describing is indeed the trust model underlying Federation, then I think this should be made much more explicit throughout the specification, see, e.g., the things I cited in my comment above.

[cicnavi]

Since both RP and OP will have to resolve the trust chain during registration / authentication, I don't see a problem of "not being sure in which federation we are". The entity which tries to resolve the trust chain defines which trust anchor(s) is/are to be used, and this is actually visible in the description of the resolve endopint: https://openid.net/specs/openid-federation-1_0.html#name-resolve-entity.

However, are there any drawbacks in having "valid trust anchors" listed in (leaf) entity configurations? My first though on this is that it is a good idea, however not sure about the broader implications.

So in example above, both RP and OP know who their own trusted anchors are. When an RP tries to resolve trust chain for OP, if "valid trust anchors" were listed in OP entity configuration, RP could "fail early" during trust chain resolution if RP sees that the TA that RP trusts is not in the OP list of valid trust anchors.

[SECtim]

Since both RP and OP will have to resolve the trust chain during registration / authentication, I don't see a problem of "not being sure in which federation we are".

Whether this is a problem or not depends on the targeted trust model - if mutual trust is supposed to mean "we are in at least one common Federation", then the scenario described above is a problem. If mutual trust only means "we both have some valid Trust Chain from the other Entity to one of our own Trust Anchors", then this is indeed fine.

I might add: From my point of view, the trust model can be either way - but I think the specification should be very explicit about which trust model it uses. And with the current texts I cited above, my understanding of the Federation spec is such that the targeted trust model revolves around "being in the same Federation" and "having at least one common Trust Anchor between" Entities.

I think that @cicnavi's comment also implies this understanding:

[...] RP could "fail early" during trust chain resolution if RP sees that the TA that RP trusts is not in the OP list of valid trust anchors.

This only makes sense if the underlying assumption is that RP and OP must have at least one common Trust Anchor.

[cicnavi]

[...] RP could "fail early" during trust chain resolution if RP sees that the TA that RP trusts is not in the OP list of valid trust anchors.

This only makes sense if the underlying assumption is that RP and OP must have at least one common Trust Anchor.

Oh right, that would actually disable your example from happening!

[jcmelati]

whereas OP only trusts Trust Anchor B

If OP only trusts Trust Anchor B, wouldn't that mean that the initial diagram is not correct, because then OP would not have Intermediate as an Authority Hint?

[SECtim]

@jcmelati The trust model of Federation (according to the spec text) revolves around trust in Trust Anchors, not Intermediates. Of course, OPs authority hints in the example would contain Intermediate and B (see also the initial issue description).

[jcmelati]

@SECtim From my current understanding, it is up for the one that is evaluating trust (RP) to define which Trust Anchor to be used. While you can set up a whole Federation structure, its effects only take shape when RP is trying to establish trust from it's perspective. Saying OP only trusts Trust Anchor B overlooks the dynamic nature of trust chains when OP also defines Intermediate as a direct superior.

According to the spec, trust is not limited to be defined by a Trust Anchor special type of Entity but rather encompasses the possibility of intermediates acting as trust anchors depending on the specific federation and context.

From the spec: While Trust Anchors typically have no Superiors, a Trust Anchor will have a Superior when the Trust Anchor also acts as an Intermediate Entity in another federation.

In the first diagram, what is described as Intermediate (and also all other entities) can only be described so in relation to a Trust Anchor context. In some other hypothetical use case for some other RP, Intermediate can very well be a Trust Anchor. In both cases, it is up to the verifier to establish the Trust Anchor context that it expects to make a decision about trusting or not some federated Entity.

[SECtim]

From my current understanding, it is up for the one that is evaluating trust (RP) to define which Trust Anchor to be used.

Agreed, and the initial example is in line with this.

Saying OP only trusts Trust Anchor B overlooks the dynamic nature of trust chains when OP also defines Intermediate as a direct superior.

I don't think the spec in its current form supports this statement. In particular, intermediates are explicitly mentioned as such (and as part of the immediate superiors of an Entity), separate from mentions of Trust Anchors (of course, an intermediate MAY at the same time act as a Trust Anchor). Also, what makes a Trust Anchor A a Trust Anchor? I'd argue: Some Entity has A's Entity ID and public keys configured as their Trust Anchor (see section 10: "An Entity that wants to establish trust with another Entity MUST have Party B's Entity Identifier and a list of Entity Identifiers of Trust Anchors and their public signing keys.") Hence, if in the example neither OP, nor RP have Intermediate in their respective Trust Anchor lists, then Intermediate is not a trust anchor - in any case, if the word "trust" (and its rather fuzzy meaning) bothers you in the context of Trust Anchor/any Entity, we can just replace it with "is part of Entity's list of Trust Anchors". In the context of "RP trusts OP" and vice-versa, the example above just uses the wording from the spec (Section 1).

According to the spec, trust is not limited to be defined by a Trust Anchor special type of Entity but rather encompasses the possibility of intermediates acting as trust anchors depending on the specific federation and context.

Also agreed, but that is not the case in the initial example, Intermediate really IS an Intermediate, not a "hidden" Trust Anchor.

In the first diagram, what is described as Intermediate (and also all other entities) can only be described so in relation to a Trust Anchor context. In some other hypothetical use case for some other RP, Intermediate can very well be a Trust Anchor. In both cases, it is up to the verifier to establish the Trust Anchor context that it expects to make a decision about trusting or not some federated Entity.

True, but again: In the initial example, Intermediate is not a Trust Anchor, it is just an Intermediate.

[rohe]

@SECtim My take on this has from the beginning been that two entities can trust each other's metadata/trust marks/keys if they are in the same federation.

The GAIN POC model is in my mind a bastard and can create any number of problems.

Since every entity in the federation MUST know at any point in time what TAs it trusts, publishing this list in the EC may actually work. It can not publish all the TAs you may end up at if you follow all possible trust chains that starts with the entity but that is not a problem. We've had this discussion a number of times and I have previously pushed back just because the entity would not know its list of trusted TAs but in fact it must.

Still this doesn't solve the problem completely. If we both trust TAs A and B and we do automatic registration then you and I may use different TAs when we collect the trust chains. I have no idea how to remedy this since there is no way to communicate the choice to the opponent.

[cicnavi]

Was some sort of "trust anchor signaling" ever considered? From the top of my head - what about introduction of additional parameter when fetching Entity Configurations that would signal the intended Trust Anchor. It seems that Well-known URIs does not prohibit this:

Registrations MAY also contain additional information, such as the syntax of additional path components, query strings, and/or fragment identifiers to be appended to the well-known URI, or protocol- specific details (e.g., HTTP [RFC7231] method handling).

When resolving Trust Chain, since we have to fetch Entity Configurations for authority hints, if we also send "Trust Anchor Signal" to them, I guess in the end we would get to one "truly common" Trust Anchor. Not sure if "Trust Anchor Signal" would be necessary on fetch endpoint...

For Automatic Registration by using request object directly, I see that for example RP can already signal the OP the "desired" Trust Anchor by including the 'trust_chain' claim.

trust_chain OPTIONAL. Array containing the sequence of Entity Statements that comprise the Trust Chain between the RP making the request and the selected Trust Anchor, sorted as in Section 4. When the RP and the OP are part of the same federation, the RP MUST select a Trust Anchor that it has in common with the OP; otherwise, the RP is free to select the Trust Anchor to use.

So, for the scenario in which RP first does Trust Chain resolution for OP by signaling the desired TA, and then sends a hint of the desired TA in the 'trust_chain' claim when doing (automatic) registration, I guess the one common TA would be known / things would be clear. Again, I don't know what other implications all this has...

[peppelinux]

I would give the Total Power to the op in deciding the ta to use

I would use this signaling using the ta_hints parameter within the entity configuration to inform other parties about the trust anchor that the leaf known above

ta_hints Is not defined yet, discussion is open

[Razumain]

Based on my practical implementation experience I consider it a misstake to include any mechanism where a federation entity asserts any information about what trust anchor to use.

I consider this to be a 100% choice of the relying party (consumer of the entity metadata).

The choice of a trust anchor is not only a choice of trust. It is also a choice of the appropriate federation context as the choice of trust anchor determines the metadata policy of the path to that TA.

A proper path validation IMO is very similar to path validation in X.509. The input to that process is a selection of relevant TA for the intended context. Then you attempt to build a path from the leaf to the TA, or from the TA to the leaf (depending on your strategy). The TA of choice may chain to a superior entity, that still makes it a TA for that relying party if it chooses that entity as its root of trust.

[cicnavi]

This issue revolves about the fact that entity can not express its belonging to specific federation. This is done through intermediates, and intermediates can join / leave federations (add / remove TAs) dynamically. Introduction of Trust Anchor Hints in Entity Configurations (IDs of Trust Anchors it considers valid) would be a way for entity to explicitly say what federations it considers itself to be part of. From the view of a federation operator where I would like to have as much control as I can, I see this as an advantage.

[vdzhuvinov]

To everybody who has commented here, I want to survey you on these two questions:

1. Should the spec support the "Federation Integrity" property? @SECtim described this as RP and OP completing registration only when both have and choose a common Trust Anchor. For other, non-OIDC Entity Types, this means not performing an application layer transaction unless the condition is met.

2. If the "Federation Integrity" property is to be supported, then at what requirement level?

• REQUIRED, meaning it being enforced when the Trust Chain resolution is taking place, and regardless of the application protocol?

• OPTIONAL, for example subject to trust framework (with the spec providing the means to enforce the property, e.g. via optional ES + API param)?

I want to get clarity on this first.

[PedramHD]

Thanks @vdzhuvinov, these questions are indeed at the core of the issue in our opinion. However, one comment on the definition of "Federation Integrity": From our POV, Federation Integrity does not necessarily entail that RP and OP choose the same TA (or choose a common TA at all); it is just about "having at least one common TA" - however, in practice, we agree that it makes sense to include "choose a common TA".

[Razumain]

I feel really strongly against any feature aiming at defining what TA MUST och should be used to validate any entity.

This is a kind of over engineering that never ends well. The complexity of participants and verifiers will increase and piles of unforeseen problems are around the corner.

We should not make it impossible to build broken federations. We should define an infrastructure with common rules that makes it possible to build working federations.

I see no compelling reason why two parties talking to each other MUST use the same TA. If this cause these parties to fail to exchange service, then there are many options to fix this without such feature.

As I said before, it would help though if policy never changed metadata, but just was used to filter what is allowed. That discussion never took off, but I think that is at the core of this issue.

[cicnavi]

Not sure how would "Federation Integrity property" / "optional ES" / "API param" thing look like or work exactly. In my head this is new and optional claim in Entity Configuration / Subordinate Statement with a list of accepted TAs, but in general I would say:

1. yes,
2. optional (but if set, then enforced). I think the current "dynamic" trust chain resolution possibility should also stay.

I've been thinking about @Razumain comment about complexity. I actually agree that this will bring complexity, so its definitely good to try and see the pros and cons... I guess every advantage is in a sense a disadvantage, depending on from which perspective we look at it...

Pros:

• Entity owners or even Federation operators will have a mechanism of control. With this, we would have the ability to designate the federations that we consider ourself part of. We would have more autonomy, the federation becomes less centralized.
• We will have ability to define trust borders. With it we can actually NOT allow particular TA which is otherwise allowed in federation (whitelisting, approving TAs).
• We have "protection" against unintended / unnoticed / unannounced "trust expansion". Without it, how would I explain to my subordinates that I can not guarantee the expansion of the whole federation at any time? So, with this I can reduce the possibility of "unwanted" entities gaining access. I know that in any serious federation this will be properly announced, but still...
• We would have possibility to make it easier for Intermediate entities to manage federation participation for their subordinates. We would be able to use one Intermediate entity which can be part of multiple federations, and it could define federation participation for its subordinates (we would not have to define multiple Intermediates to separate federation participation for its subordinates).

Cons:

• Added complexity in trust chain resolution
• Administrative burden. What happens when the legitimate change related to Trust Anchors is introduced? This will have to be properly propagated and updated on each entity which uses this mechanism... And what if it is not properly propagated / updated? I guess whole parts of federations could become isolated at times.
• There would be possibility to create sub-federations, "islands" of trust in one federations...
• ... maybe Razumain has some more.

Personally, I would still use this new mechanism rather than, for example, Trust Marks for designating federation participation. In small or simple federations, I would not use this new mechanism.

[peppelinux]

I agree with @Razumain. At the same time, I wanted to create an optional parameter to "hint" at the trust anchor a subject recognizes as valid and usable, as proposed in this PR:

https://github.com/openid/federation/pull/138

The decision to make this parameter required or mandatory, as well as the requirement to prevent trust anchor mix-ups, should be left to the trust frameworks and their implementations, and therefore kept out of the technical specification.

After all, a subject might be part of multiple federations and use multiple trust frameworks, where the rules of one should not restrict a participant's freedom to be part of another or pursue other affiliations.

The PR is open to further review and suggestions, including the potential inclusion of a paragraph in the current security considerations about the value and benefits of using this parameter.

[vdzhuvinov]

Thanks @vdzhuvinov, these questions are indeed at the core of the issue in our opinion. However, one comment on the definition of "Federation Integrity": From our POV, Federation Integrity does not necessarily entail that RP and OP choose the same TA (or choose a common TA at all); it is just about "having at least one common TA" - however, in practice, we agree that it makes sense to include "choose a common TA".

Is there a "formal" definition of the "Federation Integrity" property?

I'm trying to figure out how to define that, precisely and unambiguously, based on the current Federation 1.0 terminology.

PS: Is "Federation Metadata Integrity" the "more" precise term for this property?

[PedramHD]

We have formalized the property in Section C.1 of our report on the first part of the Federation analysis that we shared with the OIDF. The first report covers the modeling but not the proofs (which we are working on right now). Here is a somewhat informal overview:

For the formalization, we have two global mappings:

• trustAnchors: This maps an entity identifier to the set of trust anchors that the entity trusts (i.e., by definition).
• subordinates: This maps an entity identifier to the set of immediate subordinates of the entity.

With this, we say that the entity eID is in a Federation of the Trust Anchor ta if there exists a sequence of entity identifiers e_1=ta, e_2, ..., e_(n-1), e_n=eID (i.e., the sequence starts with the Trust Anchor and ends in eID) such that:

• ta is in trustAnchors(eID), and
• e_(i+1) is in subordinates(e_i)

With this, we formalize Federation Integrity: Whenever an OP entityID_op accepts an Authentication Request for entityID_rp as the RP (i.e., after explicit registration or within an automatic registration flow -- entityID_rp is the iss value of the Chain Subject's Entity Configuration of the chain used to register the RP), then there exists an entity identifier ta' such that entityID_rp is in a Federation of ta' and entityID_op is in a Federation of ta'.

Note that this does not imply that the RP and OP indeed use the same trust anchor for the registration. Also, this is not as precise as in our report, so please let us know if you have any questions.

PS: Is "Federation Metadata Integrity" the "more" precise term for this property?

We would consider the integrity of the metadata to be a different property, i.e., that the metadata that results from a chain cannot be changed by an attacker as long as all issuers along the chain are honest. Even without an attacker, using the same trust anchor does not ensure that RP and OP use the same metadata, as they might use different intermediates that result to different policies, see #86.

[PedramHD]

Just to clarify, we are not suggesting that Federation must provide Federation Integrity (in the sense outlined above). However, if there is WG consensus that the protocol should not provide this property, we'd suggest rephrasing certain parts of the specification to make this clear, especially in the Introduction.

[Razumain]

I'm just offering my humble opinion. But history of PKI comes to mind.

As co-author of RFC 5280 and at the time Program Manager for Microsoft responsible for PKI compliance in Microsoft Crypto API, I have a distinct feeling that we are repeating the mistakes of PKI all over.

Let me explain.

With PKI we added a whole pile of "small stuff" which ended up in a huge pile. We identified a lot of things that felt scary, and we fixed it. And we ended up with something where only a fraction was used, but a lot needed to be supported. True interoperability was only achieved in a fraction, consisting of the parts that really everyone needed. The list of over-engineered stuff is huge.

Never underestimate the power of keeping the principles of a standard simple (but extensible if necessary).

In this case I totally fail to see the threat that is solved. Who cares why and in what way the other party trusts me. It's none of my business and not part of anything I need to evaluate. If they trust a bad TA, it's their problem.

What I'm interested as an entity is how and why I trust the TA I select that will honor the requirements that I care about. That's it and that is a simple sound principle.

And even If I do care what TA the other party is using, and even if I advertise this, I have absolutely no means to verify if he did. And frankly I don't care. And if the other party advertise what TA he think I should use, why should I care?

I don't mean this in any offensive manner. I just ask you to re-consider and explain what the real threat is here. We didn't even go here with PKI. ETSI kind of did by signing the signer certificate in ETSI signatures, which turned out to be one of the greatest deployment blocker for ETSI standards for signature, and one of the main reasons why ETSI signatures have real problems working cross borders and PKI domains.

[selfissued]

Thanks for your thoughtful comments @Razumain. Great questions!

[vdzhuvinov]

When we reason about "integrity" (being one, or covered) in a federation, what is the role of the Entity - Authority relationships along the Trust Chain?

Shouldn't these also be a factor in the real world?

Let's return to the example above:

.---v.  .-----v-v------.   .
|    |  | Intermediate |   |
'----'  '--.--.--.-----'   |
           |  |  |         |
   .-------'  |  '------.  |
   |          |         |  |
.--v-.      .-v--.     .v--v.
| RP |      |    |     | OP |
'----'      '----'     '----'

The RP and the OP that interact with one another are both enrolled as Leaves and Subordinates of the same Intermediate. In the real world these could be apps + services that belong to the same institution, or services governed by a common trust framework (that in turn is governed by the frameworks of TA A & B).

The relationship between Entity and authority in a OpenID Federation is bidirectional and not uni-directional, a decision made by both ends. The Leaf indicates the Intermediate is its authority by including it in its authority_hints. The Intermediate by being ready to issue Subordinate Statements for the Leaf.

@PedramHD clarified how the "Federation integrity" property is defined (thanks!) and I understood this definition comes from the definition of Federation that we have in the spec. Could the definition of "Federation" be in need of a little adjusting?

[Razumain]

@vdzhuvinov. Great clarifications and questions.

I'm sympathetic to clarifications of "Federation". In my attempts to explain OpenID Federation I have struggled with this a lot. People tend to see all entities that are interconnected (like in the original picture) as "a Federation". For this reason I used to call the context of a TA for "Federation context". But I realise that this equates to the definition of "Federation Integrity". I.e. the sum of all entities that chains to a common TA, when validated through that TA.

I actually think that it would be healthier define "Federation" as the collection of services that chain to a common TA. And then use a bigger term for all services, like "Federation Environment" or "Federation Infrastructure" which may contain one or more Federations.

I don't care strongly, but it would help a lot if there were 2 different terms.

[vdzhuvinov]

@Razumain Thanks for letting us know how you view this.

Can the resolving of trust that is based on the broader "federation environment" (that doesn't lead to a common Trust Anchor) be considered a desired feature or a valid use case in certain situations? Can we have a situation when one deliberately wants that?

[vdzhuvinov]

@SECtim @PedramHD This is a question for the formal analysis:

To obtain the "Federation Integrity" property it was proposed to have Entities Configuration include a list of the Trust Anchors for the Entity (e.g. as ta_hints claim).

Can passing the Trust Chain from RP to OP in the OpenID authentication request achieve the "Federation Integrity" property?

• The RP assembles or obtains from a resolver a Trust Chain for itself. The Trust Anchor must be shared with the OP.
• The OP validates the received Trust Chain and if it's valid and its Trust Anchor acceptable proceeds. If not, the request is rejected.

This method uses existing (draft 40) parameters. It doesn't require a new Entity Configuration Claim (e.g. ta_hints).

This method also appears to address issue #86 .

[Razumain]

@vdzhuvinov Yes I think there can be use cases where 2 entities legitimately are using different trust anchors.

I think this can be a very valid use case in international settings where an Entity from Spain chooses a Spanish TA and the other entity from Belgium is using a TA from Belgium and so forth. I would not be surprised if this becomes the reality in a dynamically growing infrastructure for Wallets in EU.

The entities in a country simply wants to have a relationship with just one domestic TA and that TA then expands interoperability be creating connections to other country infrastructures, setting applicable policies for those connections.

There is a great danger in thinking that we do understand all use cases at this early point. Unless there is something generically and inherently unsafe with allowing different entities to use different TA:s, we should not attempt to control it.

[selfissued]

In the description of the trust_chain request parameter at the end of (Using a Request Object Directly), I found this surprising text:

When the RP and the OP are part of the same federation, the RP MUST select a Trust Anchor that it has in common with the OP; otherwise, the RP is free to select the Trust Anchor to use.

This explicitly sanctions proceeding during Automatic Registration when the parties don't have a Trust Anchor in common. @rohe, do you remember why this text was put in the spec?

Note that if we keep this text, it probably belongs in a more logical and prominent place, as it speaks to architectural decisions.

[Razumain]

@selfissued I do think this is another case though. This is when the RP provide a chain to itself to the OP. And here it makes sense to use a TA that chains also tho the OP as this increase the chances that the OP actually trust this TA.

This is different from saying that the RP MUST use the same TA when validating the OP. I think we are discussing the question if the RP and OP MUST use the same TA when validating each other.

However, this quote seems to support my proposed definition of "Federation". That is, the collection of services that chains to a common TA.