add redirect-url param

[zachferland]

Adding this param increases optionality for developers when choosing how they want to handle responses. It also allows the uport client to make less assumptions about the callee.

The libraries and uport client will still make default assumptions for default use cases but this allows developers to receive responses how they want and may encourage us to change our defaults if used in ways we did not expected.

Minimizing assumptions implicit in some of our params allows us to unbundle functionality/dependencies in our libs. Improving front/backend flow and allowing developers to eventually plug in their own modules.

This is proposed as the most immediate simple solution although there appears to be better overall solutions if we are willing to make other spec changes at the same time. Alternatives to this include:

• with ‘authorized callbacks’, CB could be removed from JWT and we could just have redirect_url and callback_url url params, while one or both could be specified at the same time (they would have to match one of the authorized CBs
• could specify both redirect_url and callback_url in JWT and allow for callback_type (url param) to specific redirect, post or both (cb & action selected based on that)
• could specify domain/base url in JWT and then allow redirect_url and callback_url url params (which must match base url/domain)

Notes:

• may be nice to allow additional data (params, url fragments) to be added to callbacks outside of CBs specified in signed payloads. Allows app context to be passed like sessions or to map req to responses. Although may allow CSRF attacks and server may be able to add these values if they want in the signed payloads instead still (JWTs) (although a question for authorized callbacks)

• in this quick suggested implementation, the redirect_url should match the base url/domain in the signed payload (JWT) How limiting is this requirement potentially (mobile app urls + servers?) ? might be better to just allow both callbacks to separately specified

• WIP since other pages will also be edited once a solution is chosen

[zachferland]

Moving this out WIP, since it looks like we decided on this option for now versus alternatives listed in the first comments. The other files have now been updated as well (cc @pelle). Should be all set to merge.

[bdresser]

@pelle @zachferland what's our process here? leave open until the work in mobile is complete? or merge now?

@pelle are your changes addressed & good to go?

[zachferland]

two additional comments/questions; 1: could just have redirect_url be defined as callback_url param added to "access_token" (token/signed request), tradeoff is param of same name (rather than new param), but less clarity. 2: seeing authorized callbacks added to specs as well, if these are being adding at the same time, implementation changes here slightly, but I think spec remains the same (cc @pelle )

edit: on second thought it makes sense to have both redirect_url and callback_url, as with authorized callbacks, the callback could be moved out of the signed payload and passed as callback_url, while you could still pass a redirect_url as well