Client Information Discovery without relying on microformats parsers.

[Zegnat]

This issue was created in response to a discussion in #indieweb-dev. The essentials should be summarised here, but for full context, see the chat logs starting at 11:31, ending around 11:55.

---

@pfefferle asked if it were possible to use a separate parser just for extracting h-app (IndieWeb wiki) information. Because for such “a very simple and uncomplicated format […] it would be a bit too much to include the mf2 parser”.

The problem with a boiled down parser is it would be making assumption with regards to how the author is adding the h-app object to a page. And as soon as more complex microformats structures (nesting, implied values, vcp) are introduced to the mix anything that is not a full mf2 parser will likely fail.

Conversely there might be reasons why shipping a full mf2 parser with every authorization endpoint is a problem. These problems can range from unavailability of a parser in a language, to more specific issues with packaging. The latter is what is happening for WordPress. Multiple plugins all have to ship their own version of the parser, fighting with each other over which one gets used, because there is no concept of shared dependencies.

The IndieAuth specification only depends on microformats for extracting application information during client information discovery. If this could be changed or offer an alternative straight from the HTML without further dependencies that might help authorization servers in doing this discovery.

(Note that the discovery of redirect urls already depends on HTML parsing for finding <link> elements, so depending on HTML parsing for other client information should be fine.)

Some possible alternatives mentioned during the discussion:

• Open Graph – embed the application meta data in <meta> elements. As there is no application type, this may require defining a new namespace.
• HTML – use standard HTML elements and relationships. rel="icon" for the logo, rel="self" for the client_id. The application name could be extracted from <title> or more specific <meta name="application-name"> elements.
• Web App Manifest – a JSON encoded sidefile containing all the necessary meta data. This will require discovery of the manifest file, and then a second HTTP request to retrieve it. Once retrieved the parsing is extremely straight-forward.
• JSON-LD – if a strictly specified subset is used it could be parsed with any JSON parser (no need for full JSON-LD parsing) and can be embedded within HTML (<script type="application/ld+json">…</script>).

[Zegnat]

I have started some initial documentation to see exactly what applications are publishing for discovery. Current statistics:

h-app	h-x-app	rel=redirect_uri	rel=manifest
8.70% (2/23)	34.78% (8/23)	13.04% (3/23)	34.78% (8/23)

rel=icon	rel=apple-touch-icon	rel=mask-icon
56.52% (13/23)	39.13% (9/23)	17.39% (4/23)

Next it would be helpful to see what other meta data points these pages are publishing, and have in common.

Please help expand that wiki page with any further ideas!

[Zegnat]

The table above has been updated with new statistics. This shows that rel="manifest" are equally as likely to be found on client pages as h-x-app. This Web App Manifests may be a more logical alternative than previously realised.

Further developments in mostly chronological order, for those who do not want to read a day’s worth of chat logs:

• @dshanske is reports looking for other ways to discover application logos.

  • This will likely be based on the wiki documentation on home page icons.

• @aaronpk provides another reason why h-app (and the microformats2 parser requirements it brings along) may not align with IndieAuth, as it relates to his future goal of the spec:

  • my next goal with IndieAuth is to get just the client ID part written up as an i-d and proposed to the OAuth WG

  • and I’m a bit apprehensive of including microformats parsing in that proposal

• @kevinmarks proposes native HTML fallbacks for the h-app properties:

  • url: fall back to [the page’s] url

  • logo: fall back to icons

  • The problem with this is also pointed out: which icon? Icons can mean many things, from the default rel="icon" to a slew of rel="apple-touch-icon-*", and more.

  • name: fall back to