Noodling on OpenID and subauthorizatoin
paul at ciphergoth.org
Sun Jun 26 04:17:51 PDT 2005
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
More information about the yadis