Re: WebID proxy?

On 10/20/2015 04:40 PM, Anders Rundgren wrote:
> 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 :-)
>
Indeed, thanks Anders :)
Yes we implemented browser plugins to both accept and use Information Cards.
There were 2 approaches, one where all functionality was in the plugin,
and one where the plugin was very lightweight and launched an external
application that did all the work.

For our current WebID/SoLiD use case however, this isn't really an
option, we want it to work with any standard unmodified browser.

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