Skip to content

Conversation

@rohe
Copy link
Collaborator

@rohe rohe commented Aug 6, 2025

The fact that Trust Mark validation concerns Trust Marks represented by signed JWT needed to be stressed.

Removed statement that where present in other parts of the document.

Comment on lines 3545 to 3551
Verify that the value of the instance’s
<spanx style="verb">trust_mark_type</spanx> is listed in
the TA’s <spanx style="verb">trust_mark_issuers</spanx> and if so
that the instance's <spanx style="verb">iss</spanx> appears
in the corresponding list of entity ids. Note that the list may be
an empty list which signifies that anyone can issue a trust mark
with the <spanx style="verb">id</spanx> in question.
Copy link
Collaborator

Choose a reason for hiding this comment

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

This means that a Trust Anchor MUST publish all trust_mark_types that it allows to be used in trust_mark_issuers.

I think that this is to strict. The previous version allowed the possibility of the verifying entity to also accept trust marks when they are not listed in trust_mark_issuers. But as it is phrased now, a trust mark with an type not listed in trust_mark_issuers will fail validation.

I would prefer something like, if the trust_mark_type is listed in the TA's trust_mark_issuers then the issuer must appear in the published list. But if the trust mark type is not listed, the verifier can decide by own means.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

You don't feel that the section starting with "An Entity MAY choose .. " is good enough ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Mmmhhh, in principle yes. However, it feels like a contradiction. The section after the steps states:

 Trust Marks that are not recognized within a federation SHOULD be ignored when evaluating trust in the Entity that presented them. [...]
 An Entity MAY choose, at its own discretion, to utilize Trust Marks presented to it that are not recognized within the federation, and where the accreditation authority is established by an out-of-band mechanism.

For me there is a contraction between the statements after the steps, that say one SHOULD only use approved trust mark types but MAY use others, and the steps that require all steps MUST and therefore the trust mark validation MUST verify that the trust mark type is included in the trust_mark_issuers.

I would suggest to include a statement in the "An Entity MAY choose ..." section, that in such a case step 1 of the above becomes optional.

Co-authored-by: Michael B. Jones <michael_b_jones@hotmail.com>
rohe and others added 2 commits August 13, 2025 16:21
Co-authored-by: Michael B. Jones <michael_b_jones@hotmail.com>
Co-authored-by: Michael B. Jones <michael_b_jones@hotmail.com>
rohe and others added 2 commits August 13, 2025 16:22
Co-authored-by: Michael B. Jones <michael_b_jones@hotmail.com>
Co-authored-by: Michael B. Jones <michael_b_jones@hotmail.com>
Co-authored-by: Michael B. Jones <michael_b_jones@hotmail.com>
Co-authored-by: Michael B. Jones <michael_b_jones@hotmail.com>
Co-authored-by: Michael B. Jones <michael_b_jones@hotmail.com>
Co-authored-by: Giuseppe De Marco <demarcog83@gmail.com>
Co-authored-by: Giuseppe De Marco <demarcog83@gmail.com>
Co-authored-by: Giuseppe De Marco <demarcog83@gmail.com>
Co-authored-by: Giuseppe De Marco <demarcog83@gmail.com>
Co-authored-by: Giuseppe De Marco <demarcog83@gmail.com>
Co-authored-by: Giuseppe De Marco <demarcog83@gmail.com>
Co-authored-by: Michael Fraser Raidiam <77011328+MichaelFraser1999@users.noreply.github.com>
@selfissued selfissued merged commit 6257b76 into main Aug 18, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants