[foaf-protocols] implementation specific discussion on webid; azure service bus
home_pw at msn.com
Thu Mar 17 00:12:50 CET 2011
Below, I say "Being atom, content types of various types can accompany the
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...
More information about the foaf-protocols