#dev 2020-11-17
2020-11-17 UTC
test, [chrisaldrich], deltab, jacky, reed and KartikPrabhu joined the channel
# KartikPrabhu people do think of their URLS as identifiers, e.g., twitter username
# KartikPrabhu yeah fair enough
reed joined the channel
# @justinmduke ↩️ haha yeah....... at some point i’ll replace airtable with sqlite and open source it.
and i feel like there’s some way to do that with webmentions & pingbacks but i’m too lazy to figure out how. i still need to summon the energy to figure out autotweeting from RSS (twitter.com/_/status/1328556264310206465)
jimpick, reed, jeremy, mitchell, skalnik and cjav_dev joined the channel
KartikPrabhu, [tw2113_Slack_] and geoffo joined the channel
[chrisaldrich], reed, [tw2113_Slack_], marcthiele, KartikPrabhu and jamietanna joined the channel
# jamietanna aaronpk is the IETF GitHub conversation public somewhere? Sounds like it may be a good read
schmudde and swentel joined the channel
# jamietanna As part of rolling out my own IndieAuth server I'm looking at setting expiries on tokens, and longer term, refresh_tokens, and I'm wondering if folks can weigh in on implementation
# jamietanna I'm thinking about making them single use, so I don't have to think further about constraints i.e. some sort of client_secret (although if it makes more sense, I can) but then this causes some issues for certain clients I've got, like the service that publishes syndication+updates, and my step counts, which have long-lived access_tokens
# jamietanna As I want to have those services refreshing the refresh_token freely, with no interaction from me, I've got a few choices - allow special clients to retrieve a refresh_token without my interaction (could be dangerous, especially as anyone can fake a client_id
# jamietanna Require some shared secret, which as well as the client_id could allow for offline authorization, in which case I could ignore `refresh_token`s and just go for an access_token each time
# jamietanna Otherwise does anyone have any thoughts about how best to re-seed these sorts of services that need long-lived access, but I don't necessarily want to go through the flow fairly regularly, and instead want to pre-seed the refresh_token in some config somewhere?
# jamietanna (Or is it maybe that I'm trying to avoid making them all full clients, and it doesn't make sense)
reed joined the channel
reed and [KevinMarks] joined the channel
# [KevinMarks] People not thinking of themselves as urls used to mean "use email addresses" but now it means "use opaque hashes" which makes even less sense.
# [KevinMarks] If people could remember their email addresses I wouldn't get email for all the other Kevin Marks's in the world
reed joined the channel
# [KevinMarks] I conflated 2 things there. The new annoying identity conversation is "urls are bad because DNS is centralized, so you should use [our complicated crypto thing] where all identifiers are impossible to type or remember"
# [KevinMarks] Whereas the old one was "people understand email addresses, not urls, so let's make up identifiers that look like email addresses but aren't and have a 4 stage protocol for looking them up"
reed joined the channel
# [KevinMarks] A summary of methods is here https://www.w3.org/wiki/Socialwg/AccountDiscovery - not sure if that should be on the indieweb wiki
reed and [Rose] joined the channel
# [KevinMarks] Now that's a threat that I I hadn't thought of https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/
reed and [schmarty] joined the channel
reed, geoffo and cweiske joined the channel
# jeremycherfas no-ip or duckdns
reed, [jgmac1106] and [Aaron_Klemm] joined the channel
# [Aaron_Klemm] aaronpk, just for the record, the argument is stupid because it's stupid, not because there's something wrong with URLs as identifiers, right?
reed joined the channel
reed and tomasparks joined the channel
# [Aaron_Klemm] And you bring that identity as a URL, right?
# [Aaron_Klemm] I just want to make sure I'm not 'round the bend in my personal quest to help people have a URL of their own with all kinds of identity stuff attached
# aaronpk One of the things that's possible with IndieAuth is a user can type just the domain name part of a url and it still works out, even if that domain actually hosts accounts for a number of users. That's one of the subtle things people miss when they make the connection to openid too fast and dismiss it outright
[fluffy], reed and jamietanna joined the channel
# jamietanna Sorry for dropping that wall of text then running off - just reading scrollback now
# jamietanna So I think the thing I was (very poorly) trying to explain is that I'm trying to think of how to initially seed that refresh_token, and then persist it in a way that survives application restarts. I think it's as simple as "store it on disk" so my back and forth can be ignored :)
# jamietanna I'll probably only issue refresh_tokens for now to clients that I know need that persistent access like my own, whereas I'll want other clients to force to re-auth (particularly in the case where I want to limit exposure / leakage of tokens)
# jamietanna I was thinking client_credentials would work too, but was also thinking about investigating it as a route for what happens when we do start wanting other IndieAuth clients using the grant
# jamietanna (as we're very unlikely to want to introduce client_credentials for general-purpose IndieAuth apps)
# jeremycherfas My router wants to know the IP client DMZ before it will allow me to do port forwarding. Is it the IP of the router? Having no luck searching.
# jeremycherfas I'm trying to open a port so I can use my Pi with a wireguard vpn. So I guess the other device on the network is the fallback.
# jeremycherfas But doesn't that mean that anyone and everyone can get through to that other device?
[Jeremy_Keith], [snarfed] and jeremych_ joined the channel
# [Aaron_Klemm] ↩️ That's important
reed joined the channel
# jamietanna I think I'm probably going to use `offline` scope to allow `refresh_token`s for now
reed joined the channel
[schmarty] joined the channel
# jamietanna hmm that's fair aaronpk and Zegnat, yeah that thinking of mine didn't make sense :) making it an Authorization Server / user choice is a good shout
# jamietanna regarding revocation, the token should trace back to some initial request (I'll be doing it based on the Pushed Authorization Request) so an access/refresh token that comes in requesting a revoked authorization will be rejected
# jamietanna ^ re PAR, I'm building that in as part of my implementation that even though clients aren't doing PAR, it'll be stored + referenced as if it were PAR
reed, reed_ and [Simon_Willison] joined the channel
# [Simon_Willison] I’m building an indieauth implementation right now that can’t rely on ANY server-side state - no database, not even a guarantee of an in-memory store since it’s meant to run on serverless/stateless hosting
# [Simon_Willison] I’m going to stick the state and code challenge in signed cookies instead - any reason that wouldn’t work?
# jamietanna Zegnat so in the case that the client sees you're logging out, it's up to them to tell your IndieAuth server that they're revoking it. If they're not well formed, that's nothing you can protect against
# jamietanna [Simon_Willison] that should work, I guess using something like a Signed JWT (JWS) or https://paseto.io/ would work, or even doing something yourself to create those signed cookies
# jamietanna OK, so then it depends on how the access / refresh token are linked - if there's some unique identifier that links them, then it's easier because you can find anything matching that identifier and revoke it
# jamietanna the way mine will work is it'll store the URN for the authorization request in the tokens (as JWTs)
[CrowderSoup] joined the channel
# [Simon_Willison] I’m implementing the “client” part of the spec, not the “authorization endpoint” part so I don’t get to generate any access codes - I get to control the stuff sent in the
# [Simon_Willison] `https://example.org/auth?response_type=code&client_id=https://app.example.com/&redirect_uri=https://app.example.com/redirect&state=1234567890&code_challenge=OfYAxt8zU2dAPDWQxTAUIteRzMsoj9QBdMIVEDOErUo&code_challenge_method=S256&scope=profile+create+update+delete&me=https://user.example.net/` URL but the only thing in there I could stash extra state in is the `state=` bit, and I’m supposed to be using that to confirm that it wasn’t
# [Simon_Willison] tampered with
# [Simon_Willison] so I think signed cookies are the way to go
[tw2113_Slack_] joined the channel
[tantek] and [jgmac1106] joined the channel
# [Simon_Willison] OH wait just spodde this
# [Simon_Willison] > Upon the redirect back to the client, the client _MUST_ verify that the state parameter in the request is valid and matches the state parameter that it initially created, in order to prevent CSRF attacks. The state value can also store session information to enable development of clients that cannot store data themselves.
# [Simon_Willison] So I could use a signed value as the state= parameter with all the extra stuff I need in it, and check the signature on that value to ensure it hasn’t been tampered with
[chrisaldrich] joined the channel
# [Simon_Willison] what’s trickier about the state= parameter? Is there a size limit on it?
# [Simon_Willison] (and now I see that you explained the state= parameter before I spotted that in the docs!)
# [Simon_Willison] I’m going to see if I can get it working just using state= without signed cookies first then
# [Simon_Willison] I”ve borrowed Django’s signing code so I’m confident it’s fit for purpose
# [Simon_Willison] … cancel that, I’m using itsdangerous which is equally solid (if not better)
# [Simon_Willison] Hmm… I think I still need to stash the original `code_verifier` value in a signed cookie though - it doesn’t feel safe to communicate that as part of the state= parameter
# [Simon_Willison] Not easily - I’d have to add a new dependency, rather avoid that if I can
# [Simon_Willison] I”m going to stick the verifier in a signed cookie for the moment
[KevinMarks] joined the channel
# [KevinMarks] And :exploding_head: for brain full
# sknebel https://emojipedia.org/person-in-suit-levitating/ ... TIL that's an emoji
# [tw2113_Slack_] i can see why you’d lean that way [tantek]
schmudde, [KevinMarks], [chrisaldrich], [jeremyfelt] and [tw2113_Slack_] joined the channel
# [tantek] lots to learn here (for devs) about user-empathy and pain points. really grateful for this write-up: https://twitter.com/_/status/1328837301326254080
# @smaffulli How I added #Indieweb to #WordPress: it's been a little too painful to setup and use. On the other hand, the set of tools is going in the right direction. I'll keep on exploring these tools. It feels like the early days of the internet again. (https://maffulli.net/?p=6519) https://pbs.twimg.com/media/EnD6ezxWMAMjabP.jpg (twitter.com/_/status/1328837301326254080)
jjuran joined the channel
# [chrisaldrich] someone was just asking GWG about bridgy issues in picking up photos with that same theme earlier today/yesterday. It isn't the same person is it?