Private webhooks, hold the crypto?

I was hoping to say “I was going to write about Martin's dialback system but Blaine Cook saved me the trouble!” but Blaine's system, with his goal of being crypto-free, is simpler. (At least if you ignore the use of webfinger, which I will for right now.)

As discussed in that WTF post (if you can wade through it), you need a way to authenticate the subscription request, to tell by which person owns it what posts you trust to that subscription. While I was thinking of something like OAuth, Blaine's suggestion seems to be:

• Identify the person in the subscription request.
• Discover that person's profile and find (what he calls) their “delegate” URL.
• Confirm that the subscription's callback URL is the person's delegate URL.

Blaine suggests using the HTTP From header to identify the subscribing person. (I'm not sure why that particular slide calls it “pseudocode,” but this “Addressing Identity on the Web” brief of Blaine's for an Internet privacy workshop this past December says plainly what he means.) The value of the From header is supposed to be an email address, so using it here would mandate the use of webfinger (that is, LRDD+XRD) and email address-shaped identifiers. I think that's a curious requirement to make, as the rest of this system would work just as well with an X-From-URI header and HTML link discovery (or, sure, webfinger if acct: URIs should be supported).

Seems like this “delegate” endpoint is like the activity sink I was describing: a person's PubSubHubbub endpoint where any activity they've subscribed to can be pushed. It would indeed be simpler not to have to authenticate with OAuth to it, instead using the PubSubHubbub secret as equivalent to a bearer token.

However, that also means you couldn't post activities there without having been subscribed to, so you couldn't send third-party activity such as mentions there. If Alice doesn't subscribe to Carol, Carol has no PSHB secret from Alice, so Alice can't verify that a mention from Carol is from Carol. If Alice needed to dial back to verify Carol's request, the equivalent to checking that the callback URL matched would be verifying the existence of the post containing the mention, which would require Carol's post be in a feed discoverable from Carol's profile. That's pretty particular to mentions, so other types of activity may have wildly varying verification steps.

Rather than have one-off verifications for each kind of activity, it might be easier to provide a generalized step where Carol can associate with Alice, receive an OAuth token from her, and then use the token to authenticate any activity sent to Alice's activity sink in a general way. (This is the OAuth dial-back mechanism I wanted to avoid describing, and I realize full well I still haven't described it adequately here.)

Anyway, if there's no other reason to have an OAuth token, seems to me right now in my sleepless state that this identify-and-verify step would work fine for regular subscriptions as Blaine describes. Unfortunately, an OStatus style network seems to have another reason.

Comments

[Misuba]

Do you know of any projects that are developing these ideas further?

[markpasc]

Hi, Misuba! I haven't followed if Blaine or someone else is doing something with it. I'm working on a project that does some of this (well, more the stuff from the other “WTF” post) but haven't published any code yet.