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? 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'. 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). alexis On Sun, Jan 24, 2010 at 3:06 AM, Blaine Cook <[email protected]> wrote: > I've been busy so didn't get a chance to reply to this right away, but > I want to second (or third or fourth as the case may be) Julien's call > here. > > I think that what he's getting at is actually the most important use > case for PubSubHubbub, and the existing spec doesn't *quite* provide > the necessary tools, even for publishers who run their own hubs. > > The scenario I want to enable is deferred approval of subscriptions to > private content. > > For example, take a publisher, Tom, and a subscriber, Sally. Tom is > publishing a journal of his innermost thoughts on hist own website, > and doesn't want that content to be public. However, he'd like his > friends to be able to read the journal. Let's assume for now that > we're living in the future and that they want to use PSHB to receive > his journal entries. > > Tom has three options: > > 1. He can give all of his friends a private URL, and hope that they > don't share it. He will not be able to retract access, since it's just > one URL. > 2. He can give each of his friends a different URL. He can retract > access by ceasing publishing to any one of these URLs. > 3. He can give all of his friends, or anyone who isn't his friend, the > same URL, and decide whether or not to give them access as they come > and ask. > > Option (1) is clearly not going to work if Tom has more than one or > two friends. Option (2) is the model Flickr uses for their guest > passes and is often referred to as "casual privacy" or "URL-based > capabilities". This is a good model, except that Tom has to distribute > the URL to his friends, and so needs an out-of-band mechanism to share > his content with them. Option (3) is how virtually every social > network operates, and enables people that Tom wouldn't think to share > a private URL with, but with whom he might want to share his content > to ask for permission. > > You can see my bias here; I want Option 3 to be supported over PubSubHubbub. > > In order to do this, any subscription requests need to be approved by > Tom. So, when Sally asks her feed reader to subscribe to Tom's feed, > Tom's hub must wait until Tom gets back at his computer to verify the > request. > > Julien's mechanism is great, but I'd propose that for both sync and > async subscriptions, the *confirmation* (i.e., that the callback URL > is valid) should proceed, and that either 204 or 202 be returned to > Sally immediately. Asynchronously, the hub.mode=authorize should be > sent to the URL specified in the feed's <link rel='authorization'> in > order to notify Tom that he has a new subscription request. > Furthermore, I think an extra step of redirection is needed, wherein > the authorization response can be treated asynchronously, so that > Tom's blogging software can say to the hub: "I've received your > request to allow [[sally's callback URL]] to subscribe to [[tom's > feed]], but I don't know the answer yet", and later send the hub a > callback that says "that subscription is (approved/denied)."[1] > > When Tom gets back and approves or denies the request, it may be ideal > for his hub to notify Sally's callback URL with this information, so > that Sally doesn't have to keep trying in order to know whether or not > Tom has denied her request, or if he just hasn't been publishing > anything. > > I think there are a few gaps (i.e., beyond the callback URL, how does > Tom know who's asking?) for which I have some possible answers[2], but > I'd like to hear others' thoughts on this (especially Brett's and > Brad's). Julien, in particular, can you think of any problems with the > hub returning 202/204 to the subscription request, but then later > rejecting the subscription if authorization is denied? > > b. > > 1. Yes, I realize how close this is to symmetric hubs; I'm not sure > it's the same thing, but one step at a time. > 2. 9 letters, begins with 'w', ends with 'r' > > 2010/1/21 Julien <[email protected]>: >> Here is another example of the use of this "publisher callback". >> >> We host a hub for Tumblr. When a client (say friendfeed) reads a >> tumblr feed, it finds that the feed is managed by Superfeedr. It then >> logically subscribes to Superfeedr to get it feed. We need to make >> sure that this feed is managed by us (in other words, that Tumblr will >> ping us for it). Up until now we checked the domain. That's not >> enough... because Tumblr allows its users to use their own custom >> domain. The callback could be used for that : the publisher can easily >> say whether the feed is "legit" or not. (Checking the inclusion of the >> hub <link> is obviously not enough because anybody could add that to >> their feeds...) >> >> >> On Jan 20, 4:15 pm, Julien Genestoux <[email protected]> >> wrote: >>> Alright, thanks for the awesome feedback! Let me try to reply to all 3 >>> comments without someone else jumping in the discussion :) >>> >>> On Wed, Jan 20, 2010 at 2:02 PM, Alexis Richardson < >>> >>> [email protected]> wrote: >>> > Julien >>> >>> > First, thank-you and well done for writing this down. >>> >>> > Second, this type of behaviour is quite common in things like >>> > financial services market data feeds. Often in such cases, a >>> > middlebox or middleman takes responsibility for what would ideally by >>> > an end-end relationship between producer and consumer, but which for >>> > some business reason is brokered. >>> >>> > Third, I agree with Bob's comments. >>> >>> > I also feel this potentially complicates the spec and subscription >>> > process for just one particular use case. >>> >>> Well, maybe I should have emphasize much on that in my writting, but it's >>> really an extension because I expect to not change the behavior of hubs and >>> subscribers who have not implemented it. >>> >>> > In an ideal world, a >>> > publisher who wanted to know who was subscribed via PSHB, could just >>> > set up and run their own hub. >>> >>> Well, yes, and no... publishing and broadcasting are 2 different jobs I'd >>> day. Even though you read the guardian every day, it's not a guardian >>> employee who sells it to you. I'm not sure this is a good analogy analogy >>> but I think that the hubs' job is pretty clear : gather the list of >>> subscriber and send them content, whatever that is. I think publishers >>> should not necessarily do that job. >>> >>> > But let's say that they cannot or will >>> > not do that for some reason. Instead they might run a private hub, >>> > but delegate its hosting and management to a middleman service. Enter >>> > superfeedr as a suitable such provider. But if superfeedr is acting >>> > on behalf of a publisher in this way, then why can't the mechanisms >>> > for sharing subscription data and auth lists with that publisher also >>> > be private? >>> >>> Because the decision involved on whether who should subscribe or not has to >>> be "obscure" for the hub. For me the hub should ignore the data, as much as >>> it should ignore the reasons why somebody would subscribe and why somebody >>> would publish. By delegating the decision to the publisher, then, each >>> publihser can enforce his own policy. >>> >>> > What is the benefit of including it in the spec? >>> >>> > I'd rather see hubs being able to turn down subscriptions for any >>> > reason they like, and possibly silently. >>> >>> > Please note that the above is not a strongly held view ;-) I am keen >>> > to understand more about what you are proposing. But at this stage I >>> > think this should either unspecified, or (perhaps?) be spelt out even >>> > more strongly and thought about in relation to authentication and >>> > discovery in general. >>> >>> Another example would be NYT's recent move toward "paid" content. They might >>> want to say : hey we want a hub, we don't want to make the list of >>> subscription public and yet, we only want paying services to access it. I >>> think the publisher callback works quite well in that case. >>> >>> > alexis >>> >>> On Wed, Jan 20, 2010 at 3:02 PM, Pádraic Brady <[email protected]> >>> >>> wrote: >>> > Hi Julien, >>> >>> > Having thought about I had a few conclusions. Being an implementor (loves >>> > me code ;)), it would certainly be simple to do so no complaints there. I >>> > was curious how you saw this operating in a synchronous mode of >>> > subscription >>> > - the more indirect requests needed, the longer we're keeping Subscribers >>> > waiting. I'm particularly sensitive to us engaging in transactions which >>> > will start hitting bottlenecks like PHP's maximum execution time limit >>> > (let >>> > alone whatever the locally set HTTP timeout is). I nearly always favour >>> > async mode (where possible) but most Subscribers I suspect won't want the >>> > added complexity and will prefer synchronous. >>> >>> To be, this is the weakest point : adding one more query may slow the >>> process even more. I have no solution to it, except maybe just accept it. >>> Obviously both requests (to verify the intent and to verify the >>> authorization) could be done in parallel, but that would bear the risk of >>> inconsistency for the publisher who might allow an unconfirmed subscription. >>> >>> >>> >>> > The privacy issues I really don't see. Use of any technology is always >>> > subject to the client exposing something of their identity. The exposure >>> > of >>> > certain details like their callback URL doesn't seem to be much of an >>> > issue. >>> > By definition it's already publicly exposed so what else is there to keep >>> > private? We're not looking for Joe Doe's name, address and credit card >>> > details ;). Why don't we apply this same principle to Hubs? Aren't >>> > Subscribers handing them private information in this case already?? >>> >>> Agree with all that : there is no privacy issue for me. If publishers are >>> willing to push their content into the wild, I think it's a valid concern >>> that people who subscribed accept to be seen as subscribers. When you poll >>> : you can't hide. It should be the same for pushed content. >>> >>> At the end of the day, I really think this has a huge amount of potential >>> >>> > with is underplayed by its very modest intent. I think that's the main >>> > weak >>> > spot of the proposal - it's very specific ;). Then again, its specific >>> > nature is what makes it simple to grasp and implement. For myself, I would >>> > definitely like to see Publishers being able to get some kind of feedback >>> > in >>> > real-time in this vein. It may not be foolproof but on a personal note, I >>> > already have some funky programming tampering with my feeds so certain IPs >>> > get a feed full of copyright infringement messages instead of my actual >>> > content. Surely a modest blogger like me can't be the only one plagued by >>> > content stealing. >>> >>> ... >>> >>> >>> >>> > There is absolutely no reason why we should be linking the nature of feeds >>> > to the nature of Pubsubhubbub - they may be marginally related but both >>> > offer two very different distribution methods that merely share a common >>> > distributable format. It seems quite acceptable that Publishers have the >>> > right to impose additional restrictions. They can already do it to some >>> > extent with feeds, but real-time data and interactions with a Hub offers a >>> > far richer environment to work within. >>> >>> I agree with all that! >>> >>> Paddy >>> >>> Pádraic Brady >>> >>> http://blog.astrumfutura.comhttp://www.survivethedeepend.com >>> OpenID Europe Foundation Irish Representative <http://www.openideurope.eu/> >>> >>> On Wed, Jan 20, 2010 at 3:27 PM, Alex Barth <[email protected]> wrote: >>> > The draft spec doesn't account for a change in policy. How would a >>> > publisher pull access for a subscriber that seemed harmless at the >>> > point of subscription but turned out to be malicious later? Depending >>> > on the subscription renewal policy there would be at least a >>> > considerable time span where a subscriber would still receive >>> > notifications. Is this time span neglectable? >>> >>> That's a valid concern and when thinking about it, I thought we could >>> explictly specify in the extension that if a hub accepts a subscription then >>> it's accepted for its whole span. Obviously, one requirement from a >>> publisher would be to have limited lease... If they want to ban somebody, >>> they can refuse subsequent queries... and eventually all the susbcriptions >>> will be refused. >>> >>> > In my mind the core of the problem is that fat pings aren't good when >>> > you need to worry who's subscribing. >>> >>> > I am currently using pubsubhubbub for protected feeds. I took the >>> > liberty in my implementation to support a 'light ping' that forces the >>> > subscriber to fetch the feed from the original source - authenticated, >>> > over a secure connection. This allows me to distinguish between >>> > subscribers and - if necessary - disallow access on a granular level. >>> > A very useful feature for feeds of paid content or in my case - feeds >>> > of user credentials in a federated system of sites. >>> >>> That would work, yes. Except that some publishers want both fat pings and >>> visibility. I think Dave Winer's move a few weeks ago came after he had a >>> chat with Tumblr and Tumblr's hub is at Superfeedr. >>> >>> > Correct me if we're talking about *completely* different things here. >>> >>> Nope, related... >>> >>> >>> >>> >>> >>> > Alex >> >
