Noodling on OpenID and subauthorizatoin

[Paul Crowley]

Now that OpenID is live on LJ and working, I've been thinking about what 
the next step for it is.  I don't think any of this affects the 
protocol; it's just what I was thinking about last night.

Supposing I'm "example.com/~foo", and "livejournal.com/~bar" friends me. 
   Then I can authenticate myself to LJ and read bar's friends-only 
posts.  My browser supports RSS, so I can feed bar's posts into my RSS 
aggregator and read the friends-only posts from LJ and DJ in a single 
view in this way.

However, supposing I prefer to use a web-based RSS aggregator at 
myaggregator.com.  Now this aggregator has to be able to authenticate 
itself using OpenID to LJ and DJ, and as a result of OpenID's design 
goals, it needs to know my example.com password to do so.

I might like to delegate the power to read these posts to the RSS 
aggregator, without telling it my password or passing on all my powers 
to it.  What new mechanism would make that possible?

I see two possible mechanisms:

Consumer subauthorization: LJ and DJ both record that 
myaggregator.com/~paul should be allowed to read all the friends-only 
entries that example.com/~foo can read, in a format of their own choosing

Server subauthorization: example.com publishes that information on a 
page linked from example.com/~foo, perhaps [link rel="openid.authorize" 
href="example.com/~paul/authorities.xml"], and LJ and DJ are coaxed into 
checking that page.

The advantage of consumer subauthorization: no new file format needs to 
be defined.  LJ and DJ can decide whether to allow 
myaggregator.com/~paul to view an entry without needing to be told on 
whose behalf it is trying to do so (which could be an arbitrarily long 
chain).  They can provide a user interface, and options, most suitable 
to whatever it is that's being delegated.

The advantage of server subauthorization: you can manage your 
subauthorizations in a single place.  You can subauthorize for all 
domains at once, or cancel all your subauthorizations at once.

I think that this is what SAML is for, and I seem to remember that some 
people here are familiar with SAML - what do you think?

Incidentally, it's worth thinking what will happen when 
myaggregator.com/~paul wants to authenticate itself.  It won't act on 
the redirects it gets back from the identity consumer - it will parse 
them and directly generate the resulting GET onto the consumer.

Also the application I have in mind is actually calendar aggregation, 
not RSS aggregation, but the issues are the same.
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/