1 Disclaimer

2 Defining the index I’m looking for

3 Slicing the pie

4 The contenders

5 The three fund solution - 0.19% expense ratio

6 A four fund solution - 0.17% expense ratio

A MSCI Barra’s view of the world

B FTSE’s view of the world

C Cooking the books

C.1 Percentage of world market accounted for by the US - 41%

C.2 Percentage of all-world accounted for by ex US Large and Mid Cap - 53%

C.3 Percentage of all-world accounted for by ex US Small Cap - 6.0%

C.4 Percentage of all-world accounted for by EAFE large and mid cap - 41.9%

C.5 Percentage of all-world accounted for by Emerging Stocks - 11.1%

C.5.1 Is FTSE emerging a good stand in for MSCI emerging? I think so. Here’s why

Contents

1 Kicking OAuth delegation up to 11

Delegation is all about transferring permissions. At its most general a delegation expresses something like ”User X of service Y gives permission Z to user A of service B”. Today OAuth cannot express this statement because OAuth always assumes that X = A. In other words what OAuth can say is ”The user of service Y gives permission Z to their own account on service B.”

With general delegation a user of Sharepoint Online can give permission to a user of Google Docs to see the Sharepoint Online user’s documents from inside of Google Docs. Or, as explored below, a user of Yahoo calendar can give permission to a user of Live calendar to see the Yahoo calendar user’s free/busy time from inside of Live calendar. With full delegation we can finally start having truly open permissions.

2 The first step on the road to general delegation - target user

Imagine that we added one feature to OAuth, the ability in a permission request to specify who the target user is. This would enable us to make the following statement in OAuth ”The user of service Y gives permission Z to user A of service B”. But how do we identify user A? We already have a pretty good solution to how to identify users, e-mail addresses. So let’s go with that.

But now imagine the user experience. Yochi, who uses Yahoo Calendar, wants to give Leon, who uses Live Calendar, permission to see his free/busy time. Using the new ’target user’ functionality Yochi can say to Yahoo Calendar ”Hey, Yahoo Calendar, give leon@bogus.gmail.com who uses Live Calendar the right to see my free/busy time.” Yahoo calendar can now make a three legged OAuth request to Live Calendar and specify that the permission to be granted, free/busy time read capability, is to be given to the user leon@gmail.com.

But how does Live Calendar know who is giving the permission? In other words, how does Live Calendar know that Yochi is the one granting the permission to Leon? If all we add is Target User then what will have to happen is that Yochi will have to be sent to a browser pointed at Live Calendar who will then require Yochi to prove his identity. Personally I think that oauth can handle that part just fine but let’s just say we use OpenID. So now Yochi has to login to Live Calendar via OpenID to prove to Live Calendar who he is.

The good news is that all the mechanics needed to make the previous work exists. This is important because it will take a while for the machinery I describe below to be ubiquitous so this is a reasonable fall back experience. But we can do better, much better.

3 The next step on the road to general delegation - on behalf of

In the previous section we added to OAuth the ability to specify the user who is the target of a request using e-mail. What if we could also specify the identity of the user the request is on behalf of? In other words, imagine we add an ’OnBehalfOf’ field to OAuth? Now we have reached the fully generic semantics we talked about above. We can make a statement of the form ”Yahoo Calendar, on behalf of Yochi@bogus.example.org, gives permission to see his free/busy time to leon@bogus.gmail.com using the service Live Calendar.” The beauty of the previous statement is that Yochi no longer needs to login to Live calendar to prove his identity. So long as Live calendar believes that Yahoo calendar is authorized to act on behalf of Yochi the entire permissioning step can be handled with no additional UX.

But this begs the question, why should Live calendar believe that Yahoo calendar has the right to speak on Yochi’s behalf?

4 Making on behalf of actually work - discovery

There are a number of ways that Live calendar can figure out if Yahoo calendar is allowed to speak on behalf of Yochi. But a fairly straight forward way that turns out to have some really nice capabilities (which I’ll get to in the next section) is a discovery server. Imagine if Live calendar could take Yochi’s e-mail address, Yochi@bogus.example.org and make a GET request of the form https://bogus.example.org/.well-known/finger-service?user=Yochi@bogus.example.org&service=URN:Services:calendar and get back the URL for Yochi’s calendar service? Notice that as directories go this is a fairly tame one. Queries consist of two fields (a user e-mail and a service ID) and the response is one or more URIs. In this case if the URI returned to the query points at Yahoo calendar than Live Calendar knows that Yahoo Calendar really is authorized to make statements on Yochi’s behalf, at least in regards to calendaring.

5 Another nice feature of discovery

The calendar scenario is predicated on Yochi being able to specify that Leon’s calendar is at Live Calendar. But how did Yochi know that? Did he ask Leon where he keeps his calendar and then type in some URL pointing at Live Calendar into Yahoo Calendar? Did he pick from a drop down? Ideally Yochi could just say to Yahoo calendar ”Hey, my friend Leon’s e-mail address is leon@bogus.gmail.com, give him permission to see my free/busy time” and then Yahoo calendar would handle the rest. Thanks to the discovery service that’s possible.

Yahoo calendar can go to https://bogus.gmail.com/.well-known-finger-service?user=leon@bogus.gmail.com&service=URN:Services:calendar and get back the URL for Leon’s calendar service, in this case, Live calendar. And then Yahoo can make an on-behalf of request and set up the permission. So Yochi didn’t need to know where Leon’s calendar service was at. He just needed to know Leon’s e-mail address.

6 Conclusion

The goal was to enable generic delegation so that any user of any service can give permissions to any user of any other service. To make this happen we needed to introduce two key features. First was on behalf of (and the related target user). Doing this required little more than adding two fields to OAuth requests along with the idea that users are identified by e-mail addresses. Second was discovery. By enabling a simple discovery server (two strings in, a list of URIs out) we both enable users to find other user’s services as well as allow services to figure out which services are allowed to act on behalf of which other services.

These two features give us the foundation for open permissions on the Internet.

A Some odds and ends

