I really like Blaine's scenario. I'm not 100% familiar with the full OAuth process, but I think this kinds of get closer to what it is.
On Sun, Jan 24, 2010 at 4: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. A good thing is that if Tom uses publishing platform, before asking Tom for his approval, the platfom could filter as well and may consider all callbacks (from any publisher), legit or not. For example, in the case of Twitter, Twitter may accept that Google/Live subscribe to _any_ public user feed (I guess that' the sense of the deal they signed last year), but could ask for user approval for Friendfeed or any other life streaming tool. > 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. Agreed. > 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] > Agreed too. > > 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? > I'm not sure the hub should return a 204 until the subscription is _fully_ accepted by all parties. (at least, that would make this extension downward compatible, see my next point). I think return 202 can be interpreted by "hey, we're checking that all parties agree to your subscription". The problem then lies in the 'state' of the subscription for the subscriber. My suggestion here would be to make the hub return 204 for previously accepted subscriptions. So, if the susbcriber happens to ask again, the hub can return 204 without checking the intent again. I want to insist on the fact that this should be an _optional_ extension, which means that it should absolutely not change the susbcriber's behavior, to maintain compatibility with any hub/publihser that doesn't implement this extension. julien > 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 > > >
