This is a great idea to eventually remove emails from RSS feeds and create another way to claim ownership.
Another idea would be to use DNS TXT records and have that declared in the RSS feed? i.e.

<podcast:verify type="[recordType(string)]">[url(string)]</podcast:verify>

For instances:

<podcast:verify type="TXT">my-awesome-podcast.rss.com</podcast:verify>

I imagine TXT would be the main/ only record type that apps & services can check for their specific key-value pairs. TXT records are limited to 255 characters per string, but can have multiple strings per record, essentially grouping all verification values.

This adds complexity for hosting companies that are probably more accustomed to dealing with RSS feeds than DNS records. On the other hand, it avoids polluting the RSS feed with a bunch of data that doesn't serve listeners. Alternatively, hosts could get smart about when these tags are/ aren't included but that itself is complex.

We should keep this as simple as possible so I would exclude any DNS records manipulation (which also would not work at scale). The moment we add friction, we'll slow down or prevent the adoption across the industry.
Our proposal must be so simple and straightforward that it will give "no excuses" for anyone to ignore it. This includes major players in the industry who are also highly exposed to privacy regulations such as GDPR and CCPA.
A simple tag solves the problem and it is a low hanging fruit with minimal technical implementation and UI required.
This said, @Tombarr, you make a very good point about data pollution in the RSS feed. The implementation details have not been discussed yet, but the podcast:verify tag for a given service could be required only until the feed is successfully validated and then it could be optionally removed by the user. This would avoid permanent data in the RSS feeds that is not directly related to the podcast.
An alternative approach could be having only one instance of the podcast:verify tag that redirects to a JSON file containing the various verification codes instead. Something like:

<podcast:verify url="[url(string)]" />

where the URL referred in the attribute could look like this:

{
  "service": "Apple Podcasts",
  "token": "FB7AaST68NCEqx73",
},
{
  "service": "Google Podcasts",
  "token": "gf2qrzgQxVZq7UWU",
},
{
  "service": "Spotify",
  "token": "xtHz5jkVyjfc8Yvp",
}

This way the podcast hosting service would just need to change the content of url (i.e. a plain JSON file) and the RSS feeds would contain only one instance of the podcast:verify tag. Actually this approach would be even better, because the podcast host could put in place different caching rules for the RSS feed and the JSON verification file, so that the latter is not cached at all or its cache is immediately invalidated upon change and consequently the verification would occur in real-time!

Just thinking out of the box here. Feedback is more than welcome.

👍, especially the external file idea.

Question about lifetime: should be clear what it means when the token is removed for a given service. Does it mean the verification claim is no longer valid? If not, how would one revoke a previously verified claim?

"Our proposal must be so simple and straightforward that it will give "no excuses" for anyone to ignore it."

Yes, this. I agree. The simpler the better.

I'm grateful for your work here, Alberto - it's something that is very much needed.

@jamescridland proposed to use oAuth link to display a Claim button and allow podcasters to verify their RSS feed via their podcast hosting service. While this is a valid approach, it presents a certain degree of technical overhead for both the hosting provider and the podcasting apps, that would need to implement and maintain a new oAuth layer and new UI components (e.g. button, modal box / popup).

Actually, I didn't propose oAuth. I proposed something that was, in a nutshell... "prove you own the podcast by demonstrating your ability to log into your podcast hosting company and show you own it". There's no new UI components required here really - just the ability to demonstrate your ability to visit a page in your podcast hosting company behind an auth wall, and if successful, to send a token back again proving that.

Explicitly, my "token-Auth" proposal allowed, say, Podchaser to
a) know whether this method is supported by the podcast host
b) give the user a clear button direct to their podcast host to obtain authorisation

The above podcast:verify proposal, on the other hand, doesn't allow Podchaser to know whether the podcast host supports podcast:verify, and doesn't help the user know where to go next to continue with the claiming process, since it has no signin URL for the user journey.

User-flow for a token-auth service when logged-in to the podcast host:

• (Podchaser) Thanks for wanting to claim AmazingPodcast! [Visit Buzzsprout, your host] to approve this request.
  -click-
