On Tue, Jan 26, 2010 at 1:57 PM, Blaine Cook <[email protected]> wrote:
> 2010/1/25 John Panzer <[email protected]>: > > Note: That would require the only valid form of user identifier be an > acct: > > URI, but that could be fixed. I'm not sure how the trusted delegates get > > set up in advance (for both hub and subscriber?) -- and what if neither > one > > is the IdP for the user? > > Technically, the user identifier here is From (acct) + hub.callback > parameter (http). Trusted delegates definitely need to be set up in > advance in the webfinger record. There's some future-looking stuff > here, but I figure we need to start somewhere. ;-) > > Any ideas on how to do webfinger-less trust delegation are very > welcome, as I don't really have any strong ideas about this. I think > the IdP is irrelevant here? > > > I'm not clear how this prevents me from forging your email address as a > > subscription request (to subscribe you to something), though perhaps > > piggybacking on the overall PubSubHubbub flow is enough to prevent an > > injection of a new request. Not sure. > > You could definitely forge the email + callback. That said, publish > events provide the subscribe feed, and subscribers presumably have > ready access to the full list of feeds to which they're subscribed. > This makes it trivial to reject malicious subscriptions, and > subscribers should probably send unsubscribe requests (or, more > efficiently, an "I'm not subscribed" error code) to publishers. > > It might be worthwhile to incorporate some kind of DKIM-for-Webfinger, > but maybe that's too much for the time being? > > The other lighter-weight possibility would be to modify the core spec > to require hub.secret for subscriptions, and have that value be > incorporated into the confirmation callback, or just require it as > part of this extension. > > > More to the point, if there is a standard structure for follow/subscribe > > activities, it could be leveraged here too as useful data. That could > > safely be an extension as long as there's someplace to transmit the > > structured data in the basic spec though. > > I'm not sure what you're imagining here? > - Information about the user (avatar, etc.) -- perhaps just retrieved via PoCo but they may not want to provide everything publicly, would be useful to be able to transmit additional info when requesting access - Request specific fields, though the only one I can think of is "Why do you want to subscribe?" in the case that it's a group-like-thing (for private feeds). > > b. >
