Open OIDF-automation opened 5 months ago
OIDF-automation
commented
4 months ago There’s nothing preventing implementations from building multiple trust chains in parallel, potentially ending at multiple mutually trusted trust anchors. At most, we might want to relax the language about choices made while following authority hints to explicitly say that multiple options can be explored if desired.
Would that do the job?
OIDF-automation
commented
4 months ago I think the key point in your description is “acting as both”.
It’s easy to verify that an entity is both a bank and an insurance provider but that is not the same as proving that it is acting as both.
Right ?
OIDF-automation
commented
4 months ago Yes the key point as as you say, when an entity is acting as both. As you both pointed out above we can have the two chains built and then combined after the fact if a desired “insurance AND banking” statement is to be produced. Though todo this the chains must be constructed manually.
Another point though and I’m not sure if it fully qualifies as a hole, but, in the above scenario, if an entity were to use a resolve endpoint to construct a chain between any of the entities and the trust anchor, there isn’t a way in the resolve endpoint to specify which path the chain would be produced for? I.e. one implementation may go via the banking authority intermediate and another would go via the insurance authority intermediate - both would produce different entity statements as a result
OIDF-automation
commented
3 months ago All, please note that there are very large banking groups that do a lot of international settlements that are looking at exactly this challenge. Cross border open banking. There are also ecosystems domestically with multiple federations / regulators where attributes (scopes, claims etc) are authorised and granted by different federation controllers to the same relying party. Solving this problem or somehow indicating that the trust chains / anchors need to be completely resolved along all trees is a requirement that we have now so i’m keen to see this problem resolved within this WG rather than having ecosystems come up with fragmented profiles of federation to meet this need.
TomCJones
commented
3 weeks ago It is the responsibility of the leaf node to create the chain so it is up to it to create the chain it wants. It may be that for different tasks the leaf would create different chains, and that is fine. For example at work and at home. It's possible that a note should be included in the spec for clarity.
Razumain
commented
3 weeks ago My point on this is that entities should not be enrolled under multiple Intermediate entities that chain to the same trust anchor. For me that is a federation management issue and nothing that the standard must sort out.
From the perspective of the Resolver, it has no possibility to determine what path to use.
In our implementation of the Resolver, we build a cache of all paths to each resolvable entity, in order to speed up the resolve process. This we do by traversing the tree top down using the listings endpoints. If we encounter a path for an entity that already has an existing path, we simply pick the latest and discard the other. Whatever path we find is considered valid and we have no reason to pick any particular over another.
There can be no expectancy for a requester to a resolve endpoint to expect a particular path. The result is that what path you get will not necessarily the same you would get from another resolver, or from doing path building yourself bottom up.
I think it would be OK for the standard to explain the consequence of providing multiple paths to the same trust anchor, in the worst case it could mean difference in metadata if metadata policy of the paths differs. But I think it is the responsibility of the federation entities to collaborate in order to avoid ambiguities.
selfissued
commented
2 weeks ago @rohe and @MichaelFraser1999 , do you agree with adding Implementation Considerations text along the lines that @Razumain suggests above?
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/2144
Original Reporter: MichaelFraser99
In the below example, we have a set of entities that are both trusted and can have entities issued for by the Banking Authority and the Insurance Authority. In this scenario, the banking authority will issue a metadata policy dictating what is allowed/needed to act as a bank and the insurance provider will do the same providing what's required to act as an insurance provider.
The concern arises when an entity wishes to produce a statement when its acting as both. Currently, the spec requires two chains to be built either manually or through the use of the resolve endpoint and then manually combined to produce the final entity statement.
How should this be best addressed/communicated?