<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'>
I made the Microsoft ACS sso bridge succesfully talk to myopenid provider, using the (simple) instructions found in the claimsid codeplex site. This cloud bridge talked correctly to a second bridging site hosted at the RP site, fronting one or more RP applications. The tokens released to the final RP entity provied an evidence trail of all the bridge-rewriting activities, showing who asserted what, and who performs which acts of claims transformation. Some of the more advanced modes of ws-fedp are clearly on display.<BR> <BR>So, what this means is openid fits in well with the world of ws-fedp now - and for the first time in nearly 4 years I have openid talking to the world of real estate MLSs. I haven't had that since trustbearer folks ran a openid->SAML bridge for a while.<BR> <BR>Now, the myopenid OP site has a nice feature - that the user can authenticate to the OP using a self-signed cert (rather than a password). <BR> <BR>It would be a lovely example of a coherent national id plan if I could supply my own self-signed cert - one that bears a 3C/webid URI in the URI SAN field. Ideally, myopenid would choose to assert the value of the URI as a AX value (merely), which the ACS bridge could further transform into a claim, which my RP bridge could further validate perhaps according to the webid validation process. It would be a nice display of certs working with openid working with ws-fedp, working with a mjulti-tenant, sso-powered cloud app.<BR> <BR>Out of interest, aas anyone done a similar experiment using ACS ...where the flow includes a blog-site hosted XRDS file? Perhaps, one that showcases a user vectoring the ACS to the user-configured desired openid provider?<BR> </div></body>
</html>