sknebel[fluffy]: one idea I also don't like, but wanted to have mentioned: the endpoint the token is delivered to could state a preference for a canonical url, similar to the different user profile url mechanism. I think the most natural way would be discarding the delivery attempt and restarting it towards the "fixed" url though, since you might need to generate a new token
sknebel(i.e. if I decide to give "A" a token, on delivery of the ticket my system tells the receiving ticket endpoint "subject=A", the endpoint says "uhm, that's actually spelled B" - my system goes back, does the same check as for a differing profile URL against B, makes a new ticket for a token with the same rights but for B, delivers
[tantek]1This is something I think has quite a few IndieWeb #indieweb-dev specific angles & appeals, and I worked on with other Mozilla folks for a while so I don't mind sharing here: https://webvision.mozilla.org/ (just published)
jacky> The URL acts as a global, low-friction, distributed namespace, allowing individuals to publish on their own terms, with comparatively little interference from centralized actors seeking to extract payment or exercise editorial control.
[manton]Agreed, looks good! I like the “Site-Building Ergonomics” section in the full document (the tilt to centralization when making web sites is too hard).
angelo"Our strategy is to categorize development techniques into increasing tiers of complexity, and then work to eliminate the usability gaps that push people up the ladder towards more complex approaches." I dig it.
[fluffy][sknebel] Yeah, having the endpoint provide the canonical URL would be much better, but that also means having to formalize a response from the endpoint. Right now in our ad-hoc pre-spec land I’m just expecting a 2xx code to indicate success. A 3xx redirect wouldn’t be appropriate for this, so we’d be looking at having a JSON result instead.
[fluffy]And I mean, we’re already doing a request to a profile page to look up the ticket endpoint, why not use that and rel=“canonical” at that point?
[fluffy]Having the endpoint do the redirect means an extra request (to the new profile to look up the new endpoint), which isn’t the end of the world but also feels inelegant.
[fluffy]A redirect chain isn’t secure though, imagine alice.example declaring an endpoint that pretends to be bob.example. How does the sender know what the identity is?
sknebel(if you've went A->B->endpoint and get "B" as the fixed profile URL, you dont need to fetch "B" again to check if it points to the same endpoint)
[fluffy]IndieAuth’s rules around identity collapse used to be way more liberal and were controlled at the domain level, but that leads to some pretty obvious and onerous attacks on shared domains with individualized hosting (e.g. tilde.club or academic homepages) and so that’s why we went through the whole revision with validating it based on matching endpoints.
[fluffy]It was a lot simpler when the spec was just around “okay here’s how to send a ticket to someone to redeem, let’s not worry about an automated flow” but now folks are building things with an automated flow.
[fluffy]For some reason they keep on sideband talking with me about this over email and I need to get them to come here to discuss it to a wider audience.
[fluffy]The core TicketAuth protocol was written with the assumption that we already know the canonical profile URL and that we can look up the ticket endpoint from that. Which is a great assumption for the “site owner grants access to someone” flow. But it falls apart when it comes to having someone *request* that a ticket be granted to their arbitrary URL.
[fluffy]Yeah, he emails me about TicketAuth a lot. Anyway I just asked him to bring the conversation here so I’m not the single point of contact representing all of IndieWeb. 🙂
[tantek]1"_Make it easy for anyone to publish on the web_: While early websites were relatively simple and easy to build, the demands of performance and high production values have made the web increasingly daunting to work with. Our strategy is to categorize development techniques into increasing tiers of complexity, and then work to eliminate the usability gaps that push people up the ladder towards more complex approaches."
[tantek]1and: "_Give users the power to experience the web on their own terms_: The web is for users. In order to fulfill that promise we need to ensure that they, not sites, control their experience"
sknebel [fluffy]: one idea I also don't like, but wanted to have mentioned: the endpoint the token is delivered to could state a preference for a canonical url, similar to the different user profile url mechanism. I think the most natural way would be discarding the delivery attempt and restarting it towards the "fixed" url though, since you might need to generate a new token
jacky that could be a internal disambiguation of sorts (like via someone's /contacts, rel=me or even some private mapping)
[fluffy] [sknebel] Yeah, having the endpoint provide the canonical URL would be much better, but that also means having to formalize a response from the endpoint. Right now in our ad-hoc pre-spec land I’m just expecting a 2xx code to indicate success. A 3xx redirect wouldn’t be appropriate for this, so we’d be looking at having a JSON result instead.