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. > 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). > 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. Does that clarify the goals? b.
