Re: WebID proxy?

On 2015-10-20 10:48, Timothy Holborn wrote:
> Could a browser extension [1] provide the bridge?
>
> [1] https://en.wikipedia.org/wiki/Browser_extension

Definitely yes.

There's [almost] no end to what browser-extensions can do, the problem (IMO) is that
browser extensions so far have not made it as standards although some folks are trying:
https://browserext.github.io/charter/

Personally I'm working with a universal browser-extension scheme which can be studied here:
https://test.webpki.org/webpay-merchant

This prototyope (albeit for payments) is pretty much like a souped-up version of
Information Cards which I believe Markus have worked with in a past life :-)

Anders



> On 20 October 2015 at 18:36, Markus Sabadello <markus@projectdanube.org <mailto: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:
>
>     [[NOTE: This is an Etherpad originally written at http://piratepad.nl/eXd4UsVuaWon 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
>
>     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.
>
>
>     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).
>     - what exactly is the interface between the client and the WebID proxy?-- HTTP? (maybe using basic auth)
>     - how generic/specific to LDP/SoLiD protocols should this interface be?-- TBD
>     - 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.
>     - is the WebID proxy hard-coded in the browser app, or is decoupled/discoverable?-- Should always be discoverable. (in a Link header maybe?)
>     - can an app support both native WebID and WebID proxy?-- Definitely. Solid apps already do (this feature is built into rdflib.js).
>     - 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.
>     - 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.
>
>
>     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
>
>
>     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
>>>
>>>     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 (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
>>     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
>>>
>>
>>     __
>
>

Received on Tuesday, 20 October 2015 14:41:18 UTC