• (Buzzsprout) Podchaser wants to check you own AmazingPodcast so you can claim it on their website. This OK? [Yes]
  -click-
• (Podchaser) Thanks for approving it! Claimed!

User-flow for a token-auth service when not logged-in to the podcast host:

• (Podchaser) Thanks for wanting to claim AmazingPodcast! [Visit Buzzsprout, your host] to approve this request.
  -click-
• (Buzzsprout) You need to log in to do this [username] [password] [go]
  -logs in-
• (Buzzsprout) Podchaser wants to check you own AmazingPodcast so you can claim it on their website. This OK? [Yes]
  -click-
• (Podchaser) Thanks for approving it! Claimed!

User-flow for this service:

• (Podchaser) Thanks for wanting to claim AmazingPodcast! You need to add this token '5d5d4a5s' and a token title 'Podchaser'. Look for something in your podcast host marked "Verification" in your dashboard.
  -there's nowhere to click-
• User remembers their podcast host, goes to log in, looks for verification data, copies and pastes it over
  -there isn't a journey back so nowhere to click-
• User goes back to Podchaser somewhere and hopefully hasn't lost the session details and tells Podchaser that it's been updated

It would strike me that a two-button tokenAuth press is markedly simpler for the user than copying/pasting tokens into RSS feeds (and amending core code libraries to fiddle with RSS feeds). I'd add that it offers less support overhead, and will result in significantly fewer abandoned carts. If the issue is "how do we send a token over the internet in a secure way" then I'd hope there's prior art we can learn from here. But I'd suggest keeping clear of the RSS feed aids simplicity here.

Is there a way we can clarify the user-flow here?

@jamescridland thank you for elaborating your token-Auth proposal with further details, examples and clear use cases.
The main takeaway is that the token-Auth approach you propose would offer a better UX for the the user (i.e. the podcaster) compared to the verification-tag approach. I agree. The main reason for a better UX of token-Auth is that the end user effectively would see one button to claim their show and they would just need to log into their podcast host. All the rest, all "the magic", would happen behind the scenes.
On the other end, the verification-tag approach would require the user to log into their podcast host, find where the verification option is, manually copy-paste a token, then go back to the original app requesting verification.
Building technology and products today has the ultimate goal of making people's life simpler. UX should be at the heart of every solution and according to this criterium token-Auth is the clear winner here.

However, other factors come into play such as the complexity of implementation, interdependencies and likeliness of adoption.
To state the obvious, it is in nobody's interest to design a solution with the best UX that ends up not being broadly adopted because of the underlying complexity, and I have a feeling that token-Auth approach may end up in this bucket.

What happens behind the scenes in the token-Auth approach can be oAuth itself, or something very close to it:

• (Podchaser) Thanks for wanting to claim AmazingPodcast! [Visit RSS.com, your host] to approve this request.
  -click-
• (RSS.com) You need to log in to do this [username] [password] [go] -logs in- /// SKIP this step if already logged in
• (RSS.com) Podchaser wants to check you own AmazingPodcast so you can claim it on their website. This OK? [Yes]
  -click-
• [HERE BE DRAGONS 🐉 ]
• (Podchaser) Thanks for approving it! Claimed!

A closer look to [HERE BE DRAGONS 🐉 ]:
In the token-Auth approach, a web view opened by a third party app would not (and should never) share data such as cookies or tokens. From the technical standpoint, what needs to happen here is some form of callback to send a response to the app originating the request. This response needs to be then verified as trusted and valid. This can be achieved:

• a) using oAuth: the app originating the request and receiving a response token then sends an oAuth request to the podcast host using the token received to validate it OR
• b) via a request to a RESTful endpoint specifically created by the podcast host: the app originating the request and receiving a response token then sends a new request to the podcast host via an API endpoint with a payload including the token previously received. The endpoint would then return a status such as 200 or 403 that can be used to validate the token.

The aforementioned flow for the token-Auth approach presents a number of drawbacks, including (but not limited to):

