#dev 2021-06-21

2021-06-21 UTC
#
astralbijection[ okay, so after much effort it seems that building off of the oauth2 framework is more effort than it's worth
#
astralbijection[ it's hard to inject me= into everything
#
astralbijection[ as an introvert, this is doubly true
samwilson, jeremy, KartikPrabhu, [tantek], cambridgeport904 and capjamesg joined the channel
#
Zegnat We made `me` optional (almost) at the same time as response_type=id was dropped. Also to make it more compatible with standard OAuth2.
#
Zegnat Do you need a me parameter for your implementation, astralbijection[?
#
Zegnat There was a long discussion about this, and in the end, me was made optional: https://github.com/indieweb/indieauth/issues/19
#
Loqi [00dani] #19 Allow the 'me' parameter to authorization endpoints to be omitted?
pepperoni joined the channel
#
Zegnat astralbijection[: what guide/documentation were you following that pointed you at response_type=id and the me parameter? I am wondering if there is something that we can update as the community to reflect the modern IndieAuth spec
hendursa1, [Murray], IWSlackGateway, [KevinMarks], [tantek] and pepperoni joined the channel
#
astralbijection[ <Zegnat "astralbijection: what guide/docu"> I followed the spec on w3 (https://www.w3.org/TR/indieauth/#authentication-request) as well as the guide on the wiki (https://indieweb.org/authorization-endpoint#Request)
#
Zegnat Hmm. Yeah, I see now that we have let the wiki pages go quite stale. We should at least add some sort of warning there that the spec is newer than the wiki page.
#
Zegnat I do not know if we can do anything about the W3C Note. The live spec is where that Note links to as the latest editor’s draft: https://indieauth.spec.indieweb.org/
#
Zegnat There have been a bunch of changes since the publication of the 2018 W3C note: https://indieauth.spec.indieweb.org/#changes-from-09-august-2020-to-26-september-2020-li-2
#
Zegnat https://indieweb.org/authorization-endpoint#Creating_an_Authorization_Endpoint so, hopefully that eliviates some confusion. I do not have time to do a rewrite of the guide itself right now ...
chenghiz_, justBull, pepperoni, [KevinMarks], [Murray], hendursaga, IWSlackGateway, capjamesg and [tantek] joined the channel
#
[tantek] Once the spec is updated to include things discussed on the wiki, the wiki should *link* to that section of the spec, instead of putting in "some sort of warning"
#
[tantek] Like if you're going to take the effort to put in a warning, it's not much more work (and A LOT more useful to everyone reading) to instead link to section of the spec
[fluffy], [tw2113_Slack_] and pepperoni_ joined the channel
#
Zegnat I am happy to update the wiki page when I have more headspace for it. But I am happy to call out to people who may be doing their implementation based on the wiki that it is a number of updates behind on the actual living standard for now. (So much so that a request made in accordance with the wiki may not even be accepted by an auth endpoint anymore...)
pepperoni_ joined the channel
#
[tantek] that sounds like potentially harmful content that should be removed
#
aaronpk the wiki content is meant to be an implementation guide, covering the topic from the point of view of individual roles, and potentially including things that aren't in the spec as well, such as methods of user authentication at the authorization server
#
aaronpk where the spec has a single section describing the interaction at the authorization endpoint, the wiki content is meant to be written separately from the point of view of the app as well as from the AS
#
[tantek] ok that makes sense
#
[tantek] that may be worth putting in a "About this page" or something section on the page
#
aaronpk 👍
shoesNsocks and shoesNsocks1 joined the channel
#
[tantek] GWG, as someone who is a fan of weather and displaying weather information, thought you might appreciate this design approach to displaying temperature, perhaps for your archive pages for ranges of days / months / years: https://showyourstripes.info/
#
[tantek] it reminds me of Dopplr's upcoming trips color bars, one segment per destination city
rockorager joined the channel
#
GWG [tantek]: I have not gotten to temperature archives yet. Making a note
#
[tantek] GWG, cool (so to speak). Was unsure where to collect that design example
#
[tantek] what is temperature
#
Loqi It looks like we don't have a page for "temperature" yet. Would you like to create it? (Or just say "temperature is ____", a sentence describing the term)
#
[tantek] ^ GWG
[chrisaldrich] joined the channel
#
GWG Temperature is a measurement of hot or cold that is often a property of posts to convey conditions at the time of posting.
#
GWG What is weather?
#
Loqi Weather is the state of the atmosphere at a place and time as regards heat, dryness, sunshine, wind, rain, etc https://indieweb.org/weather
#
GWG Maybe it should be there
deeden joined the channel
#
[tantek] yes that's fair (so to speak 🙂 )
#
[tantek] weather << Cool design example for displaying an archive summary of temperatures across posts: https://showyourstripes.info/ (looks a lot like [[Dopplr]]'s trip stripes)
#
Loqi ok, I added "Cool design example for displaying an archive summary of temperatures across posts: https://showyourstripes.info/ (looks a lot like [[Dopplr]]'s trip stripes)" to the "See Also" section of /weather https://indieweb.org/wiki/index.php?diff=76130&oldid=72817
KartikPrabhu, [Will_Monroe], Seirdy and [jacky] joined the channel
#
[jacky] https://waxjs.net/features/
[chrisaldrich], [Murray], [tw2113_Slack_], [fluffy] and [tantek] joined the channel
#
[tantek] does anyone actually use atom:id elements that do not have their domain in it? and anyone know if any Readers that support Atom actually perform some sort of origin-limiting on Atom:id? Because if not, I'm pretty sure it's trivially spoofable for someone to provide "updates" to say, some mainstream media feed of articles, with slight alterations in the titles or summaries or even contents of the articles.
#
[tantek] and anyone treating atom:id elements as all part of some global unique namespace (which is how RFC4287 defines the comparison operator) https://datatracker.ietf.org/doc/html/rfc4287#section-4.2.6.1
#
[tantek] this bit is the key: "
#
[tantek] ```Comparison operations MUST be based solely
#
[tantek] on the IRI character strings and MUST NOT rely on dereferencing the
#
[tantek] IRIs or URIs mapped from them.```
#
[tantek] "
#
[tantek] must be based *solely* on the IRI character strings, that means a processor MUST NOT compare them with some additional factor, say the source domain of the feed
#
[tantek] this seems like a massive hole. what am I missing?
#
[tantek] or was this back in the day when people thought there's no way feeds would do nasty things like consuming and republishing each other's atom:id in entires with slightly more recent <updated> dates?
#
[tantek] this makes me want to recommend that folks DO NOT rely on atom:id for anything, because there's no spec-compliant way to use it that's not vulnerable to this spoofing attack
#
[tantek] where are all the feed file defenders when you need them 😛
#
aaronpk it's possible to follow that rule while still namespacing the IDs to the domain the feed is hosted on
#
aaronpk in other words, it doesn't say you *can't* limit the comparison to IDs only from the same feed or domain
#
aaronpk which you can do even treating the ID as an opaque string