new role: User's Proxy

[elf-pavlik]

Having unknown number of Resource Server to honor user defined access rules for all the applications they use can introduce various challenges. Among them all the Resource Servers need a way to:

• Identify application user uses Identifiers for applications #30
• Discover user defined access applying to that application
• Access those user defined and app specif access rules list of trusted apps should not be public #7

Moving all that responsibility to a single User's Proxy, which the user can choose, may simplify all the above. When application interacts with all the Resource Servers via user's proxy, all those Resource Servers only need to identify the user (not the application) and check if the user has required access mode to requested resource. User's proxy would have responsibility of applying app specific authorizations defined by the user. This would also partially address #34 since Resource Server would only respond with HTTP 403 to User's Proxy if user doesn't have required access mode. User's Proxy, which has full access to all the app specific authorizations, would detect missing app access mode without even making request to the Resource Server. User's Proxy would most likely have access to all the app authorizations managed with specialized app discussed in #29

[csarven]

solid/vocab#26

[elf-pavlik]

This approach shares some aspects with #47

I think we can achieve what we need building on access delegation framework like OAuth2 without need for suggested here proxy.

[bblfish]

As discussed at yesterday's meeting there is an interesting isomorphism in functionality between the role of the launcher app #45 and that of the proxy described here. What the launcher app does client side, the proxy does server side. There is a role for both options.

[elf-pavlik]

I think we can discuss many aspects of proxy approach independently of just one aspect of where it actually runs.

One of issues I find with it, it would require a lot of additional spec writing on how HTTP requests get forwarded, including handling of various kids of responses - redirects, errors etc. While on first sight it may seem attractive to look for an approach simpler than OAuth2, in the end it looks to me like slightly reducing complexity in one place by adding a lot of complexity in another place. I see such move especially disadvantageous in current status quo where OAuth2 has great adoption, stable specs, familiarity among developers, tons of educational materials etc.

Just to consider one example, can you describe how you imagine making HTTP GET request to https://alice.example/foo via proxy where alice.example responds with some 3XX redirect to https://alice.examlpe/bar ? I mean the part of interaction between the client and the proxy, the other part between the proxy and alice.example seems straight forward.

[zenomt]

unless the proxy runs in the user's web browser (or at least same computer), it might not have the same connectivity to resource servers that the user's browser would have. also it might not have the same list of trusted Certificate Authorities or trust rules for them.

[elf-pavlik]

@zenomt since you brought up multiple times aspect of asymmetric connectivity, could you possibly submit PR documenting relevant use case(s) you would like panel to take into consideration?

[zenomt]

@elf-pavlik sure, #54