Thoughts on building a finger service

Those folks of a certain age will remember the finger command/protocol which allowed one to look up information about a person based just on their login identifier. This command was extremely useful even if it had some troubling security and privacy implications. Efforts are underway to create a Web Finger but for reasons I’ve previously discussed I think the underlying technologies for those efforts are sub-optimal. So in this article I propose what I think is a much simpler approach. My motivation for caring is that I think having a finger service will make permissioning systems much more useful (see here and here).

Contents

1 Disclaimer

I don’t always remember to put on a disclaimer because this is my blog and my opinions and by default the assumption should be that anything I say here represents my views and only my views. But just in case, this article (like all the articles on my blog) represents my views and only my views.

2 Scenario - discovering a friend’s calendar service using a local application

Martok wants to invite Dax to a meeting but to do so Martok needs to see Dax’s free/busy time which is available at Dax’s calendar service. But Martok doesn’t know which calendar service Dax uses. So Martok uses the finger functionality from inside of his local calendaring client to take Dax’s e-mail address and use it to discover Dax’s finger service. Martok then authenticates to Dax’s finger service and queries for Dax’s calendar. Dax’s finger service has been instructed to share details such as Dax’s calendar service location with anyone who is part of Dax’s personal address book. Since Martok is in Dax’s personal address book he is allowed to see where Dax’s calendar service is kept.

Note: This scenario is strictly about programmatic interaction with the finger service. I’ll leave UX issues for another day.

3 My personal opinions on requirements

3.1 The finger service should just point at other services

Once upon a time finger directly returned key information about the user such as their office location or status message. But in the new world order with social networks all over the place it seems more reasonable to think about finger as a catalog of pointers to more specialized services. In other words one shouldn’t go to Finger to find out someone’s status. One should rather go to Finger to find out what service or services a user uses to publish their status (Messenger? Facebook? Twitter?). The same thing with other services such as blogs (personal or work?), calendars, preferred social network, etc.

3.2 The finger service needs to support authentication and authorization to control who gets to see what

Because of the privacy and security implications of finger it’s necessary to authenticate who is requesting information (even if the authentication is just ’anonymous’) and to require the requester to specify exactly what information they want. This allows the finger service to reason about who is making the request and what they want and so decide what is appropriate to share.

It’s tempting to argue that it isn’t necessary to know what the requester wants since who they are should specify what they can see. But I believe that as a rule it’s not a good idea to over share.

3.3 The finger service should just be a service, not a document

I have previously explained my concerns about the XRD/LRDD approach to finger. So I won’t repeat myself here other than to say - I believe finger is a service not a document. So I expect that people will issue queries to the finger service and get back responses, not just do global GETs.

3.4 The finger service should start with trivial queries and get complex later

At its heart the finger service is a database with ACLs on top. So one could imagine specifying that the interface for the finger service should be something like OData. I actually expect that eventually finger services will sport interfaces like OData because they will make potentially interesting query and data navigation capabilities possible.

But in the short run I think we need to focus on easy things first. If all we do initially is just create an interface where someone can submit an identifier of a service and get back what, if anything, the finger service is willing to say about that the user’s usage of that service then we will have done a good thing for the world.

3.5 The finger service should at least support using e-mail addresses as user identifiers

A perennial argument about how to identify users is what kind of identifier should be used? Whatever that identifier is it has to be something that enables a finger client to go from that identifier to the finger service that handles that identifier. Similarly the identifier needs to be something that is easy for users to remember and exchange. Something that is easily transcribable and typeable so users can just type a friend’s identifier into an application or service and away they go. To date there is exactly one user identifier that has proven robust across all of these requirements - e-mail addresses. So email addresses are a minimum required user identifier. This means that the finger service has to define how to find the finger service for a particular individual by starting off with nothing more than their e-mail address.

3.6 The finger service should use HTTP, in preference to DNS, to go from e-mail to finger service

