Re: [apps-discuss] Aggregated service discovery

[Michiel de Jong <[e-mail]>]

IMO, webfinger/swd is the way to go. they are currently being merged
into one. All discovery paths should use webfinger/swd as the first
step, and then do other stuff (including requiring credentials) in
documents linked from there. There are cases where a service is
specific to a domain, but not to a user, but I think they should still
also be announced from the same first starting point (which is
/.well-known/host-meta).

how to deal with private information (meant only for the user
themselves), is not very well documented. the webfinger/swd spec
basically leaves it out of scope. Basically what you would do IMO is,
for a user "<user>@<host>", announce a first starting point at
https://<host>/.well-known/host-meta, and then use "follow your nose"
to discover everything else. That includes discovering the home-pages
of any domain-specific APIs, as well as caldav, BrowserID, OpenID,
ActivityStreams, foaf, PoCo, remoteStorage, email addresses, avatars,
and everything else. The first starting point should be available
without credentials, publicly, and with CORS headers on there. Then as
you follow the links to all these services, you will find barriers
where maybe a bearer token or a client-side certificate or something
else is needed to retrieve the next bit of information.

But the first starting point should always be public, on
/.well-known/host-meta and with CORS headers on there. Even if it's
just to say "nothing to see here unless you can give me credentials of
type X" (IMO, OAuth end-point discovery can itself serve here as a
syntax for expressing that, although i think announcing
credentials-requirements is still a relatively under-explored part of
discovery best practices).


Cheers!
Michiel