Potential risks of using `logo_uri` in Trust Marks

[jcmelati]

The logo_uri claim in Trust Marks allows logos to point to arbitrary URLs. That brings security questions:

Security Concerns:

• References permanently links to potentially uncontrolled resources
• Unverifiable data content is inserted into a signed statement
• Creates potential remote code execution attack vectors
• Cross-site scripting (XSS) risks
• Possible inconsistency in resource delivery over time

Without a compelling operational necessity for a logo in a trust mark, these security concerns suggest the logo_uri feature should probably be eliminated, or have its existence properly justified in regards to the concerns above.

Possible Solutions:

1. Remove logo_uri field. The core purpose of trust marks is verifiable attestation. Logos are decorative and should be handled separately by applications that need them. This makes the Trust Mark self-contained.
2. Embed logo as a base64 image or SVG within the trust mark.
3. If embedding the logo bloats the JWT size, we could add a logo_hash field next to the logo_uri to verify logo hash integrity against the signed statement.

[Razumain]

I don't share this concern.

As I see Trust Marks being used, they are always validated first. The logo URL is a piece of voluntary information that can be used to retrieve a logo image after it has been determined that the Trust Mark is trusted.

I do agree that for most usages, the need for a logo is very limited. But I can't really see any harm or unrealistic threats beyond what is always the case then dereferencing data from outside sources.

[peppelinux]

see: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-11.2.3-2.11.2.6.2.2

[peppelinux]

also

• adding credential issuer logo parameter in the issuer metadata OpenID4VCI#170
• clarify that logo_uri can be of multiple schemes OpenID4VCI#141

[vdzhuvinov]

My reasoning is this:

The Federation spec gives entities a method to check if a Trust Mark can be trusted or not.

If a Trust Mark that validates as accepted includes or references malicious content, this is first a problem of how a federation is run and whether it can be trusted in the general sense. A badly run federation could equally well enroll malicious Subordinates, or define risky metadata policies.

[jcmelati]

The messages above are exactly the reason why I believe that having logo_uri in the Trust Mark is not a good idea. Let me elaborate.

As I see Trust Marks being used, they are always validated first. The logo URL is a piece of voluntary information that can be used to retrieve a logo image after it has been determined that the Trust Mark is trusted.

The act of validating a Trust Mark indeed implies that the content of the logo URL is also trustable. That is of course not necessarily the case. The logo content can change over time, differ between requesters (content poisoning), or become compromised through domain expiration - none of which invalidates the Trust Mark's signature.
There's a fundamental contradiction here. We call it a Trust Mark, but it contains references to data that we cannot actually trust.

If a Trust Mark that validates as accepted includes or references malicious content, this is first a problem of how a federation is run and whether it can be trusted in the general sense. A badly run federation could equally well enroll malicious Subordinates, or define risky metadata policies.

A Trust Mark can include malicious content even if the federation is run properly, and even if the subordinate that issued it was not malicious. The issue isn't about federation governance - it's about the design decision to include untrusted references in what's supposed to be a trustworthy attestation.

[Razumain]

The act of validating a Trust Mark indeed implies that the content of the logo URL is also trustable.

As designer of web applications I think I need to strongly disagree with this.

All content obtained from the internet or from outside source is regarded as untrusted and malicious unless proven otherwise, and properly sandboxed and tested for compliance to the purpose for which the data is used.

This is a principle we MUST uphold for all data retrieved by referencing any URL, and failing to do so will lead to severe security vulnerabilities.

This is why I don't see this particular URL as a big threat that stands out among all other stuff we need to get throught URL:s. The concept of an image is well understood and can be sandboxed properly to be allowed to deliver visual content only, and prevented from e.g. delivering code that can be remotely executed.

For further discussions on this subject in general I think OWASP is a great resource: https://owasp.org

[vdzhuvinov]

@jcmelati To make sure we are on the same page, are you concerned with the case when

1. the logo_uri is hosted under the control (domain) of the Trust Mark issuer; or
2. is hosted by a 3rd party, outside the direct control of the Trust Mark issuer?

[jcmelati]

While I appreciate @peppelinux reference to Credential Issuer Metadata, I believe Trust Marks present a more fundamental concern as we're embedding potentially mutable references in what's supposed to be a verifiable attestation.

Trust Marks are designed to be verifiable statements that can be relied upon throughout their lifetime. Including a reference to external content that could change or become controlled by different entities (through domain expiration, transfer, etc.) contradicts this core purpose, regardless of who initially controls the domain.

There is no way for someone verifying a Trust Mark to be sure that whatever content of logo_uri they are reading is the exact same as intended by the issuer. I have a hard time wrapping my head around calling a Trust Mark something that references data in a non-deterministic way.

This differs from Credential Issuer Metadata where logo_uri exists within self-attested metadata under the issuer's current control. The key distinction isn't about URL security practices, but about maintaining the integrity of attestations across their lifetime.