-
Notifications
You must be signed in to change notification settings - Fork 7
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
Explain Trust Mark Issuer validation in more detail #153
base: main
Are you sure you want to change the base?
Conversation
Validate that the Trust Mark Issuer is part of the Federation | ||
and that it is possible to get verified metadata about it | ||
by using the procedure defined in <xref target="resolving_trust"/>. | ||
</t> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
by using the procedure defined in <xref target="resolving_trust"/>. | ||
</t> | ||
<t> | ||
If delegation is not being used (TBD HOW TO DETERMINE THIS?), |
There was a problem hiding this comment.
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.
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?) | ||
The claims for the Trust Mark identifier | ||
in the <spanx style="verb">trust_mark_owners</spanx> value | ||
are used in the following way: |
There was a problem hiding this comment.
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.
Validate that the Trust Mark Issuer is part of the Federation | ||
and that it is possible to get verified metadata about it | ||
by using the procedure defined in <xref target="resolving_trust"/>. | ||
</t> |
There was a problem hiding this comment.
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
Co-authored-by: Giuseppe De Marco <[email protected]>
<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 |
There was a problem hiding this comment.
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...
@@ -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?) |
There was a problem hiding this comment.
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.
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 .