Registration 2 - Should data: URLs be allowed as valid logo_uri values?

[Serkan Özkan]

We would like to clarify if “data:” urls with a valid image mime type, e.g data:image/gif;base64,R0lG.... , should be allowed as valid logo_uri values in dynamic client registration requests.

data: urls are widely used and supported. And they are convenient for client registration as an additional http request is not needed to fetch the logo image. The image will be embedded in the registration request.

‌

For more information on data URLs:

https://tools.ietf.org/html/rfc2397 The "data" URL scheme

https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs

[Joseph Heenan]

(This question arose because the new java conformance suite explicitly allows data urls -see https://gitlab.com/openid/conformance-suite/-/merge_requests/865#note_289042487 , and as the conformance tests may interpreted as representing the official position of the OIDF it seemed best to double check with the working group)

[Serkan Özkan]

Additionally, the current conformance suite (the python one) also allows data urls implicitly as it does not validate logo_uri values.

[Michael Jones]

Discussed on the 9-Apr-20 call

[gffletch]

I think there are pros and cons to supporting data URLs in this manner.

Pro:

• One less outbound fetch for the Authorization Server

Con:

• AS MUST security check the image bits to ensure there are no known attacks associated with the client provided image

• Allows the client to impersonate another client more easily (e.g. the rogue client can present another client’s image)

  • Difficult for the AS to determine if the provided image should be allowed for this client. Can not do any comparisons between the domain of the callback URL with the domain of the logo URL (as an example)

‌

[Serkan Özkan]

I think both cons apply to regular urls as well.

For checking image bits: An image downloaded from a regular url may also contain malicious bits.

For impersonation: A rogue client can download a third party logo and host it on its own server. Using regular urls does not eliminate the risk.

In my opinion the spec should not forbid the use of data urls and let OPs decide what’s best for them.

[Michael Jones]

We’re already not forbidding their use. But we’re also not saying that they’re supported.

This actually seems parallel to the situation with supported image formats. We don’t say that JPEG, BMP, PNG, TIFF, etc. are or are not supported. We just say: “The value of this field MUST point to a valid image file“.

It wouldn’t be an errata action to make any of these things more specific. We could them as enhancements.