RE: FOAF SSL success, form windows RDFa (via linked data)

ok, so since there is so little time left,

 

the SAN URI has http://foo/x#me (for now).I will assume validators will not follow any HTTP code other than an 200.

 

 

The service locator for the cert:key ( in its ASN.1 subjectpublic blob form, within the cert, as encoded using DER) in question can point to a service access point, and endpoints can refer. They can refer to other endpoints in the normal course of re-locating service delivery access points, or make 303 types statements (which I failed to mint, after an hour of trying, since ASp.NET MVC3 just doesnt want me to).

 

I note that I have two choices, for the URI I put in the service locator :

 

if I put this: http://uriburner.com/about/id/entity/http/idweb.cloudapp.net:8080/Home/About, im expecting the UA to use content negotation, and pull down its teh object in favorite encoding rules (much like any layer 6 psap, negotiating the presentation data value (PDV)). Im goint to assume asking for the RDFa access type is not advised, here

 

If I am a browser to said URI, I will get a redirect to another document in human readable HTML

http://uriburner.com/about/html/http://uriburner.com/about/id/entity/http/idweb.cloudapp.net:8080/Home/About

 

Whats more, its RDFa parsable, at least for doctypes etc.

 

I think this means that I put in

 

1 SAN URI: http://idweb.cloudapp.net:8080/Home/About#me

 

2 and subject identity URI:  http://uriburner.com/about/id/entity/http/idweb.cloudapp.net:8080/Home/About
3 and subject identity URI:  http://uriburner.com/about/html/http://uriburner.com/about/id/entity/http/idweb.cloudapp.net:8080/Home/About

 


A validating agent can pull its favoriate machine-centric PDV from 2. A RDFa-aware validating agent can pull alternatively from 3. It may be possible for a VA asking for text/html or application/xhtml to get redirected from 2 to 3.

 

By some magic I dont understand, a validating agent can also get from

http://uriburner.com/about/id/entity/http/idweb.cloudapp.net:8080/Home/About to the equivalent of an XRD, identifying service access points. This seems to involve some somehow posting arguments that induces the page to morph to a different rdf type as its basis.

 

Finally, on the HTML form of the serice deliver page (3), we see such as 

 

http://uriburner.com/rdfdesc/oat/crypto.js
http://uriburner.com/rdfdesc/oat/xpath.js
http://www.facebook.com/dialog/oauth?api_key=172525162793917&app_id= ....

 

here we see that the RDFa page is more thah a mere serialization alternative, for a PDV. Its even IS a service client implementation, and can be bearing such as the javascript for the very SSL client implementation that will now make use of the access points.

 

very very nice.

 

This is a variant of what I wanted to do a long time with someone from javasoft long time ago (that Bellovin crushed), in putting javascript into the cert's HTML extension, making the cert into a mobile page - with its own implementation of the service access method it keyed.

Received on Tuesday, 10 January 2012 01:30:56 UTC