• Interdependencies in implementation across podcast apps, directories and hosts (e.g. definition of and adherence to common standards and guidelines)
• Critical security challenges:
  • A malicious podcast app requesting the verification via token-Auth could easily replace the host web view with a copy. Phishing the podcast login and password would become very common. Once you gain access to the host, you gain full control of a show. A malicious app successfully phishing credentials would be able to programmatically publish spam episodes or alter existing episodes and distribute them everywhere via the RSS feed. This behavior would be very hard to detect by the podcast host;
  • Changes in origin control. The login screen of any modern podcast host (with the minimum viable compliance to security standards) controls for requests origin. Allowing a login page to be displayed in a web view by a third party means making the origin control less strict. Man-in-the-middle attacks to intercept and store the podcast host credentials would be easy to perform.

The technical implementation of the token-Auth approach would require 10X efforts (ballpark), as well as overhead for maintenance and observability due to the complexity of the system.
The technical implementation of a verification-tag approach, on the other end, would take only a few hours (at RSS.com, we estimated 6 person-hours in total for the end-to-end implementation, testing and release of this feature).
For instance, if I wear the hat of the Product Manager at RSS.com, the token-Auth approach would be an "Epic" that I would add to my long list of tasks to build at a future time, whereas the verification-tag would be a simple user story and a low hanging fruit that I could "squeeze" into any given development sprint with very little overhead.

The end-user UX for token-Auth is superior and this is what makes the proposal so appealing in the first place. The verification-tag UX flow is not as clean as the token-Auth flow and it does require some degree of extra support from the podcast host to make it clear to the user where the verification setting is and where to paste the token.
However, the potential cybersecurity issues that the token-Auth may create, would require podcaster education about "podcast phishing" and how to prevent it (a problem that we barely have nowadays).

Last but not least, the token-Auth approach requires all the industry align and to move together towards the same goal, to adopt the same methods and standards. In an ideal world, even if the intent and appetite from everyone in the industry was there, the execution times would take too long. Having worked in tech in a large multinational corporation and dealt with their internal processes (including compliance), I cannot imagine large companies acting quickly on this.

On the other hand, adding an extra tag in RSS feeds according to the verification-tag approach would not require full alignment in the industry, but it will force everyone to eventually switch to the new method mainly because of compliance requirements.
In an initial phase, the <podcast:verify> tag would coexist with the <itunes:email> tag. However, by adding a viable alternative to the <itunes:email> tag, we would effectively create a solution that would expose everyone in the podcasting industry (nobody excluded) to potential GDPR, CCPA & data privacy lawsuits because of the presence of email addresses in RSS Feeds. These lawsuits will be most likely successful given the existence of a viable alternative to verify a podcast (aka the <podcast:verify> tag), hence creating precedents that will encourage everyone else, especially large multinational organizations that are more exposed to this kind of scrutiny, to quickly adopt the new alternative solution. I bet that those very people in charge of data privacy and compliance that so often slow down processes in technical departments of large companies will be the first ones to encourage their tech departments to adopt the verification tag and remove email addresses from RSS feeds.

For all the aforementioned reasons, when balancing between UX, technical complexity and likeliness of adoption, I believe that the <podcast:verify> approach has more chances to achieve our ultimate goal of removing personal data from RSS feeds.

My prediction is that:

• In the "best case scenario", more and more organizations will adopt the Podcasting 2.0 namespace and use <podcast:verify> tag as the claiming method for podcasters to verify ownership of their shows.
• in the "worst case scenario", some large organizations will adopt their own version of the <podcast:verify> tag (e.g. <itunes:verify>) which will make the <itunes:email> tag obsolete in any case, thus effectively solving the current challenge of public email addresses in RSS feeds.
  Not a bad outcome either way!

I think we should put this in phase 5 if we can settle on a format in a reasonable amount of time. I think I agree with @albertobeta here that while the oAuth style handshake is a better user experience, the back end complexity is sufficient enough to make it a hurdle for hosting companies to adopt.

I think it would be a real shame if a proprietary thing came about. So, we could always formalize both and incorporate a version attribute that tells which method to use. Version 1 could be a token based approach and version 2 could be the full oAuth handshake.

Just brainstorming here.

I had suggested something like a verify/claim tag in February, so I suggest considering some of the responses to that.

