Loqigroup in the context of the indieweb (also "indie group" or "indie groups") is a place where people can deliberately share content with each other, not necessarily on their own domain (though likely copied from via webmention etc.) https://indieweb.org/group
[snarfed]1, angelo, mro, baracurda, cybi and jacky joined the channel
[fluffy]Just want to validate my thinking on something: If someone’s IndieAuth identity is https://example.com, and then they later get a TicketAuth grant as http://example.com, those identities shouldn’t be considered equivalent, right?
[fluffy]Like I see it as the same issue as trying to log in as https://example.com and then having the IndieAuth endpoint return a me of http://example.com, which is also forbidden.
jan6imho they should be equivalent, simply because they are almost certainly the same site, but might just use different defaults, e.g. if you type in "mydomain.com" then it might assume https:// but you yourself might only use the http:// version (or vice versa)
jan6ideally you'd only use one or the other, sure, but I don't think that a different protocol for the same domain should mean any difference, as it's most likely just a typo or mistake, but small enough to not really matter (and further on, if you make a http website, and sign on to stuff, and later on figure out how to set up https, why should you need to have two different accounts? and if you
[fluffy]If everyone has to start supporting various schema-upgrade (or in this case downgrade) mechanisms then you have to start to worry about everyone implementing it correctly
[fluffy]In this specific case, I have a user who was logging in via IndieAuth using the https URL, then was testing TicketAuth using the http URL, and then was surprised that the TicketAuth-granted bearer token didn’t have the same permissions/identity as the IndieAuth-granted bearer token.
[fluffy]And when I pointed out this difference he insisted that the http URL was canonical, not https (even though his profile page and IndieAuth endpoint were both specifically making https canonical)
jan6I don't really know how exactly it works internally, but maybe you could have a warning of "you've also used other-protocol:// url before, are you sure you're using the correct one?"
[fluffy]It’d be much better to have this formalized in a standard. I don’t personally care whether the standard says that identity URLs should be scheme-agnostic or not, I just care that it’s consistent and there’s something someone can point to to say “yeah this is okay” or “yeah don’t do that”
[fluffy]And given how most (all?) IndieWeb standards consider the scheme to be part of the canonicalization of the URL and require a strict match, I don’t see why there should be an exception for this one case.
[fluffy]You have to dig in through the specs, but like IndieAuth is very explicit about this. Let me see if I can find it in the (admittedly hard to navigate) spec.
[fluffy]and also about TicketAuth, which is a new-ish protocol that a bunch of us are trying to get established before it becomes a spec. All TicketAuth things are being newly-developed.
[fluffy]And like I mean he’s totally right to get a TicketAuth token with differing URLs, but I’m trying to figure out if I’m right to treat those differing URLs as being different identities when it comes to *access control to private entries on my site*
[fluffy]If consensus forms around identity URLs being scheme-agnostic then I would be fine with coding that into Publ’s identity layer but I’m not going to go through that work for something that I do not expect to be the consensus.
[fluffy]Oh also Publ’s identity layer supports mailto: URLs as well, and theoretically could support any other scheme that could be used to verify someone’s identity. I’d really rather avoid context collapse.
jackyoh my fault - I meant yes that those would be equivalent but only if they resolve (when doing a HEAD/GET to get the 'final' URL) to the same thing
angeloafter hand-drawing those IndieMark concentric cirlces and realizing that they're effectively overlapping pie charts i looked up a d3 pie chart recipe and got to work on a "scorer/validator" http://159.89.143.168:5010/
sknebel[fluffy]: what is the flow in their case? they go to your site and put their URL in a form field which then triggers your site to send them a ticket?
[fluffy]This is the provisional TicketAuth request flow, where someone can make a POST request to my token endpoint with action=ticket_request&subject=http://foo.example and that initiates the ticketauth flow.
[fluffy]Digging into this made me realize I’m also not properly canonicizing the case on domains, so example.com and Example.com are being treated as different, when IndieAuth’s spec explicitly says they should be the same
sknebelin principle we dont even want to start the initial lookup on HTTP if we can help it, since the lookup of where to send the token is security relevant
[fluffy]and so like Authl doesn’t support rel=canonical, but Publ’s TicketAuth implementation leans on Authl to do the endpoint discovery, and I don’t want to have to fetch the profile page again from Publ just to see if there’s a rel=canonical
[fluffy]but I also don’t want to special-case this stuff in Authl, which I’m trying to keep agnostic of consumer (even though I think Publ is the only consumer at present)
@JavaScriptKicks Pros and Cons of Using JavaScript Interop in Blazor by @Syncfusion https://javascriptkicks.com/r/505710?url=www.syncfusion.com/blogs/post/pros-and-cons-of-using-javascript-interop-in-blazor.aspx?utm_source=jskicks&utm_medium=cpc&utm_campaign=javascript_prosandcons_bpnews #javascript #productivity #webanimation #webmentions #webassembly via @JavaScriptKicks (twitter.com/_/status/1506270924399595524)
Loqi group in the context of the indieweb (also "indie group" or "indie groups") is a place where people can deliberately share content with each other, not necessarily on their own domain (though likely copied from via webmention etc.) https://indieweb.org/group
[fluffy] Just want to validate my thinking on something: If someone’s IndieAuth identity is https://example.com, and then they later get a TicketAuth grant as http://example.com, those identities shouldn’t be considered equivalent, right?
jan6 imho they should be equivalent, simply because they are almost certainly the same site, but might just use different defaults, e.g. if you type in "mydomain.com" then it might assume https:// but you yourself might only use the http:// version (or vice versa)
jacky https://indieauth.spec.indieweb.org/#url-canonicalization is hinting that this _should_ be the case
angelo after hand-drawing those IndieMark concentric cirlces and realizing that they're effectively overlapping pie charts i looked up a d3 pie chart recipe and got to work on a "scorer/validator" http://159.89.143.168:5010/