My goal with the previous article was to provide a very high level overview of how full delegation could work in OAuth. In this appendix I provide a similar high level overview of a number of ancillary features needed to fill out the experience.

B How exactly did Live calendar provision with Yahoo calendar?

In most OAuth contexts there is an assumption that two services have provisioned with each other out of band and that’s why they can securely talk to each other. But requiring everyone to provision out of band with everyone else is not a recipe for a scalable web. What I think we want is the ability for any two arbitrary services to be able to provision a relationship dynamically. There are two parts to provisioning from a technical perspective. One part is establishing a secure communication channel. The other part is establishing a shared application protocol.

B.1 Establishing a secure communication channel

Establishing a secure communication channel generally means creating a mutually authenticated connection, that is, a connection where both ends have authenticated each other. Public key cryptography would be a great technology to use here were it not that most of the languages/platforms used on the Internet do not have good public key support. So instead I propose that we use SSL (ironically built on public key cryptography but in a sufficiently low level way that there exist high quality wide spread support) to establish a shared symmetric key between two services. This key can then be used to sign things like request/access tokens (thus authenticating the sender) over a SSL connection (thus authenticated the receiver).

Establishing the shared symmetric key requires two round trips. For example. let’s say that Yahoo Calendar wants to provision with Live Calendar. Note that this provisioning would only need to happen once. The symmetric key, once established, could be used with all on behalf of requests between the services independent of the users involved. In other words the symmetric key is provisioned between the services directly.

1. Yahoo calendar (after using discovery to find the Live calendar provisioning endpoint) would send a HTTPS request to Live calendar’s provisioning endpoint including a cryptographically secure random number.
2. Live calendar (after using discovery to confirm the Yahoo calendar provisioning endpoint) would send a HTTPS request to Yahoo calendar’s provisioning endpoint including both the cryptographically secure random number and the symmetric key that is to be used between the services.

That’s it. The two services have now securely established a shared key that can be used to sign tokens and prove identity. This same mechanism can also be used to generate new keys when it’s time to do a key rollover.

B.2 A shared application protocol

As for the second part, the shared application protocol, the Internet is full of those. Are we talking about a file or photo sharing service? WebDAV. Are we talking about a content management system? Delta-V. calendar? CalDAV. You have a problem? DAV has a protocol. :)

C How did Yochi’s discovery server come to list Yahoo calendar as Yochi’s calendar service?

In the scenario Yochi’s discovery service is at bogus.example.com but Yochi’s calendaring service is at Yahoo. How did Yahoo tell bogus.example.com to list Yahoo Calendar as Yochi’s discovery service? Making this work is really just an application of bog standard OAuth. After setting up his Yahoo Calendar, the Yahoo Calendar service would redirect Yochi with a standard OAuth delegation request to Yochi’s discovery service to set itself as Yochi’s calendaring service location. Yochi would confirm to his discovery service that he agrees (again, this is bog standard OAuth) and the change would be made.

D And why was Live calendar allowed to discover who Yochi’s calendar service is anyway?

It’s not a good idea to have discovery services sharing information about user’s services to just anyone. So in our scenario the discovery service should have demanded authentication from Live. But it seems doubtful that Yochi would have thought to give Live permission to see his discovery data. What is more likely is that Yochi set up his discovery service to allow anyone in his address book to see his service locations and Leon is in his address book. So what should happen is that Live should make an ’on behalf of’ request to Yochi’s discovery server in Leon’s name. But how does Yochi’s discovery server know that Live Calendar is allowed to act on behalf of Leon?

The answer is that Yochi’s discovery service will make a request to Leon’s discovery service on behalf of Yochi to find out Leon’s calendar service and see if it’s Live Calendar. Leon’s discovery service can easily validate that Yochi’s discovery service is allowed to act on Yochi’s behalf by matching Yochi’s e-mail address to the discovery service location (e.g. they are both bogus.example.org) so it knows everything is o.k. Since Yochi is in Leon’s address book, Leon’s discovery service will respond to the request confirming that Live is allowed to act on behalf of Leon. And now the scenario is complete. Yochi’s discovery service knows that Live can act on behalf of Leon (at least in this context) and since Leon is in Yochi’s address book the request for calendar location information from Live is positively responded to.

E What if Leon wanted to ask Yochi for permission to see his free/busy time?

This article has worked on the scenario where Yochi wants to inform Leon that he has been granted a permission. But a more general case is that Leon realizes he needs access to Yochi’s free/busy time. This just requires adding a command to OAuth ”asking for permission” whose semantics are ”User X of service Y asks for permission Z from user A of service B”. But all the details of discovery, permissioning, etc. are the same as above. Once user A reviews the request and approves it then the process of notifying User X that they have received the permission is exactly as given above.

F Where can I go to learn more? (Read: I’m having trouble sleeping)

I’ve tried my best to keep this article focused on the big picture and in something reasonably approximate to English. But I’ve written a series of articles going into the gory details of how all this can be made to work. Those articles are:

Open Permissions Matter for an Open Web

An argument for why open permissions matter and an exploration of the components needed to make them happen.

The Outline of a Profile for Granting Permissions Using OAuth WRAP

Provides a sequence diagram and supporting material explaining how the basic protocol exchanges would work.

Thoughts on Building a Finger Service

What I call a discovery service in this article was more traditionally called a finger service. This article explores key issues in designing a dirt simple finger service.

Using OAuth WRAP and Finger for Ad-Hoc User Authentication

This is where I first introduce how to do ad-hoc provisioning (e.g. using two request/response pairs to establish a shared symmetric key). But I do it in the context of showing how OAuth can be used as a replacement for OpenID v1.

Thoughts on Updating Finger Services

All the gory details on how services can update user’s discovery services.

Contents

The OpenID community has worked long and hard to make ad-hoc logins possible on the web. Part of that process has been experiments with a number of different technologies and approaches. Below I make my own proposal for how to handle ad-hoc logins on the Internet using OAuth WRAP and my own spin on Finger. I offer this up as food for thought.

Contents

1 Disclaimer

