<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">You should be able to run both openID 2.0 and openid AB/C as a provider.<div>Most of the large IdP will do that.</div><div><br></div><div>There are a number of risks in openID 2.0 the FICAM profile lists mitigations the US requires from OP and RP.</div><div><a href="http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf">ICAM OpenID 2.0 Profile</a></div><div><br></div><div>If you don't control the RP they can always get it wrong. That is not unique to openID.</div><div>One issue with openID is that extensions are not required to be signed. So some AX providers include the AX parameters in the signature and others do not.</div><div><br></div><div>That causes the RP to have to configure on a OP basis if they need to check the signature.</div><div><br></div><div>The logic s that the RP must know what AX attributes to ask the OP for and if they are self asserted etc so they can configure the signing as well.</div><div><br></div><div>This can lead to RP defaulting to not checking signatures for AX to increase interoperability. A good idea if you treat everything as self asserted. A bad one if they are counting on users not being able to modify those assertions.</div><div><br></div><div>If you are providing sensitive or verified attributes using AX, you need to think it through carefully. You also need to be certain that your RP understand what is going on. </div><div><br></div><div>OpenID AB/C will hopefully learn from openID 2.0 and make it harder for RP to shoot themselves in the foot.</div><div><br></div><div>If you are interested in the work, then join the openID AB WG.</div><div><br></div><div>Regards</div><div>John B.</div><div><div><div>On 2011-04-15, at 8:27 AM, Kleber - Corujito wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Nice.</div><div><br></div><div>then would it be something like this?</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div>Some day our Provider should implement OpenID AB/C and still support OpendID 2.0 (I hope OpenID libs help us).<div>
For 2.0 RPs we would return information through AX that we assume a risk of eavesdropping.</div><div>For RPs using OpenID AB/C we would pass all information that we want.</div><div><br><div class="gmail_quote">On Thu, Apr 14, 2011 at 7:31 PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">You have identified one of the reasons openID 2.0 doesn't qualify for LoA 2 (SP-800-63).<div>
<br></div><div>There is nothing in AX by default, You would have to build something custom, then you have interoperability issues.</div><div><br></div><div>The proposed openID AB/C spec or whatever the final name will be avoids this in two ways.</div>
<div>1. with the Web server flow the attributes are directly retrieved by the RP from the IdP using a oauth 2.0 token. </div><div>2. There will also be an encryption option for JWT tokens that contain claims.</div><div>
<br>
</div><div>Most things will just use the direct retrieval (1).</div><div><br></div><div>John B.<div><div></div><div class="h5"><br><div><div>On 2011-04-14, at 6:18 PM, Kleber - Corujito wrote:</div><br><blockquote type="cite">
<div>Thanks John,</div><div><br></div>we are uncomfortable with some information (like user's email) being passed plain text through redirect. We don't want this information be able to eavesdropping.<div><br></div>
<div>I understand from your answer that there is nothing to do about that in openId or AX. Am I right?</div><div><br></div><div><br></div><div><div class="gmail_quote">On Thu, Apr 14, 2011 at 6:07 PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">The SREG 1.1 spec for openID 2.0 is unofficial but used. <div>Some people still use SREG 1.0 with openID 2.0 but that is not spec compliant.</div>
<div><br></div><div>The only official standard to pass attributes is AX in openID 2.0.</div><div><br></div><div>By default they are not signed or encrypted, so the values can be modified by the user. </div><div>This was considered OK in the design because all the attributes are self asserted.</div>
<div><br></div><div>The IDP can easily make the AX parameters part of the signed body of the assertion.</div><div>However you may find that RP are not necessarily checking for that.</div><div><br></div><div>Any encryption would need to be custom.</div>
<div><a href="http://openid.net/specs/openid-attribute-exchange-1_0.html" target="_blank">http://openid.net/specs/openid-attribute-exchange-1_0.html</a></div><div><br></div><div>openID Connect has merged into openID AB. We expect to circulate draft specs at IIW.</div>
<div>It will have more of the features it sounds like you are looking for.</div><div><br></div><div>The mailing list is:</div><div><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></div>
<div><br></div><div>John B.</div><div><br><div><div><div></div><div><div>On 2011-04-14, at 4:28 PM, Kleber - Corujito wrote:</div><br></div></div><blockquote type="cite"><div><div></div><div>Hi guys,<div>
<br></div><div>We are building a new OpenID Provider. It works, but we would appreciate some security tips. Can you help us? :)</div><div><br>
</div><div>we read AX and SREG specs and we wonder if is there another way to pass user information from Provider to RP?</div><div>We were figuring out if parameters could be passed in a encrypted way.</div><div><br></div>
<div>is there something from openid community that we are missing? I read from <a href="http://openidconnect.com/" target="_blank">openidconnect.com</a> some time ago that it is considered 'openid 3.0'. Should we implement it?</div>
<div><br></div><div>Thanks</div><div>-- <br>Kleber Manoel Infante (Corujito)<br>
</div></div></div>
_______________________________________________<br>general mailing list<br><a href="mailto:general@lists.openid.net" target="_blank">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>
</blockquote></div><br></div></div></blockquote></div><br><br clear="all"><br>-- <br>Kleber Manoel Infante (Corujito)<br>
</div>
</blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>Kleber Manoel Infante (Corujito)<br>
</div>
</blockquote></div><br></div></body></html>