W3C home > Mailing lists > Public > public-xg-webid@w3.org > April 2011

Re: How to request a WebID?

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 06 Apr 2011 16:47:19 -0400
Message-ID: <4D9CD157.1050608@openlinksw.com>
To: peter williams <home_pw@msn.com>
CC: 'WebID XG' <public-xg-webid@w3.org>
On 4/6/11 4:16 PM, peter williams wrote:
> The single biggest road block I have is that my realtors take their personal
> laptop into their brokers office where they rent desk space (having just had
> webid working fine, over starbucks wifi); and webid stops working. That's
> because the larger corporate brokers run firewalls that intercept https -
> which breaks webid.
> This is the reality of my user group ; they are half corporate, half
> consumer; being intensely mobile. Though their laptops are windows home
> edition (or worse), which they connect to enterprise lans - at which point
> the DHCP service auto-issues the PC LAN connection a new web proxy endpoint
> - which then does the https interception (and thus the webid interference).
> To talk to the broker's sharepoint LAN site (which delivers them their
> broker backoffice tools), they have already imported the broker's root cert
> (issued by the local Microsoft CA). So the proxy (based on the same root)
> appears seemless to them, as it spoofs the real https sendpoint.
> Being consumer-grade users, they they just will not tolerate something
> working and not working, depending where they plugin their PC. They probably
> don't give a damn about the friendly broker doing the interception thing
> (the whole liability handoff thing is part of the realtor/broker handshake).
> Now, technically, we may have to develop a layer 7 bridge, in which one can
> post SSL messages over HTTP POST, to tunnel **past** the "interfering" TLS
> web proxy. This is perhaps where the ssl client built in a page's javascript
> comes in, I think.
> So Long as ONLY the client authn https handshake is tunnelled OVER the
> https-intercepting/interfering firewall, I don't think there would be any
> objection to a layer 7 SSL deployment that bypasses the intercepting proxy.
> Realty brokers (enforcing legal regulations on spying, snooping, data
> retention, etc in order to cover their very major financial liabilities) can
> still insist most "transactional use case" https traffic is intercepted.

What about IPv6 with IPSec enhanced with WebID? Could the move to IPv6 
be an alternative route via WebID tweak of IPSec?
> Ok, this is the art of making research into a product someone wants to buy.

Yes, but also one of the more extreme since the whole world needs to 
unshackling from myopic data silos that already pervade the Web.

I think being able deal with the following already hits the opportunity 
cost palpability mark:

1. Sharing resources across Depts
2. Ditto across Divisions
3. Ditto across InterWeb.

On the personal front:

1. Sharing ACL protected resources across InterWeb -- photos, music, 
videos, bookmarks, calendars, addressbooks, reports etc..
2. ACL protecting comments - blogs, wikis etc..
3. Smart notification services -- SemanticPingbacks vs broken Web 2.0 
4. Inbox reclaim -- WebID enhanced S/MIME (which we've already 
implemented successfully).


> It has to actually work in the reality folks live in, not research reality.
> I don't mind selling the future a bit (to show the movement has 5+ years of
> momentum), but it HAS to actually work, today.
> Ok. Is there anything a browser vendor can do to help enable SSL engines -
> running in javascript?
> For windows for example, they can make the SSL ciphersuites available to the
> COM API usable by IE-hosted pages, so the platform's primitives deliver the
> specialized SSL HMACing, and the sessionid caching, etc
> -----Original Message-----
> From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
> On Behalf Of Kingsley Idehen
> Sent: Wednesday, April 06, 2011 9:21 AM
> To: Peter Williams
> Cc: WebID XG
> Subject: Re: How to request a WebID?
> On 4/6/11 11:58 AM, Peter Williams wrote:
>> Using the myxwiki as a test platform, I found something strange:
>> Having used opera to enroll and the export the credentials to a . P12
>> file
>> 1 I could complete webid using an opera browser on several versions of
>> windows (having imported the .p12)
>> 2 I could do the same with install versions of ie 8 and 9 (after .p12
> import).
>> 3 on the same pc as the ie case, my own https client will fail to complete
> webid - using the same certs as available to ie. (all acls, etc, were
> addressed). Something in the webservice client/server lib for the x509token
> validator  behavior  seems to prevent the cert bring used (even though it
> supplied as the desired cert at the API).
>> If I guess, it's because the cert from myxwiki is missing the pkix client
> authn oid. But this is only a guess. I cannot easily tell where the enforcer
> might be: whether it's clientside or serverside enforced.
> Peter,
> I assume you are repeating these tests using:
> http://id.myopenlink.net/ods ? I would appreciate QA and feedback re.
> that ODS based service too.
> You should be able to use IE, Safari, FF, Opera, and Chrome.
> Safari, IE, Chrome, and FF (plus .NET extension) will talk to the local host
> OS key store.
> Opera and FF (modulo .NET extension) use their own stores.
> Kingsley
>> On Apr 6, 2011, at 8:29 AM, Henry Story<henry.story@bblfish.net>   wrote:
>>> On 6 Apr 2011, at 17:18, Peter Williams wrote:
>>>> What l learned by trial is that not all browsers use the hints in the ca
> message of ssl. Others use it, quite literally. Both behaviours are
> conforming, as the message contains hints (only) by design. Your
> implementation may cue off the hints, or it may ignore them. Opera ignores.
> Ie uses. I dont know what safari does. I don't know what 10 browsers in
> iPhone-like phone browsers do.
>>> That's what we need a precise description of. Which browsers do,
>>> which don't. If enough do it, then it may be worth working on this. It
> comes up regularly.
>>> So I'll add to the issue that it requires working out which browsers this
> functions on.
>>>> In my https client, I uses a STD dialog of windows, also used by ie I
> suspect. The dialog allows several selectors, each of which constrain which
> of the certs in a users personal trust store are shown. (I don't know if
> this works on a windows phone, though.) Two options are natural (they are
> the kind of knowhow a security professional would be expected to show, on a
> certification test): using cert policy oid (as selector), using application
> policy oid (as selector).
>>>> There is another angle: whether any and all (selected) certs should be
> shown that match, or only those that have the netscape (or better the iso)
> client usage oid. But this begs yet another question: must that extension be
> marked critical? If it's not, an implementation is entitled to ignore it's
> hint. Thus unit test for client tend to be platform specific, unless one is
> careful.
>>> The Java libraries I have been working with add the netscape client
>>> usage oid. Anyone testing should try to get an idea of how each
>>> browser works currently, taking those into account. The we can see where
> we are starting from.



Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Wednesday, 6 April 2011 20:47:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:43 UTC