My employer has nothing to do with anything in this article. They didn’t review it, authorize it or influence it. It’s my ideas and my ideas alone. So blame me.

I have a deep interest in identity issues mostly as part of my fervent desire to live in an Open Web and that web doesn’t exist today. So I ask the reader to please take these ideas in the spirit that they are offered, as a fellow traveler trying to find a successful path to a web where users decide who they want to interact with.

2 Logging into the Foo service - a scenario

Joe wants to use the Foo service. To do this Joe needs to log into the Foo service. Joe’s identity provider is example.com where Joe is known as joe@example.com. The Foo service and example.com have no previous relationship. Joe tells the Foo service that his email is joe@example.com (note: the scenario works just as well with just Joe’s domain so there is no need to expose one’s identity). The Foo service then uses finger (my thoughts on which I have explored here) to obtain example.com’s symmetric key negotiation service and login service endpoints. The Foo service uses the key negotiation service to negotiate a symmetric key with example.com. Then the Foo service uses a profile of OAuth WRAP to forward Joe to the login service asking for proof that the user really is joe@example.com. Example.com validates Joe’s identity and then forwards Joe’s web browser back to the Foo service with a security token attesting to Joe’s identity.

3 My thoughts on requirements

3.1 No federation, no registration, it’s truly ad-hoc

We need an approach to authenticating users across services that doesn’t require the services to have any pre-existing relationship. The services must not need to register with each other, federate or any other ’off line’ magic in order to successfully authenticate users to each other.

3.2 No public key encryption beyond SSL/TLS, at least not initially

The use of public key encryption has obvious applications to this scenario. But I believe we have to start simple with solutions that do not require any form of PKI beyond SSL/TLS which I believe should be mandatory requirements of the protocol. Yes, in the future, we definitely should extend to PKI because it has some very nice advantages but I believe that the base functionality shouldn’t use anything more than SSL/TLS with some HMAC thrown in for validation of security tokens. Note however that support for SSL/TLS is mandatory and a critical component of the security of the key negotiation algorithm defined below.

4 An example

When Joe first navigates to the Foo service he is prompted to login. Ideally Joe should just type in his identity provider’s domain name (example.com) but realistically most users won’t ’get’ that (at least not initially) and will probably just type in their e-mail addresses, in this case, joe@example.com.

The Foo service has never had an interaction with example.com before so the first thing it does is do a lookup on example.com’s finger service to find the location of example.com’s key negotiation endpoint. This process consists of sending a POST request to https://example.com/.well-known/finger-service?service=example.com with a scope (a la OAuth WRAP) of URN:SomeStandardsOrgId:KeyNegotiationService. The response would contain a URL such as https://example.com/keynegotiationservice.

The Foo service would then send a request to establish a symmetric key to https://example.com/keynegotiationservice. The request would contain Foo’s key negotiation service URL (https://foo.com/mykeygenerator), a request ID and a cryptographically secure randomly generated number that I’ll call proof1.

Example.com would then double check the key negotiation service location by using a finger request on foo.com to find foo.com’s key negotiation endpoint. Once it had validated that the URL it received in the key negotiation request matched the value retrieved from finger then example.com would issue a POST to that URL with the request ID, proof1 and a symmetric key value that is to be used to sign security tokens between example.com and the Foo service.

At this point there is now a symmetric key that both Example.com and the Foo service (represented by the domain foo.com) have agreed to use with each other.

Now the Foo service will perform a second finger lookup but this time look for URN:SomeStandardsOrgId:LoginService. This time the Foo service wants to know where to send Joe in order to log him in.

Foo service will then forward Joe’s browser to the URI returned in the previous finger request along with an OAuth WRAP style permission request of ”Please log this person in and tell me who the heck they are.”

Example.com will then log Joe in and ask Joe if he wants to tell Foo service who he is. Joe will say yes and Example.com will redirect Joe back to Foo service with a security token, HMAC’d with the shared key, asserting Joe’s identity.

And now we’re done. Joe logged into Foo service using his identity provider example.com even though Foo service and example.com had never had any previous interactions with each other.

Only the colored links involve standardization. The blue links (3/3R, 5/5R and 7/7R) use finger whose design I have discussed elsewhere. The green links (4/4R and 6/6R) are the symmetric key negotiation algorithm I introduce in this article. The red links (2R, 8, 9R and 10) are a minor profile of OAuth WRAP that I discuss in this article.

4.1 What if Joe’s identity provider isn’t the same as his domain name?

This is actually not an uncommon situation. For example, users establish Facebook accounts with e-mail addresses that Facebook doesn’t own yet Facebook acts very much as an identity provider. Some services, like Google and Live are identity providers where users can either choose to use a domain for their e-mail controlled by Google or Live (e.g. gmail.com or live.com) or they can use an existing e-mail address. This can sometimes create confusion. If Joe has a Live account he created with the e-mail address joe@example.com and Joe wants to login to the Foo service then if he says his e-mail is joe@example.com the Foo service will go to example.com instead of live.com who is Joe’s identity provider.

This is a really sticky problem and I’m pretty convinced that it’s not interesting to solve. The reason identity providers like Live or Google let users use existing e-mail addresses from domains not owned by identity provider was as a convenience. That convenience is proving more and more troublesome to the point where the message needs to go out - login using your identity provider. So if Joe wants to be known as joe@example.com then example.com better be his identity provider. Otherwise he needs to get another e-mail address.

I know many people don’t find this to be a satisfying answer but I believe that bending ourselves over backwards to solve a weird pointer problem just isn’t worth the effort.

4.2 Why do we need proof1 in messages 4 and 6? Shouldn’t the request ID be enough?

As long as the request ID contains a cryptographically secure random number of sufficient length then yes it is enough. But I felt like calling out the requirement for the secure value as its own value in the exchange in order to hammer home how important it is from a security perspective. The security of the key establishment hinges on the use of TLS/SSL and the exchange of an unguessable secret. If either is compromised then the key establishment protocol is not secure.

4.3 How did Example.com know what security token format to send proof of Joe’s identity in to the Foo service or what claims to use?

