Explain Trust Mark Issuer validation in more detail

[selfissued]

Fixes #127

Note that this PR currently contains four questions prefaced by "TBD" that I'd like people's input on.

This whole section needs to be significantly tightened. I started by pulling in @rohe's thoughts from the issue, albeit in a rough form.

A rendered version of this PR can be viewed at https://openid.github.io/federation/mbj-trust-mark-issuer-validation.html .

[zachmann]

This step would also be required when using the trust mark status endpoint, right? First it must be verified that the TMI is part of the federation and its trust mark status endpoint must be obtained.

[peppelinux]

we always must be sure that the trust mark issuer is still eligible and trustworthy, trust mark status alone is not enough if the trust mark issuer has been banned

[zachmann]

Should be fine to check if the delegation claim is present in the trust mark.

However, the next points suggests to look at the TA's trust_mark_owners claim. So I woudl say there are two approaches:

• TA-centered: First checking if the TM is supposed to use delegation.
• TM-centered: First checking if the TM actually uses delegation.

[zachmann]

For me this does not feel like step 4 of "manual verifying a trust mark": I would prefer to start with the basic things needed; then determining if the trust mark uses (or should use) delegation or not; and then differentiate how a delegated and not-delegated trust mark is verified.

Generally, I think it's helpful to be more clear about delegated trust mark issuance.

[peppelinux]

we always must be sure that the trust mark issuer is still eligible and trustworthy, trust mark status alone is not enough if the trust mark issuer has been banned

[cicnavi]

...and that it is possible to get verified metadata about it...

In addition to resolving Trust Chain for Trust Mark Issuer, is getting metadata really necessary? Should we try to get "verified metadata" for some entity type? I presume for federation_entity type or?

For federation_entity type it is stated:

All Entities in a federation MAY use this Entity Type. The Entities that provide federation API endpoints MUST use this Entity Type.

All of the federation_trust_mark_ endpoints are optional, so Trust Mark Issuer might choose to not priovide any endpoints.

Must we validate that we can get resolved metadata for (posiblly empty, but valid) federation_entity? Maybe consider being more clear about this...

[peppelinux]

yes, the trust mark issuer might decide to issue short lived trust marks without requiring the availability of the trust mark status endpoint

[cicnavi]

Regarding delegation, this might be common sense, but I don't see any instruction for validating that the trust_mark_id claim from the Trust Mark JWS is the same as the trust_mark_id in Trust Mark Delegation JWS, and that the iss from the Trust Mark JWS is the same as the sub claim in Trust Mark Delegation JWS. Without this check, Trust Mark Issuer can include delegation JWS that is verifiable using jwks and sub claims from trust_mark_owners, but which actually doesn't say that the Issuer is "allowed" to issue that particular Trust Mark.

[selfissued]

Merged main into the PR. Roland's changes addressed 3 of the 4 TBDs.

@peppelinux and @rohe please re-review.