<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">At the time the profile was authored the interpretation of SP-800-63 was that the assertion could not be passed through the browser unencrypted. <div><br></div><div>The SAML 2.0 Web SSO required that assertions sent from the IdP to the RP be encrypted.</div><div><br></div><div>The other method that was allowed in SP-800-63 was a authenticated direct connection between the IdP and RP, sometimes refers to as artifact binding (think OAuth 2 code flow).</div><div><br></div><div>Both methods protect the assertion from being MTM or otherwise leaked by the browser.</div><div><br></div><div>Subsequent to that based on an updated SP-800-63 the SAML profile was changed to allow the SAML POST response binding with only TLS on the endpoints and no assertion encryption. (xmlenc with CBC is broken anyway)</div><div><br></div><div>I <a href="http://www.thread-safe.com/2012/01/ficam-saml-20-web-sso-profile-updated.html">blogged</a> about the change several weeks ago <a href="http://www.thread-safe.com/2012/01/ficam-saml-20-web-sso-profile-updated.html">http://www.thread-safe.com/2012/01/ficam-saml-20-web-sso-profile-updated.html</a></div><div><br></div><div>There is a backstory to this, I will leave it to others to wonder why the change happened.</div><div><br></div><div>Suffice to say the reason openID 2.0 was rejected at LoA 2 is no longer valid under the updated interpretation of SP0-800-63. </div><div>I am focusing on openID Connect right now, so don't think there is much to be gained going back and fighting the openID LoA 2 battle again.</div><div><br></div><div>If others want to press NSTIC/FICAM to reconsider openID at LoA 2 then go for it.</div><div><br></div><div>The system is not always reasonable. You need to pick your battles.</div><div><br></div><div>Regards</div><div>John B.</div><div><br></div><div><br><div><div>On 2012-02-14, at 4:42 PM, Francisco Corella wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt">John,<br><br>> The thing that stopped openID 2.0 from being SP-800-63 LoA2 was the<br>> lack of protection of assertions from the Identity provider to the RP<br>> (No encryption or TLS protected direct communication)<br><br>In the FICAM profile of OpenID 2.0, which you co-edited, I believe the<br>assertions are sent with TLS protection from the IdP to the browser<br>and from the browser to the RP. I realize that's indirect rather than<br>direct communication. But why the insistence on direct communication?<br>The browser has to be trusted anyway.<br><br>Francisco<br><div><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new
roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight:bold;">From:</span></b> John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>><br> <b><span style="font-weight: bold;">To:</span></b> Peter Williams <<a href="mailto:home_pw@msn.com">home_pw@msn.com</a>> <br><b><span style="font-weight: bold;">Cc:</span></b> <a href="mailto:openid-general@lists.openid.net">openid-general@lists.openid.net</a> <br> <b><span style="font-weight: bold;">Sent:</span></b> Tuesday, February 14, 2012 9:30 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [OpenID] OpenID Providers Invited to Join in an NSTIC Pilot Proposal<br> </font> </div> <br>
Peter,<br><br>The thing that stopped openID 2.0 from being SP-800-63 LoA2 was the lack of protection of assertions from the Identity provider to the RP (No encryption or TLS protected direct communication)<br>The thing that also stops it from being LoA 3 is a lack of asymmetric signatures for non repudiation.<br><br>Support for PKI as the primary authenticator is the same for both openID 2 and SAML 2, and not one of the considerations.<br><br>OpenID Connect <a href="http://openid.net/connect/">http://openid.net/connect/</a> which is currently being voted on by the membership as an implementers draft addresses both issues.<br><br>One might reasonably expect that once openID Connect is an approved specification FICAM will produce a profile of it, perhaps upto LaA 3 non Crypto or LoA 4 with Holder of key.<br><br>There is also a openID Connect interop currently taking place amongst a number of the open source implementations
<a href="http://osis.idcommons.net/wiki/OC3_OpenID_Connect_Interop_3">http://osis.idcommons.net/wiki/OC3_OpenID_Connect_Interop_3</a>.<br><br>Foundation Members should read the proposed spec and vote for or against it as an implementers draft.<br><br>The reason for the implementers draft is that it locks in the IPR contributions of all the contributors (Google, MS, Facebook, and Me etc).<br>It also allows people to work on implementations without the spec changing weekly.<br><br>There will likely still be some changes from the implementers draft to the final version based on testing feedback.<br><br>We have been working on the specification in the openid-ab WG for several hers now so this should not be a big sup prise to anyone.<br><br>Regards<br>John B.<br>On 2012-02-14, at 2:09 PM, Peter Williams wrote:<br><br>> <br>> Well that was interesting.<br>> <br>> <br>> <br>> The shibolleth folks managed to setup a somewhat false distinction, 2+ years ago, with the help of several UK academics, to establish that
the "protocol" of openid (v1 or v2) was inherently limited to LOA1 - by design nature. One sees this division BUILT IN to the ETSI work on nationa-id cards for future-telco, very clearly. Becuase SAML2 CAN be used with PKI, it was able "uniquely" to claim a space of being LOA2+ capable.<br>> <br>> <br>> <br>> NOw we learn that "openid connect" is not openid-2 (with bells and whistles). its an LOA2-capable definition, per se. Not knowing what openid connect is, I cannot really comment... In our space, we are still considering whether to turn on openid as-is (via the Microsoft STS bridge for websso protocols). openid as conceived is almost viable (now), to boostrap a professional agency/representation relationship.<br>> <br>> <br>> <br>> This move-up to LOA2 is going to restart a SAML2 war, since openid is not staying in its place (supporting blogging comments, and logon to a billion sites that "dont matter" - a phrase that is (c)
UK academia).<br>> <br>> <br>> <br>> of course the distinction was false all along, but such are government programs - full of falseness and pretense and day-by-day political hashes. Its hard talking 2 storys out of your mouth at the same time - but thats what governing (and pre-competitive funding) is often all about. <br>> <br>> <br>> <br>> Perhaps folks here should all disclosure their "review" and 'influence" roles in the NSTIC program. John is quite open and fair and fully disclosed (if with a 6 month delay, so some proper use of FOUO can create effective working conditions for program management). Im not sure about others.<br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> _______________________________________________<br>> general mailing
list<br>> <a ymailto="mailto:general@lists.openid.net" href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>> <a href="http://lists.openid.net/mailman/listinfo/openid-general">http://lists.openid.net/mailman/listinfo/openid-general</a><br><br><br>_______________________________________________<br>general mailing list<br><a ymailto="mailto:general@lists.openid.net" href="mailto:general@lists.openid.net">general@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br><br><br> </div> </div> </blockquote></div> </div></div></blockquote></div><br></div></body></html>