[foaf-dev] FW: cert policy extension URL - example as requested

Peter Williams pwilliams at rapattoni.com
Tue Apr 20 23:18:14 CEST 2010


Out of interest, did you ever implement a cert verification web API, in support of FOAF+SSL rollout?

If you recall, the idea was for a FOAF+SSL webserver to offload over https to an API provider responsibility to (i) receive a cert (or cert thumbprint, or cert url) + some kinds of rules identifier (to allow for customization, per requestor), (ii) perform any and all FOAF+SSL procedures, returning (iii) a Boolean?

Ideally, the web query protocol would be WRAP (since its so simple).

This is similar to work currently done by the foafssl.org website - except that said website merely takes a parsed-out webid  as input token (rather than the cert, as input token).

Its relevant because in the windows world, it's really quite easy to specialise the WebSSO libraries Microsoft are delivering to millions of programmers, allowing FOAF+SSL to "exercise control". If one sets the certvalidation=custom flag in the relevant webapp config file, the custom class could be calling the (wrap-style) API. Thus, all the foaf+ssl apparatus would "qualify" whether the SAML token signing cert (bearing a webid) supporting the signed SAML assertion/response is "valid", under the FOAF relying parties trust model. FOAF+SSL would be acting an interceptor that is, at the very cert validation/verification interception point built into the world of certs.

Not very pure, I know: but very applied. Lots of demand for FOAF files bearing trust stores of public keys would follow...


-----Original Message-----
From: Kingsley Idehen [mailto:kidehen at openlinksw.com] 
Sent: Monday, April 19, 2010 7:26 PM
To: Peter Williams
Cc: foaf-dev at lists.foaf-project.org
Subject: Re: [foaf-dev] FW: cert policy extension URL - example as requested

Peter Williams wrote:
> forwarding what probably bounced.
>
>
> ________________________________________
> From: Ian G [iang at iang.org]
> Sent: Monday, April 19, 2010 4:33 PM
> To: Peter Williams
> Cc: cacert-policy at lists.cacert.org; Peter Williams; foaf-dev at lists.foaf-project.org
> Subject: Re: cert policy extension URL - example as requested
>
> Hi Peter,
>
> On this surprising link, another community idea I'd never heard of!
>
>
> (cross-posting warning ... up to you to deal with it if it bounces :)
>
> On 20/04/10 4:08 AM, Peter Williams wrote:
> ...
>   
>> If there is a desire to make CAcert focus on novel trust models, there
>> is a good opportunity to match interests with the semweb folk, who are
>> finally get to groups with the practical engineering of the semweb for
>> problems of trust (without losing that central European idealism, that
>> are largely lost on Anglo/American societies). Culturally, I suspect the
>> two communities (FOAF+SSL community and CACert community) have a lot in
>> common.
>>
>>     
>
>
> Culturally, I suspect you are right.  But institutionally I think we
> differ a lot.
>
> My short view, having just read a few pages on FOAF (not sure SSL comes
> into it) is that they are trying to build an open Facebook / LinkedIn /
> Zoom, etc.  Yes of course they will disagree with that, but the
> institutional problem is that they are trying to build something that is
> already done for free elsewhere, and it is already controlled by
> big-corp.com, and controlled well (another disagreement).  So they have
> a world of pain ahead of them, because the network effects are against them.
>   

Hmm. In reality the network effects are against the likes of Facebook 
since they aren't actually imbibing the powerful essence of the World 
Wide Web :-)

Privacy is going to be the inflection point that unravels the frailty 
inherent in the approach taken by Facebook et al. That said, should they 
ever adopt FOAF+SSL they will actually be in the position espoused. What 
a paradox eh?

> Whereas we are trying something different:  our "tech" model is as you
> eloquently put it out there in the software, after 20 years of effort,
> just waiting to be used.  Our barriers are not so much the network
> effects but people-utilisation & scaling effects to meet the audit
> hurdle and etc, etc
>
>     ask now when your audit is ready,
>     rather,
>     ask how you are doing your audit :)
>
> Also, there has to be a nod to the mission:  are we protecting people's
> privacy and/or security?  Or are we helping them to export their most
> treasured assets, their network, for the benefit of others?  These two
> goals are somewhat at odds, and here at CAcert we haven't yet solved the
> privacy v. security dilemma as yet [1], let alone the P+S v. social
> network monster.
>   

Well FOAF+SSL solves both in a Webby way.

>
>
> Granted, if Verisign were to start doing free certs for all purposes,
> all the time, and Facebook were to charge $100 per year for each user,
> we'd suddenly be a lot closer in institutional terms :)  And nobody
> likes the other guy's drive-by criticism...
>   

Facebook could just as well mint WebIDs for its members and put those in 
FB certificates, and end up with what they really want.

Whoever figures out FOAF+SSL first will enjoy the real benefits of 
network effects consolidation and market position defensibility.

In reality, it highly unlikely a behemoth will grok what's at hand, and 
therein lie the opportunity for the next game changing Web oriented 
startup or smartup.

The great thing about the Web is its lack of an eraser. My comments are 
deliberately worded with the future in mind :-)
>
>
> iang
>
> [1] But we will, if we can get the programmes that are rolling out over
> the last couple of years bedded in sufficiently to build on them.
> _______________________________________________
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>
>   


-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 







More information about the foaf-dev mailing list