Re: [apps-discuss] Aggregated service discovery

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

On Thu, May 24, 2012 at 4:54 AM, Andrew McMillan <[e-mail]> wrote:
> The UI would be that I have three 'facts' and I would like to use these
> to configure my $SERVICE.  I'd like to be able to supply the same three
> facts for any service and hope that my software was able to hide further
> complexity from me, ideally supplying them only once, and authorizing
> each client on first use.
>
> I believe those facts should be:
>
> * A domain name
> * A username
> * Some authentication token(s)
>
> Of course the domain name could be a URL, but in providing a standard
> simplification a domain name offers the advantage that it is shorter
> than a URL, and if we then define a set of standard transformations to
> that domain name (such as an SRV lookup to discover protocols, hosts and
> ports, and appending some standard path) we can save my mother a lot of
> laborious and error-prone data entry on her smartphone.
>
> Regards,
>                                        Andrew McMillan.

i find this a super interesting question. i have been thinking about
this as well, and i think we don't have a good solution for this right
now, so it would be cool to change that. aspects i see:

1: Existence - listing which services even exist
2: Version - which version of the spec the instance claims to be compliant with
3: End-points - this is service-specific
4: Options - which types of encryption, signature, encodings, etc. are supported

i think these 4 types of discoverable information make sense for most
services. And i think if we combine webfinger/swd with json-home, then
we probably have enough expressive power to announce these 4 types of
information in a sensible way.

but the main objection people would have to doing this is i think
privacy/security. you don't want to announce the exact details of all
your services publically, because:
1) it makes it easier for an attacker to know where to attack your systems
2) it may reveal non-public information about your users unnecessarily.

Given that the user story Andrew describes (and i think this is the
correct thing to be looking at), starts out with a domain identifier,
a user identifier within that domain, and some authentication
token(s). If we have a trusted client then we can already use those
tokens during the discovery. In other cases we would have to use maybe
OAuth or similar to get derived tokens for doing the actual discovery.
If we do that, then we need to announce that that is the case. In the
case where you use resource owner password credentials, then i can see
how you could discover everything you want in 1 round trip. if you use
derived credentials (e.g. implicit grant), then i think 3 round-trips
are unavoidable: one to discover the discovery and OAuth end-points,
one to obtain the derived token, and one to do the actual lookup with
it.

My 2ct,
Michiel