My assumption is that we will define profiles for common situations like this. So there will be a profile called ’login’ and that profile will specify things like what security token format to use and what claims can be placed in that security token.

4.4 Wouldn’t it be easier for the Foo service to just make one directory lookup request against example.com instead of two?

This is really more of an issue for the finger server article but my opinion is that with HTTP/1.1 pipelining (and in this case the POST’s semantics are idempotent so pipelining is fine) I don’t see any reason to over optimize. Besides these requests should be reasonably rare.

4.5 Why is Example.com using finger in 5/5R to find Foo’s key negotiation service URL when that value was already provided in message 4?

In theory any request that can be validated against a domain over TLS/SSL should be ’trusted’ as having properly come from that domain. But in practice paranoia is a healthy thing. Let’s say an attacker has managed to take over some small part of example.com and is using that to launch key attacks. By checking the key negotiation service location in message 4 against the value returned by the finger service in 5R, example.com gives itself an extra level of protection.

4.6 How do keys expire and get replaced?

As part of the key exchange one expects that an expiration date will be associated with the key. To keep things running smoothly it will be necessary to be able to roll keys over without a ’gap’ where no key is in place. This means that at a minimum the two parties to a key negotiation need to handle having at least two keys active at the same time.

For example, let’s say a key has been negotiated and will expire in a few days. One of the parties may decide it is time to create a new key so that it can be established before the old key expires. For this scheme to work at least two keys have to be active at the same time, the old key that is about to expire and the newly established key.

In general a new key is established any time the key negotiation exchange is made. So in theory an unbounded number of keys could be put into play. In practice however each side is likely to have some upper limit to how many keys they want in play at any one time. This limit can be enforced either by refusing to add new keys if there already exist a maximum number of unexpired keys or dropping off an existing key (e.g. no longer honoring it) if the maximum number of supported keys has been reached. Which approach isn’t as important as making sure both ends of the conversation understand what has happened. My own preference is for each side to just support a maximum number of keys and to refuse to create new ones if that maximum is filled with unexpired keys. I think the failure scenarios for that situation are easier for each side to understand.

4.7 What happens if a key gets compromised or lost?

My own thinking is that the key negotiation protocol should have a message exchange type of ”Delete all keys we have negotiated” along with a human description of what the heck happened and some contact information since a follow up is probably necessary. This exchange would occur using the same two step pattern as establishing a key so as to prevent attacks.

4.8 Aren’t there race conditions between two services trying to establish keys?

You betcha. Imagine a case where a user is logging into one of example.com’s services using a Foo service identity and vice versa. This could easily result in two different keys getting established between the same services. But as long as we mandate that each side be able to handle a reasonable number of keys (say 10 just to pick some integer) then it really shouldn’t matter.

4.9 Does Foo service repeat this entire process with everyone from example.com who wants to login?

Heck no. The negotiated key is good for all communications between foo.com and example.com

4.10 Why do we need to discover the location of the key negotiation or login services? Why not just hard code their locations under /.well-known?

Somewhere I can hear Mark Nottingham groaning. Strictly speaking hard coding the locations under /.well-known is at least logically consistent. But in general hard coding makes for fragile systems. It limits implementers flexibility around where services should be hosted. So it seems like a good idea to hard code as few things as possible and let everything else be dynamic. Hence the desire to redirect through a finger server.

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.

In a previous article I talked about adding a profile to OAuth WRAP that would enable users to ask for or grant permissions to each other. In this article I show that an OAuth WRAP profile to handle granting permissions only needs two request/response pairs. I then show that an OAuth WRAP profile to handle asking for permissions only needs one additional exchange.

Contents

1 Granting Permission - The free/busy time example

In this example the user joe@google.com, who uses the Yahoo Calendar service, wants to give permission to mike@example.com, who uses the Live calendar service, to see Joe’s free/busy time. Mike will then login to Live calendar service, accept Joe’s permission grant and then schedule a meeting with Joe where Joe’s free/busy time will be displayed to Mike.

In looking at the sequence diagram it’s worth noting that the entire proposal comes down to creating a profile for OAuth WRAP that introduces request/response pairs 2/2R and 3/3R. That’s it.

7/7R are already defined by OAuth WRAP, 8/8R are defined by other protocols like CalDAV and everything else occurs outside of any standard context. So while a lot is going on the amount we have to add to enable interoperability is quite small. The sequence diagram does, however, bring up some interesting issues that I explore below.

1.1 How did Joe know to tell Yahoo that Mike keeps his calendar at Live?

One can imagine that Joe went into his Yahoo address book and clicked on a button saying "Give Mike permission to see my free/busy time". Yahoo knows that Mike’s e-mail address is mike@example.com but how does Yahoo figure out where Mike keeps his calendar? I don’t think it will ever make sense to ask a customer where their friend’s calendar is because the customer might either not know or have the wrong answer. For privacy reasons Yahoo in many cases can’t tell the customer if their choice is right or wrong. So my suspicion is that Yahoo will need to find out for itself where the calendar is for the associated e-mail address.

In the long term there will exist discovery services that given an identifier like an e-mail address can return information such as where the owner’s calendar(s) is(are). I hope to discuss my ideas around that problem in another article. But in the short term my guess is that services will just have to ask their partners. In some cases, where there is very deep trust (or very long legal agreements and enough money to sue if things go bad) services will just bulk upload lists of who they host calendars for to their partners and update those lists on a regular basis. In other cases a service will have to send a protocol request to their partners asking "Do you host X’s calendar?" This request/response pair is shown in 2/2R in the diagram.

This means that a service like Yahoo who is probably partnered with a large number of other services will either have to check its local database of bulk uploads and/or make queries to partner services in order to figure out where a user’s calendar is. This won’t scale but it’s probably o.k. in the short term until the discovery service infrastructure is up and running.

1.2 What if Mike has multiple calendar services?

