<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal>With OAUTH-guarded endpoint going mainstream (in the likes of Microsoft Exchange MTA), we have been looking hard at what to do – with SAML2. The amount of SAML2 we do with partners diminishes by the month – and has been diminishing for years now. So mch so, that we no longer maintain the software for our SAML2 endpoints. At some point their crypto or other compliance will fall below some interoperability minimum. Either ADFS will fill the gap, or we will stop doing SAMl2 protocol.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Now, SAML2 assertions are not going the same way. And signed SAML2 assertions, in particular. Since token decoders for signed SAML assertions come built into .net, we even added a native .NET endpoint that can accept SAML2 (idp-initiated) responses bearing SAML2 assertions (signed). Furthermore, there is the ability to present SAML2 signed assertions as grant types to OAUTH access token endpoints (STS), that returns something suitable for an HTTP header supporting a lightweight web service call. We have been using some of this for a while now, for a next generation (realty) data listing and membership services – mixing OAUTH and SAML2.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Out of interest, is anyone in the Shib dev community also thinking in this vein – mixing and matching SAML2 assertions with OAUTH? .. so as to get the best of both worlds, particularly as websso browser world for pages supports websso for javascript-based web service calls.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>