RE: neither FCNS nor FOAFSSL can read a new foaf card (hosted in Azure). RDFa validators at W3C and RDFachecker say its fine...

I have spent a few hours getting really to grips with both ODS and linkburner. 

Certain things are VERY straightforward.

 

I logon with a password, and then map a cert to the account (just like in windows). And, I can use the ODS builtin CA, to mint a second cert with a variety of browser plugins/keygentags. The net result is I can do https client auhn to ODS, replacing the password challenge. Technically, a cert-based login to ODS may even count as an act of webid validation (rather than mere https client authn based on fingerprint matching).

 

Next, the account gives me a profile page. For any n certs registered (with logon privileges, or not), the profile publishes cert:key. Well done. From cert, infer cert:key. For a third party cert, I can now reissue it (same pubkey) adding the ODS profile URI.

 

Then I got a real feel for sponging an html/rdfa resource. The proxy prpofile/URI is essentially a new profile, borrowing bits from the "data source" that it screen scrapes. It has nothing to do with the accounts' own profile page. The resultant profile has a proxy URI, and one can put this in the SAN URI set of the cert whose pubkey was in the the original data source (and now in the proxy profile).

 

I altered by http://yorkporc2.blogspot.com/ template/page. It now as a webid.cert relation/link. Its a data URI, of type cert... with base64 blog content. Ideally, sponger would now infer cert:key from that link (but not any webid/foaf material), much like ODS profile inferred cert:key from its store of mapped certs/accounts. It would sponge the rest of the foaf card as normal.

 

I was able to use the ODS webid validator to validate against my cloud/azure hosted TTL card.

 

I was able to run sparql queries on my yorkporc HTML and TTL resources. I now understand (finally, after 2 years) why the sparql query for HTML gives the proxy name for the subject (with cert:key) rather than the data sources URI. Im really doing sparql against the proxy profile (not the data source), despite the FROM clause in the sparql identifying the data source. When one uses a non sponged resouce (TTL), the sparql result is more insituitive as to subject names.

 

i went through all the product documentation.

 

I learned that you are using the foaf:account as a mapping mechanism (not merely a publication device). If one uses facebook websso to authenticate, it maps to an ODS account whose foaf profile publishes said foacebook account name in a foaf:account property.

 

I suspect (but could not confirm) that the foaf:openid similarly enables an openid identifier presented in openid websso to mapto a ODS profile, on login authentication. O failed at any UI to get the system to act as an openid relying party, talking to my http://yorkporc.wordpress.com's openid server.

 

The built in openid server (that uses a webid challenge) is confusing. I dont know if the webids and profiles that it vouches for are limited to those in an ODS profile, in a proxy profile, or are for any other public webid (for which a proxy profile is immediately created).

Received on Wednesday, 28 December 2011 05:38:15 UTC