havenweb
TicketAuth support?
Hi, there's been some pretty great strides in support for IndieAuth Ticket Auth which is a simple mechanism for publishers to provide a bearer authentication token to clients (such as feed readers), which is significantly more secure than private per-user feeds. Are there any plans to support that on the reader and/or publisher side of Haven?
Getting more widespread adoption of this mechanism would be great.
I've definitely thought about IndieAuth-based approaches for several things and it's in my plan for further development. At the initial stage, I'd like to provide some level of compatibility with existing feed-readers, which brought me to http basic auth.
The link you shared highlighting the risks of Atom item sharing is new to me. Do you know anything else about this? From the article I can't tell if they are using a credential as a query/url parameter, or with HTTP Basic Auth. Haven uses basic auth. This means that feed credentials should obviously be credentials to any feed reader, but anytime you entrust credentials to third-party software you're taking a risk. Newsblur for example has a habit of assuming feeds are public and making them publicly visible as soon as 3 or more people are subscribed to the same feed.
Do you know of any feed readers (or feed publishers) that currently support TicketAuth for accessing private feeds?
I'm the author of that linked article. I was specifically speaking to the situation of using a private per-user feed, e.g. https://example.com/feed/327982acbaf38bf or the like; any tokens stored in the URL will be leaked if an item is shared in an Atom context (whether the item is private or not).
I don't know of any feed readers which support bearer tokens yet although there's a few IndieWeb folks working on them right now, such as omz13 and David Shanske, and I have plans to write one as well (although I haven't had the time/energy to actually start on it).
HTTP Basic Auth is an interesting approach. How well does that work with existing feed readers? I wasn't aware that there were any major aggregating readers that supported it, although I can see it working well with things like Firefox Live Bookmarks, and presumably Haven supports it as well. In any case I'd think that sending a stored bearer token shouldn't be terribly different than sending a stored basic auth string, and the only "hard" part about TicketAuth is supporting the ticket exchange itself.
And yeah the privacy implications of a shared feed subscription are pretty onerous, which is why I think that a reader with bearer token support needs to be built with that in mind from the ground up (which is absolutely what I'm planning if I ever get around to writing Subl). There's also some subtle implications on how WebSub works in an authenticated world, especially when using third-party hubs; basically you need the hub to support "thin pings" (which are technically not in the WebSub spec but I think most readers work with them anyway).
If you ever want to test implementing bearer token support, you could get one for my blog feed; my site has a user profile page where you can fetch one for manual inclusion, and then you can test bearer tokens without needing to implement the full TicketAuth flow.
Closing this. I'm sticking with RSS for broader compatibility for now but may explore TicketAuth at another point.
Except for my time!
On Tue, Dec 27, 2022, 11:59 AM fluffy @.***> wrote:
TicketAuth is an addition to RSS, not in opposition to it.
— Reply to this email directly, view it on GitHub https://github.com/havenweb/haven/issues/29#issuecomment-1366079376, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2DVLRWMLI4KS7CO5RRS4DWPMU7XANCNFSM5S7HMAJQ . You are receiving this because you modified the open/close state.Message ID: @.***>
Yes, totally understandable! It's just that the way you phrased the close message made it sound like RSS is different than TicketAuth, rather than TicketAuth being a means of providing authentication to RSS.