2016-10-03 UTC
jungbin, timbl, shepazu_ and dan joined the channel
# 16:25 cwebber2 getting a little bit distracted by the intarwebs though # 16:26 cwebber2 has 3 more responses from wide review sent to private email or via xmpp to add to the document... # 16:27 cwebber2 the majority of responses seem to be "where's the cyrptographic integrity component / signatures" esp from people implementing existing federation systems, which is interesting to see # 16:28 cwebber2 but, since we can't specify auth, and thus can't normatively provide it # 16:28 cwebber2 at least it indicates that we can non-normatively suggest how it might be done # 16:29 aaronpk tho I feel like it should be possible to specify signing without auth # 16:30 aaronpk reviews the specific text in our charter about auth being out of scope # 16:32 aaronpk apparently that was not explicitly excluded in our charter, must have been in a meeting # 16:33 cwebber2 I loosely remember the first boston meeting and the SF meeting, though I could be wrong # 16:36 aaronpk anyway I do think verification is different than authentication # 16:39 cwebber2 aaronpk: verification feels like it is authentication, in that you're authenticating that the person who posted it is who they say they are # 16:39 cwebber2 but maybe it's a different authentication mechanism than login tantek joined the channel
# 16:39 aaronpk which is why i was trying to find the reasons we excluded authentication # 16:39 aaronpk authentication as a login mechanism is a different beast # 16:40 aaronpk i'm pretty sure we all agreed that coming up with a login mechanism was the thing that was out of scope # 16:40 cwebber2 aaronpk: well, it's *potentially* a different beast :) # 16:43 cwebber2 aaronpk: it's more likely a much more related beast if you're talking about authentication *between* servers and you use signatures for it # 16:43 cwebber2 as in, a user on server A is having its client authorized to post as itself, and presents that to server B # 16:44 cwebber2 but I suppose for client -> server on server A, the client would have either its own key or token anyway. # 16:44 Loqi [Aaron Parecki] First draft of Private Webmention sending # 16:45 cwebber2 aaronpk: ah, it's based on generating tokens for specific URLs? # 16:46 cwebber2 though, it will mean storing up a lot more tokens I guess # 16:46 aaronpk kind of. it actually leaves it open to the implemenation to decide whether to do it per URL or per domain or whatever # 16:46 aaronpk also if you use self-encoded tokens you don't even need to store them # 16:47 aaronpk basically it leaves open some interesting possibilities for implementation specific details like that, while still being specified enough to be interoperable # 16:56 tantek that's one of the most important balances to strike in writing a good spec / standard # 16:56 tantek (also really happy to see this discussion here between aaronpk cwebber2 ) # 16:56 Loqi aaronpk has 1111 karma (62 in this channel) # 16:58 aaronpk anyway it's interesting that that's the feedback you're getting! tantek and shepazu joined the channel
aaronpk so far my own implementation only failed one test ;-) https://aaronparecki.com/uploads/Screen-Shot-2016-10-03-09-25-13.png
@csarven @dret We are also referring to Accept-Post at https://www.w3.org/TR/ldn/ and wanted to double check. (twitter.com/_/status/782984099262763012)