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>).