Posts tagged with: indieauth

So, in my interpretation, @gRegorLove is issuing a token to my user...wpdev.gwg.us, but in his, he's issuing a token to his user that I'm allowed to use. I'm assuming his conception is based on his being the owner of the resource.

In my interpretation, when I grant a token to a client like indiebookclub, I’m issuing the token to that client and the token has my information in it. Similarly, with Ticketing, I’m granting a token to an individual site and the token has my information in it. In both cases the token is used to access something on my site.

I’m open to do this differently, but currently I don’t understand why it would be different. The issuer, subject, and resource seem to communicate all the information about who the token is for and how to use it.

Some more context: this is specifically for Ticketing. I’m testing from staging.gregorlove.com and sending tickets to wpdev.gwg.us.

In my mind, sending a ticket to someone is analogous to an IndieAuth Client redeeming an authorization_code — both an authorization_code and a ticket are redeemed for an access token. As a result, my implementation for generating the access token hasn’t changed for the Ticketing flow so far. My access token response includes a me property of staging.gregorlove.com.

David’s implementation is apparently expecting that me property to be wpdev.gwg.us so he can identify which user the token can be used on behalf of (thinking specifically of multi-user environments like WordPress).

It feels odd to me to return someone else’s URL in the me property. It seems like the initial subject sent with the ticket should be verified by the recipient and used to determine the user on the site before redeeming the ticket. If a valid user isn’t identified, it should return an error instead of trying to redeem the ticket.

I think the main use for the me property in the Ticketing flow, so far, is as a reminder which site the access token can be used for. It might be displayed in an admin interface, for example.

I’ve implemented this: my ticket_endpoint will accept a (currently optional) iss parameter. If that’s included, the endpoint will check that the issuer URL advertises indieauth-metadata endpoint and is valid as described in the spec.

I think I like this solution to the privacy concern. It also avoids the overhead of advertising endpoints on multiple resource URLs. So I lean towards requiring the iss when sending a ticket. However, I’m not sure how many implementations might send an issuer URL that does not advertise the metadata endpoint.

I now have the building blocks for Ticketing for IndieAuth set up.

On my staging site, the metadata endpoint now advertises the ticket_endpoint. That endpoint is accepting POST requests with parameters: ticket, resource, and subject. If the request is valid, it will be stored and return HTTP 202 with the message “Accepted.” Tickets are not automatically redeemed yet.

In the IndieAuth module admin, I set up a page to issue a ticket by entering a URL for “Allow access to” (the resource) and “Send ticket to” (the subject). Submitting that form will check the subject URL for an indieauth-metadata endpoint that advertises a ticket_endpoint. If that is found successfully, a ticket is created and sent there.

Finally, I updated the token_endpoint to accept POST requests with grant_type=ticket and exchange the ticket for an access token.

Next I will be working on automatically redeeming received tickets for access tokens and setting up some private posts to work with granted access tokens.

I am currently using the same code that generates authorization codes to make the tickets. I think this should work fine because it already handles creating an opaque string that is valid for a short period of time (5 minutes). The module also ensures these can only be used once and logs key information for each request like client_id (source code). I need to run some tests to ensure tickets can’t be used as authorization codes and I might need to add some metadata to differentiate the two in the admin area.

Feel free to try to send a ticket to my staging site and ping me in IndieWeb dev chat. I can also send you a ticket if you’d like to try that out. I look forward to discussing this with other implementers!