Posts tagged with: issue

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.