omz13angelo: I have updated toolbox.imoxia.com to give the client more detailed info when login fails, plus dumping the raw response from the AS into the server logs on my side... hopefully this can help locate the problem
GWGomz13: In your proposed spec, you define it as the user profile of the subject. The Ticket Auth wiki page describes it as 'the access token should be used when acting on behalf of this URL'
GWGThe ticket is sent with a resource and a subject. Discovery uses the token endpoint of the resource. The subject's use primarily seems to be to identify the person the ticket is for if there are multiple people using 1 ticket endpoint.
[schmarty]anyone here implemented an IndieAuth metadata endpoint? how about a client that uses it? i know i'm late to the game since it was added to the spec in Dec 2020 but it seems like we have no documented examples.
[schmarty]it seems that the only token verification mechanism in the spec now is via introspection endpoint, and the introspection endpoint "must" require some form of authorization. for now i am supporting "Bearer" in my setup, but i realize that introduces a challenge for services like Aperture which is built to support multiple users and their indieauth implementations.
aaronpkmy plan was to give people a setup screen in Aperture where you could give it a way to authenticate to that endpoint, but i haven't touch Aperture since that update
sknebel(is the token itself a valid answer for "a form of authorization"? "this token authorizes whoever holds it to find some information about this token"?)
aaronpkthe question is do you want to allow arbitrary software to validate tokens you issue? or do you want to explicitly authorize these things? this is the main way indieauth diverges from the model that oauth sets up
sknebel"this token is still good" is IMHO sufficiently useful to allow it. doesnt necessarily have to reveal all the other details the token holder should already know?
[Jamie_Tanna]Schmarty I've got the metadata endpoint, and I'm using it in micropub-go for discovery (as is anyone using hawx's indieauth Go library), but that's pretty limited usage so far
[schmarty]the initial token fetch includes an expiry so in some ways the only thing a client might need to ask is whether the token has been revoked before its expiration, i think?
[Jamie_Tanna]For services I write I'd issue them client creds, although I've not technically done that yet for introspection so it's technically not secured fully
sknebel"the client will find out a token was revoked when it goes to use it and that fails" - now I want to go check which micropub clients handle that gracefully, i.e. not throwing away the post-in-progress
sknebel(although one can seriously argue if "return to client, get prompted 'hey I need you to login again'" or "reutrn to client, write post, post, get login prompt" is better UX, so maybe thats not a that good argument)
omz13at some stage I'll open up an API to toolbox; it will need an access key and, for kicks and giggles, I've implemented device flow to allow a cli to get it (which works surprisingly well but was an absolute PITA to have a smooth UI/UX)
omz13GWG, perhaps its best to think of toolbox as a mélange: it does some client things; it does some server things; it is a public and protected resource server; it is a full authorization server
omz13for example, toolbox as a private resource server: https://toolbox.imoxia.com/private/codecow will gate you, until you login... the more interesting bit are the headers it exposes, particularly www-authenticate
omz13[snarfed] it looks like you successfully identified yourself... and then a csrf checked failed; if you visit the root https://toolbox.imoxia.com/ are you into the main site?