Re: WebID proxy?

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 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
>>
>