Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger

[Marten Gajda <[e-mail]>]

Hi John,

good question. I see a couple of advantages over RFC 6186 (and at least
some of these have led to the development of the current draft).

# user specific configuration

The draft we're talking about allows a service provider to return a user
specific configuration file. Some example use cases are

 * premium services can be included for premium users only, the client
of a "free user" would not attempt to set up a service that it has no
access to
 * user specific endpoints - consider a company with an office in Europe
and an office in the US. All email addresses may share the same domain,
say `example.com`, but the European users actually access IMAP under
`imap.eu.example.com` and the US users access IMAP under
`imap.us.example.com`. A configuration document can be smart enough to
return the correct endpoint for each user, while SRV can't do that.

# one document to rule them all

A service configuration document contains information about all services
a service provider offers. You don't need to guess which services might
be there. Also, the service configuration client doesn't even have to
know how to handle all the services. Ideally the configuration client
would run on system level and dispatch the setup of each service found
in the configuration document to the respective service handlers which
are registered with the system.

# additional information
 
A service configuration document allows to integrate additional
information like

 * OAuth2 scopes that are required to access a specific service
 * a link to an account management page
 * support/operator contact information

# easier to integrate

## for clients

Doing an SRV lookup is not well supported by some (or many) of the
existing platforms & frameworks. Many Frameworks provide methods to
resolve domains back and forth, but other record types are often not
supported out of the box.
We're developing Android clients for CalDAV & CardDAV and to do an SRV
lookup we would have to integrate a 3rd party DNS library. Of course
that 3rd party library should support DNSSEC, otherwise you can't trust
the result of the SRV lookup.

The draft we're talking about uses HTTP based technology, which is well
supported in a secure manner by pretty much every platform/framework.

## for services

Setting up DNS records is not an issue for large service providers,
though it can be a problem for smaller installations if your hosting
service doesn't give you such control over your DNS settings.
Setting up Webfinger and a service configuration document can be quite
trivial. In simple cases you can get away with a few static files on
your server. In other cases a simple PHP script might solve this.

# works cross domain (at least in theory)

Technology like OpenID Connect allows to separate the identity provider
from the actual service provider. So my email provider might not be the
same as my calendar provider, but both use the same identity provider
for authorization. My calendar client should be able to discover my
calendars, even though my user id has a completely different domain part.

Services like webfist.org can make this even more versatile and gives
users full control over their service configuration document, even if
their email provider doesn't support it.


That's it for now. There may be other good reasons to favor a service
configuration document over SRV records.


Cheers,

Marten






Am 03.06.2016 um 02:43 schrieb John Levine:
> If I may ask an obvious question, how much better in practice is this
> likely to be than RFC 6186?  I realize that 6186 is somewhat
> inflexible and requires that the address or the local-part be the
> login credential, but it is my impression that the vast majority of
> mail servers are set up that way anyway.
>
> R's,
> John
>
> _______________________________________________
> webfinger mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webfinger

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: [phone]
email: [e-mail]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743