Federation - trust_marks_issuers claim available for all entities

[Francesco Marino]

Regarding the trust_marks_issuers claim, the specification says that "a trust anchor MAY use this claim to tell which trust mark identifiers and their issuers are trusted by the federation. This claim MUST be ignored if present in an entity statement of other entities than trust anchor." In sec 5.3.2 it says that "For other externally issued trust marks, it is an out-of-band process to define and announce accreditation authorities to other entities and it is left to the discretion of the receiving party to assign an appropriate level of trust to such trust marks."

What if we consider the trust_marks_issuers also optional in the entity configuration of all entities?

I mean, we could have different types of trust marks. The "federation" trust marks can be issued only by the entities in the trust_marks_issuers of the trust anchor, while external trust marks can be defined by other entity types independently. Each entity could define in its entity configuration its own trust mark that certifies, for example, a particular agreement with other parties defining also the accreditation authorities that are able to issue that trust mark.
This trust mark would not be valid for the federation trust, so information about this trust mark (including its issuers) could not be provided by the trust anchor but only by the entity that defines it.

[Vladimir Dzhuvinov]

If I get this correctly, an intermediate will be able to define their own trust_mark_issuers , but it is up to the other entities to decide whether to honour those or not?

[Francesco Marino]

The point is this: the usage of trust marks as a certification of an agreement between parties (e.g. leaf entities), not strictly related to federation agreement, should be under the control of the entity itself. In this case this entity actually plays a role of trust mark issuer and makes available not only the trust mark status endpoint but also the trust_marks_issuer. In italian Attribute Authority use case, as you know, we are leveraging the trust mark usage in order to “certify” the agreements between RPs and AAs. Basing on the current specs, an AA must ask the TA (in an out of band process) to add the authorities accredited to issue trust marks of this type to the trust_marks_issuers claim in the TA's entity configuration.

Obviously it will be up to the other entities to decide wheater this type of trust mark makes sense or not.

[Vladimir Dzhuvinov]

I see. Thanks for this clarification! The example made the point clear. In the current spec version anyone can include a trust mark, but only the TA gets to specify where the lookup can take place, which for non-TA sanctioned trust marks makes it difficult to figure out how to look them up. So, with this proposal other entities can publish a trust_marks_issuers where necessary to facilitate the lookup.

This makes sense to me.

[Michael Jones]

@Giuseppe De Marco will ask for clarifications.

[Giuseppe De Marco]

Thank you @Francesco Marino for having pointed out this.

Your proposal is remove this text “This claim MUST be ignored if present in an entity statement of other entities than trust anchor.“
Then rationale is that in italy we’re enabling the Attribute Authorities and these can have direct conventions with the RPs and also an autonomous onboarding system. Not all the AA need this but some for sure.

The Federation trust mechanism allows the participant to establish the trust with the AAs. At the same time the Trust Anchor won’t handle the onboarding on behalf of the AAs, also it won’t handles the intermediaries of AAs. These latter, some of these, claims their autonomy as well.

This scenario makes the AAs able to have their intermediaries and also issuing trust marks,. The first is not covered by oidc fed and doesn’t need this because it’s only an implementation/administrative pattern without any impacts on the participants and the general interoperability model of the federation. The second is covered by oidc fed and we like this.

The requirement for this autonomy of the AAs is that these wants also to publish the trust_mark_issuers by their own, saying which of their intermediaries can issue the AA trust marks on their behalf.

I expressed my doubts on that and then we decided to don’t allow this, because we dont think that an AA would activate/deactivate dozens of intermediaries per day. I mean that an AA onboards a specified number of intermediaries and pushes the request to the TA (fed authority) to include these in the trust_mark_issuers of the federation.
This is what we adopt for a concrete implementation.

However we think that oidc fed may open the door to the possibility that other participant may publish the trust_mark_issuers that they think are important for something that’s not belong directly to a single federation. ìThis change is very little, having said that the text “This claim MUST be ignored if present in an entity statement of other entities than trust anchor.“ could be removed. How the participants in a federation creates different paths for different purposes is something interesting and I think that OIDC Fed shouldn’t prevent this

[Giuseppe De Marco]

Updated proposal. The text may change in this way

“This claim SHOULD be ignored if present in an entity statement of other entities than trust anchor.“

@Roland Hedberg

[Michael Jones]

While it’s always possible to change MUSTs to SHOULDs, it’s usually better to understand WHY an implementer wants the MUST to not be there and what they will accomplish by having the resulting flexibility. Then perhaps we can accommodate their needs in a direct way that also benefits others.

Thanks for continuing the discussion, @Giuseppe De Marco .

[Giuseppe De Marco]

Following the discussion in GAIN PoC this issue could became a requirement in context where each participant may claim its autonomy. I’d wait the evolution of this discussion in the GAIN POC before closing this issues.

I’m in favor to close this and force all the parties to communicates their trust mark issuers to one or more Trust Anchors. IF we reno unce to this requirement the costs will be moved to the participants of a federation that should implement bilateral trusts mechanisms to consider each trust_mark_issuers published by every participant as trsutworthy.

[Francesco Marino]

In OIDC Fed we have the trust_mark_issuer as an entity type. The Metadata of this entity type contains only the status_endpoint. I think that we could also add the trust_marks_issuer as an optional parameter in order to allow any trust_mark_issuer entity type to independently manage its trust mark issuers. What do you think?

[Michael Jones]

On the 12-Aug-22 Federation editor’s call, we agreed to close this after Giuseppe talks to Francesco about it. Giuseppe will add the rationale for closing it at the time it is closed.

[Giuseppe De Marco]

As discussed in the 12-Aug-22 Federation editor's call, we decided to confirm the text already in the Federation spec. Even if every participant may expose the claim trust_mark_issuers in its entity configuration, the TA is the sole entity that defines the rules of a federation, the issuers and its intermediaries.

Following the current Federation spec, nothing prevents that many trust anchor can be supported by a participant and with this mechanism many trust_mark_issuers definition, belonging to many Trust Anchor, can be supported.

We think that for both implementative and normative aspects, too much autonomy to Attribute Authorities or federation intermediaries would produce a sort of way to elude how the trust must be established, making the functioning of a Federation too complex and fragmented.