Let's try to reheat this, because it's important.

I really, really don't like the idea of telling a customer to copy/paste a token into RSS. We've got to do better than this.

How about this user-journey for a customer on Libsyn to claim their podcast on Spotify?

The (Libsyn) podcast RSS feed advertises that it supports QuickVerify, and where to send the user.

<podcast:verify authUri="https://libsyn.com/my-account/verify?token=" authName="Libsyn"></podcast:verify>

Spotify sees this code and adjusts its claim process to be...

• To claim My Amazing Podcast visit your podcast host, [Libsyn], and give us permission: click here [authUri + "2y4f2j5"]

The link is https://libsyn.com/my-account/verify?token=2y4f2j5&name=Spotify&back=https://spotify.com/continue-claiming (the token, a friendly name for Libsyn's UI, and where the customer should be taken after verification).

The user clicks the link

(The user might need to log into Libsyn)

The user agrees with Libsyn that Spotify can claim this podcast.

Libsyn amends the RSS feed for this podcast to read
<podcast:verify authUri="https://libsyn.com/my-account/verify?token=" authName="Libsyn">2y4f2j5</podcast:verify>

... and takes the user to the "back" URL to continue the claim process.

Spotify refreshes the RSS feed to see if it can see its token in there

if the token is visible, THEN the user has shown that they own the podcast, and the claim is successful.

The token is removed after 24 hours or if the user requests another claim from someone else. There is no requirement for this token to be visible longer than that; and no requirement (that I can see) that would require multiple tokens being visible at one time.

Essentially, the same as "copy this code into this RSS feed", but we've given Spotify (in this case) both a URI and a friendly name to help this be programmatically added from their UI.

In an initial phase, the podcast:verify tag would coexist with the itunes:email tag.

There's no privacy benefit from doing this. But I see the benefit of a fallback. So, instead, how about...

• if <podcast:verify> is supported, then <itunes:email> is automatically removed from the RSS feed. For backwards compatibility, a user may be given the option to make <itunes:email> visible for up to 1 hour, on-demand, by their podcast host.

That's not brilliant, but it does mean that most of the time, an RSS feed won't contain any email address in it at all.

