-
Notifications
You must be signed in to change notification settings - Fork 10
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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 | ||
by using the procedure defined in <xref target="resolving_trust"/>. | ||
</t> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe 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?), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should be fine to check if the However, the next points suggests to look at the TA's
|
||
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. | ||
|
@@ -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 commentThe 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 |
||
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
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
|
@@ -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. | ||
|
@@ -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> | ||
|
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.
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 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...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.
yes, the trust mark issuer might decide to issue short lived trust marks without requiring the availability of the trust mark status endpoint