#dev 2020-11-19
2020-11-19 UTC
# 
@simonw Implementing IndieAuth for Datasette - inspired by a weekend spent at IndieWebCamp East Coast #indieweb https://simonwillison.net/2020/Nov/18/indieauth/ (twitter.com/_/status/1329223093311574017)
# @simonw ↩️ IndieAuth is essentially the spiritual successor to OpenID - it lets you use your own domain name to sign-in to services in a decentralized fashion
Since Datasette actively encourages deploying brand new web applications to new URLs on a whim, it's a great fir for authentication (twitter.com/_/status/1329232167851814912)
maxwelljoslyn, [tantek], nickodd, KartikPrabhu and [chrisaldrich] joined the channel
# 
@blaine ↩️ In the meantime, IndieAuth is, imho, a step backwards. OAuth/OIDC sign-in with login_hint works *great*; the lack of auto-/no-registration / a public key version is a real bummer, though. (twitter.com/_/status/1329271750924800000)
# @simonw ↩️ I'm intrigued by the IndieAuth thing where you can input a domain but your final identifier is a page specific to you on that domain - seems like it could help avoid users having to register their own domain or remember their full URL (twitter.com/_/status/1329272943474397184)
# @blaine ↩️ (specs exist, but no-one uses it; I really wish IndieAuth was something we could realistically add support for on e.g. Conde sites, but the "you must register your own domain" aspect makes it virtually impossible) (twitter.com/_/status/1329272420025339904)
# 
@aaronpk ↩️ This one I’m really confused on, and we should probably chat about it to clear things up. IMO OIDC is more of a barrier here because the default is that clients need to register. With IndieAuth there is no expectation of client registration at all. (twitter.com/_/status/1329277964400267265)
# @simonw ↩️ I thought that was valid with RelMeAuth but not IndieAuth - how can I get that working as an IndieAuth client? (twitter.com/_/status/1329277698569428992)
# @aaronpk ↩️ There is no obligation that you have to register your own domain for IndieAuth to work. I’ve talked about this at ActivityPub Conference showing how they can use IndieAuth to enable a standards-based app ecosystem for ActivityPub/Mastodon apps. That of course uses shared domains. (twitter.com/_/status/1329277462530772993)
# @aaronpk ↩️ so it turns out this works. I can type in “aaron@parecki.com” in an indieauth prompt and it works. because that is a URL. (twitter.com/_/status/1329277149975511041)
# @simonw ↩️ Thanks, filed an issue https://github.com/simonw/datasette-indieauth/issues/21 (twitter.com/_/status/1329279332607422464)
# @aaronpk ↩️ Email addresses *are* domain-based auth. I think you’re conflating two different parts of the system. In IndieAuth, the canonical user identifier doesn’t have to be the thing the user enters in a login prompt. This is also true for almost every other authentication system. (twitter.com/_/status/1329280422295977984)
treora joined the channel
# 
@ozaed ↩️ I use DNSSEC since 6+ years, while I have seen many auth protocols come and go. And 'IndieAuth' I first heard today. (twitter.com/_/status/1329303439722033154)
[tantek] joined the channel; nickodd left the channel
maxwelljoslyn, swentel, schmudde, jjuran, gxt, jeremych_, [Raphael_Luckom], geoffo, [tantek] and [Aaron_Klemm] joined the channel
# 
[Aaron_Klemm] He also said he's "pro IndiAuth" so there's a bit of talking out both sides of the mouth there
# [Raphael_Luckom] Does anyone have a good resource to share on strategies of content organization? Right now my hugo-generated blog has next post / previous post links on each post. That's cool, but what if I wanted to publish "list of posts with tag X"--when you go to those posts, should they still have previous / next links in the context of their chronological order? I'm sure there are some library-science-y practices for doing this, but I don't know
# [Raphael_Luckom] where to look for them.
# @simonw ↩️ This seems to contradict the spec - https://github.com/simonw/datasette-indieauth/issues/21#issuecomment-730485391 (twitter.com/_/status/1329460513588199424)
[KevinMarks] joined the channel
# 
[KevinMarks] I think a "next with this tag" could make sense, assuming that time ordering for them is clear, but if a post has multiple tags that's confusing. By default doesn't Hugo make you paginated list pages per tag, so you can have summary there ang click through?
# [Raphael_Luckom] Yeah, that's how it works, but I think that once you click through a tag-list link, you land on a post whose 'next' is not in the context of the list you clicked through--I think your idea of "next with this tag" is exactly what I was getting at--it seems like what I want, but it also seems like it would get confusing in exactly the way you described.
# sknebel I like how cweiske does it on his site, although it is a bit busy: https://cweiske.de/tagebuch/android-root-adb.htm
# 
@autiomaa Good article about the future of web authentication methods, together with implementation details.
"IndieAuth is a spiritual successor to OpenID, developed and maintained by the IndieWeb community and based on OAuth 2." (twitter.com/_/status/1329464376106119175)
# [Raphael_Luckom] Oh, with the sidebar that has a few different contexts, that's really cool, I might copy that
# 
petermolnar [Raphael_Luckom]: re content organisation: if I'm not mistaken we had a session where adactio (?) talked a bit about taxonomy, folksonomy, etc; the notes are on https://indieweb.org/2018/Berlin/datalake but they look a lot more vague than I remember. That, or it was another session.
# [Raphael_Luckom] cool thanks!
# [Raphael_Luckom] The links in that session got me to finally go read the 1945 essay "As We May Think" (https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/) and so far it's a banger
reed joined the channel
# 
Loqi Navigation refers to the UI, UX and markup allowing people to move around a website https://indieweb.org/navigation
# Loqi archive navigation is UI specifically for navigating archives, often organized by time period https://indieweb.org/archive_navigation
# [Raphael_Luckom] thanks, yeah that's it
# 
Zegnat [Simon_Willison] great point there on the spec maybe not clearly defining what would be accepted and what not for people to enter as a login URL. I have tried to capture the thoughts here: https://github.com/indieweb/indieauth/issues/65
[Murray], [chrisaldrich], [tw2113_Slack_], [Aaron_Klemm] and [Simon_Willison] joined the channel
# [Simon_Willison] Oh I think I've spotted a spec confusion: "The resulting profile URL MAY be different from the canonical profile URL as resolved by the client, but MUST be on the same domain." - that's a security issue right? The problem is that the final JSON returned by the profile URL response https://indieauth.spec.indieweb.org/#profile-url-response could have anything in the "me" field - it's up to my client implementation to verify that the "me"
# [Simon_Willison] URL is on the correct domain and reject it otherwise
# [Simon_Willison] I missed that subtlety (I think I assumed this MUST was a requirement for the auth server, not the client) which means I have a pretty nasty security hole in my implementation!
# [Simon_Willison] Would definitely benefit from the spec emphasizing that! Also, what does "MUST be on the same domain" mean?
# [Simon_Willison] Does that include sub domains?
# Loqi It looks like we don't have a page for "indieauth.rocks" yet. Would you like to create it? (Or just say "indieauth.rocks is ____", a sentence describing the term)
# [Simon_Willison] I had to figure out how to install Wordpress to help test my implement- thankfully that's only a few clicks on DigitalOcewn even if your PHP ecosystem knowledge is as rusty as mine
# [Simon_Willison] But... I had two bugs that showed up the moment other people tried it https://github.com/simonw/datasette-indieauth/commits/0.3.2
# [Simon_Willison] Question: “The resulting profile URL _MAY_ be different from the canonical profile URL as resolved by the client, but _MUST_ be on the same domain.” - what are the rules for “on the same domain”? Do I just need to look at the whole domain portion of the URL e.g. `www.example.com` or should I consider `foo.example.com` to be on the same domain as well?
# [Simon_Willison] found the answer: https://indieauth.spec.indieweb.org/#differing-user-profile-urls
# [Simon_Willison] it’s not 100% clear from that section if subdomains count as the “same domain” or not
# [Simon_Willison] I think there may be a need for new terminology in the spec: it talks about “User profile URLs” and “Client identifier URLs” - but there’s also the thing-that-the-use-typed-in-the-first-place - I’d been assuming that was the user profile URL but it’s not, for two reasons: 1. the final user profile URL may differ from what they typed in and 2. `foo@exmaple.com` is a valid initial input URL even though the rules for user pro
# [Simon_Willison] that the `username@` bit isn’t valid
# [Simon_Willison] Maybe the spec needs something like a “user input URL” to cover that?
# [Simon_Willison] so “same domain” does include subdomains yeah? Or is `example.com` the same domain as `foo.example.com` BUT `bar.example.com` is not the same domain as `foo.example.com`?
# [Simon_Willison] Also, does this mean that it wouldn’t be safe for me to deploy my own indentity provider implementation to Glitch since all Glitch apps share the same domain? If I deployed an identity provider at `simon-indieauth.glitch.me` then someone else could deploy `evil-indieauth.glitch.me` and return a `"me"` value of `simon-indieauth.glitch.me` from it, stealing my identity
# [Simon_Willison] Oh wow! That means implementations need to ship with a copy of the public suffix list
# [Simon_Willison] which is possible but definitely needs to be called out in the specification
# [Simon_Willison] I can use https://pypi.org/project/publicsuffix2/
# Loqi A subdomain typically refers to a domain with one more "name(dot)" component than that which someone actually has registered which is often seen indieweb sites with a family name domain like joel(dot)franusic(dot)com, or often on silos like matt(dot)wordpress(dot)com https://indieweb.org/subdomain
# Zegnat https://github.com/indieweb/indieauth/pull/56 removes the "MUST verify that the canonical profile URL is on the same domain"
# [Simon_Willison] This kind of thing needs to be really clear in the spec - we don’t want to fall into the same trap as JWT where the same security hole (alg=none) shows up in multiple implementations
[KevinMarks] joined the channel
# [Simon_Willison] I'm going to implement same domain including same subdomain first since that closes my security hole, I'll do subdomain matching later (once I understand the public suffix list issue)
# [KevinMarks] If we got, say, blogger to support indieauth, accepting [user].blogspot.com makes sense.
# Zegnat They too say to use the term origin for security: https://url.spec.whatwg.org/#warning-avoid-psl
schmudde joined the channel
# [Simon_Willison] I’ve released a security fix in 1.1, plus a GitHub security advisory warning against using version 1.0 https://github.com/simonw/datasette-indieauth/security/advisories/GHSA-mjcr-rqjg-rhg3
# @simonw ↩️ Spotted a critical security vulnerability it datasette-indieauth - I've shipped v1.1 with a fix and posted a security advisory to the repo on GitHub here https://github.com/simonw/datasette-indieauth/security/advisories/GHSA-mjcr-rqjg-rhg3 (twitter.com/_/status/1329530678443032577)
[Raphael_Luckom] joined the channel
# [Raphael_Luckom] This is very impressive incident response.
# [Simon_Willison] Another question… “It MUST follow any permanent redirections from this URL to discover the canonical profile URL, in the same manner as initial profile URL discovery.”
# [Simon_Willison] What about temporary redirects?
# [Simon_Willison] I’m currently planning to follow 301s (up to a limit of 5) but throw an error if I encounter a temporary redirect - is that the right thing to do?
# [Simon_Willison] that’s from https://indieauth.spec.indieweb.org/#differing-user-profile-urls
# [Simon_Willison] It refers back to https://indieauth.spec.indieweb.org/#discovery-by-clients which says:
# [Simon_Willison] not modify the canonical profile URL, nor do subsequent permanent redirects
# [Simon_Willison] > Clients _MUST_ follow HTTP redirects (up to a self-imposed limit). If one or more successive HTTP permanent redirects (HTTP 301 or 308) are encountered starting with the very first request, the client _MUST_ use the final permanent redirection’s target URL as the canonical profile URL. If any other redirection (such as HTTP 302, 303, or 307) is encountered, it must still be resolved for endpoint discovery, but this redirection does
# [Simon_Willison] Should I follow the exact same rules for verifying the “me” value at the end of the flow? The language there only mentions “permanent redirections” but then says “in the same manner as…”
rawtext joined the channel
# sknebel that was TODO to be changed after the session, cf https://indieweb.org/2020/Pop-ups/IndieAuth#Issue_53
# [KevinMarks] Is that making the 301 "cache the new" and 302 "cache the old" distinction? If so it may make sense to make that explicit.
# [Simon_Willison] so 302 and 301 should be treated the same?
# [Simon_Willison] That does simplify my implementation if I just need to follow-all-
# [Simon_Willison] follow-all-redirects and treat the final URL as the canonical URL
# [Simon_Willison] (The Python httpx library already throws an exception for me after a maximum number of redirects, which is good)
# [Simon_Willison] Aah OK, so my final step is “look at the `"me"` URL returned by the authorization server, fetch that URL, follow all redirects and confirm that it has the same `rel="authorization_server"` that I started with”
# [Simon_Willison] But I still need to differentiate between 301 and 302 in the code I’m writing that resolves the canonical URL for the user profile at the start of the flow?
# [Simon_Willison] The difference between temporary and permanent URLs is turning out to be the hardest part of the spec to implement - PCKE was actually pretty simply in comparison
# [Simon_Willison] thanks for the tips!
schmudde, [schmarty], geoffo and [chrisaldrich] joined the channel
# [Simon_Willison] New release with those changes - it now follows permanent/temporary redirects correctly and verifies that the `authorization_endpoint` from the final `me` value matches the endpoint from the start of the flow https://github.com/simonw/datasette-indieauth/releases/tag/1.2
# @simonw ↩️ Here's datasette-indieauth 1.2 with improvements to how the code follows and verifies redirects https://github.com/simonw/datasette-indieauth/releases/tag/1.2 (twitter.com/_/status/1329565075225526272)
[tantek] joined the channel
# [Simon_Willison] Had a thought about an IndieAuth test suite: turns out lots of my test code consists of mocked HTTP responses https://github.com/simonw/datasette-indieauth/blob/1.2/tests/test_indieauth.py
# [Simon_Willison] That way every implementation could share the same test suite - would make spinning up new correct implementations MASSIVELY easier
# [Simon_Willison] How about a language-agnostic IndieAuth test suite consisting of a folder full of mocked HTTP requests, maybe in JSON? Plus data showing the expected result for signing in with a specific me= URL?
# [Simon_Willison] I'd like an interactive tool too - but a static folder of mock requests is easier to integrate into CI
# [Simon_Willison] https://github.com/twitter/twitter-text/tree/master/conformance is an interesting example of a cross-language test suite, using YAML
geoffo joined the channel
geoffo joined the channel