Hi!
I’m very excited to see more RSS activity here. Podcasts are the clearest demostration of RSS’ potential, the one application domain that has remained largely unenclosed by miserable platforms because RSS’ flexibility enabled a more-than-good-enough, standard-ish approach, and no one has managed to embrace-extend-extinguish it, although it’s clear, as you point out, that several firms are trying to do so, using “premium” content as the hook.
RSS is a metadata format extraordinaire. All useful metadata related to items in a feed should find their way into an XML namespace and be provided within the feed via extensions. That certainly includes information about how to authenticate and become authorized to access linked resources.
An interesting choice implicit in your proposal is that the level at which you propose to require authorization is the item enclosure (or potentially some other resource linked within the item). The feed itself would be public, right?
An alternative approach might be to require authentication to access the feeds themselves. My only experience with “private” feeds has been Substack podcasts, where a basically permanent token is embedded in both the feed URL and enclosure links. Substack’s is a weak model from a security perspective. If the feed URL is shared so is the content. Perhaps Substack monitors for tokens that seem too promiscously used.
Your model is more ambitious, and could be much more attractive to creators hoping to sell access to their work. A public feed can itself be a kind of marketing funnel. Presumably people would marble free content with premium, to entice people to subscribe to the feed before they’re ready to pay for anything. Then premium items, podcast episodes, comics, would ever, would become ads for themselves inside the subscribed feed.
(People do this informally with “promos” and “teasers” already. Apple’s <itunes:episodeType>Trailer</itunes:episodeType> is a bit of existing, related metainformation.)
One really basic piece of metadata you might think about defining is just a tag to indicate whether linked or enclosed content is public or will require some kind of authorization. I would like it if my feed reader put a lock or something to signify links that are going to slam me into a paywall. Podcast clients also should be able to efficiently notify users of the availability status of whatever UI users are scrolling.
It looks like your JWTs would be rich enough to let feed readers and podcast clients know whether they are already authorized for particular items, so one might imagine clients maybe showing no lock for freely-available content, a closed lock for content requiring authorization not yet attained, and an open lock for content requiring authorization but already authorized. (I’m sure three are more beautiful ways to present these three status in clients, but just for example.)
In this model, only linked or enclosed resources could be premium, right? If, for example, you want full-content text to be premium, you’d not embed it in the feed at all, but make that an authenticated link. It might be worth thinking about whether there are ways you can extend this so, perhaps, a full content version of the feed itself is an authenticated resource. As an RSS text enthusiast, I really want my articles in my feed reader. That would also require coordination with clients, so for example users would first subscribe to a public feed without the fulltext resources, but could authenticate and then clients would automatic substitute the richer feed as their subscription.
It’s a very rich mine to vein!
I have mixed feelings about exclusive content in general. I’m a nineties information-wants-to-be-free guy, who understands that humans need to be paid, but still hates every paywall and wishes we’d come up with better models to support creative work.
But in the current, actual world, it’s much much better that there be a standard like the one that you propose than that creators and audiences migrate to proprietary infrastructures. So I think work like this could be a great addition to RSS.