Extension to Allow Clients to Get Tokens Secured by Ticket

[dshanske]

Want to start discussing this.

Proposing a simplified way for a client to get access to the token secured by the ticket endpoint. Starting with the autoauth solution, suggest that the client, in a user initiated interaction, needs to secure a token with a scope that gives it permission to retrieve tokens, let's say scope 'external_token'. We already have a flow for this, so no changes are required.

So, using the example of a social reader application, when you configure it, you grant it, or don't grant it permission to retrieve external tokens.

Then, the client would use that token, with the scope, to request it be given a copy of the stored token. That would likely be at the token endpoint for the user they are obtaining it on behalf of, with a new grant_type, providing the token that authorizes them to get these tokens, the client_id of the client requesting it, and the resource the URL the token allows access for.

Just started thinking about this, so a bit rough.

[dshanske]

@Zegnat commented that overloading the token endpoint might not be the best idea, and having a query to the ticket endpoint with the previously mentioned bearer token might be better

[dshanske]

If we end up querying the ticket endpoint, then it would have to be another POST request, with a bearer token with the 'external_token' scope in the Authorization header, with the resource URL, and it would either return the access token it previously got or error.

Or alternatively, to match the syntax of token introspection, it could be a POST request with the token supporting the external_token scope in the body instead? For example, token=xxxxxx&resource=https://example.com with the response format being equivalent to the IndieAuth access token response, with the added elements of resource

[dshanske]

Actually, looking, token introspection uses aud, not resource. Too many changing parameter names.

[dshanske]

By using the token introspection language, we mirror what we're introducing into the token endpoint, and it ends up being a similar flow to implement. But, debating the POST formatting. Which makes more sense?

1. POST with token as a parameter, similar to the format of introspection? In introspection, the token parameter is the one you want info about. In this, it would be the one you are using as authorization to get a token. So maybe not.
2. POST with the token in the Authorization header? This is more consistent with an authenticated request, except that would mean the only parameter would be resource. And in that case, we have the issue of the ticket send flow being a POST request using 'ticket', 'resource', 'subject'? Would there be an issue with this just having resource?

Also, looking at the discussion on the refresh_token flow, @aaronpk pointed out that client_id is a mandatory parameter in that flow, even though it should be associated with the token already, for various reasons. So that would suggest in this context, subject should be a mandatory parameter. Client_id probably should as well, because the client would be issued a token giving it scope to request these tokens stored in the ticket endpoint.

Decisions, decisions...

[dshanske]

Wonder if the flow for getting an introspection token #99 should match the proposed flow for getting a token to retrieve external tokens.