[foaf-protocols] double validation. My windows code for webid can finally use myxwiki AND foaf.me. thanks Kingsley!
home_pw at msn.com
Sat Mar 26 17:55:29 CET 2011
Using .p12 credentials from a year ago from myxwiki (and imported into
Opera), I can logon to foaf.me still, using foaf.me implementation of the
webid spec's VA process. Direct Operate to the "simple logon" resource, and
the foaf.me. foaf.me acts as the validating party for the rest of the
website, accesed then using the home page.
If I logout from the site, I can go back to the home page. I'm then
redirected to an IDP selected by the foaf.me site. The IDP can also
authenticate me (and I assume create an IDP session). Its slow, but it does
relay that remote validation statement back to foaf.me, using a signed
websso message. Foaf.me creates a session. The UI does not differentiate
whether the "session" is due to reliance on a remote IDP's validation
activity, or reliance on the local foaf.me validation activity.
Using opera, I was also able to create a new webid (+ client cert) on
foaf.me, that does the same as above.
So, with 2 credentials in opera (one issued by myxwiki last year, and one
issued by foaf.me today), I can also now create an https tunnel to my own
win32 https endpoint, from Opera.
My server is a command-line windows server, and uses uriburner for all
semseb activity - per Kingley's latest query. This is just Henry's query,
suitably marked up for Uriburner's Query - which now acts as a data service.
In summary, my server consults the uriburner data service remotely, which
further remotely pulls the foaf card identified in the query. It returns a
simple sparql result set of mods/exps from either the RDFa of mywiki, or the
XML/RDF of foaf.me - depending on which SSL client cert credential is "in
effect" in Opera. My own code then compares the first binding against the
cert's pubkey (where the mods are mapped into base64, and the exps are
mapped into a .NET INT64).
So finally (after trying on and off for a year), I have my "FOAF+SSL" code
working again. It all broke when we introduced RDFa, if you recall - since
the windows semweb lib I was using then had no RDFa capabilities - and had
zero likelihood of ever getting them. Virtuoso has saved the day, acting as,
ahem, a data service, delivering some XML as a resultset.
It's all very trivial .NET code - which is the good news - and Ill post the
project later. Its simple . because uriburner and its Virtuoso server is
doing all the semweb work. (Thanks!)
I'd be interested in a volunteer who would run my command-line server on an
i386 mac, as a windows binary. I've no idea what would happen on that
platform (when running windows in parallel with unix), since I augmented the
server's VA from the webid spec with an optional experiment. The endpoint's
cert validation interceptors will make two queries: one to a windows cert
store, and one to uriburner. If the client cert is not present in the cert
store, the admin of the server is prompted (interactively) to store it (in
the "personal" trust list store of the admin user's windows account, not
that same principal's root store). When this happens, then and only then is
the webid VA process performed - as secondary opinion. Both tests must pass,
that is, for the (windows WCF) authorization/trust process to allow the
https channel to fully form. Obviously, Im trusting uriburner to make true
statements itself, and to be detecting tampering with foaf data communicated
on the wire between uriburner and the foaf card data source.
Now, the https endpoint front a simple restful web service. And, per
architecture, the web app is entirely stateless. So, there is no concept of
login/logout - just authenticate/authorize. Formally, if you can
authenticate to the https endpoint, then the http request will be delivered
to the webapp. So there is state, but its SSL SessionID state managed by the
There can be MULTIPLE endpoints for the webapp, note (each with distinct
SessionID state). I intended to experiment with this, later today.
If one goes to the same endpoint twice from the same opera client tab, one
can repeat the service call, with no additional cert-picker popup by Opera.
Whether a full handshake is occurring that 2nd (nth) time, I don't know. It
may be that the server framework provides stored SSL session state (stored
server side) to the WCF interceptors, rather than inducing a new client
authn signature to be generated, to prove current possession of the private
I'll now work on figuring how to induce the SSL close protocol to fire,
using .NET, in its WCF/Webinding profile. This will help me understand webid
and "logout", in a pure, restful architecture.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foaf-protocols