We can easily imagine that Mike has a personal calendar that he keeps at Live and a work calendar that is run from his business. One can also imagine that both Live and Mike’s business are federated with Yahoo. So when Yahoo goes out looking for where Mike’s calendar is they are likely to find not one, but two calendars. In fact it could be even more complicated. Let’s say that before deciding that Live was his primary personal calendar service Mike created accounts with a few other calendar services. He has since abandoned those calendars but he used the same e-mail address, mike@example.com, to create all the calendar accounts. If Yahoo is federated/registered with those calendaring services then Yahoo could find itself having numerous potential calendaring services who all say they represent mike@example.com and at least two of them are even right!

One suspects that the only sane way to handle this for now is for Yahoo to just find all the calendar services who have an entry for Mike and send the permission request to all of them. Most likely Mike will probably accept Joe’s request for his Live calendar and reject Joe’s request for his work calendar. But just as likely Joe might accept both requests and that’s probably a good thing. In the end Joe needs to know when Mike is busy, if Mike hasn’t federated his two calendars together then the only way to have an accurate picture of Mike’s activities is to get free/busy time from both calendars. Yahoo would then pull the data from both and show Joe a unified free/busy time view for Mike.

1.3 How did Live know the requests came from Yahoo?

In the sequence diagram Yahoo sends two requests to Live, one to find out if Live has Mike’s calendar (2/2R) and another to notify Live that Joe has granted Mike permission to see Joe’s free/busy time (3/3R). In the short run my guess is that services like Live will require services that want to talk to it to register and as part of that registration the requesting service, in this case Yahoo, will get what OAuth WRAP calls a client id and a client secret. Yahoo will include those values in its requests and so authenticate itself to Live.

In the long run I’d actually like to see an ad-hoc system that lets two services exchange requests without a previous relationship. In a future blog post I hope to explain how this could be made to work.

1.4 How did Live know what permission Yahoo was asking for?

My guess is that requests 2/2R and 3/3R will use the OAuth WRAP request/response format which is just HTML Forms. So we would expect that request 3 will include some indicator of what permission or permissions are being asked for. This is nothing new in and of itself, OAuth handles this all the time today. What’s unfortunate is that the way OAuth typically handles this is that every service posts its own unique list of permissions it handles and anyone wanting to work with that service has to work with that service’s permissions. This makes economies of scale hard to come by. Also the permissioning part of the game is the easy part, all things considered. The hard work comes in request/response pair 8/8R where the free/busy time is retrieved.

My hope is that folks in communities like calendaring, document sharing, etc. will get together and create packages of both claims for use with OAuth WRAP as well as details on what protocols to use along with those permissions. But one step at a time.

1.5 How did Live know that joe@google.com was the one who asked Yahoo to make the request?

The real question is probably more subtle - how did Yahoo know its user was the legitimate owner of joe@google.com? It turns out that there are a non-trivial number of ways that Yahoo could have validated Joe’s identify. But the two typical approaches are:

E-mail Validation

Joe could have created an account with Yahoo using the e-mail address ’joe@google.com’ and Yahoo e-mailed a confirmation message to that address that Joe then had to click on and then log in again. This provides reasonable proof that the user owns the e-mail address ’joe@google.com’.

WS-Federation, SAML-P or OpenID

Yahoo could have a trusted federation with Google and so accept Google’s attestations of Joe’s identity.

My guess is that initially Live will require that Yahoo disclose the mechanism used to authenticate the user’s identity. Live will then decide how to proceed based on context and the authentication mechanism. Yahoo’s disclosure could be as simple as a field in the permission notification request that says "auth_type = EmailValidation" or what have you. Live would then trust that Yahoo was being honest about the value it put in the auth_type claim.

There are some edge case scenarios where a service that is giving permission might not know the public identity of the person granting the permission. I have some ideas on how to solve that problem but they are fairly complex so I’ll save them for another day.

1.6 How does Joe remove permission for Mike to see his free/busy time?

In message 1R Yahoo let Joe know that it was able to deliver the notification request, although Yahoo won’t tell Joe where the request was sent. But Joe won’t ever know if Mike actually accepted the request since, to be blunt, it’s none of Joe’s business. Joe can offer the permission but that’s it. But what is Joe’s business is if Joe changes his mind and wants to withdraw permission he needs a way to do that.

Thankfully removing permissions can be handled completely outside of the protocol. Joe needs to let Yahoo know that he no longer wants Mike to be able to see his free/busy time and at that point Yahoo will remove Mike’s permission from its permission store. It’s worth remembering that the way OAuth WRAP works every time a particular user gives a particular permission to another particular user a refresh token is issued. That token is unique to the combination of Source User/Source Service/Destination User/Destination Service/Permission. In our case that is joe@google.com/Yahoo Calendaring Service/mike@example.com/Live Calendaring Service/See Free Busy time. So the next time that Live comes with the refresh token (request 7) to get a new access token (7R) the request will be denied since Joe had Yahoo remove the permission.

2 Asking for permission - extending the free/busy time example

In this version of the example Mike asks for permission to see Joe’s free busy time. By way of reference, in the previous example Joe pre-emptively granted Mike permission, Mike hadn’t asked. The scenario is that Mike creates a meeting in the Live calendar service and invites Joe. Live sees that Mike doesn’t have Joe’s free/busy time and prompts Mike if he would like to ask Joe to see his free/busy time. Mike responds in the affirmative. Yahoo queries the services it knows to see if anyone owns Joe’s calendar and gets a positive response from Yahoo. So Live asks Yahoo to forward a free/busy time view request to Joe from Mike. Mike logs in, sees the request and approves it. At that point the rest of the flow is essentially identical to the previous example. Yahoo notifies Live that Joe has granted the permission and Live uses that permission to show Joe’s free/busy time to Mike.

In comparing this example to the previous example only one new request/response pair is added, 4/4R. All the other request/response pairs that deal with anything that needs to be standardized are already defined in the previous example. And even 4/4R is a variant on 7/7R.

A variant on this scenario would be to have Mike both request Joe’s free/busy time while simultaneously granting Joe the right to see Mike’s free/busy time. But I suspect these should be modeled as two separate interactions.

