[fluffy]also, if someone specifically removes the profile and email scopes, does that mean Authl shouldn’t parse those out of h-card? Or does it just mean that it’ll be fine for Authl to still consume the public information on the h-card?
Rattroupe"which should be considered more authoritative: the information from the profile scope, or the h-card?": in my case, it's much easier for a user to edit his profile vs an h-card
Rattroupe(from #indieweb) "BTW I didn’t see that you’d added specific support for profile scope. What fields did you end up settling on for the profile? I’ve been wanting to add that into Authl but I haven’t had anything that provides a profile to parse yet."
[fluffy]Authl has actually requested profile scope for *ages* and it’s (sort of ) in the wild, but it hasn’t done anything with the returned profile because nobody had implemented it yet 🙂
[fluffy]I think there’s a gap in understanding here, because like. Authl requests profiles (but doesn’t use them) and I was excited to see that you’ve implemented them at the indieauth server level 🙂
[fluffy]SO far I’ve only had the ‘profile’ scope as a placeholder because a scope is required for the client request and it seemed innocuous and unlikely to cause conflicts.
rattroupe[d]I’ve noticed in some other oauth-related specs that a client must request and be granted an offline_access scope in order to get a refresh token. Is that something we care about?
GWGBut according to the spec, and I read through it just this evening again, it says that the authorization server decides whether it will give refresh tokens. So, if you want it to decide based on the granting of a scope, you can.
rattroupe[d]I guess the thinking is, with a refresh token a client could potentially remain authorized indefinitely, which is something a user might not want automatically granted
rattroupe[d]It’s a little more than an implementation detail. If the client has the burden of requesting a refresh token, that means an endpoint doesn’t have to burden the user at all if no refresh is requested. But if it’s up to the endpoint implementation then the endpoint has to ask the user every time, if it wants to implement refresh tokens at all
GWGaaronpk is the OAuth2 expert, but if I understand it correctly, and why I was one of those pushing for it, is that short-lived access tokens with refresh are better than a long-lived token for clients where you want them to have access for a longer period of time
[fluffy]did refresh tokens ever get added to the TicketAuth spec? Publ’s ticket endpoint provides them as a matter of course but it’d be nice for it to be formalized
ZegnatI would say that, in TicketAuth, you redeem the ticket for a token at an OAuth token endpoint. Refresh tokens are just a feature of the token endpoint, so not sure there is a need to add anything specific about them to TicketAuth?
[fluffy]@rattroupe I had to take a break from Authl stuff but I’ve released a new version that hopefully supports IndieAuth profiles (or at least the unit tests say it do), and it’s been deployed to https://beesbuzz.biz/ - feel free to visit https://beesbuzz.biz/blog/profile and see if it works as you expect!
[fluffy]!tell rattroupe IndieAuth profile implementation is live on https://beesbuzz.biz/ although there’s an issue where it’ll cache stuff from the IndieAuth server response erroneously if e.g. someone logs out and back in without the scopes set. I’ve already fixed that in the code but I’m going to hold off on doing another release so quickly.
jamietannarattroupe[d] that should be fine - didn't we make PKCE required in the spec? So it's fully up to us as to whether we support legacy sites or not
rattroupe[d]I thought I had coded it to support legacy non-PKCE sites but I didn’t test it and it turns out there was a bug. Should be easy to fix though
rattroupe[d]!tell [fluffy] I logged in to beesbuzz and saw the profile scope in my log, and the login appeared to work, but I don’t see the profile information used anywhere on the site.
[fluffy]like there should be something like a “Hello, [your name here]. [sign out]” pair of links. The ‘your name here’ one would take you to your profile.
[fluffy]The point to the profile page is so that you can see how you look to me, and so that I can see who you are so that I can grant you access to private entries.
rattroupe[d]I was confused because I didn’t see a profile link on the home page, and the first few links I clicked on didn’t go to a page with a profile link either
[fluffy]ah, right, that could be a bit more clear. On the home page it’ll show a login link if you’re logged out and there’s a recent private entry, but there’s no profile link there.
[fluffy]PKCE has been a low priority because of the use case of Authl so far but I definitely do want to support it eventually since Authl isn’t *just* for Publ’s private-entry login.
[fluffy]like I intend to use it on any app I build that requires login, and I designed it to be straightforward to integrate into any Python app (with it being especially easy for Flask but there’s no Flask requirement)
rattroupe[d][fluffy]: I posted a rant about profile URLs, in the end I decided to have a single-user config for Authorio and reiterate.app is running in single user mode
[fluffy]I *sort of* agree with your rant in principle but in practice IndieAuth does support the idea of things like reiterate.app/rattroupe/ or whatever.
[fluffy]Back when I used OpenID for login in a lot of places I used a hack to have my profile URL be beesbuzz.biz/fluffy/ which just had a couple of links to things.
[fluffy]I guess we don’t actually have verification that it’s your IndieAuth profile that was used, though; if you have the same data on your h-card then it *could* have been pulled from that.
[fluffy]I could make that shorter too although that’s currently hardcoded into Authl itself. It’s just there to make it so that the h-card doesn’t have to be re-fetched after a successful login.
rattroupe[d]Hmm.. Ed my profile settings back to what they should be, logged out and back in of beesbuzz, but I’m still seeing the (cached) test values
[fluffy]Hmm, only the h-card should be getting cached at all… oh, but the endpoint discovery is also cached, so yeah I guess it’d only refresh after the cache expires.
[fluffy]Arguably I could just make it not cache anything but then people will probably get annoyed at how many times it makes a request back to the server. You can never really win.
rattroupe[d]I can see in my logs that you are requesting and receiving the updated profile info each time I relog but I guess you’re discarding it in favor of your cache?
[fluffy]unfortunately the cache is all in-process and I don’t have debugging logging enabled for beesbuzz.biz (since that’d make my site really slow) so I can’t do any forensics on this particular thing.
rattroupe[d]I’m logged in to beesbuzz with my laptop. I then visited the site with my iPad, and I’m not logged in there. So I tried logging in on my iPad, and it went through normal flow. I authenticated with my site, but then it redirected to beesbuzz homepage and I was still not logged in.
rattroupe[d]The endpoint is reiterate.app/authorio/auth. I get redirected there just fine, that’s where I authenticate on my end. Then I get redirected to http://dev-authl.beesbuzz.biz/cb/ia and eventually to the homepage
rattroupe[d]Ah it’s because I was tapping return on the iPad, but clicking the submit button on my laptop, and the cancel button is the default because it’s the first one in the form
GWG I tried my hand at a PR for refresh tokens https://github.com/indieweb/indieauth/pull/90
rattroupe[d] I’ve noticed in some other oauth-related specs that a client must request and be granted an offline_access scope in order to get a refresh token. Is that something we care about?
[fluffy] @rattroupe I had to take a break from Authl stuff but I’ve released a new version that hopefully supports IndieAuth profiles (or at least the unit tests say it do), and it’s been deployed to https://beesbuzz.biz/ - feel free to visit https://beesbuzz.biz/blog/profile and see if it works as you expect!
jamietanna rattroupe[d] that should be fine - didn't we make PKCE required in the spec? So it's fully up to us as to whether we support legacy sites or not