(If a podcast host doesn't give an authUri in their <podcast:verify> tag, then Spotify could either a) retreat to the email-based verification; or b) give UX asking for their token to be added.

Hi all,

I think before moving anything further, maybe we could take another look at #342 which is the same purpose and where I already detailled how this could be implemented easily on hosting providers, in a secure way, without emails, and without requiring to modify feeds for every requests.

Thanks ! 😃

The comment related to @PofMagicfingers suggestion is at #342 (comment)

I’m going to write up a placeholder for the verify tag in Phase 6 and link it to this issue. That’ll at least give us a place to start. @PofMagicfingers, your flow in #342 is well described. We could sandbox this on the Podcastindex.org site for a couple of test feeds. All I ask is we avoid oAuth. It’s just overkill IMO.

All I ask is we avoid oAuth. It’s just overkill IMO.

Yes that's what my comment and flow proposal is about : mimicking oauth, with reasonable security, without the hassle of oauth : no registered apps, no timed or specific tokens etc, only a pub/priv key system, using well known jwt technology, to authenticate the approval

@PofMagicfingers I'm converting your proposal from #342 into a standalone doc. I'll link it here and we can use this issue as the main discussion thread for verify.

I can see pros and cons of adding the authorization framework to either podcast:locked or podcast:guid. They both have their advantages and their problems. I think it ultimately makes the most sense as a standalone tag (podcast:verify). We can always extend the schema of podcast:locked, but the core of that tag is the presence of an email address attribute which is the very thing we are trying to get rid of. I'd rather have podcast:verify, which could actually be multi-use and just have the lock tag remain as as-is for a fall-back and update the wording to have it reference the verify tag if present.

When I say "multi-use" I mean it could also serve as the base tag for open subscriptions as well, which this handshake you've described works well for. The consumer would just be a podcast app instead of a platform or service.

I'm going to "send a pencil with the astronauts" on this one.

Why not simply encourage podcasters to put a non-personal email address in the RSS feed?

I'm going to "send a pencil with the astronauts" on this one.

Why not simply encourage podcasters to put a non-personal email address in the RSS feed?

I think the short answer would be "because they won't (or don't know how to) do that."

Personally, I'm not that bothered by emails being public because let's face it, all of our email addresses have been (and will be) breached/exposed over and over and over again. The horse is out of the barn on that front. The main advantage I see here is it's an easier experience. It all stays in the app (webview) and nobody has to fiddle with emails.

Thank you for the proposal, @daveajones

I think the example of the podcast:lock tag to the top adds some complication - "but isn't this proposal supposed to remove email addresses? why is there an email address in it?"

I'd much rather see this as a different tag. Or - I'd much rather deprecate the podcast:lock email functionality completely with this upgrade. This replaces the email functionality completely (and makes it much faster and less prone to problems).

Same. I agree on those points. If it’s a new tag we just deprecate the lock tag. Nice and easy.

@PofMagicfingers Do you want to work on this with me? I'd like to build a proof of concept to show it working. I can add the consumer side support podcasterwallet.com if you can add the hosting side support to Podcloud. If you don't want to that's fine. I just thought it might be fun to collaborate.

@daveajones why not, but I would not be able to look into it before September. I'm pretty busy at the moment 😶

@daveajones why not, but I would not be able to look into it before September. I'm pretty busy at the moment 😶

Nice! Created a discussion and project for it.

I'll go ahead and start building the consumer side and you can do the host side whenever you get time.

I love the idea of simplifying the verification process and protecting privacy. It's just that we're building a solution than will never fully accomplish that.

Until every app supports the new verify method, an email address will always be needed in the RSS feed. Sure, hosting providers could make a temporary toggle for verification purposes, but that seems to be overcomplicating the process for everyone.

I just don't see how this tag can actually succeed at its purpose.

@theDanielJLewis It's regrettable that you feel the need to spend time criticising and posting negativity. Just waving your hands around and suggesting it can't be done so we should all stop wasting our time is deeply unhelpful.

My suggestion here is that when a podcast hosting company adds support for the sign-in bit of podcast:verify, they also add a toggle to remove the itunes:email tag from their RSS feeds. If you are using an old service that doesn't support podcast:verify, you can toggle the itunes:email tag to make it appear on demand (ideally for a limited time).

If that seems sensible to suggest, I'd be happy to add it to the proposal; or perhaps DJL can shoot this idea down as well.

@theDanielJLewis It's regrettable that you feel the need to spend time criticising and posting negativity. Just waving your hands around and suggesting it can't be done so we should all stop wasting our time is deeply unhelpful.

My apologies, @jamescridland, that's not how I wanted to come across. So let me try communicating it this way:

I have these concerns; how can we address them for the best reception and implementation of this good idea?

@daveajones I'd love to see the simplest version of this implemented, especially with Apple's looming deprecation of <itunes:email>.

For our users, the most user-friendly approach is to give podcasters a "Verification code" field in the UI of their podcast hosting provider:

I have Apple Podcasts people who've told me:

if there was a plain text field (like DNS offers) for anyone to put any text and validate it then we would look to using it for the verification. Otherwise, the current process we have now with <itunes:keywords> or <copyright> tag is the process.

If this version existed, Transistor would support it immediately:

<podcast:verify service="Transistor">FB7AaST68NCEqx73</podcast:verify>

Future iterations could include auth URLs, etc., but in the absence of a simple, plain-text field for validation, podcasters are going to have to continue to put codes in <itunes:keywords> or <copyright>

That verify method is very similar to one of the multiple ways you can verify ownership of a site with some kind of meta tag in the HTML (in addition to DNS). So it's not radically different.

@daveajones I'd love to see the simplest version of this implemented, especially with Apple's looming deprecation of <itunes:email>.

This is a common sense idea Justin. It solves an immediate need in a clear way and doesn’t impede the tag from expanding to a more robust mechanism in the future as we work out the other part.

I’m going to open up phase 6 this week so I’ll put this in there as you’ve written it.

I'm closing this, since podcast:txt offers verification.