Going from an e-mail address to the finger service that owns that address essentially requires figuring out how to use the DNS name in the e-mail address to find the finger service. One obvious way to do this would be DNS SRV records. We could add a new SRV type for finger services and allow discovery that way. The downside to this approach is that it requires the ability to manipulate DNS records on the server side and the ability to make DNS queries on the client side. Neither is a common operation for most programmers or users. So basing discovering on DNS is likely to slow adoption. Nothing stops us from adding an extension based on DNS but I personally don’t think that it is the right place to start.

Instead I think we should build on top of RFC 5785 that defines a location for hosting ’well known’ services via HTTP. So if someone has the e-mail address joe@example.com they could try to find the finger service for Joe at http://example.com/.well-known/finger-service.

There are some pretty obvious problems with this approach. For example, what happens if the owner of one’s e-mail domain doesn’t support the finger service? Is one supposed to change one’s e-mail address just to get to a service provider who does support the finger service? The answer, I believe, is, unfortunately, yes. It’s the nature of hierarchical trust systems that there are choke points, in this case, the domain owner. We could look for a web of trust system but previous experience with systems like GPG teach that while these systems can be powerful they are hard for users to understand so I don’t feel they are a good starting point.

Nevertheless the RFC 5785 approach does offer flexibility. For example, let’s say I don’t want to host my own finger service but I do own goland.org. I can easily set up a redirect rule in my domain to redirect requests for http://goland.org/.well-known/finger-service to where ever my finger service actually rests. I would posit that more people know how to set up redirect rules then know how to configure SRV records.

3.7 The finger service should use SSL/TLS when dealing with non-anonymous queries/responses

Any finger service that needs to support authorization/authentication (and one hopes that is the majority) must support SSL/TLS. The OAuth 1.0 signature/encryption experience has taught that adding message integrity/confidentiality as a layer on top of protocols like HTTP is so difficult as to be impractical for even sophisticated developers. So rather than re-invent the wheel we’ll require using the one that’s already there, SSL/TLS.

Note: The reader is well advised to review articles such as this one that explain some fundamental flaws in how SSL is used operationally. The way certs are used today enables abuse and I think this is much more threatening in the long run then functional flaws like the renegotiation attack for which a fix is likely to be available sooner rather than later.

4 Martok gets Dax’s free/busy time - An example

In this example Martok’s calendar client is going to start with Dax’s e-mail address and use it to go to the reserved URL for the finger service and ask for Dax’s calendar location. Embedded in the request is a security token authenticating Martok to Dax’s finger service. For right now I’ll just wave my hands and say that Dax’s finger service is federated with Martok’s Identity Provider and so recognizes the HMAC/signature/etc. on the security token. In a later article I’ll explain how we can build on top of the finger service to enable ad-hoc authentication of users without federation.

Dax’s finger service will validate Martok’s security token and return the location of Dax’s calendar service. Martok’s calendar client will then get a security token for Dax’s calendar service and use that to access Dax’s free/busy time. Again, I’m going to assume that Martok’s Identity Provider is also federated with Dax’s calendar service.

Note: To keep the picture from getting too big I have collapsed the services and their associated authentication servers into a single box.

This picture is essentially the STS/Kerberos two step repeated over and over again. Martok’s client gets an access token from the identity provider which is provided to the service’s authentication server who exchanges it for another security token that is then presented to the service. All the exchanges in red are bog standard OAuth WRAP calls. The only thing needed to be added to support finger is 4/4R in blue. My guess is that even 4/4R will be an OAuth WRAP profile extension where the wrap_scope will probably be a URI indicating the user and service that is being sought. Or maybe we can add another field. In any case it’s a pretty obvious variation.

4.1 Where did the refresh token in message 1 come from?

I’m assuming that Martok’s calendar client is using OAuth WRAP section 6.3 to get a refresh token to allow it to talk to Martok’s identity provider. I intend to go more into this scenario in a future article.

4.2 How can the access token from 1R be used both in message 2 and message 5?

Both requests require the client to authenticate itself to the same service, Martok’s identity provider, so the same access token can be used. The only problem is if enough time passed between message 2 and 5 that the access token (which is typically short lived) expired. In that case the client would need to repeat request 1 to get a new access token. This is all standard OAuth WRAP behavior.

