Make it optional to provide an actual Trust Mark in Entity Configuration, or allow expired Trust Marks

[Razumain]

I forgot about this one, also discussed in Stockholm. I include it here for completeness.

Many implementers are considering short lived Trust Mark JWT:s.

At the same time we want leaf entities to publish Entity Configuration that includes all Trust Marks. This makes Entity Configuration publication more dynamic than it should need to be.
This is the only thing that prevents the Entity Configuration to be more long lived and updated only in case of information update (or expiry).
This also requires the leaf entity to implement the Trust Mark endpoint API for continuous update of Trust Marks.

It would be helpful if inclusion of the actual Trust Mark is optional. If the Trust Mark is absent, the verifier simply has to request a new one.

The downside of this is that the verifier would need to know the id of the issuer to do this, and that would require a change to the current format.

An alternative is to keep the spec as it is, but clearly state that it is legal to provide an old expired Truts Mark. It is then up to the verifier to request a new one from the same issuer.

In either case, I think some clarifying language would be helpful.

[zachmann]

I'm in favor of requiring that either the trust_mark_id + trust_mark_jwt or trust_mark_id + trust_mark_issuer MUST be provided.

I consider this a minor non-breaking change to the spec.

[selfissued]

@zachmann, if you have the Trust Mark JWT, you don't also need a trust_mark_id parameter because you have the trust_mark_id in the JWT itself.

@Razumain, it's already optional to provide Trust Marks in Entity Configurations. Not all Entities need them. As for expired Trust Marks, they should be disregarded.

@Razumain, it sounds like what you're actually asking for is a new feature that if you have a trust_mark_id claim and possibly also a trust_mark_issuer claim in an Entity Configuration, then that's interpreted as a signal that a Trust Mark with that ID can be obtained from that Issuer when needed. Do I have that right?

[Razumain]

@selfissued

On the first question to me - Yes the Trust Mark claim is optional, but IF you include it it must contain BOTH trust_mark_id and the trustmark. It would help here if it MUST contain the trust_mark_id and MUST contain one of trust_mark_id or trust_mark_issuer

On the second question - Yes.

On the remark to @zachmann - I would like to make trust_mark_id mandatory. We use the same structure in resolve responses and there it is very useful to always get trust_mark_id. This because the resolver must validate the trust_mark and therefore, if this claim is included in the resolve response, you actually don't need to look at the trust_mark at all.

[zachmann]

@zachmann, if you have the Trust Mark JWT, you don't also need a trust_mark_id parameter because you have the trust_mark_id in the JWT itself.

While this is conceptual true, the spec (currently) REQUIRES that the trust_mark_id (as well as the trust_mark_jwt) is given. And this for good reason. The trust_mark_id is used to find the correct trust mark without the need to actually inspecting it.

I think I'm on the same page here with Stefan.

[rohe]

If you don't have the trust_mark how would you know which issuer to ask for a new trust_mark ??

That information only exists in the trust_mark it's not part of the trust_mark_type.

[zachmann]

If you don't have the trust_mark how would you know which issuer to ask for a new trust_mark ??

As noted above:

I'm in favor of requiring that either the trust_mark_id + trust_mark_jwt or trust_mark_id + trust_mark_issuer MUST be provided.

It's clear that the trust mark issuer must be known, and the entity would publish the trust mark issuer in the entity configuration - instead of the jwt.

[selfissued]

We merged #225, which operates only on Trust Marks and not on references to Trust Marks or the possibility of issuing new Trust Marks with certain characteristics. This was published in https://openid.net/specs/openid-federation-1_0-43.html.

Being consistent, the trust_marks claim in an Entity Statement should also continue to include Trust Marks themselves.

I propose to close this issue on this basis.

[zachmann]

We merged #225, which operates only on Trust Marks and not on references to Trust Marks or the possibility of issuing new Trust Marks with certain characteristics. This was published in https://openid.net/specs/openid-federation-1_0-43.html.

Being consistent, the trust_marks claim in an Entity Statement should also continue to include Trust Marks themselves.

While I agree that there MUST be the option to include the JWT, I don't see the updated status endpoint as a reason to not allow the proposed change.

After all the trust mark status endpoint is entirely optional and there are other ways to verify if an entity has a certain trust mark (type) or not.

I'm still in favor of allowing an alternative to trust_mark_type + trust_mark_jwt, that is trust_mark_type + trust_mark_issuer. As noted in the initial proposal this gives benefits for short lived trust marks so the entity configuration does not need to be updated with the same interval.

[Razumain]

I see that not much has been said about this for a while. Just want to add that I support @zachmann's proposal.

[rohe]

I don't think adding trust_mark_type + trust_mark_issuer to trust_marks in the Entity Statement is a good idea.
To me it's like mixing apples and pears.

If there really is a use case for having that combination (I would like to have it described to me) I would rather add another claim to the Entity Statement.
If so I propose ephemeral_trust_marks to be the name of that claim.
As with trust_marks the value would be a JSON object but with the standard claims trust_mark_type and trust_mark_issuer.

This would make it clear that trust marks and ephemeral trust marks are different and should be handled so.

[selfissued]

ephemeral_trust_marks is a possible extension. At this point, if people want to experiment with it, it should go into its own extension specification.

Other than defining this possible extension, are there other changes being requested in this issue that are actionable now?

[Razumain]

I think I understand where you want to go with this. And I respect that. But I really think you may miss the point why this is important and why doing something actually adds significant value.

May I start with the significant values and why it is important:

Avoid revocation
Revocation IS hard and resource consuming. AND you have to be clear about what you are actually revoking. In credit card revocation, we are not revoking the individual cards, but the credit card number (the identity). In X.509 certificates we do not revoke the identity, but the individual certificate. Revocation requires infrastructure, accurate data-bases and retention policies (For how long should I be aware and respond with revoked status).
One way to avoid revocation is to just issue short lived attestations. If you loose your privilege, you simply can't get a new proof. That is simpler to provide and simpler to consume, and that is significant value.

Allow static Entity Configuration declarations
The burden of having leaf entities publishing EntityConfigurations can be quite high. At least when you try to build up the use of OIDF in a pre-existing service infrastructure. I't getting significantly harder if the entity needs to constantly refresh its Trust Marks to update EntityConfiguration. The alternative is to leave EntityConfiguration static and ignore that the Trust Marks there has expired. But that can cause unpredictable behavior with different implementations. Some choosing to ignore them, some thinking they are invalid, and some actually refreshing them and finding them active.

It is there fore (in my mind) a significant improvement to allow EntityConfiguration to NOT include the actual Trust Mark, but instead indicate the trust mark type, and the issuer instead. This allows any chain validator to simply ask for a new Trust Mark from the declared issuer. This should be a natural and supported option.

I think the change is small and non controversial. Just include 3 fields (trust_mark_type, trust_mark and trust_mark_issuer but make at least trust_mark optional.

What do you gain by not doing this?