Usage of the Me Parameter in the Access Token Response

[dshanske]

This is the result of a conversation @gRegorLove and I had at IWC SD 2023 today.

In my implementation, I take the me property of the access token response and use this as the user identifier.

@gRegorLove pointed out this idea is not explicit in the specification. It is implied by the fact that the 'me' entered into the client need not be the same URL output as the 'me' parameter, however, which was my assumption.

Proposing that this be noted more explicitly in the specification.

[gRegorLove]

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.

(Originally published at: https://gregorlove.com/2023/12/some-more-context/)

[dshanske]

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.

(Originally published at: https://gregorlove.com/2023/12/some-more-context/)

I honestly believe that is what it is supposed to mean, thus the need for clarification in the overall IndieAuth spec, not just the Ticketing extension. Me is defined as "the canonical user profile URL for the user this access token corresponds to" which applies whether it is grant_type=authorization_code or grant_type=ticket by the way the spec is written. 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.

I agree with @gRegorLove that I should verify the initial subject before asking for a token and have done that. There is no point in collecting a token meant for someone has no role on that site. However, I still believe that for both grant_type flows, I should verify who the token is for in a multi-user environment with the me response, because that is who the token endpoint says the token is for. The ticket endpoint receiving a subject could be a way of a ticket endpoint deciding whether it will redeem the token or reject it, but I'm not sure it should be used to ultimately decide who to deliver the redeemed token to in a multi-user environment.

[gRegorLove]

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.

(Originally published at: https://gregorlove.com/2023/12/in-my-interpretation/)