[fluffy]Like, I parse their profile when they sign in anyway, so if their profile includes a ticketauth endpoint, that’s a good time to send them a ticket.
[fluffy]Hmm, so, I’m just noticing that the token_endpoint declared for the final leg of the transaction is using the IndieAuth token endpoint? What if someone needs separate token endpoints for IndieAuth vs. TicketAuth?
[fluffy]Like someone might want to use one token endpoint for a standard token grant for a Micropub client, but a different one for the Ticket Auth flow.
[fluffy]and I mean it’s not like Publ supports token grants for anything else just yet, and any interesting uses of that would still be Publ-specific, so yeah never mind
[fluffy]like the token auth for getting an authenticated feed would be on the main page (or at least on the root level of what people are subscribing to a feed of), and the token auth for getting a micropub grant would be on the category page of where they’d be posting, etc.
jamietannaI think we should clarify the Ticket Auth page to use a non top-level `resource`, as I feel it's adding a bit of confusion because that's where the `rel=token_endpoint` is usually referenced from - anyone got objections if I update it?
jamietannaIs there any reason we may want a different token_endpoint between profile URL and pages? If so, I'd say it's better to leave it back to profile URL checks which folks are more likely to do
[manton]In Micropub, I support paging through posts or media uploads via q=source, but I realized there’s no way to get the total number of expected posts (which would be useful for things like progress bars). Has anyone experimented with adding a “total post count” field somewhere?
GWGThe same way I added why short lived tickets, because when someone asked me that at HWC when we were chatting, I didn't have a quick answer ready that satisfied them
ZegnatNote that it is up to the person sending a ticket (you) to tell the ticket endpoint (potential reader) where to look for a token endpoint through resource. E.g. my current implementation always hardcodes the resource to my top domain, so that would be the only place I ever need to advertise my token endpoint.
ZegnatProbably tomorrow when I am less burned out, but it is on the list! I am first going to check why you are not getting an expires_in from my token endpoint...
jamietanna1Got what looks like a free day off tomorrow - hoping to get a ticket endpoint out for integration, although mine will require the `issuer` methinks, so may not work with others' out of the box
LoqiIt looks like we don't have a page for "Ticket Auth" yet. Would you like to create it? (Or just say "Ticket Auth is ____", a sentence describing the term)
LoqiTicket Auth is an extension to IndieAuth that enables a publisher to send authorization, known as a ticket, that can be redeemed for an access token https://indieweb.org/IndieAuth_Ticket_Auth
ZegnatGWG: I just found why you are not getting the expired_in. Stressed me only added it to the DB query, but not to the part where I actually return it in the body
ZegnatBut I can add support pretty easy, maybe even before create day this weekend. As I already support POST action=ticket. Just need to add a branch for action=revoke :)
ZegnatYou should only send a 200 if you accept the revocation. It is only whether you actually did a revocation or not that should not be signalled by the status
ZegnatIt is kinda interesting how the reason why revocation always returns 200 (so you cannot try to guess tokens) is a little unneccessary with IndieAuth where token verification exists so I can go and check tokens there.
ZegnatThis is also why token introspection spec expects clients to send along a token that specifically has the right to check tokens. So introspection is not public as it is in IndieAuth
ZegnatAt that point, it should just be dropped from the spec in favour of introspection. But that might make it harder for people to onboard. So pros and cons there.
jamietannayou mean to require token verification to be protected by some client credentials? May need to look at how OAuth handles public, credentialed clients
ZegnatNo, but the point is they can do it. And it is the reason why introspection spec says all info requests need to have their own bearer token included.
ZegnatSo you would expect resource servers to have a token for that and be able to inspect tokens. But random clients do not have that token and thus cannot get the info
ZegnatOff to bed with me now. I’ll see about adding revocation in the short term. And then it is time to add some sort of hidden data thing to my homepage when you send a token along.
ZegnatDumb thing is, the revocation support and everything already exists in my actual token endpoint code (MinToken), it just does not in this quick endpoint for ticket auth
hendursa1, jeremycherfas, [schmarty] and nekr0z joined the channel
@rowanmanning I just finished drafting a blog post that covers implementing Webmention on a static website. If this sounds intere… https://twitter.com/i/web/status/1412171439529238530 (twitter.com/_/status/1412171439529238530)
jamietanna I think we should clarify the Ticket Auth page to use a non top-level `resource`, as I feel it's adding a bit of confusion because that's where the `rel=token_endpoint` is usually referenced from - anyone got objections if I update it?
jamietanna1 GWG I think I'm leaning more towards not requiring token_endpoint to be set on every page
Zegnat Note that it is up to the person sending a ticket (you) to tell the ticket endpoint (potential reader) where to look for a token endpoint through resource. E.g. my current implementation always hardcodes the resource to my top domain, so that would be the only place I ever need to advertise my token endpoint.
Loqi It looks like we don't have a page for "Ticket Auth" yet. Would you like to create it? (Or just say "Ticket Auth is ____", a sentence describing the term)