<podcast:verifyOwnership> #534
Replies: 26 comments 62 replies
-
|
Why not use |
Beta Was this translation helpful? Give feedback.
-
If I understand this correctly, it does use Currently, without
|
Beta Was this translation helpful? Give feedback.
-
The @jamescridland yes! That's exactly the kind of flow you could create with this tag. This completely eliminates the need for the podcaster to add anything to their RSS feed and immediately provide authorization to any app seeking to verify ownership. |
Beta Was this translation helpful? Give feedback.
-
Some Security StuffAfter the host auths you, and you are redirected back, the site that receives you needs to do some kind of handshake with the host with a token from the redirect URL, right? Otherwise, this is easy to fake? Also, I think to avoid phishing or some other security problems, the host would have to have an allowlist of sites that the redirect can go to. Here's the attacking scenario: a) Bad guy wants to steal your podcast on listening app X that supports podcast:authorization Google, Stripe, etc, all have allow lists for domains and/or sites that the redirect can go to. I think hosts would have to do the same. This starts to increase the complexity of this then, where each host needs a list of approved apps. So I think the actual implementation of this is a little bit harder / more complicated than your description. It is, of course, doable! Separately, my personal viewThe problem that @jamescridland describes is more of a branding problem / the difference between a feature's name and how it's rendered in the feed. I feel 95% of the problem with podcast:txt would be standardizing the podcaster-facing name and the language we use around it. The average of times a podcaster connects their podcast to a new service is maybe < 20 over the lifetime of their podcast, probably much less. The pattern of 'enter a code' is a very common one for verification around the internet, and is simple for hosts and apps to implement. Apple, one of if not the largest apps, already uses this technique. I'd love to see more iteration on the existing solution vs. tossing it just yet. Just my 2 cents. |
Beta Was this translation helpful? Give feedback.
-
No I don't think because this is a one-time authorization. The only reason I can think of for a token would be if we wanted them to continue to make authorized requests.
I think 99% of the problem is complexity for the podcaster (and the podcast host) that significantly interrupts the flow of the podcast app that requires authorization. |
Beta Was this translation helpful? Give feedback.
-
|
As a podcast host. I fully support the removal of the email as it was used by bad actors aka Acast to spam hosts. Podcast:Txt seemed to be a simple solution at first glance but in practical terms it is a nightmare because it relies on the user to login to their host find the Podcast:txt field and then republish the RSS feed. This can take 5+ mins or more by which time they are bored or have gone onto another task. Tom's solution is simple and neat. We will try and test this with Buzzcast to see how it works. |
Beta Was this translation helpful? Give feedback.
-
This proposal doesn't address that, since Apple (for example) requires a correct email for |
Beta Was this translation helpful? Give feedback.
-
Apple no longer has this requirement. |
Beta Was this translation helpful? Give feedback.
-
I agree that an oauth-style flow would be a lot easier for the podcaster, for sure. I'm just not sure the juice is worth the squeeze -- would love to hear from more folks. Our customer bases likely have varying characteristics / struggles.
I could be wrong or missing something, but imagine this scenario:
I think for this transaction to be secure, there'd need to be some back end exchange between myplayer.com and mypodcasthost.com after the redirect, or some kind of signature in the redirect URL using a key that myplayer can authenticate. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Mike This is great you identified a security hole in this method of authorisation but do you have an alternative solution? After hosts started removing email from RSS it's become a total fuster cluck when trying to get podcasters to claim their shows. We desperately need a secure method like Oauth to get this process of claiming a podcast as automated and one-click as possible. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
I was just trying to be helpful by pointing out the security issues here; I don't have a lot of stake in this feature as I don't think it's as big of a problem as other folks seem to think. The two issues (domain whitelist and back end handshake) are both doable if you want to secure this idea. That essentially makes this an oAuth, and maybe that's fine? RedCircle doesn't plan on removing the email, and we're happy to implement txt with a better user facing name as well. A significant oAuth implementation probably wouldn't get near the top of our priority list, there's just too much to do and speeding up an already 'ok' email based flow just doesn't feel worth it to me. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Mike Many hosts have removed the email from the RSS feed. Yes they have added support for Podcast:Txt but podcasters either don't understand what to do or simply can't find where to find the podcast:txt field. A simple Oauth secure method would be awesome. It also would allow us to tag each podcast with the confirmed podcast host in our database. We also intended to split 1% of podcast transactions with the host. Sam |
Beta Was this translation helpful? Give feedback.
-
@tomrossi7, can you point me to a more current reference that confirms this? I'll happily remove it from my validator if there's a source I can cite. https://help.apple.com/itc/podcasts_connect/#/itcb54353390
@mkadin, I feel like you're right about the potential attack vector, and I wonder if this could be simplified even more to eliminate it. For example, it could work like:
Hosts could even auto-expire |
Beta Was this translation helpful? Give feedback.
-
|
I think I like this idea -- essentially the same as using podcast:txt to display the token. If we can think of a clean way for the feed to tell an app what URL to send the podcaster to within the host's UI, this could be pretty low friction. That said, we cache our feeds at the edge, and invalidate them when the feed is updated. The result is that it may take 1-2 minutes before a feed is updated. Not sure if other hosts might have that problem too. |
Beta Was this translation helpful? Give feedback.
-
|
@mkadin I think you are correct 😬. A nefarious actor could just monitor the requests and they would see the Okay, okay, okay. Here me out:
Idea 1 would work today and be pretty easy BUT I hate that you are waiting for the RSS feed to update. Thoughts? @CharlesWiltgen I don't know that Apple has formally communicated it anywhere, but many hosts (including Buzzsprout) have removed emails without any issues with Apple. |
Beta Was this translation helpful? Give feedback.
-
|
Is there any further thoughts on this proposal. I really want to implement this but don't want to waste my time if the proposal from (@tomrossi7) Tom Rossi is going to be changed. |
Beta Was this translation helpful? Give feedback.
-
|
This would be very helpful for companies like mine. Right now (with the 5 hosting providers who have removed email from RSS), we've written up training for podcasters to unhide their email temporarily so they can validate ownership of their podcast. ^ It's an extra step for the podcaster, which I always hate. With that said, I'm a HUGE fan of hiding email addresses in RSS. My hope is that every one of us does that. I'll say this in every post I do on here: But the less we can show in RSS, the better. I'd love one day for it to be nearly blank. Simplicity is the ultimate sophistication. |
Beta Was this translation helpful? Give feedback.
-
|
A cheaper/quicker way might be to have the option to leave off the OAuth entirely, and instead the UX goes like this...
Benefits of this are that it takes the podcaster to the page that she needs to add the code. If it's possible to add the code as well, that's probably good. Another potential benefit is that we could use an open database of podcast hosting companies, so doesn't require any work on the podcast hosting company side if they're truly lazy. If we know it's a Buzzsprout podcast, we know it won't deal with adding the auth code, so the UX would work like this:
And another potential benefit is that it could still work with an OAuth-like service if both sides want to code that. The podcast host might add a "type=oauth" flag in the tag maybe. |
Beta Was this translation helpful? Give feedback.
-
That's my advice as well. An OAuth flow makes a lot more complicated without commensurate benefits. All one has to do to verify ownership is to prove that one can make an agreed-upon change to the feed¹. If it's good enough to prove I control an entire domain, it's good enough to prove I control a file. ¹ What exactly that is doesn't matter much, but in addition to the option of requiring both parties to support a new element/attribute, you could even allow podcasters to temporarily add a challenge code anywhere in any required element. For example, they could append “(8d88311b)” to the title of their oldest episode just long enough to validate ownership. |
Beta Was this translation helpful? Give feedback.
-
👍 Having a fallback option that works for anyone is good thinking and often overlooked. My slight variation on this idea would be to add Whatever we adopt, I am fully in support of providing a fallback option for the majority of hosting platforms that do not yet implement our new standard. Remember, our goal is to let the podcaster prove that they are the owner of the feed, and we should definitely allow podcasters to prove themselves in whatever way THEY can, even if their current host doesn't support our new standard. If the host provides additional ways that are more streamlined, all the better. But at a minimum, this shouldn't absolutely depend on the host implementing new features. The |
Beta Was this translation helpful? Give feedback.
-
|
Here is my proposal. In the following example, we have a
<podcast:verify
verifyUrl="https://hostingcompany.com/verify/some-podcast-guid"
publicKey="my-public-key"
/>to Benefits
What do you think? Anything that I'm missing? Could this be made simpler? |
Beta Was this translation helpful? Give feedback.
-
|
I would recommend the public key of the podcast owner/creator be carried in a separate Roughly something like: <podcast:ownerIdentity
publicKey="MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAygB8Uk2NdMSQInDHIcNMw4VabaT..."
name="Dave Jones"
type="rsa2048"
/>
|
Beta Was this translation helpful? Give feedback.
-
|
Hi, Dave. Having the public key in a separate tag sounds good to me, though I don't think I understand the other use cases. E.g., what do you mean by "validation of the |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if we just need to suck it up and implement oauth? Otherwise every use case we come up with where we want to go through the podcast host to verify ownership will require a lot more specification? 🤷♂️ |
Beta Was this translation helpful? Give feedback.
-
|
That token could perhaps be the |
Beta Was this translation helpful? Give feedback.
-
|
OAuth would help ensure the But adapting as much as possible from what already exists out there (PKCE) might be useful in order to leave the possibility for Now, we could adopt steps 1–6 of PKCE, changing only two things:
In the future, we could have the option to include |
Beta Was this translation helpful? Give feedback.
-
I do this all the time with domains (a far higher-value asset) and it's really simple — no OAuth flows or public-key cryptography required. Proving ownership is trivially done by adding a challenge code to a feed you own. The party asking for proof knows it's you because you gave them the feed URL and they gave you the code, and so its existence in the feed proves ownership. Man-in-the-middle attacks can't work even if they get the code because you provided the feed URL, and only you can change your feed. I'm not a security expert and I'm happy to be educated. What am I missing? |
Beta Was this translation helpful? Give feedback.
-
Yes, that's the status quo—a lot of services, including Apple, already do that. Now, we even have a dedicated The point of this discussion is that this workflow is too messy and overall difficult for some users. You personally might have experience doing this kind of stuff with DNS records, etc., but that's far from all podcasters. |
Beta Was this translation helpful? Give feedback.
-
That's great! I didn't realize support for If that wasn't the case, my thought it would be straightforward to scan for it wherever it was easiest for the podcaster to temporarily add it — in // assumes XML has been parsed as a JSON object using something like fast-xml-parser
function scanForChallengeCode(obj: any, code: string): boolean {
for (const key in obj) {
if (typeof obj[key] === 'object' && obj[key] !== null) {
if (scanForChallengeCode(obj[key], code)) {
return true;
}
} else if (obj[key] === code) {
return true;
}
}
return false;
}
const hasChallengeCode = scanForChallengeCode(jsonObj, 'EXAMPLE-CHALLENGE-CODE');
console.log(hasChallengeCode); // true if the challenge code exists, false otherwiseIf OAuth works like I think it would, would using it require support in both whatever's generating the feed and whatever's validating ownership? I'm wondering how that would work for folks using SSGs, Blubrry PowerPress, etc. |
Beta Was this translation helpful? Give feedback.
-
|
I spoke with @tomrossi7 earlier tonight, and we kind of landed on the solution that @jamescridland proposed above - just having a simple authorization tag with a URL pointing to the hosting company. The app wanting to verify ownership would send a random string (of some specified constraints) as a parameter to that URL. The hosting company would then force a login by the user, and once complete, would just take that string and place it in the TXT record and republish the feed. The service requesting authorization would then poll the feed until it finds the token or a timeout period expires. The benefit of this flow is that it allows self hosted feeds to also easily comply with the authorization spec. The requesting app/platform can also show the token to the user when there is no authorization tag present which falls back to the manual editing behavior. There isn’t a way to avoid having to poll the feed for an authorization code if the service in question is going to support self hosted feeds. So, that code will have to be written regardless - it might as well be put to use all the way around. I really can’t find a flaw with this simple scenario. If we have missed something, please point it out. @jamescridland laid it out well in his posting above and is worth re-reading. One thing that I have been guilty of with this tag/spec is describing it as “authorization” which tends to lead towards credential acquisition, and thus to a solution like oAuth. But really, it’s just owner verification that is needed here, not credentialing or authorization in the technical sense. And we literally just got finished solving owner verification with the TXT tag so it makes perfect sense to use it. |
Beta Was this translation helpful? Give feedback.
-
I think that makes sense. The spec should spell out how to clean up after itself for sure.
OP has naming rights so you're good to go. Lol. |
Beta Was this translation helpful? Give feedback.
-
|
Another edge case the spec should probably consider is when a feed is verified with multiple services over the same period of time. The spec allows for multiple It would be nice to indicate which service the |
Beta Was this translation helpful? Give feedback.
-
FWIW, services will need to do that whether you give hosts the freedom to define their own challenge string or not. The spec could be ultra-prescriptive and require a specific format like " @ryan-lp, what is the thinking behind also making a |
Beta Was this translation helpful? Give feedback.
-
|
I think we keep it simple and avoid being overly prescriptive. Just let the platform choose their own unique string to insert into the TXT field and then they just verify that its there (which is what they are doing today). |
Beta Was this translation helpful? Give feedback.
-
Yes, I'm in agreement with that part, but I'm saying that "even though" there is no problem there, it will still be helpful to make it clearer which of multiple
I didn't suggest that, actually. The I agree that we don't need to specify a strict format, but as long as we are specifying a guideline to remove the tag after 24 hours, it would not be harmful to also provide a guideline to construct the I think we at least need some guidance here because here is how the tag is already being used in the real world (actual example): If multiple different service providers use a similar looking verification code, it would be very difficult for someone on a self-hosted feed to easily know which one to delete. Of course the above example has another problem in terms of security, as I don't think such a short verification code would provide much security for the feed owner, whether it's a short random number, or the database row id of the podcast. We don't really need a standard format, but just some guidance to pick a more easily identifiable value (whatever you choose), such as: |
Beta Was this translation helpful? Give feedback.
-
|
Sorry this isn't prettier 🤣. This could be really simple. @mkadin would you guys support it? Do you think others in the PSP would implement? 
|
Beta Was this translation helpful? Give feedback.
-
|
@tomrossi7, what problem does this solve that just watching for in-feed proof via a challenge token doesn't? (I still feel like I'm missing something, so I appreciate the patience.) With this method, it seems like ownership validation effectively requires permission/participation from a host. What happens if the host doesn't support it, or decides not to support it for certain 3rd-parties? What happens to feeds generated by SSGs, where the content is delivered by a static site generator, and there's no host endpoint to communicate with? That's not to say that "full duplex" ownership validation wouldn't have a place. One strategy from a standards POV would be to require "half duplex" validation (i.e. a unique challenge token in a designated feed element), then follow that with a recommended method for OAuth-based protocol when possible (assuming there are benefits to that). |
Beta Was this translation helpful? Give feedback.
-
|
I think what Tom proposes here is basically that. The only trick is that the host can have 'one-click' experience for adding the code to the feed. Tom, this gets around my security objection earlier. The backend handshake is basically happening via the feed. In general, RedCircle doesn't plan on removing the email, so this isn't as important to us. But if this becomes a thing that lots of apps and hosts are doing or planning to do, it seems simple to implement, we'd be down. |
Beta Was this translation helpful? Give feedback.
-
|
@CharlesWiltgen yeah, this is really to make it easier for podcasters to validate their feeds with 3rd parties. Rather than the podcaster having to go find the place to modify their feed and copy and paste in some token, they can just click a link. The field shouldn't be required by the spec, but a nicer way to verify ownership. |
Beta Was this translation helpful? Give feedback.
-
Okay, so the intent of this is to allow podcasters to validate ownership without changing the feed. Another way to put it is that it validates ownership via the service generating the feed instead of via the feed itself. (Let me know if I'm still not getting it.) I think that's great, but I strongly recommend that the spec also require dead-simple, "half duplex" feed-based ownership validation so that it's still useful for hosts or hosting methods that can't/won't support this, to support feeds generated by SSGs, etc. That way there's a universal method, plus a neato interactive method. |
Beta Was this translation helpful? Give feedback.
-
|
If the path forward is just a URL to automate filling in the TXT tag, do we really need a standalone tag for this? Any reason this shouldn’t be implemented as a new attribute on the TXT tag? |
Beta Was this translation helpful? Give feedback.
-
@ryan-lp If the verification URL is always in the RSS feed, that would allow
The use of a central database is for a fallback, and is not a "verification URL", merely a URL to point the user to the dashboard to make the change. Sadly, we could probably only link the user to the dashboard, rather than the place where you change the TXT value: here are example URLs that would be nice but won't work... https://dashboard.rss.com/podcasts/business-journal-spotlight/settings/ or https://www.buzzsprout.com/1538779/podcast/edit_advanced - in both examples, a central database wouldn't be able to know the internal ID portion of that URL. The best we could do is, in the above examples, link them to https://dashboard.rss.com/ and to https://www.buzzsprout.com/ (which automatically takes you to your dashboard when logged in). Does that help? |
Beta Was this translation helpful? Give feedback.
-
That was more a rhetorical question. The point being, we don't really want to temporarily add the verification URL to the feed in the same way that the verification token is temporarily added to the feed, and that is one of two reasons for why we really need a standalone tag for this (in answer to @nathangathright 's question above).
Ah, that's right. I had forgotten that detail, thanks. |
Beta Was this translation helpful? Give feedback.
-
Those are the same thing. The owner adds a single challenge code to validate that they own/control the feed. It can be anything that's uniquely (to avoid MITM attacks) provided to the person/org "claiming" the show — a unique UUID, a random sentence from Moby Dick, etc., and a URL if that's interesting. Supporting multiple authentication flows is no problem. Here's how it should be done according to the Podcasting 2.0 spec, which explicitly showcases the use of <channel>
<podcast:txt purpose="verify">podboogie.com confirmation #: S6lpp-7ZCn8-dZfGc-OoyaG</podcast:txt>
<podcast:txt purpose="verify">https://myFirstPodcastHost.com/login?redirect_uri=https://www.example.com/dashboard&response_type=code&client_id=123456&scope=owner</podcast:txt>
<podcast:txt purpose="verify">Super-Deluxue™ Hosting authentication code: “It is not down on any map; true places never are.”</podcast:txt>
</channel>The confirming service will just iterate through the |
Beta Was this translation helpful? Give feedback.
-
|
The detail I was overlooking was that |
Beta Was this translation helpful? Give feedback.
-
The verification URL and the verification code are two different things because they are provided by two different entities and at two different times, and are not in a 1-to-1 correspondence, so they can't both be put into a single tag as was being proposed in #534 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
As an App developer, I am pleased this new tag is being finally discussed. But one thing being overlooked is the user experience. So far I have heard about the user changing the TXT field and republishing with a podping update. Technically that this is not a problem but it's never going to work for 90% of users. Most users don't know how to change their DNS records etc. And unsurprisingly they don't know how to add their email back into their RSS feed. And in the same way, they won't know how to update the Podcast:Txt field. The user needs to know nothing other than their login and pwd. So in the RSS feed there is a new field Podcast:Verify or <Podcast: Txt> e.g <podcast:txt purpose="verify">ddlllvznnm</podcast:txt> . Podfans reads this field and adds a claim button with the URI and token back to the host. The user is asked to login to verify their credentials and then when proved a URI redirect is sent back to Podfans. This is one click and back like Oauth. This is a good user experience. The alternative of waiting for Podping and then we have to update the claim button to show verification might take over a minute. The other problem for Podfans is we can't send the email with instructions to access the podcast admin dashboard until we have verification. However if this works then this fixes another problem for app developers. It means we can also verify who the host is for the podcast. The iTunes:Generator field is a mess of data. Some people put in their host e.g Captivate and others put in their RSS generator e,g Podcast Index uses Sovereign Feeds while others put in random text. Knowing the podcast host will allow Podfans to make a 1% split back to the host for all the transactions for that verified podcast and any other podcasts that host verifies will also get a 1% split. |
Beta Was this translation helpful? Give feedback.
-
|
Again, a dumb question - but it's fine for the RSS feed to take a little time to change if it needs to. Just check that asychronously, surely? Use the token as a signal to continue with the claiming process, but the TXT record as the authority to claim. Here's Buzzsprout taking it's time to change an RSS feed... 
And here's a naughty, naughty hacker... 
|
Beta Was this translation helpful? Give feedback.
-
|
Yup! Just needs good UX where the podcaster can get to work on other stuff before verification delay. |
Beta Was this translation helpful? Give feedback.
-
It's not about the work. It's about having a single flow that works for all podcasters (hosted and non-hosted both). A podcaster that hand codes their feed or uses a wordpress plugin is not going to have the option for oAuth. And, I don't think we want multiple verification flows. @mkadin I don't understand your attack scenario here. How can this work if the token never shows up in the feed? |
Beta Was this translation helpful? Give feedback.
-
|
All good! I do think in the end, that a spec that allows for a few different types of verification is probably the right move in the long run though. The attack scenario I'm talking about is in response to @jamescridland 's "dumb question" up above, where he's asking about why the feed part is necessary. I agree it is! |
Beta Was this translation helpful? Give feedback.
-
|
@mkadin Ah, I see. Thanks for the explanation. |
Beta Was this translation helpful? Give feedback.
-
@samsethi, why is that? I was told by someone in the thread that
A feed owner has to add a challenge code (required to be an OAuth Authorization Server URL in the method you're prescribing) in either case, right? What makes it simpler for the feed owner to add that instead of a unique string? My 2¢: I'd suggest making it even simpler and recommending (vs. requiring) the use of |
Beta Was this translation helpful? Give feedback.
-
|
This is a messy rough-draft of the authorization tag write-up. Please look for glaring errors: https://github.com/Podcastindex-org/podcast-namespace/blob/phase-7/docs/1.0.md#authorization |
Beta Was this translation helpful? Give feedback.
-
I think it's unclear to use two different words "authorise" and "verify" interchangeably in a formal spec. I would stick to one term. Google calls this process feed verification, so for familiarity we can go with that.
If we care about some CDNs taking a significantly long time to purge a key from the cache, it may also be worth specifying a protocol bust the cache during verification: CloudFront has a page where they also suggest this approach since it allows for the cache to be invalidated IMMEDIATELY rather than in a couple of minutes (in the worst case): https://repost.aws/knowledge-center/cloudfront-serving-outdated-content-s3
So If podfans wants to poll in a way that temporarily bypasses any CDN delays, it might do something like this: where the query string is Note that this would only try to eliminate any delays caused by CDN cache invalidation, it does nothing for any other bottlenecks that may exist at the host. |
Beta Was this translation helpful? Give feedback.
-
|
Good stuff! A few notes / my thoughts:
Don't feel super strongly about any of the feedback, just chiming in! |
Beta Was this translation helpful? Give feedback.
-
|
So it's on the service to provide unique callback urls to support multiple outstanding requests? Or should the hosting company redirecting to the callback url tack on the token as a qp? Also there should be a callback on failure. If the hosting company does not recognize the feed (say it's for a show not longer on the platform, or the wrong hostname, or any feed it doesn't recognize), it should be able to communicate that back immediately, instead of the service having to wait around forever never getting callback |
Beta Was this translation helpful? Give feedback.
-
|
Also |
Beta Was this translation helpful? Give feedback.
-
|
I would drop the I do like @mkadin's idea for specifying a |
Beta Was this translation helpful? Give feedback.
-
@tomrossi7 Can we call this the |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, maybe even |
Beta Was this translation helpful? Give feedback.
-
I'm ok with a
Just habit. I don't trust people to know what is and is not good entropy. :-)
What is a good client side expire time in your opinion? |
Beta Was this translation helpful? Give feedback.
-
|
5 minutes is probably the upper bound for us, I think Tom said its his lower bound. I'd set it to like an hour? Because this is going to take some time, we should encourage the app to have UX where the user can accomplish stuff while the verification process is ongoing, as James suggested earlier. |
Beta Was this translation helpful? Give feedback.
-
|
My guess is that some hosts use a queued process to rebuild and upload RSS feeds which we need to wait for, followed by manual cache expiry. An hour seems a long time though. If the process on the podcast host's side is "add this TXT value and flag this RSS feed for immediate update" then is an hour really the timeout value? Could we not go for an expectation of 15 minutes or something? It should be no different to publishing a new episode. |
Beta Was this translation helpful? Give feedback.
-
|
Some feed changes would understandably be more expensive than others (particularly those working with the referenced audio file), but simply adding a TXT should be one of the fast ones. Then it would be solvable using a Priority Queue: |
Beta Was this translation helpful? Give feedback.
-
|
This tag should be deprecated as no one wants to implement it. I have tried for 2 years. We can use the TXT tag which many hosts support and add the purpose= verify field i.e remove from phase 7 |
Beta Was this translation helpful? Give feedback.
-
I propose we create a tag for podcast hosts to include an authorization_uri for authorizing ownership of a podcast.
Something like this:
Now anyone that ingests the RSS feed and wants to verify ownership, can pop a web browser to the authorization_uri. The request must include a redirect_uri (e.g. https://www.mypodcasthost.com/authorize/my/parameters?redirect_uri=https://myplayer.com/authorization). The host will receive the request and walk the podcaster through authorization. Once its completed, they redirect to the redirect_uri.
I'm not a mobile developer, but I believe this would work with Universal Links as the redirect_uri.
This is basically a dumbed down version of OAUTH, but would be simple and powerful.
Beta Was this translation helpful? Give feedback.
All reactions