[foaf-protocols] implementation specific discussion on webid; azure service bus

[peter williams]

Below, I say "Being atom, content types of various types can accompany the
URI."

 

In Atom, can the content attached to a URI be a MIME multipart/alternative
content type? .such that to one URI might be bound in the atom stream 3
alternative streams of metadata: (i) the openid file (with microformats),
(ii) the foaf card, (iii) the XRD for hammarstack markup?

 

From: peter williams [mailto:home_pw at msn.com] 
Sent: Wednesday, March 16, 2011 12:18 PM
To: foaf-protocols at lists.foaf-project.org
Subject: implementation specific discussion on webid; azure service bus

 

What does it have going for it?

 

It has client-certs, with SAN-URIs.

The URI is discoverable on the web, using atom

Being atom, content types of various types can accompany the URI.

Presumably, this could include a foaf card.

 

Thus, the azure service bus could offer a way to deliver a million foaf+ssl
capabilities to a million folks, using the "remoting concept". The resources
they interact with would leverage the server-side of the bus as the client
side of the web.

 

Obviously, everything in reality is spyable. But, its better than the web
(where folks pretend it's all end-end https, but it is rarely due to the way
https CONNECT proxies and https SSL MITM agents really work).

 

Ok. I think I have an experiment thesis, a testable condition, and an
interesting implementation concept. Since I have to learn to program the
service bus anyways (to comprehend the role of this latest year's token
blobs), I might as well play with it in the FOAF+SSL/webid sense. I can
understand better how folks in the token world impose delegation semantics
on a server (now acting as client) - which is consistent with an W3C webid
IX issue anyways.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20110316/87cb3f25/attachment.htm