It works, but I still want to scream.

I created yet another web role in Azure, discarding MVC (thinking it to be a hinderance). The master site template and the page from the MVC project were simply moved over to a classical ASP.NET project. The Home/About resource from the MVC world is now /About.aspx. produces  the following view in a browser. To the relatively named subject (#me) I bind a webid cert:key predicate whose value is a reference to structured entity of the RSAPublicKey type. With an anonymously named subject, this latter entity has two further predicates: the modulus and exponent. These predicates each bear a property (a value type) constraining the object value – much like a particular relation between actual entities in the ER world can have properties.


Click here to execute the render a sparql query concerning the graph:


The result is:


mod exp s

in the entity whose subject name is “”, note the uriburner prefix (to what is now a “proxy” URI). Viewing this URI in the browser shows:


Now, lets create a cert with two SAN values


When we use this value at FCNS we still get errors:



We did learn something about linked data (finally) though, in the sense that the uriburner page reveals how it wraps or “connects” to my underlying page. Not only does it cache, but it describes it further. If nothing else, it describes the method it uses to crawl my triples into “my” local triple store in my “dataspace”. This is all very nice, except that webid doesn’t work.

So, let’s now take some advice and replace the relative names “#me” (in the underlying triple collection) with absolutely named triples.

We start with


and (having edited the master document for the foaf:primaryTopic reference, similarly) we end up with


Understanding that my data space in ODS is a wrapped copy of my “connected” data source, where all identifiers are proxy URIs (including such as foaf namespace), presumably ONLY the ODS-based webid validator can take advantage of this particular triple store – knowing to do webid queries in this “connected” context.




Does this mean the same cert works at FOAFSSL, or FCNS? Well… sort of. It’s all relative (and upside down, and twisted inside out).






We can guess that FOAFSSL is able to reason with the more advanced triples in the openlink reference, and tune up its query to validate the cert against the linked data version of my “connected” profile – though it cannot do so against the original source.


About home_pw

Computer Programmer who often does network administration with focus on security servers. Sometimes plays at slot machine programming.
This entry was posted in webid. Bookmark the permalink.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s