4.3 Well then, why couldn’t the access token from 3R be used with request 6?

Because access tokens are service specific. The access token returned in 3R was only good with the finger service so it couldn’t be used with the calendar service. Therefore the client had to execute request 5 to get an access token for the calendar service.

4.4 Wait, remind me again, how did Martok’s calendar client know where Dax’s finger service was?

The scenario assumes that Martok, either directly or via an address book, gave the client Dax’s e-mail address. Let’s assume that Dax’s e-mail address is dax@example.com The calendar client pulled the domain name out of the e-mail address, in this case example.com, and then created a request of the form http://example.com/.well-known/finger-service. Note that I just made up ’finger-service’, the actual value will be whatever goes into the standard. The interesting question is how did the request identify Dax?

One way is in the URI itself. We could specify https://example.com/.well-known/finger-service?localname=dax. We could even handle cases where a finger service is handling an address from a domain other than its own via https://example.com/.well-known/finger-service?email=dax@federation.com. Alternatively Dax’s identifier could go into the request body, possibly into the wrap_scope element.

4.5 Why do we bother with the previously mentioned STS/Kerberos two step anyway?

The answer is scalability. It turns out that requiring services to handle authentication directly is expensive. Life works better if there is a centralized authentication service who handles the expensive authentication actions and then hands out a short lived token (typically good for a few hours) that can then be used with services without further ado. This is why OAuth WRAP uses the refresh and access tokens.

4.6 How did Martok get permission to access Dax’s finger service or free/busy time?

For the example we just assume that Dax said something like ”anyone in my address book can see my calendar location and my free/busy time” and Martok was in Dax’s address book. Martok’s identity was validated to the finger and calendar services by the security token issued by Martok’s identity provider. But in the more general case I’m proposing that we extend OAuth WRAP to enable individuals to ask each other for permissions. See here and here for more details.

4.7 How did Martok’s identity provider know how to issue security tokens with formats and claims supported by Dax’s finger service and calendar service?

My guess is that if the finger service as proposed here takes off then there will be a defined standard for a default security token format along with a default identity claim that can be used in any situation where one entity needs to prove its ’identity’ (in this case, an e-mail address) to another. See the previous question for why the finger service and calendar service honored the identity assertion from Martok’s identity provider.

4.8 Couldn’t Dax’s finger server tell Dax’s calendar server that Martok is allowed to have access to free/busy time?

This is a feature I’m interested in mostly because over time individuals trying to manage their security in a coherent way are going to get a really serious headache. How can anyone remember which permissions they gave to which services for which people? What’s needed is a centralized place where users can manage their permissions across many services. The finger server could either be that service or be in communication with that service. In that case rather than Dax telling the calendaring service directly ”Give Martok access”, she could instead tell this to her centralized permission service who would then be discovered by Martok using the finger service. Martok would then ask that central permissioning service for a token to give to Dax’s calendar service to prove he had a right to access her free/busy time.

But I think it’s premature to try and create this kind of infrastructure right now. To be blunt, until it hurts nobody is going to spend time and money fixing it. So while some enterprises are just now barely trying to get started on issues like managing security policy across multiple internal services (and believe me, that hurts way worse than a single user managing their permissions) I suspect users effectively addressing this issue is some way into the future.

In fact my strong suspicion is that the way things will really work is that users are going to synch at least the e-mails in their address books across services and then specify permissions based on the address book’s structure or tags. ”Anyone marked as family can edit X” or ”Anyone marked as business can see Y”, etc.

It’s tempting to argue that we shouldn’t design a system we know is problematic at the start but synchronized permission management is an unsolved problem mostly because we aren’t sure as to the most effective way to present permissions to users (this is also known as a the policy problem).

4.9 Couldn’t Dax have multiple calendar services?

Absolutely. My guess is that services like calendars will have standard finger schemas that can say things like ”I’m the work calendar” or ”I’m the second personal calendar” or whatever. It will be up to Martok and his calendar client to decide how many of those services he should try to synch free/busy time for.