2.1 How does Live know that the notification in 7 is a response to the request in 4?

Strictly speaking correlation isn’t necessary since Live should be able to recognize that it asked for specific permission from Yahoo for a specific user and if it later gets that permission then matching the request with the response shouldn’t be a big deal. One can imagine Live keeping a table where the index is on a set of columns that specify what service the request went to, what user at the server it was targeted at, what permission was asked for and what local user made the request. Correlating 7 with 4 then becomes a simple task of looking up the appropriate entry in the table. If there is an entry then this is a response to a previous permission request and if there isn’t an entry then this is the previous example.

But if we really want we can just include a correlation ID from Live in request 4 that Yahoo is expected to include in 7 because 7 was generated in response to 4. If 7 was generated on its own (e.g. the previous example) then no correlation ID would be present.

Contents

Disclaimer

This article represents my personal opinions and only my personal opinions. Nothing in this article should be construed as representing my current employers opinions, actions, plans, or what have you.

1 Bring in the scenarios!

1.1 Notification that permission has been granted

Jane works at Big Corp international where she uses Exchange to maintain her work calendar. Jane wants to give her spouse, Lucy, permission to see her free/busy time so that Lucy can schedule events with Jane that won’t interfere with Jane’s work schedule. Jane sets up a permission for Lucy in her calendar granting Lucy permission to see Jane’s free/busy time. Lucy, who uses Yahoo Calendaring for her personal calendar, is notified by Yahoo that Jane has granted the permission and asked if she accepts the permission. Lucy accepts the permission and Jane’s free/busy time is displayed in Lucy’s Yahoo Calendar.

1.2 Asking for permission

Morgan is a vendor hired by Istvan’s company to help with a project. Morgan uses Google Docs to edit and manage documents while Istvan uses Sharepoint Online. To get the project done Morgan needs access to certain documents in Istvan’s Sharepoint. Morgan uses a permission request dialog in Google Docs to send a request to Sharepoint Online asking Istvan for access to Istvan’s Sharepoint. Sharepoint Online receives the request and shows it to Istvan who approves granting Morgan read/write access to a particular sub-directory in Istvan’s Sharepoint. Sharepoint Online then notifies Google Docs that Istvan has granted Morgan read/write permissions to a directory in Istvan’s Sharepoint. Google Docs notifies Morgan and displays the folder from Istvan’s Sharepoint as part of Morgan’s Google Docs workspace.

2 Breaking down the scenarios

Below I break the scenarios into what I think are the ’key’ actions. My suspicion is that if we can define reasonable ways to achieve each of these actions then the rest of the questions around how to implement the scenarios will more or less answer themselves.

2.1 Notification that permission has been granted

Identify the principal

In order to grant a permission Jane had to let Exchange Online know ’who’ Lucy is so that Exchange could transmit the permission to Lucy. What is the pointer used to identify Lucy to Exchange Online?

Describe the permission

What format did Exchange Online use to tell Lucy about the permission granted by Jane? What information is needed in the format?

Discover where to deliver the permission notification

How did Exchange Online figure out where to deliver the permission notification to?

Deliver the permission notification

What are the details of how Exchange Online delivered the permission notification, isn’t this just a spammers dream?

Utilize the permission

Assuming that Lucy accepts the permission how does she go about taking advantage of it?

2.2 Asking for permission

Identify the principal

How did Aahan tell Facebook that he wanted to ask for permission from Aanjay at Flicker? What is the pointer that Aahan used to identify Aanjay to Facebook?

Describe the permission

How does Facebook tell Aanjay about her father’s permission request? What is the format? What information is in the format?

Discover where to deliver the permission request

How does Facebook know where to deliver the permission request?

Deliver the permission request

What are the details of how Facebook delivered the permission request, isn’t this just a spammers dream?

My assumption is that if the permission request is granted then notification of this fact will be delivered in the manner specified in the previous section.

3 Addressing the scenario components

3.1 Identify the principal

The obvious answer would seem to be e-mail addresses. Jane types in lucy@yahoo.com (or more likely selects Lucy’s entry in Jane’s personal address book which then resolves to lucy@yahoo.com). Unfortunately e-mail addresses are lousy identifiers for a couple of reasons.

Late bound identifiers

Are identifiers that are resolved to a principal at time of use and are not guaranteed to always bind to the same principal. In other words, Jane’s spouse Lucy may have control over lucy@yahoo.com today, but who knows who might own lucy@yahoo.com tomorrow?

Non transferable

If Lucy decides that she no longer wants to use Yahoo and would like to move to another identity provider or even be her own identity provider there is no well defined way to achieve this goal with an e-mail address. Once the address is abandoned, that’s it. There’s no forwarding mechanism.

Not uniquely bound to an identity provider

It’s tempting to argue that when trying to interact with the identifier lucy@yahoo.com it makes the most sense to contact yahoo.com. But what to then make of folks like Live or Google who will let users create account with other identity provider’s e-mail names? For example, Lucy can create a Google account using her Yahoo address. So when typing in lucy@yahoo.com to give a calendaring permission does Jane mean Lucy’s calendar with Yahoo or Lucy’s calendar with Google?

These are all very serious problems but solving them will require introducing a new identity infrastructure. There are ways to make this new infrastructure work over the old one but the issues are complex and I think we should solve the easy problems before the hard ones.

So I’m going to assume that principals are identified by e-mail. Once we have that more or less working we can move on to the more difficult identity issues.

3.2 Discovery where to deliver the permission notification/request

So who gets notified that a permission has been granted? I suspect a key requirement is that we don’t mandate a single notification point for all services. In other words if I want to notify someone about a calendaring permission I should be able to do that at a different location than say an IM permission. That way services can be well factored and spread out. But this also means that there needs to be some mechanism to go from the principal identifier (an e-mail address) to the right address to notify for a particular service.

There is already a proposed solution for exactly this problem that we could, in theory, build on top of - Link-based Resource Descriptor Discovery (LRDD). But besides supporting no less than three different discovery mechanisms and throwing in XRD I think LRDD has is backwards. It assumes that one publishes all the data to be known about oneself. Besides wasting space this makes versioning and extensibility a nightmare. What if one supports four different types of calendaring protocol with various versions for each one? LRDD requires publishing the whole lot.

