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 is a TA in relation to a specific federation, it could be also 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.

‌

[Giuseppe De Marco]

What about extending the Trust Mark Status Response from

{
  "active": true
}

to

{
  "active": true,
  "trust_mark": { ... }
}

where trust_mark is optional in the response.
Or better defining a new endpoint specialized for this scope? → this brand new endpoint would be optional, exactly as the trust_mark in the status response.

[Michael Jones]

Endpoints are a big deal. We should be parsimonious with them.

We should discuss this use case on a call with the editors or a working group call.

[Vladimir Dzhuvinov]

I’d suggest to keep the concerns separate and define a new Trust Mark issuer endpoint (i.e. not overload the existing status endpoint).

[Vladimir Dzhuvinov]

The separate endpoint will naturally entail a new federation metadata parameter which will make this TM issue capability discoverable.

If the current status endpoint is overridden this extra discovery benefit will not be there.

[Giuseppe De Marco]

Agree with you @Vladimir Dzhuvinov

[Giuseppe De Marco]

PR here https://bitbucket.org/openid/connect/pull-requests/666

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/666