On errors we now have an about and type link, both explaining the error. I’d love to add a link which doesn’t explain, but allows the end-user to solve the error.
For example, on a authentication error, I would like to point the end-user to a page to login.
I was thinking about naming it links.action or links.solve. I’ve also been thinking whether it should allow an array of links (e.g. login or sign up).
Anyone else finding that useful? Would this be a good addition to the spec?
Why would a backend that only returns JSON have to deal with how a GUI does authentication?
The web is finally separating backend APIs with web browser URLs. Don’t bring them back together! 
The authentication was just an example. A common one though, as application often have authentication go via another backend. However, I would say JSON:API is not only for backends which only return json. For me the backend doesn’t necessary live in isolation from the application for end-users.
For me it is very helpful if an api supplies end-user urls next to api urls. See for example html_url in GitHub’s response to an issue api (https://developer.github.com/v3/issues/#response-2). It allows the backend to stay in control of those urls, to change them when needed.
"url": "https://api.github.com/users/octocat",
"html_url": "https://github.com/octocat",
Notice how the domains are different. api.github.com is the API based on JSON and github.com is the API that returns HTML, CSS, JS, etc. This is fine.
But returning sometimes JSON and sometimes HTML on the same domain (API) is bad design.
Now, the links member is there for links within the rest of the API, not for other APIs.
If you really want to have these URLs in your JSON:API payload, they should be an attribute or part of a meta object.
I know it is a link to another domain. However, I don’t see that restriction stated in the spec.
If done while communicating a content-type I don’t agree it is bad design.