Closed aaronpk closed 12 months ago
What would the use case be? Just like OAuth authorization codes, these are extremely short lived and there is no recourse if they expire other than starting over
Jamie Tanna wonders if this is more about allowing the granted token to expire? That should be clear when redeeming the ticket and receiving an expires_in in the response from the token endpoint, and the optional presence of a refresh_token
Related #81
The only reason I can see to add an expiry time to the ticket is if you want to tell the system how long they have to redeem it. This isn't an issue if you automatically redeem all tickets(which I did in my test implementation), but it is an issue if you want the owner of the ticket endpoint to review the invitation first.
I don't see a use case for rejecting a ticket granted to them; they could simply opt to not use it after it's been granted.
Like, the whole point to TicketAuth seems to be avoiding having any sort of follow request flow in the first place.
@jamietanna, @fluffy-critter Are we fine with closing this question?
@jamietanna If you concur, we can close this?
To confirm, my view is that tickets should be short-lived (i.e. 60-180 seconds), to ensure that they're auto-redeemed, and if not redeemed in time, they can be reissued if needbe.
@jamietanna This question is about whether it should be returned, we're in agreement that it should expire.
I'm going to mirror the language about authorization codes in IndieAuth..https://indieauth.spec.indieweb.org/#authorization-response
Language is in the draft spec. This can therefore be closed.
(moving from the wiki)