Re: WebID proxy?

Could a browser extension [1] provide the bridge?

[1] https://en.wikipedia.org/wiki/Browser_extension

On 20 October 2015 at 18: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:
>
> [[NOTE: This is an Etherpad originally written at
> 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
>
> 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 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>
> 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
>
>
>
>