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

["Paul E. Jones" <[e-mail]>]

Marten,

>
>Am 14.07.2016 um 08:19 schrieb Paul E. Jones:
>>Let's make sure the new draft is scoped to just mail configuration.  
>>(If we want to go further with calendar, contacts, etc. then arguably 
>>those should be separate URLs.  My mail and calendar is not provided 
>>by the same provider, for example.)
>If we only support mail configuration this will probably fail. I think 
>one of the strengths of this draft is that everything is in one place.

But, everything is in one place in the sense that WebFinger is the one 
place.  The type of information required to configure contacts and 
calendar are quite different than email.  So why produce a JSON document 
that tries to blend all three?

The only thing I'm suggesting is to define the link relations.  In the 
future, there might be another (e.g., tasks).

>>Certificate Auth: I'm not sure what the problem is here, unless people 
>>want to use enterprise-issued certificates (i.e., those that are not 
>>from a public CA).  If that is the case, I would not want my mail 
>>client to insert those into my trusted certificate store.  So, would 
>>those be one-time uses?  Not very useful.  I'd say the IT department 
>>needs to install whatever root certs are needed.  A client should 
>>authenticate the certificates it sees, but we don't need more words 
>>about it other than to say the TLS connection must be authenticated.
>No, this is about client authentication, i.e. the client has to provide 
>a client certificate signed by some specific authority. This is not 
>widely used and probably more for corporate or personal use cases, but 
>we have a significant number of users of this security feature.
>At least in Java it's a real pain to distinguish a client certificate 
>request from any other SSLException. So it would be helpful to know in 
>advance if a specific client certificate is required or not.

Oh!  I totally had this backward.  The challenge I see with using client 
certificates is that one of the benefits to using WebFinger is that I 
don't have to manually configure my email clients I have on my 6 
different clients.  Even in the enterprise, having a mobile device and 
computer is more common.  So, I would not be opposed to this, but I'm 
not sure it would be used much, particularly since the user is already 
authenticating with other mechanisms.  If the expectation is the user's 
device will also authenticate with the mail server using the same 
certificate, I guess this might be required.

>>Document structure:  I think keeping this simple is really best.  I 
>>don't think we need multiple mail providers. If the email address is 
>>[e-mail], then I think it's reasonable to assume example.com 
>>is the provider.  Yes, a user could go enter WebFinger information for 
>>some other provider, but the average person will not want to do that.  
>>That's having the user configure the server so it can configure the 
>>client.  Not much gained there.  I would have something that's no more 
>>complex than something like this:
>>
>I fully agree that we should keep it as simple as possible. However, 
>one of the keys to success is that we support the services and use 
>cases that are not covered by the existing mechanisms. That's why I 
>believe that the document should have a generic structure that works 
>with pretty much every service out there. It shouldn't be designed 
>around email. This is one of the reasons for me to ditch the 
>host/port/transport notation and just use a single URI instead. I'm not 
>aware of any service that can't be addresses with a URI.

Those are just properties of the mail service.  The next thing will have 
its own set of properties.  The JRD sent by WebFinger is a document 
along the lines of what you describe: very generic.  And, that was 
viewed as good.  There is really very little one can convey: a subject, 
some properties, and a set of links with associated properties.

But, it gets really tricky trying to define something complex with a 
JRD, and that's intended.  Folks in the WG did not want it to do more 
than what it does.  And I think the same philosophy should be extended 
to the services like mail, calendar, contacts, tasks, or whatever.  If 
each one is defined for the specific purpose they serve, the documents 
will be clean and clear.


>Another goal should be to revert the service discovery process to some 
>degree. Instead of having the client to probe the provider for each 
>service that might be supported, the current spec reverts that and 
>returns a list of everything that's supported. The local "account setup 
>agent" then can probe the local device software for client modules or 
>applications that might support a specific service. Ideally this would 
>be supported on OS level. So you run a generic account configuration on 
>OS level, the OS pulls the service configuration document and calls the 
>installed handlers for each supported service. It there is no client 
>for a specific service the OS could make suggestions like "Your 
>provider also supports <Some service>. Search the App Store for a 
>suitable client app now".

That's an interesting idea, but I would still prefer to keep the config 
in different resources.  Everything you describe could be done with 
naming conventions or properties in the JRD.  For example, a link might 
have a "rel" value of "mail-config" and an "href" value.  This might not 
mean much, but there could also be a property that indicates that it is 
an "auto-configuration" link, perhaps the name of the service (e.g,  
"Email"), etc.


>That's why I believe that we should put all services into a single 
>document, instead of using service specific rel-types that need to be 
>probed by the client.

Another reason not to do it: even within the same organization, 
different departments might manage different services. You run into 
challenges trying to get people to coordinate.

Another reason is that folks in the IETF like to have things broken into 
granular pieces.  That's why WF is more-or-less just a directory of 
links.

>If, like in your case, calendars and email are not hosted at the same 
>provider, the webfinger response for your account should just contain 
>two provider entries, each pointing to a document that lists all the 
>services provided by this provider.

In my case, I would expect [e-mail] to return only the 
email service, since I don't have a calendar service there.  I would 
select the "Add Account" option in my email software and enter another 
user ID to get the calendar.  Yeah, I could have this in a single WF 
reply, but the problem is that the average user isn't going to be adding 
such entries to his or her account.

Of course, we do need to allow for the possibility that the IT 
department will have one group running email and another handling 
contacts / corporate directory services.  So, a company might very well 
have two links in the JRD returned by WF.  And, that goes to my point, 
again, that there's no point trying to define an all-encompasing 
document.

To be clear, though: I'm not opposed to having a generic document that 
tries to be flexible enough to convey just about anything.  I'm OK with 
that.  I just don't think that we should have a single document that 
carries information for more than one service.  I just don't see the 
benefit in doing that vs. having two or three different link relations 
-- one for each service to be configured.  That said, I do not see that 
it's very useful to have a generic document format vs. a specialized 
one.  After all, we still have to define the exactly contents of the 
documents, generic or specialized.

Paul