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? b.
