Skip to content

Explain Trust Mark Issuer validation in more detail #153

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 29 additions & 13 deletions openid-federation-1_0.xml
Original file line number Diff line number Diff line change
Expand Up @@ -3429,14 +3429,35 @@
</section>
</section>

<section title="Validating a Trust Mark" anchor="trust_valid">
<section title="Validating a Trust Mark" anchor="trust-mark-validation">
<t>
An Entity SHOULD NOT try to validate a Trust Mark until
it knows which Trust Anchor it is using.
To validate a Trust Mark Issuer, follow the procedure
defined in <xref target="resolving_trust"/>.
To determine this, first resolve the Trust Chain,
about the Trust Mark Issuer,
as described in <xref target="resolving_trust"/>.
</t>
<t>
To validate a Trust Mark, either:
<list style="symbols">
<t>
Use the Trust Mark Status endpoint to verify that the
Trust Mark is still active
as described in <xref target="status_endpoint"/>.
</t>
</list>
or perform these steps:
<list style="symbols">
<t>
Validate that the Trust Mark Issuer is part of the Federation
and that it is possible to get verified metadata about it
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...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...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

by using the procedure defined in <xref target="resolving_trust"/>.
</t>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@peppelinux peppelinux Jan 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

<t>
If delegation is not being used (TBD HOW TO DETERMINE THIS?),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

validate that the Trust Mark Issuer is entitled to issue Trust Marks
with the given Trust Mark identifier (TBD HOW TO DETERMINE THIS?).
</t>
<t>
Validate the signature of the Trust Mark JWT and verify that
it has not expired.
Expand All @@ -3447,7 +3468,7 @@
of the Trust Anchor's Entity Configuration,
verify that the Trust Mark contains
a <spanx style="verb">delegation</spanx>
claim.
claim. (TBD WHAT TO DO IF IT DOESN'T?)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

The claims for the Trust Mark identifier
in the <spanx style="verb">trust_mark_owners</spanx> value
are used in the following way:
Comment on lines 3468 to 3474
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Expand All @@ -3464,15 +3485,7 @@
</list>
</t>
</list>
or:
<list style="symbols">
<t>
Use the Trust Mark Issuer status endpoint to verify that the
Trust Mark is still active
as described in <xref target="status_endpoint"/>.
</t>
</list>
</t>
</t>
<t>
Note that the Entity representing the accreditation authority
SHOULD be well known and trusted for a given Trust Mark identifier.
Expand Down Expand Up @@ -10050,6 +10063,9 @@ Host: op.umu.se
<t>
-42
<list style="symbols">
<t>
Fixed #127: Explained Trust Mark Issuer validation in more detail.
</t>
<t>
Fixed #130: Allow multiple Trust Anchor values to be passed in resolve requests.
</t>
Expand Down
Loading