[tantek]aaronpk, how would you answer this question? What's a good estimate of the size of the end user population for IndieAuth IDP’s? (I'm thinking roughly micro.blog users + Known users + WordPress IndieAuth plugin installs?)
LoqiIt looks like we don't have a page for "identity provider" yet. Would you like to create it? (Or just say "identity provider is ____", a sentence describing the term)
aaronpkhis diagram of the number of IdPs vs RPs vs Users still holds in the IndieAuth model, although it's more like IdP software rather than IdPs, and more like O(100) instead of O(10)
aaronpkrather than think about it as "but what about IndieAuth", it's more helpful to think about the underlying problem IndieAuth is solving and make sure that this new thing can also solve that
aaronpkif the browser can participate in the flow as a first-class citizen, then the whole step of the website showing a URL field to ask the user to enter their URL goes away and it can happen automatically
aaronpkideally I'd like the WebID API to not make the assumption that the RP will be deciding the provider ahead of time, and provide a mechanism for the user to establish one or more IdPs with the browser directly, so that the RP can ask the browser to "just authenticate the user somehow please"
aaronpkI say it this way because I know that there's no point in arguing things like "user IDs must be URLs" since that is a pointless battle that we will not win
aaronpkfor example some apps will want to limit the IdPs they trust for various reasons. so it should be possible for an app to say "i want the user to log in with any of these providers: google, apple, twitter"
[tantek]I'll leave it to aaronpk if he wants to click the links above and add IndieWeb-specific definitions with references to IndieAuth and common services / implications
GWGThe biggest issue I see for me getting more adoption on my IndieAuth implementation isn't an IndieAuth issue...so many people are blocking auth headers.
@kixiQu↩️ are responses a la webmentions necessarily "post"-type content rather than page-type? but then isn't the point of the web non linear asynchrony? (twitter.com/_/status/1283209411859640323)
[fluffy]The WebID discussion reminded me of the current gap in the IndieAuth spec that I wanted to see addressed. I finally responded to the most recent comment on it, both with why I don’t think why the query parameters need to be handled, and with an actual in-the-wild example of how it’s a problem. https://github.com/indieweb/indieauth/issues/35
[fluffy]I see it as a flaw though. There are a lot of people who don’t want to get their own domain, and who might want to participate in the indieweb from a site like tilde.club.
[fluffy]Obviously it’s less of a concern for most things like Mastodon or whatever where there’s a single authority for the entire domain, but tilde.club or academic homepages or whatever deserve to be part of the indieweb too.
nekr0z[fluffy]: isn't the cornerstone and the proper ID for IndieWeb the personal domain, though? I mean, the first thing the Getting Started wiki page says is 'get your own domain'.
vilhalmereven if you pointed it at wordpress or something else at least it would offer a more or less permanent identity against potential hosting changes
superkuhThe way I do webmentions can accept from .onion for my .onion(s). But that's because I cheat and just log POST, remove any that dupe 3 times, and then read manually with eyes in a text editor.
[fluffy]tumblr’s templating is flexible enough that I bet one could do a fully indieweb thing on it too. I mean, assuming external endpoints, of course.
[fluffy]yeah, like, I absolutely agree with the ideal world where everyone owns their own Internet presence but that’s a long ways off, and there’s also aesthetic reasons why people might want to be on a shared domain without a shared underlying platform. (like, again, tilde.club)
[fluffy]anyway at least this discussion led to a simpler-to=implement-and-codify possible solution. Inspired by your token_endpoint observation! jacky++
[KevinMarks]Sgnodemapper was a superset of this idea where the structure of each silo's user urls was described. (it also dealt with the id vs name mapping)
ZegnatSince the conception of IndieAuth, I have run it for a path rather than a domain (vanderven.se/martijn/) and even hosted the endpoint under that path and not on the main domain. Nothing is stopping you from doing that.
ZegnatI think the way IndieAuth puts the line at domain is correct, because it makes it clear that the domain owner is still the one with final control. They could easily interject and “MITM” your endpoint if you host it on a path.
ZegnatI think just writing in the spec that IndieAuth needs to be path based might give people the wrong impression of how the web is actually protecting them.
ZegnatTrue. But is that a problem? The domain owner can also pretend to be any path owner, right? I think it is good to make clear to people that paths are not actually selfcontained.
sknebelyes, the domain owner can pretend to be any path owner. but in a bunch of scenarios (i.e. the ones fluffy listed) the relationship between domain owner and path owner is different from the relationship between individual path owners
sknebelI'm not saying IndieAuh necessarily *has to* handle that, but it's IMHO not a foregone conclusion, feels kinda like an artificial restriction and not what my mental model of it was
ZegnatI guess my take was always that nothing in IndieAuth is stopping you from using paths, but IndieAuth makes it pretty clear that in the end the domain owner is in control. Which is correct.
ZegnatSo I guess the argument is: we agree the domain owner is always in control. But even with that, we may still want different path owners to be separated?
[manton]GWG: 🙂 I just reviewed the dozen proposals that you linked from the pop-up description and added a few more comments on GitHub. There are a few proposals that I’m really interested in “finalizing” as much as possible, because I’ve implemented them in the “2.0" versions of the Micro.blog apps, which will ship in 1-2 months. After the apps ship, it will suck to change the implementation.
GWG[manton]: Add them in...the list I added was based on whether it seemed we could get through them quickly or they needed work but seemed to have interest...so the list is up for debate.
[manton]I’m also going to be documenting everything Micro.blog supports with examples, so that it’s easier to get a sense of the scope of the various parts of the API, in one place.
[fluffy]Insisting that the domain owner be in control of all things IndieAuth has a rather alarming set of side effects. Like, that implies that on shared-domain static hosting, it’s up to the domain owner to select a specific IndieAuth endpoint and inject the headers/link tags into all pages being served up, or to actively filter out such things from hosted content if they don’t want to take the responsibility.
[fluffy]Again, tilde.club is my go-to example of this. It is a static-hosting dumping ground. The folks who run it very specifically do not want to insist on a particular “stack” for member pages to run, and I doubt they’d have any interest in managing anything IndieAuth-related.
[fluffy]Like, sure, the domain owner CAN be in control, but that’s putting a lot of burden on the domain owner, when all they’re trying to do is offer a nice place for people to have an old-school ~username website.
ZegnatBut they are? The domain owner picks the server it points at, and at that server they run the software they chose, and that software can MITM anything anyone else is doing.
ZegnatMy point is not that a domain owner is going to take control, my point is that control starts with them and they can give it to others, but they can at any point take back that control.
[fluffy]As it stands, tilde.club is not doing anything to rewrite members’ HTML files. Anyone can declare an IndieAuth endpoint. And that endpoint has no guarantees of being legitimate.
[fluffy]tilde.club has no official indieauth support, and they aren’t in the situation that they’re going to provide it. But people on tilde.club might want to join in on the indieweb, which means using indieauth.
ZegnatMaybe. I kind of like it because it makes it clear in the spec that domain level is how things are segregated on the web. Not saying there is no reason for IndieAuth to segregate on path. But then I would like to see a big warning somewhere to inform people that as soon as the owner of one path-level up decides to do so, they can hijack your auth.
[fluffy]Any given tilde.club user might, for example, use RelMeAuth along with indielogin.com as their endpoint, not realizing that any other tilde.club user can trivially forge their identity.
[fluffy]Like, on the github issue I have proposed two approaches we could take to make the protocol itself more secure against trivial identity hijacks on shared domains. What problems are caused, vs. what they solve?
[fluffy]Like yes they lose some small amount of flexibility in the protocol, but is that flexibility needed? Especially weighed against the overall flexibility gained by allowing users of shared domains to use whatever IndieAuth endpoint they want?
ZegnatI am not sure where or how a warning would go. That is one of the reasons I hesitate to add things. I do think that domain based is not the same as URL based logins (see my own identity not being domain based). But from the security aspect the back of my mind keeps shouting at me that only domain-based is secure simply because of how WWW infrastructure is done.
ZegnatBut as you said, maybe the fact that IndieAuth is domain-based is already not clear to people? In which case we may be doing more harm than good right out of the gate already
[fluffy]Right, and I reject the notion that IndieAuth should be domain-based, especially since it’s designed to be modular and easy to add into any HTML page.
[fluffy]And again, there’s an inclusiveness thing. We want users who don’t have the knowledge/ability/financial resources to set up their own domain and hosting.
[fluffy]Wouldn’t it be great if college classes that involve building a webpage were able to include a bit on “and here’s how to use the indieweb so you can log in to other peoples’ sites as https://example.edu/~username“?
[fluffy](without adding an IT support burden such as requiring their already-stretched-thin webserver admins to do all of the things to make that safe)
ZegnatBut I can totally see how, right now, it would be based on an "honor system" if multiple paths hosted their own auth endpoints. And by containing the auth endpoints to paths that would disappear. The only trust level left would be you trusting top-level is not going to add an auth endpoint.
ZegnatNo arguments there. I would love to see it. I identify everywhere as vanderven.se/martijn (I should maybe make a ~martijn alias [thinking emoji]). The only issue I see is from the infrastructure and security point of view.
[fluffy]I think the relative harm caused by the top-level domain adding an endpoint is a lot less than the relative harm caused by spoofing exploits. Like, if a domain admin is seeing that hey, everyone’s using IndieAuth! Here’s a new endpoint to use! doesn’t actually hurt anything, assuming users are still able to log in to the things they log into.
[fluffy]I guess the possibility might be that the domain admin might decide that *nobody* should use IndieAuth and then they add a Link: header that goes to an endpoint that denies all requests, or something.
[fluffy]anyway mastodon is way less interesting from the path-based ownership perspective because it’s already running on a site-wide stack. There’s already a single point of authority for an identity.
[Murray]is there any way to send a webmention without rendering it to a page i.e. from a form? Fairly certain the answer is no (can't think how it would work) but just want to confirm
[Murray]Yes, I was just looking into how Bridgy did that (or at least noticing it mentioned in a few places). I was already thinking about a self-destructing page of some kind to make this work, but I might go a different route entirely
[Murray]And tbc the aim here is definitely to make it on the Web 😂 I'm just trying to come up with a way for people to interact with my webmention endpoint (?) without actually having to setup webmentions themselves
[snarfed]if you're hosting all of those parts, it will probably be easier to just have the form write straight new comments to your site's storage, and not try to use the protocol at all
[Murray]I was hoping there _might_ be some way to just stick all the relevant information into the URL somehow, but no worries, thanks for confirming my suspicions
aaronpk[Murray]: that sounds like trackback, which sends the contents of the comment in the POST request itself. the problem with that is it's too easy to spam.
[Murray]Yeah [aaronpk] I was thinking spam would be a likely issue, guess I'd hoped I might fly under the radar (not like my personal site gets a lot of traffic), but from a protocol perspective that makes sense
[fluffy]So I just posted a test comment via commentpara.de, and I noticed that the comment pages are sequentially-increasing numerically. So I looked at the most recent 10 comments, all of which were “testing” or “does this work?”
jackyso I'm working on /Koype/Publish and I'm curious: how "bad" of an idea is it to send a whole page as a update to a micropub endpoint? Like I can work on doing tracked changes so like I'd only send partial changes when one chooses to submit them but :thinking:
jackyI want the latter because I do have a longer term goal to keep changes I make in my micropub endpoint stored against an entry as something that's timestamp-versioned to make a bit of a trail
jackyso sending the whole page would be a combination of fetching the page from micropub, having the client edit some parts of it and then resending it
Loqi It looks like we don't have a page for "IDP" yet. Would you like to create it? (Or just say "IDP is ____", a sentence describing the term)
aaronpk obligatory link to bridgy stats to see if there's anything there that might help https://snarfed.org/2020-06-27_bridgy-stats-update-5
@kixiQu ↩️ are responses a la webmentions necessarily "post"-type content rather than page-type? but then isn't the point of the web non linear asynchrony? (twitter.com/_/status/1283209411859640323)
KartikPrabhu what's that tweet trying to say?
vilhalmer I have one actual Page just because I felt like it fit the aesthetic https://vil.lv/sc3k.html
[fluffy] The WebID discussion reminded me of the current gap in the IndieAuth spec that I wanted to see addressed. I finally responded to the most recent comment on it, both with why I don’t think why the query parameters need to be handled, and with an actual in-the-wild example of how it’s a problem. https://github.com/indieweb/indieauth/issues/35
superkuh tor onions, vilhalmer.
[KevinMarks] Webfinger--
[manton] GWG: 🙂 I just reviewed the dozen proposals that you linked from the pop-up description and added a few more comments on GitHub. There are a few proposals that I’m really interested in “finalizing” as much as possible, because I’ve implemented them in the “2.0" versions of the Micro.blog apps, which will ship in 1-2 months. After the apps ship, it will suck to change the implementation.
Zegnat Maybe. I kind of like it because it makes it clear in the spec that domain level is how things are segregated on the web. Not saying there is no reason for IndieAuth to segregate on path. But then I would like to see a big warning somewhere to inform people that as soon as the owner of one path-level up decides to do so, they can hijack your auth.
@KappaTalks Integrating #Webmention with my blog https://www.kappawingman.com/posts/webdev/2020/07/15/integrating-webmention-with-my-blog/ #indieweb #blog #pelican #ssg via @KappaTalks (twitter.com/_/status/1283443642061881344)
jacky so I'm working on /Koype/Publish and I'm curious: how "bad" of an idea is it to send a whole page as a update to a micropub endpoint? Like I can work on doing tracked changes so like I'd only send partial changes when one chooses to submit them but :thinking:
[jgmac1106] chrisaldrich zegnat and I have a long and storied past exploring /citation will have to add to page
@w3bk3rn3l Using Yarns Microsub Server to subscribe to RSS Feeds and Monocle to read them. Nice and cool solution. #indieweb #rss #microsub #yarns #monocle (twitter.com/_/status/1283526600223600640)