Blaine On Sun, Jan 24, 2010 at 10:30 PM, Blaine Cook <[email protected]> wrote: > 2010/1/24 Alexis Richardson <[email protected]>: >> This is a nice idea in that it deals with one of the comments made by >> the list on Julien's suggestion, by making authentication async. >> >> Three comments: >> >> 1. This in effect makes the granting of authority part of the >> protocol. Is this a good thing? > > I think so! I can poll for public (and serve) feeds until the cows > come home, but doing so with private feeds is much more complicated.
I agree it looks cool at first glance. I fear it opens up a can of worms that someone who knows this area better is about to describe... >> 2. In Blaine's narrative there are two actors other than the >> subscriber - the hub and the publisher. Wouldn't a more elegant >> solution push the granting of authority to a general actor who could >> be either one, or a third? This could be a 'capability provider'. > > Sorry, I should clarify. I love Julien's approach of having the > publisher specify an URI that handles authorization. Effectively, that > means that the publisher delegates authority to a 4th party (in most > cases, though, the publisher will be the same as the > permission-authority). +1! Exactly. Also - yes - "Julien's approach of having the publisher specify an URI that handles authorization" is the heart of this. >> 3. @Blaine, I like your proposal but don't see how it *necessarily* >> distinguishes cases 2 and 3. For example a hub could generate a URL >> (per case 2) and still delay auth (per your example). > > Case 2 is a subset of case 3, absolutely. Case 3 isn't possible > without deferred auth, but Case 2 is viable either way. Exactly - the implication is one way. Good, just checking :-) > Does that > clarify the goals? Yes it does. I think the list should spend some time looking into the proposals. alexis
