#dev 2020-11-17

2020-11-17 UTC
test, [chrisaldrich], deltab, jacky, reed and KartikPrabhu joined the channel
#
aaronpk
I think i’m gonna start talking about business use cases when discussing indieauth concepts in a larger audience
#
aaronpk
like “use an app to manage the products sold in a woerdpress site”
#
aaronpk
at least that way nobody can bring up the “but users don’t think of their identifiers as URLs” argument :eyeroll:
#
KartikPrabhu
people do think of their URLS as identifiers, e.g., twitter username
#
aaronpk
Whether or not they do, there's a large subset of people in the identity space who remember openid 1 and firmly believe people do not
#
aaronpk
and I'm tired of those arguments so I'd rather not have them
#
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)
#
GWG
I'm still trying to figure out how to turn the weather sensors into a summary
jimpick, reed, jeremy, mitchell, skalnik and cjav_dev joined the channel
#
aaronpk
interesting debates about whether to use github issues in IETF work
KartikPrabhu, [tw2113_Slack_] and geoffo joined the channel
#
jacky
aaronpk: yes plz re: biz case of indieauth
[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)
#
sknebel
where does refresh_token require interaction?
#
sknebel
or am I misunderstanding the question
reed joined the channel
#
Zegnat
MinToken does token expiration by default (lifetime 7 days). And I can just bump the lifetime in the SQLite if I want a certain token to be around for longer.
#
Zegnat
I have been thinking of adding an “advanced” tab to the interface where I grant access, where I can tell my authorisation server for how long I want the token to be valid.
#
Zegnat
Not sure how I will roll that into refresh tokens yet. But the standard for refresh tokens, surely, is to give the client both the bearer token and the refresh token simultaneously?
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
#
Zegnat
“now it means "use opaque hashes"” - citation needed. I do not think people, as in general people I could ask here around the office, use any hashes. They think email address or possibly phone number as identifiers, if I were to guess.
#
[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"
#
Zegnat
Sounds ’bout right, haha
#
Zegnat
I think it is helpful to always make time to differentiate between what users think and what the latest tech discussions are :) Not to call you out specifically [KevinMarks], apologies for the sudden citation needed prompt
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
reed and [schmarty] joined the channel
#
aaronpk
jamietanna: I'm a bit confused. If you're doing an IndieAuth flow to issue these tokens in the first place you could also issue refresh tokens to these apps that you want to have long lived sessions. The refresh token is used to get new access tokens without any further user interaction
#
aaronpk
if you want these apps to get tokens without your interaction in the first place then that sounds like the client credentials grant in OAuth and you'd need these apps to have a client secret
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
#
aaronpk
There's certainly nothing wrong with URLs as identifiers. It's debatable whether people think of their own (existing) URL-based identifiers as URLs, and whether that's something that should continue to be promoted
#
aaronpk
however that also misses the point about IndieAuth which is more about the idea of bringing your own identity and letting apps work in an open ecosystem
#
aaronpk
when I bring up IndieAuth in these circles I often get a quick dismissal of "oh users don't think of their accounts as URLs so it will never work" or "this looks like openid 1 which failed so this automatically fails too"
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
That's absolutely the goal too!
#
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
#
nolith
aaronpk: what is the best way to debug an aperture channel? I have a channel with 3 sources, aperture states there are 47 entries but both Together and Indigenous thinks that channel is empty
#
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)
#
aaronpk
as a PHP developer I always forget about the concept of “application restarts” because PHP apps restart on every request :D
#
[fluffy]
Except for when they don’t because of hidden shared state in the underlying php server
#
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
#
[fluffy]
(Database connections, mostly)
#
jamietanna
(as we're very unlikely to want to introduce client_credentials for general-purpose IndieAuth apps)
#
aaronpk
nolith: there’s a UI bug in Aperture right now where that number you see on the Aperture website is actually saying how many items it’s found from that URL, not how many of those are actually in the channel
#
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.
#
aaronpk
for example if you have a filtering rule to only add items matching a certain word, that count will still show all 10 items even tho there might be only 1 in the channel
#
nolith
I have no filter, I'm not an advanced user, I'm using it like an RSS reader on steroids
#
[fluffy]
[jeremycherfas] probably referring to the internal IP address of the device you want to use as the default fallback for incoming traffic
#
aaronpk
nolith: it could be that the entries are from a date more than 7 days ago so it was removed from the channel too
#
aaronpk
(it should be cleaning those up and actually deleting them entirely but but that runs only periodically)
#
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?
#
nolith
aaronpk: that could be. Those are all blogs from friends that do not write often.
#
nolith
so if I add a new source that has posts older than 7 days I'll see noting new on the channel until a new post is published
#
aaronpk
yeah that sounds right
#
nolith
thanks aaronpk++
#
Loqi
aaronpk has 66 karma in this channel over the last year (226 in all channels)
[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
#
aaronpk
jamietanna: you don’t really need a scope for that. scope is a request from the app. so if you have a list of apps you know you want to allow refresh tokens from, hard code that list in your server
#
aaronpk
otherwise any app could arbitrarily ask for the offline scope
#
Zegnat
If that becomes documented behaviour, if I were an app maker I would by default request the offline scope. Because obviously permanent access is always a superior user experience from my side.
#
aaronpk
also note that there is some precedent for this already in OAuth with the scope “offline_access”
#
Zegnat
Whether to issue refresh tokens or not, if you see this as a security feature, I would say it has to be user choice. And then it would make sense for it to be part of the authorisation screen, rather than client initiated like scopes
#
aaronpk
yep it only makes sense to make it a client choice so that the client can voluntarily downscope its request
#
aaronpk
which is how scopes currently work
#
aaronpk
without them, the default would be allowing every app full access
#
aaronpk
with scopes, clients can say “actually i only need read access” etc
#
Zegnat
now wonders how to revoke refresh tokens
#
Zegnat
I guess if the current-valid bearer token is revoked, you need to make sure to also revoke the coupled refresh token?
#
Zegnat
Could be some pitfalls there
#
[fluffy]
[jeremycherfas] The whole point to a DMZ setting is to have all Internet traffic (anyone and everyone) being routed through the specified device, so, yeah.
#
[fluffy]
Also this is more of a #indieweb-chat thing since it’s not indieweb-specific.
[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
#
Zegnat
I am thinking the case where I click on a logout button in my client. The client wants to do the right thing to go and revoke the token so it can't be used if anyone finds it lying around. I think that has nothing to do with PAR?
#
Zegnat
Or you mean you are going to use the PARs as some sort of identifier on your end? That's interesting.
#
Zegnat
I think I am waiting to see GNAP mature more before making any calls on 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
#
Zegnat
jamietanna: I was more thinking about how I would handle that. Because the server needs to revoke two things: the current bearer token the revoke was done for *and* the refresh token it has on file
#
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
#
Zegnat
[Simon_Willison]: any reason you need to store state in the browser at all? If you can put all state in the access code that would be nice. That way when the client comes to exchange the code for a token all the state is packed in there, even if that request does not transmit cookies
#
Zegnat
jamietanna: yep, that is what I was working out in my head :) And was mostly wondering if there were other pitfalls surrounding issuing 2 tokens per client. Revokation was just the first to mind.
#
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]
tampered with
#
[Simon_Willison]
so I think signed cookies are the way to go
[tw2113_Slack_] joined the channel
#
Zegnat
Ah, sorry, yeah, as the client the way to statelessly pass information between it and a AS is to pack it in to the state parameter :)
#
Zegnat
Can't think of any immediate problems with cookies though, if you do not want to use the state parameter
#
aaronpk
either way is totally fine. signed cookies aren't even really considered stateless in the oauth world because the cookie itself is that stateful part
#
aaronpk
if you didn't want to use cookies at all you'd have to use the oauth state parameter and that's where it gets a bit trickier
[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
#
Zegnat
Depends if you can encrypt rather than just sign your state value
#
Zegnat
If you only can do signing, then PKCE does get a little trickier, yes
#
[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
#
aaronpk
yeah you'd have to sign the state parameter, that's what i mean by trickier :)
#
aaronpk
er, encrypt
#
aaronpk
brain is full
[KevinMarks] joined the channel
#
[tantek]
aaronpk in that case, I request a new photo, specifically for one of your mood variants
#
[tantek]
not the brain full variant (which would also be funny), but for when you "gonna start talking about business use cases"
#
[tantek]
you need an mood icon for 👔 and subtly add that emoji to posts where you're "talking about business use cases"
#
[tantek]
a* mood icon
#
[KevinMarks]
And :exploding_head: for brain full
#
[tantek]
🕴 <- makes me think of Michael Jackson videos for some reason
#
sknebel
"This character was originally introduced into the Webdings font as an “exclamation mark in the style of the rude boy logo found on records by The Specials". This levitating man was known as Walt Jabsco." is oddly specific
#
[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)
#
[tantek]
also a good opportunity for the #indieweb-wordpress++
#
sebbu
oh, i added it to my wordpress too
#
sebbu
haven't tried to use it as indieauth yet though
jjuran joined the channel
#
[tantek]
hmm why didn't that karma to cleverdevil work?
#
[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?