[jacky]this might be interesting for parsers that don't want to use something something like readability to mangle a page into MF2-esque JSON (on their end)
shoesNsocks1, samwilson, [KevinMarks], [Murray], chenghiz_, barnaby, ben_thatmustbeme, [tantek], [schmarty] and [manton] joined the channel; Poorchop left the channel
[manton]Anyone have experience with Caddy? We’re considering switching from Nginx to Caddy to simplify HTTPS for hosted blogs on Micro.blog… https://caddyserver.com
barnabyI’m way more familiar with ACME than I ever intended on becoming, as my current web host charges silly fees for certs, but allows you to set your own. so I made a script which authenticates and renews a multi-domain cert for all my domains, then emails me the new cert and key in a GPG-encrypted email, to remind me to update them in the host UI
petermolnaraaronpk: I wasn't arguing with that, I just wanted to point it out that automation with nginx is ok in case one doesn't want to move from nginx, and this - built-in certs - would be the only reason.
sknebel(which can be a browser, which has all the issues you reference, but also can be done between services etc. although many implementations kind of assume that you have a shared private CA for all participants)
barnabyspecifically what I’m thinking about is: Server A makes a request to server B, signed with the private key used for Server A’s TLS cert. server B fetches and verifies server A’s public key, and uses it to verify the request
sknebelalthough the "B fetches and verifies server A’s public key" part I'm not sure if that's done, I think more commonly you just check that the cert is valid and from a trusted CA
barnabyI didn’t put a proof-of-concept together for it to check if it worked, but I dug around in some openssl libraries and it seems like most of the parts are there
aaronpkthis is a big topic in the oauth group right now too, there are a few different ideas floating around for how to do client authentication which this idea basically is
aaronpkpersonally i'm most excited about reviving HTTP signatures since I think that strikes the right balance between doing the signing in the transport and application layers
jamietannas'all good :) I wonder if you can try it on a subset of server(s) to give it a go? I've found the mix of auto-TLS and batteries-included for easily proxying between things to be useful, and I guess the Caddy API may be super helpful across the fleet of servers that run m.b ?
[manton]Definitely, I think it potentially simplifies several things for us. I might split off my own blog (or a few test blogs) to route through Caddy as a first test.
[manton]Great, thanks. Because our hosted blogs are static sites, I’m hoping it’ll be straightforward to switch. (Just need a little bit of special handling for 404s.)
jamietannaI'm thinking that I may get around to implementing it (soon) but go with the route of "always issue a refresh token" as a way of nudging folks to implementing it
jamietannaas well as being a good way of ensuring persistent access can be used - and in my case, if a refresh_token isn't used in 90 days (as far as I can remember, at least...) then it expires and a new one is required, leading to me needing to re-issue a ticket
jamietannaI've still got to make a few changes to strengthen my IndieAuth-protected endpoints to validate the `resource` a token is issued for, and even if someone had a token, they wouldn't (yet) be able to use it, but I think I may use this as a way to lead into private posts
jamietannathat's fair re not doing refresh tokens yet - I'd like to raise a PR to one of the major clients, but not gotten round to it as it's lower on my priority list
jamietannaso interestingly Netlify does ticket-based auth as part of the OAuth journey which I've just found while authing on this machine for the first time
jamietannahttps://open-api.netlify.com/#tag/ticket has a bit of info, will try and find a bit more - but this is where the client says "I have a ticket that I want the user to auth with" and seems quite similar to the OAuth Device Flow
jamietannait looks like they've either taken Device Grant and tried to simplify it, or re-implemneted it before realising there's an official OAuth grant for it
barnabyI’m definitely interested in the ticket auth stuff, looks like it could be a good method for giving sites temporary discretionary access to private resources
[jacky]yup! tbh I hope that once I grok it enough, something like that could be easy to put into a check for something like nginx as a proxy_auth flow then static sites could probably get in the fun of private content 🙂
barnabye.g. a way of server A being able to say “I want to be able to make authenticated requests to server B”, so server B sends a ticket to server A’s endpoint, which is then exchanged for a code
barnabythere’s a lot more fragile back and forth and discovery involved than my hypothetical mutual TLS idea, but it would fix the problems with that approach, and build off existing indieweb building blocks
barnabyoh sure, I’m just thinking out loud, in case someone can shut my idea down with a security issue I’ve overlooked, in which case I can stop thinking about it
LoqiAutoAuth is the working title of an extension to IndieAuth that allows clients to authorize to other servers in the name of their user, without the user being present to confirm each individual authorization flow https://indieweb.org/AutoAuth
GWGIf you want speculation...the next step after we implement the spec as written is to add how someone can request a ticket be sent to them... And how it could work with clients
calebjasik, nekr0z and Abhas[m] joined the channel
GWGAlso, in this scenario, the ticket endpoint requests all tokens and the client requests them from the token endpoint, as opposed to from the external token endpoint
sknebelAutoAuth as currently written down generally does more to "police" requests, e.g. it will only send a request to the publisher if the users site has approved that - ticket auth appears to go in the direction of not caring about that
sknebelat the point you have the question of "if I'm willing to deliver tickets on request, how much do I care about that request being actually authorized by the site I'm sending a ticket to"
sknebelone way I could see is including a "as you requested" indicator in the request delivering the ticket, to distinguish from a ticket being delivered because A wanted to give one to B
sknebelAutoAuth would go and verify "hey, did you really want a token for XYZ?" before doing anything. but if you consider creating tickets cheap, that's not needed. so that bit you could skip. maybe there is value in explicitly rejecting a ticket offer though
sknebelprobably comes down to questions like "what am I supposed to do if I get a new ticket for something I already have a token for", "do I invalidate an old token if I issue a new ticket for the same thing", ...
sknebelanyway, for clients I think the model of "they get an indieauth scope that allows them to ask the site for tokens" makes sense - if they then get to make the requests to publisher for a ticket to be issued themselves or not is probably open?
[jacky]a bit of brain banging: what's the implication of having a specialized token and authorization endpoint for people? like if you were building a service - I can see it as a way to do a 'harder' check against the usability of a token or request flow but I can see that being done by doing some session checking
aaronpkright now we've been relying on scopes quite a lot, but as we've been doing more "interesting" combinations of things, the idea of a resource identifier might be useful
[jacky]I can see this being used for a 'progressively requesting' reader to first only allow it to read from microsub and then when asked for a more interesting function (maybe something mutable like blocking, muting or the like), it can potentially get a _separate_ token for doing other things
petermolnar upgrade your nginx, if applies: https://nvd.nist.gov/vuln/detail/CVE-2021-23017
[manton] Anyone have experience with Caddy? We’re considering switching from Nginx to Caddy to simplify HTTPS for hosted blogs on Micro.blog… https://caddyserver.com
barnaby I’m way more familiar with ACME than I ever intended on becoming, as my current web host charges silly fees for certs, but allows you to set your own. so I made a script which authenticates and renews a multi-domain cert for all my domains, then emails me the new cert and key in a GPG-encrypted email, to remind me to update them in the host UI
aaronpk i noted some of the history here https://oauth.net/http-signatures/
jamietanna [manton] I've used Caddy for a few services in the past and recommend it! I don't use other web servers where I can avoid it, now
maxwelljoslyn manton I like caddy definitely give it a shot, not as configurable as the competition but great fast setup for simple use cases
Loqi AutoAuth is the working title of an extension to IndieAuth that allows clients to authorize to other servers in the name of their user, without the user being present to confirm each individual authorization flow https://indieweb.org/AutoAuth
[jacky] a bit of brain banging: what's the implication of having a specialized token and authorization endpoint for people? like if you were building a service - I can see it as a way to do a 'harder' check against the usability of a token or request flow but I can see that being done by doing some session checking