Add recommendation to not include Trust Mark issuer in Trust Anchors

[Razumain]

I discovered this problem at the workshop in Stockholm.

Here is the problem illustrated as a use-case:

I run Federation A with Trust Anchor TA-A and I want to extend my federation to services under Trust Anchor TA-B

Referring to earlier discussions, it should be valid, and sometime necessary to not make TA-B a direct subordinate of TA-A. One major reason could be to avoid policy conflicts between TA-A and TA-B. So in this case I make relevant IE:s under TA-B subordinate entities directly under TA-A.

But here is the problem. I also want to honor some Trust Marks under TA-B, but in this case TA-B itself acts as the Trust Mark issuer for these Trust Marks. I actually ran into exactly this problem in Stockholm.

As I have not made TA-B a subordinate of TA-A, I have no means of trusting these Trust Marks. The only way I could solve this was to also include TA-B as a subordinate of TA-A, but this also create multiple paths to the same entity. Some via TA-B and some via its subordinate IE:s.

I could solve this in my implementation as I have a parameter for resolvers to ignore subordinates under a particular entity, So I included TA-B with this restriction. But this is far from ideal.

Conclusion
I think we should have a section on recommendations regarding what services that fits well together and what federation services that should not be mixed. I can think of several valid guidelines and recommendations.

• Trust Anchor fits well with a Resolver - Allows a single trusted key both to validate paths and resolve entities
• Trust Anchor should not include Trust Mark endpoints (for reasons above) as it makes it harder to chain between federation contexts
• Federation Endpoints (TA, IE, TrustMark issuers, Resolvers) MUST NOT aslo provider federated services (OP, RP, OAuth client, Authorization server, Resource server, etc) under a common Entity Identifier.

[MichaelFraser1999]

I'm in agreement with the proposal to create a "good practices" or recommendations section. The first two points I also agree with, and while I don't think these should be normatively enforced, they are useful learnings for ecosystems. We've encountered this exact scenario in a real-world setting where two entities proposed to join two Federations bilaterally without an overarching TA.

I'm not sold on the final point though - I can think of valid scenarios where an openid provider of some form may well want to also issue trust marks as an example. I'd not be against warning of the pitfalls, but I don't believe we should explicitly caution against it

[Razumain]

@MichaelFraser1999 . I actually agree with your use case here. I think an OP could provide a Trust Mark Issuer.
I think I would rephrase this to say the Trust Anchors and Intermediate Entities MUST not also be (OP, RP, OAuth clients etc).

[zachmann]

Slightly unrelated but also related: It would be nice to have an entity type for trust mark issuers, so trust mark issuers can be easier identified.

[MichaelFraser1999]

I'm still leaning towards highlighting the issues an implementation may encounter in given scenarios, rather than trying to normatively prevent it. Especially as this is for a specific scenario - we don't want to prohibit federations being built in whatever shape people want if they know they won't encounter this specific scenario.

[rohe]

Regarding having a special entity type for trust mark issuer I proposed that ages a go but was voted down :-)

So, I'm trying to understand the setup.

You have two federations (A&B).
Now you want entities in A to be able to verify/validate trust marks issued by trust mark issuers in B
without having TA-A listing the trust mark issuers in B that should be usable by entities in A.

Also you don't want TA-B to be a member of A.

Correct so far ?

[lj-raidiam]

The recommendation to use separate entity IDs for the trust mark issuer and the trust anchor—when these are provided by the same service—makes sense and provides clarity in more advanced or complex ecosystems. That said, I believe it should remain a recommendation rather than a strict requirement. In simpler ecosystems, this level of separation might not be necessary, and enforcing it could add unnecessary overhead. If an ecosystem evolves later and separation becomes needed for such advanced use cases, implementers can always migrate accordingly. Unfortunately for them the migration may not be that straightforward.

[selfissued]

@Razumain, can you answer Roland's question above that's attempting to clarify the situation you are concerned about? Thanks.

[Razumain]

@selfissued @rohe Sorry for my temporary absence.

My actual intention for this was to propose guidance, and explain the consequences of certain service mixtures under a common Entity Identifier. I'm perfectly fine with recommendations here.

[selfissued]

@Razumain I hope things are OK for you and your family. Glad to have you back.

I'll think about what kinds of guidance we should provide.

[peppelinux]

from my perspective,

trust mark issuers makes sense within the TA's entity configuration because it brings the evidence about which are the valid trust marks issuers within the federation according to its TA

having multiple federation using m,ultiple TA, even linked between them, doesn't move the requirement to have the trust marks issuers published by the TA used as landmark for evaluating the trust.

additional documents and draft about federations of federations alongwith their implementations consideration are welcome if they do not break the basic rules defined within the core federation specs

following this proposal, it's important to consider that trust marks issuers is an optional parameter

[selfissued]

@Razumain, permit me to ask two clarifying questions:

1. Which recommendations above do you support? (There's already a lot of text in the issue.)
2. Can you add answers to @rohe's specific questions in his comment Add recommendation to not include Trust Mark issuer in Trust Anchors #214 (comment) ?

I hope things are well for you and yours. Best wishes.

[Razumain]

Regarding having a special entity type for trust mark issuer I proposed that ages a go but was voted down :-)

So, I'm trying to understand the setup.

You have two federations (A&B). Now you want entities in A to be able to verify/validate trust marks issued by trust mark issuers in B without having TA-A listing the trust mark issuers in B that should be usable by entities in A.

Also you don't want TA-B to be a member of A.

Correct so far ?

I thought I answered this a long time ago. Sorry for not being responsive.

Yes, I think you got it right. And I understand that the guidance is harder than when you first look at this.

Basically, chaining to entities in another federation should bypass the TA of that federation to avoid policy conflicts. That we discussed a long time ago. But if the Trut Mark Issuer is that TA, then we have problems. I then have to also chain to the TA and that creates paths with potential policy conflicts.

I think the following recommendations would be valid:

• An entity intended to act as a Trust Anchor SHOULD NOT also perform the role of being a Trust Mark Issuer.
• An entity issuing subordinate statements should NOT also perform the role of a federation service under the same Entity Identifier. E.g. OP, RP, OAuth entity etc.

I think these are wise recommendations that helps to avoid some tricky problems.

[rohe]

Responding to the trust mark issue.

There is nothing that prevents an entity from having trust marks issued within the context of different federations.

The entity validating trust marks just have to chose which federations (TAs) it trusts and wants to use when validating/verifying the available trust marks for an entity.

It doesn't have to choose just one TA.