Browser UI Branding

[dj2]

With the current spec the browser is presenting UI to the user for them to sign-in to the website. There is desire for that UI to be branded by the IDP in certain ways. Specifically we've been looking at branding the colour of the presented button and adding a small logo to the side of the button.

My assumption is that this branding is the same for all IDP accounts. We do not need to know the user that is signing into the IDP in order to decide which branding to present to the user. If that is not the case then we'll need to move where the IDP data is provided.

Proposal

The IDP data is added into the .well-known/fedcm metadata file alongside the various endpoint URLs. If the branding is not present then they default branding (UA defined) will be used.

{
  "branding": {
    "background-color": "#fff",
    "foreground-color": "#000",
    "icon": {
      "url": "https://icon.example.com"
   }
}

The background-color or foreground-color could both be set or only one of the two set. The colours are a hint to the UA, not a requirement. The UA reserves the right to reject the colours and use the default colours if the provided colours don't fall within accepted usability colour contrast ratios.

[dj2]

The icon should be an array. The icons need a size provided as different UAs may use different icons. If no size is provided the size is assumed to be 24x24.

{
  "branding": {
    "icons": [
      {
        "url": "https://icon.example.com/icon-16",
        "size": 16
      },
      {
        "url": "https://icon.example.com/icon-32",
        "size": 32
      }
  ]
}

In all cases, the icons are expected to be square in size, so only a single dimension is returned. All icons returned are required to be maskable (https://www.w3.org/TR/appmanifest/#icon-masks).

[dj2]

Does this allow for SVG icons? If the IDP puts a data-url in url where the data is an SVG, is that valid?

[dj2]

I used -'s in the names above but looks like the app manifest spec uses _. So, those should probably be background_color and foreground_color as the keys.

[pkotwicz]

Comment 1:
If a size is not specific for an icon, we should use the same selection algorithm as for the web manifest.
https://www.w3.org/TR/appmanifest/#icons-member

Specifically this section:
If there are multiple equally appropriate images in icons, a user agent MUST use the last one declared in order at the time that the user agent collected the list of icons. If the user agent tries to use an icon but that icon is determined, upon closer examination, to be inappropriate (e.g. because its content type is unsupported), then the user agent MUST try the next-most-appropriate icon as determined by examining the manifest image resource's members.

Comment 2:
There is no use in supporting SVG icons as supporting SVGs in browser UI in Chromium is non-trivial. The app manifest spec theoretically supports SVGs (sizes="any") but the SVG support for app manifests was never added to Chrome. (Not sure about other user agents but doubtful)

[kdenhartog]

My assumption is that this branding is the same for all IDP accounts. We do not need to know the user that is signing into the IDP in order to decide which branding to present to the user. If that is not the case then we'll need to move where the IDP data is provided.

Hey been following this work for a bit now and just saw this issue pop up. In regards to this assumption I'm not sure it holds true for Microsoft's implementation used for SSO (speaking as a user - I don't work for them). From the looks of it when first submitting the email to their outlook page they use standard white branding and then depending on the email domain the branding appears in the password entry page which allows for logos and what appears to be images (might be SVGs, but not sure) as backgrounds. I'm not sure how well that would map to the current user flows suggested, so I'll let someone from their team speak up about it. However, as a user, I do like the ability to see the image or maybe SVGs as a background based on the domain provided in these multi page UIs currently used. It helps me when I'm running multiple outlook accounts to know I've gone to the right place without having to remember different URLs. I can just show up at Outlook.com and figure it out from there.

[dj2]

@pkotwicz about about a base64 encoded image, could that be possible? The generalized request is, can we do a single fetch of the metadata end point and also get the icon at the same time. Saves a network round-trip if we can.

[dj2]

@kdenhartog when you say branding appears, do you mean branding for your enterprise, branding for outlook or something else?

We have no plans for general backgrounds, just setting the colour of the button and adding a small logo on the left side of the button.

[kdenhartog]

A picture of their flow is probably more useful here because it's essentially both outlook branding and enterprise branding that gets switched out based on the domain.

This is the first screen I see on outlook.com

This is the second screen I see:

[hpsin]

I'm not sure it holds true for Microsoft's implementation used for SSO (speaking as a user - I don't work for them).

Yes, you're correct. Microsoft models our IDP as a collection of servers owned by specific companies - so if you try to sign in to Outlook using login.microsoft.com/AcmeCorp.com - we show the AcmeCorp branding in the background. We also show the Outlook-specific branding in the foreground. So we have two layers of branding that we'd like to show, specific to both the app and the tenant (both of which are somewhat hidden from us in FedCM, I believe).

[kdenhartog]

Thanks for popping in and confirming @hpsin

[dj2]

So, we really only have one branded item, a button with a small logo on it. Would the preference be for the button to get branded as Outlook or as AcmeCorp.com? Basically, is the branding consistent for the IDP, or is the preference that every account returned in the accounts_endpoint could have different branding?

[pkotwicz]

@pkotwicz about about a base64 encoded image, could that be possible? The generalized request is, can we do a single fetch of the metadata end point and also get the icon at the same time. Saves a network round-trip if we can.

Yes getting the icon from base64 is possible.

[cbiesinger]

SVG is supported in app manifests in Chrome on Desktop and Android: https://twitter.com/quicksave2k/status/1450826163941781520

[pkotwicz]

@cbiesinger : If I read the tweet correctly, it sounds like SVG is NOT supported in app manifests on Android.
There seems to be a plan to eventually add support http://crbug.com/1251181

[cbiesinger]

@pkotwicz it sounds like the linked CL in that tweet implements it, no? (also mentioned in the last comment on that bug)

[pkotwicz]

@cbiesinger : It looks like http://crbug.com/1251181 has been marked as fixed.

[kdenhartog]

the preference that every account returned in the accounts_endpoint could have different branding

This sounds most closely aligned to what my preference would be as a user, but I'm not fully aware of the trade-offs in complexity that would be incurred at this point.

[samuelgoto]

From a notation perspective, I'm wondering about two things:

(a) how do we not corner ourselves from further extensions?
(b) how do we make this feel not foreign to web developers?

On (a), I'm wondering what happens when we want to use branding for other parts of the UX. Can we scope foreground-color and background-color to, say, the button, such that in the future, if we want to pick foreground-color for another element it doesn't conflict?

e.g. do we need one level of nesting?

{
  "branding": {
    "button": {
      "background-color": "#fff",
      "foreground-color": "#000",
      "icon": {
        "url": "https://icon.example.com"
     }
   }
}

On (b), I'm wondering if we could use the same type of terminology that CSS uses for styling. e.g. should we use color for the font color as opposed to foreground-color?

{
  "branding": {
    "button": {
      "background-color": "#fff",
      "color": "#000",
      "icon": {
        "url": "https://icon.example.com"
     }
   }
}

More generally, would it be possible for this to be isomorphic (the JSON notation seems fine) to a strict a subset of CSS?

e.g. this would probably go too far, but worth noting as an option:

{
  "theme": {
    ".sign-in button": {
      "background-color": "#fff",
      "color": "#000",
      "icon": {
        "url": "https://icon.example.com"
     }
   }
}

[achimschloss]

the preference that every account returned in the accounts_endpoint could have different branding

This sounds most closely aligned to what my preference would be as a user, but I'm not fully aware of the trade-offs in complexity that would be incurred at this point.

+1 from my side - this would also enable this API to work better with this use-case fedidcg/use-case-library#7

[samuelgoto]

A small update here: I'm writing down in the spec here what has been implemented, to give us a baseline to work from.

I still think that this is best represented in something separate from the accounts_endpoint as I described here but I want to at least make sure that the spec is consistent with the implementation.

[dj2]

Marking this is complete. The branding information was added to the spec, and has been moved to the fedcm.json file in #202