[Openid-specs-ab] Issue #2075: An infrastructure for trust marks only (openid/connect)
peppelinux
issues-reply at bitbucket.org
Sat Oct 28 11:04:40 UTC 2023
New issue 2075: An infrastructure for trust marks only
https://bitbucket.org/openid/connect/issues/2075/an-infrastructure-for-trust-marks-only
Giuseppe De Marco:
There may be cases where Federation would be used only for provisioning and evaluation of Trust Marks, without trust chains and subordinate/authority relationships. In these cases the following points seems of interest:
* authority\_hints in the EC, the current specs mandates the presence of this claim for all the entities that are not TA: `For all Entities except for Trust Anchors that do not have any Superiors, this is REQUIRED and MUST NOT be the empty array` . The proposed change would be \``For all Entities that have any Superiors, this is REQUIRED and MUST NOT be the empty array`\`. This also implies that a TA even if it a TA in relation to a specific federation, it could be a leaf or an intermediate within another federation. Even if it is an advanced topic, I believe that is resonable applying this awareness in this specific part of the text.
* subordinate listing and trust marked listing endpoint return a json array containing the entityid of the federation entities, while we do not have any endpoint that, given a sub=$entityid, returns the trust mark for that entity. Some proposal was made in the PR related to trust marked listing endpoint but then removed to satisfy the response schema of the listing endpoints. This remains an open point for the specs.
In relation of the last point, in italy we use to provide the trust marks issued by a superior to a subordinate within the entity statements. This is good for the italian use case but have limits for the provisioning of the trust mark.
We should imagine an infrastructure where an entity, using the federation api, can obtains the updated trust marks without any kind of out of band mechanisms and then allow that in the specs.
The proposal for the second point is the creation of a new endpoint for the provisioning of trust marks.
Responsible: Giuseppe De Marco
More information about the Openid-specs-ab
mailing list