<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'><div dir='ltr'>
<BR>I think you are right. In the openid sense, what matters is doing what the windows' cardspace process used to do - create a browser sandbox for security bridging. Then, we recall the early work (here) on enabling an openid provider to be bridged by such a process. The signed JSON/javascript work will help here, since the JSON 'output format' can represent a serialization of a particular (RDF) graph, and the javascript is script...that can use the web socket.<br><BR>If the script is implementing an SSL client, one can hide the contents of the socket's plaintext from the browsers/vendors - which/who, given the evidence, we must assume are in some pact with policing authorities. (I dont mind that, personally ; I only mind that its hidden and undisclosed, promoting thereby distrust in civil authority in an internet world - that amplifies fear)<BR> <BR> <BR><br> <BR><div>> Date: Wed, 12 Oct 2011 11:09:31 -0700<br>> To: home_pw@msn.com<br>> From: sysadmin@shadowsinthegarden.com<br>> Subject: Re: [OpenID] signed json in javascript, relationship to openid?<br>> CC: openid-general@lists.openid.net<br>> <br>> >What do folks feel about this? is this incompatible with openid? is <br>> >it part of the movements future? .. to re-cast the trustworthiness <br>> >of the browser itself?<br>> <br>> Signing discrete components of web-pages, through a script sourced <br>> from elsewhere, but providing the signature through the party that <br>> must trust your browser to run the right code? +1<br>> <br>> -Shade<br></div> </div></body>
</html>