There’s a proposal in the podcast namespace for an authorization tag and I think PowerPress, an existing WordPress plugin that facilitates podcast hosting, can implement the same authorization flow as a podcast hosting provider. The proposed authorization flow is described to work something like this when a service wants to confirm a user owns a podcast:
- Service reads an authorization url from the podcast’s rss feed
- Service generates a onetime token
- Service calls authorization url with token & rss feed as parameters
- Website hosting authorization url verifies it’s the home / host of the feed
- Website has user log in
- Website presents user a confirmation page
- If user confirms, website inserts the token into the
<podcast:txt>tag - Website publishes updated rss feed
- If website supports it, it sends a podping to notify watchers of the updated feed
- Website sends a success response if the feed is updated and a failure response otherwise
User interaction is done at this point. The service still needs to see the updated feed, but that is beyond the bits I want to talk about here.
This entire flow could be integrated into PowerPress and be completely transparent to the user who installs the plugin in WordPress. Nothing about this flow requires the user to configure anything they haven’t already configured if running PowerPress today because:
- PowerPress already knows what podcast(s) it is hosting
- PowerPress already manages xml tags within the rss feed for the podcast(s) it hosts
- WordPress already knows how to authenticate someone before allowing them to get to any administrative pages
- WordPress plugins have the ability to create new REST API endpoints (see the WP OAuth Server plugin for an example of this)
Given that to operate PowerPress a user must already know how to log into WordPress, this can be a seamless enhancement to PowerPress if it implements the following:
- a new REST API endpoint that would be called by the service mentioned above. It would need to receive and process the parameters defined in the podcast namespace’s specification.
- an administrative page that is presented as the confirmation dialogue. This page would have to process both an affirmative response and a disapproval response from the user
- the insertion of the provided token in the
<podcast:txt>tag - the sending of the success or failure response to the requesting service
Every other aspect of this flow already exists in PowerPress or WordPress itself.
If PowerPress adds this functionality, the user gains the ability to prove they own a podcast by doing nothing more than having an up-to-date PowerPress plugin installed, logging into WordPress, confirming they want to proceed, and waiting for the updated feed to be seen by the service.
I don’t think it can get much easier than that.
