Re: WebID proxy?

> On 20 Oct 2015, at 08:36, Markus Sabadello <markus@projectdanube.org> wrote:
> 
> Thanks Henry. I think the redirect part of what you describe makes sense to me.
> But you say "a server can redirect to such a service, which authenticates the user using a client certificate".
> This is actually what we want to avoid, i.e. we want to authenticate the user in some other way, and have only the web service deal with WebID.
> 
> Sorry for the unstable Piratepad link. Since pads also expire at some point, I'll paste the contents here to make sure they are not lost:

Ah thanks: it helps to have the text available. 

> 
> [[NOTE: This is an Etherpad originally written at http://piratepad.nl/eXd4UsVuaW <http://piratepad.nl/eXd4UsVuaW> on Oct 19th 2015 by Markus S., Justas A., Eelco W., Joachim L. In the "Questions" section, answers are by Andrei S.)]]
> 
> A WebID proxy for restricted browsers
> ==========================
> 
> In July 2012, Elf Pavlik wrote about the idea of a "WebID proxy", which could enable non-WebID-capable browsers to use WebID via a hosted service:
> https://lists.w3.org/Archives/Public/public-webid/2012Jul/0069.html <https://lists.w3.org/Archives/Public/public-webid/2012Jul/0069.html>
> 
> This assumes that a session is somehow established between the browser and the WebID proxy. This can happen using any identity protocol, e.g. OpenID, Mozilla Persona, or even username/password or Facebook Connect.
> 
> We also assume that the browser's configuration cannot be changed. This rules out using traditional HTTP proxies (SOCKS, ...).
> 
> The WebID proxy holds the user's client certificate(s) and exposes an interface that a browser app can use for accessing LDP and other WebID-enabled resources.
> 
> Could also be called WebID agent instead of WebID proxy. Could also be called SoLiD proxy/agent.

yes, of course. That seems to me the best way to build the system - while always also making sure it would work without such a proxy. 

> 
> 
> Questions:
> ---------------
> - could be a part of CORS proxy on gold -- Yes, we are considering adding this feature to Solid servers). In fact, we are thinking of routing all requests through such a proxy, which would enable us to cache resources on the server. Also, one possible alternative is to use the delegation feature of WebID-TLS, in which the server (an agent with its own WebID) will run requests *on behalf* of the user (gold supports this feature already).

Yes, we need to work together on 
http://www.w3.org/wiki/WebID/Authorization_Delegation <http://www.w3.org/wiki/WebID/Authorization_Delegation>
and look at how workable that is.

> - what exactly is the interface between the client and the WebID proxy? -- HTTP? (maybe using basic auth)

It could be using WebID-TLS or other global authentication methods for open proxies, or even just username password for personal ones.

> - how generic/specific to LDP/SoLiD protocols should this interface be? -- TBD

For personal proxies it could be up to each service.
But there may be quite a few issues that we could agree to, that would make this a lot easier to think about.
I think we have a few implementations of proxies already.
One question that may be interesting is: would there be an avantage of using the actual HTTP proxy standards.
I think one would need to consider if JS can open to such proxies...

> - if a one-to-many mapping between user account and WebID is desired, how does the client "choose" a WebID? -- One would assume the mapping is handled by the server. The proxy resource (URI) can also be ACL'd.

We the Authorisation_Delegation wiki above.

> - is the WebID proxy hard-coded in the browser app, or is decoupled/discoverable?-- Should always be discoverable. (in a Link header maybe?)

Well you'd have a default that the user can change, like currently in your browser.

> - can an app support both native WebID and WebID proxy? -- Definitely. Solid apps already do (this feature is built into rdflib.js).

yes.

> - would such construction pose any security threats? -- My (Andrei) main concern revolves around transparency. I would like to avoid having agents use my personal credentials. Instead, agents should use their own credentials and allow me to delegate some work to them.  This helps servers take informed decisions as to who is really authenticating and how.

yes, it is easy to get things to work if the server pretends to be the user. But then that can create confusion.
But if we work with delegation this makes it more likely to fail. ( STill the user could then always access the 
resource directly )

> - should we use WebID-RSA instead of WebID-TLS in such construction? -- I don't think WebID-RSA is relevant in this discussion, since the reason for having this proxy is based on lack of support for client certs.

Btw, think we should move to support https://tools.ietf.org/html/draft-cavage-http-signatures-05 <https://tools.ietf.org/html/draft-cavage-http-signatures-05>
instead of WebID-RSA, and just specify how we tie the key to the webid.

Both have advantages, and they can work together. In fact my rww-play server should have 
both working this week, as I want to explore some features in the latest JS specs.


Henry

> 
> 
> People to talk to:
> -------
> - Melvin
> - Pavlik
> - Andrei
> 
> Places/Forums to post:
> -------
> public-webid@w3.org <mailto:public-webid@w3.org> mailing list
> https://gitter.im/solid/solid-spec <https://gitter.im/solid/solid-spec>
> 
> On 10/19/2015 12:47 PM, Henry Story wrote:
>> 
>>> On 19 Oct 2015, at 11:07, Markus Sabadello <markus@projectdanube.org <mailto:markus@projectdanube.org>> wrote:
>>> 
>>> Hello,
>>> 
>>> In July 2012, Elf Pavlik wrote about the idea of a WebID proxy that could be used without installing certificates on a client:
>>> https://lists.w3.org/Archives/Public/public-webid/2012Jul/0069.html <https://lists.w3.org/Archives/Public/public-webid/2012Jul/0069.html>
>>> 
>>> A few days ago at GET-D <http://get-d.net/home/events/getd-summit-hackathon-berlin-iii/> in Berlin, the Jolocom <http://jolocom.com/> team and others talked about this idea again.
>>> 
>>> So we wrote up the following pad with some initial thoughts and questions:
>>> http://piratepad.nl/eXd4UsVuaW <http://piratepad.nl/eXd4UsVuaW> (please re-try few times if not reachable)
>> 
>> I can't get that link to open.
>> 
>> On the whole this is a good idea. We used to have one online written in Java
>> https://github.com/bblfish/foafssl-java/blob/master/foafssl-identity-provider-webapp/src/main/webapp/login.jsp <https://github.com/bblfish/foafssl-java/blob/master/foafssl-identity-provider-webapp/src/main/webapp/login.jsp>
>> Now that I know a bit more about crypto, I guess in this protocol, we are missing the salt.
>> 
>> It is quite simple: a server can redirect to such a service, which authenticates the user using a
>> client certificate. If it succeeds the service then redirect the user to a URL indicated in the request, puts the URL in the header, adds a date, ( and should add the sale to avoid replays ), the server signs it
>> with its public key ( published at a URL ) and redirects the user back there. 
>> 
>> Perhaps someone can write this out nicely on a wiki, and we can have a little spec 
>> like that, so that people could use different providers easily. On the other hand the danger
>> is that this kind of spec quickly gets more and more complicated as people then ask for attribute
>> exchange and more features.  To keep it simple, one should require that the user of the service
>> at least haved an RDF parser so it can then GET the WebID and get the extra attributes.
>> 
>> 
>> 
>> 
>>> 
>>> Before developing this further and possibly duplicating efforts, we'd like to ask for feedback.
>>> Perhaps you could advise if this exists already, or if not, how to best approach it?
>>> 
>>> Markus
>>> 
>> 
>