It’s tempting to argue that LRDD is easier to implement than a service since with LRDD one can, in theory, just publish a static file. But given the type and amount of data likely to be in a LRDD retrieved discovery file, the ’static file’ argument is, in my mind, a fiction. The data in a LRDD file will be dynamic and it will be maintained so it’s a service. Might as well treat it as one.

LRDD, besides describing what’s in the discovery file (e.g. the file containing the pointers to various services) also describes how to find the discovery file for a particular user when starting with an e-mail address. Specifically LRDD uses Web Host Metadata. But this is just another static file (using the XRD format that is also used in LRDD) that hangs off a well known address. Instead of using a request/response service (”here is the e-mail I’m looking for”, ”here is the address to go to”) It uses a static file that includes a templating language which one downloads and then locally feeds the e-mail address into the template which then spits out a URL.

So the LRDD process of going from an e-mail address to a service URL involves two steps. First one retrieves the Web Host Metadata that contains the pseudo-regular expression that one then downloads and ’runs’ locally to translate the e-mail address to a LRDD discovery file location. Then one retrieves the LRDD discovery file and from there finds out the service address.

Personally I think having a service at a well known location that one can send a request of the form ”I want to talk to the calendaring permission server for user X” and get back a response would be oodles easier to implement and reason about and involve one less hop.

But in any case, at least there is some existing work to start from.

3.3 Deliver the permission notification/request

In theory delivering the request or permission notification is easy enough, just POST some bit of XML or JSON and call it a day. But this is going to be a spammer/security nightmare. We need some authentication. But in this case we need to authenticate the sender, which is the service sending the notification and not the user who granted the permission. This simplifies things a bit and more accurately represents who the responsible parties are. (Note: For you WS-* heads, this is explicitly not an ’act as’ scenario)

For services with long standing relationship HMAC’s can be used to validate the POSTs by pre-arranging a shared secret. For ad-hoc scenarios I suspect we’ll want to use digital signatures and leverage the previous discovery mechanism to find the public key for a service. That way when a service receives a message it can validate the signature by checking the source service’s public key.

Another check against spamming/security attacks is to make sure to only process requests or permission notifications who are identified as coming from people the user ’trusts’, typically people in their address book. Yes, this leaves open the question of how to handle requests that aren’t from folks in the address book but most social networking systems already deal with this by asking users if they wish to receive requests or permissions from people they don’t have listed.

3.4 Utilize the permission

In the case of a permission notice the service receiving the notice will need the right information to use the permission on the user’s behalf. This is a classic OAuth use case so my guess is that we should just use OAuth access tokens in the permission notice and use the OAuth access pattern to exchange the access token for a request token (or whatever they are called this week) which is then passed into the actual service.

3.5 Describe the permission

This leaves the question (which I moved out of order because I actually think it’s the least interesting question) of what the actual permission notification/request looks like. My guess is that we should, again, rely on OAuth. It has a very simple format that can be easily adapted for the purposes of describing anything and it provides mechanisms for sending requests either over SSL or without. Again, no need to get fancy. The whole thing then becomes just another OAuth profile.

4 Conclusion

I think we have all the pieces to create a really powerful ad-hoc sharing infrastructure that can allow a user of any random kind of service to ask for or grant permissions to any user of any other service. This is what a real, open, social web is all about. So let’s get cracking!

My unhappiness started when First Tech's website was down for 5 days, worse yet, a scheduled 5 days, so they could upgrade their online banking. In this day and age to have a 5 day downtime for an upgrade is unacceptable. This is not the 1990s. This isn't even the 2000s.

Things only got worse when, according to their own notice the upgrade failed because after 5 days of being down they got three times their normal traffic and couldn't handle the load. Huh? You were down for 5 days, what the heck did you think was going to happen? Of course you're going to get a load spike! Their solution was to roll all of their website back to the old website so they could get back up and running while they figured out what to do about the extra load. The planning screw ups this situation called for are, well, concerning.

All of this was irritating but then there was the final straw. Their new on-line bill pay system wouldn't work for me. It kept saying my login failed. I sent mail to their help desk and they quickly responded (still good customer service). Their instructions were for me to reset my browser's security settings to accept third party cookies. What? I have to commit one of the most basic privacy mistakes and let everybody on the Internet trivially track me just so I can use your bill pay service?

This is a bank we're talking about. An institution which is supposed to be all about privacy. And they are so clueless that they think it's o.k. to require third party cookies? Their previous behavior already gave me good reason to question their technical competence but this is just over the top.

So does anyone have a recommendation for a bank with a solid web banking system that has a clue about privacy?

Contents

1 How much does a single year of college cost today?

Living in Washington State the obvious college to think about is the University of Washington. UW’s total costs for the 2010-2011 academic year for an instate student living away from home are $21,033. In my opinion UW is currently the only world class university in Washington State and I wouldn’t want to pin all of our daughter’s hopes on one university. So we’ll have to face the reality that our daughter may go out of state. Since I went to UCLA let’s see what UCLA would cost for the 2008-2009 academic year for an out of state student - $50,214 for an out of state student living in an off campus apartment. And remember, the UCLA figure is what it costs for an out of state student to go to UCLA today, right now, this very moment. Not, say, oh 15 years from now.

2 How quickly are college costs going up?

The most comprehensive source of information I could find on college pricing is [Board(a)]. But the raw data is available as spreadsheet in [Board(b)], I used Table 5. Please note that when staring at the table below the numbers in table 5 are adjusted for inflation.

Unfortunately there is a problem with the data. The 2009-2010 school year saw the single largest year-on-year increase in public four-year college tuition in the entire data set (which admittedly only goes back to 1979). The increase for private colleges was one of the largest ever. This does odd things to the numbers. For example, if I calculate the 10 year geometric mean increase from 1999 through 2008 I get 3.03% for public colleges and 1.89% for private colleges. Quite a change from the numbers above. So do college tuition increases during the greatest recession in recent memory where colleges, public and private, were essentially set loose on their own with their endowments pummeled really serve as a good basis for calculating what’s going to happen over the next 15 years? Beats me.

My guess is that 2010-2011 is going to be even worse, I know the UC system on its own increased tuition by 32%. Yes, 32%. So maybe these sky high rises are just the future and we need to get used to it? Or more likely at some point the whole system collapses because as the old saying goes, anything that can’t go on forever, won’t.

But in the meantime I need to estimate the future college cost increases. So I’m going to take the 15 year number, for no particularly good reason and I’m going to average it. In other words I’ll assume that for the next 15 years college costs will go up at a rate of (0.0317 + 0.0252)/2 = 2.85%.

3 How much will the bill be?

The first question is - how long will our daughter take to get her undergraduate degree? I haven’t had much success in finding solid data on how long it takes to graduate from college but I did find one data point from 2000. The table on page 46 of [for Education Statistics(2003)]. It claims that students on average took 55 months to graduate although students who went to only one college took 51 months on average but even that number can be split into 53 months for a public school and 47 months for a private college. I don’t have any trend data on these figures and no clue what anyone is projecting for the future. Still the message here is that in 2000 public school students took about 4.5 years to graduate and private school students took 4 years. Given the outrageous costs of college the only way I can see the number of years substantially increasing is if students are attending school part time to try and make ends meet. So I’m going to guess that my daughter is probably going to go to college for 4 years. Or, put another way, given what we expect to be paying 15 years from now she better not need more than 4 years.

In terms of the cost basis I’m going to pick the UCLA out-of-state figure, $50,214 and the 2.85% growth rate. As my daughter is now 4 years old she has 15 years left until she goes to college. The only problem is that the school year (which determines when I have to cough up the money) doesn’t follow the calendar year. Schools start around September and run through June or so. This means my first check to college should be due around September of 2024.

The 2024 figure comes out because my daughter will turn 5 in 2011 and start kindergarten during the 2011-2012 school year. She will have 12 years of school after Kindergarten. So 2011+12 = 2023. In other words, she will graduate high school during the 2023-2024 school year. Which means she will start college during the 2024-2025 school year.

So the goal is to have enough money to pay for her first year of college by September of 2024. In reality I could stretch it out since most of her college expenses will be paid by the quarter/semester (tuition, fees, books and on-campus housing) or month (general living expenses and off-campus housing). But trying to be that exact over a 15 year period seems like useless specificity.

So, to keep myself mildly insane (as opposed to completely wacko) I’ll assume we’ll save money on a September-September basis. Or, in accountant speak, our college ’fiscal’ year starts in September.

And yes, this always drives me nuts at work. ”The project will be delivered by 2008”, ”Wait, is that calendar or fiscal year?”, ”AAAAHHHH!!!!!”

So, let’s see, $50,214 base figure, 2.85% real rate of growth (e.g. after inflation), for 15 years to save until her first year of college, with 4 years of college total, the total bill will be $319,499.38. (See the appendix for details)

Oy.

Keep in mind, that the previous figure is ’real’ not ’nominal’ money. Or in other words, this is ’inflation adjusted’. So $320,300 is how much I’m estimating it will cost to send our daughter to college in 2010 dollars. By way of comparison, sending our daughter to UCLA today for 4 years would cost $209,606.90.

So, I guess we can look on the bright side. Sending our daughter to college 15 years from now will ’only’ cost $109,892.48 more (in 2010 dollars) then it would to send her to college today. Oy

A Calculating the cost of college

The math for calculating a compounding entry is thankfully very straight forward:

In the example I gave above the CurrentCost is $50,214 for 2010-2011 and GrowthRate is 2.85%. Let’s say my daughter was going to college in one year. In that case the cost would increase over one year and be $50,214*(1+0.0285) = $51,645.10. In other words the YearsToGrow value would be 1 because there was only one year in which the growth would compound. So if my daughter is going to college in 15 years from now then the YearsToGrow value is 15.

So the math for calculating my daughter’s expected cost of going to college is:

The cost for sending my daughter to college in 2010-2011 would be:

References

Contents

1 Where should the money go?

The IRS has kindly summarized all the various options available to get tax benefits for spending money on education in [IRS(2009)].

That various tax credits and deductions one can take when spending taxable money on education all come with strict limitations on the income one can earn and still qualify for the tax credits. Marina and I certainly plan to exceed those limits by the time our daughter gets to college so we can’t rely on their use for our planning. U.S. Savings Bonds are also not a viable option for similar income cap reasons. The Coverdale IRA doesn’t work because its contribution limits are low given the costs of college and eventually we would hope the income limits would also be an issue. The IRA option isn’t a terribly good one for us because we need our IRA money to pay for our own retirements. If we have to choose between saving for our own retirement and paying for our daughter’s education then we will choose our retirement. It would be unfortunate if our daughter has to take on debt to go to college, it would be catastrophic for all involved if our daughter has to spend the rest of her life supporting her parents.

Although we probably can’t use the various tax deductions for taxable money we can still choose to invest for our daughter’s college education using taxable money, alternatively we can use a 529 plan. I’m not a huge fan of 529 plans. I don’t like the fact that if we don’t use all the money we have to pay a penalty above and beyond the deferred taxes to get it back. I also don’t like the fact that the investment options for 529s tend to be both limited and expensive. But the fact is that money we put into the 529 plan grows and exits completely tax free. This means that all the income on the principal we deposit in a 529 plan will never be subject to taxation. To put this benefit into perspective imagine our marginal tax bracket is T% and our college investments makes an I% return. In that case if we put the money in a taxable account our return after N years would be (1 + I * (1 - T))^N where as in a 529 our return would be (1 + I)^N. For example, if our marginal tax bracket was 25% and we got a 5% return on our investment over a 17 year period then we would get a - 1  23% or so higher return on investment from a 529 than a taxable plan. That’s the kind of benefit that is too expensive to give up.

So we’ll be using a 529 plan.

References