[OpenID] Questions about security? :)

John Bradley ve7jtb at ve7jtb.com
Fri Apr 15 13:08:12 UTC 2011


You should be able to run both openID 2.0 and openid AB/C as a provider.
Most of the large IdP will do that.

There are a number of risks in openID 2.0 the FICAM profile lists mitigations the US requires from OP and RP.
ICAM OpenID 2.0 Profile

If you don't control the RP they can always get it wrong.  That is not unique to openID.
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.

That causes the RP to have to configure on a OP basis if they need to check the signature.

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.

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.

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.  

OpenID AB/C will hopefully learn from openID 2.0 and make it harder for RP to shoot themselves in the foot.

If you are interested in the work, then join the openID AB WG.

Regards
John B.
On 2011-04-15, at 8:27 AM, Kleber - Corujito wrote:

> Nice.
> 
> then would it be something like this?
> 
> Some day our Provider should implement OpenID AB/C and still support OpendID 2.0 (I hope OpenID libs help us).
> For 2.0 RPs we would return information through AX that we assume a risk of eavesdropping.
> For RPs using OpenID AB/C we would pass all information that we want.
> 
> On Thu, Apr 14, 2011 at 7:31 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> You have identified one of the reasons openID 2.0 doesn't qualify for LoA 2 (SP-800-63).
> 
> There is nothing in AX by default,  You would have to build something custom, then you have interoperability issues.
> 
> The proposed openID AB/C spec or whatever the final name will be avoids this in two ways.
> 1. with the Web server flow the attributes are directly retrieved by the RP from the IdP using a oauth 2.0 token.  
> 2. There will also be an encryption option for JWT tokens that contain claims.
> 
> Most things will just use the direct retrieval (1).
> 
> John B.
> 
> On 2011-04-14, at 6:18 PM, Kleber - Corujito wrote:
> 
>> Thanks John,
>> 
>> 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.
>> 
>> I understand from your answer that there is nothing to do about that in openId or AX. Am I right?
>> 
>> 
>> On Thu, Apr 14, 2011 at 6:07 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> The SREG 1.1 spec for openID 2.0 is unofficial but used.  
>> Some people still use SREG 1.0 with openID 2.0 but that is not spec compliant.
>> 
>> The only official standard to pass attributes is AX in openID 2.0.
>> 
>> By default they are not signed or encrypted, so the values can be modified by the user. 
>> This was considered OK in the design because all the attributes are self asserted.
>> 
>> The IDP can easily make the AX parameters part of the signed body of the assertion.
>> However you may find that RP are not necessarily checking for that.
>> 
>> Any encryption would need to be custom.
>> http://openid.net/specs/openid-attribute-exchange-1_0.html
>> 
>> openID Connect has merged into openID AB.  We expect to circulate draft specs at IIW.
>> It will have more of the features it sounds like you are looking for.
>> 
>> The mailing list is:
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> John B.
>> 
>> On 2011-04-14, at 4:28 PM, Kleber - Corujito wrote:
>> 
>>> Hi guys,
>>> 
>>> We are building a new OpenID Provider. It works, but we would appreciate some security tips. Can you help us? :)
>>> 
>>> we read AX and SREG specs and we wonder if is there another way to pass user information from Provider to RP?
>>> We were figuring out if parameters could be passed in a encrypted way.
>>> 
>>> is there something from openid community that we are missing? I read from openidconnect.com some time ago that it is considered 'openid 3.0'. Should we implement it?
>>> 
>>> Thanks
>>> -- 
>>> Kleber Manoel Infante (Corujito)
>>> _______________________________________________
>>> general mailing list
>>> general at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-general
>> 
>> 
>> 
>> 
>> -- 
>> Kleber Manoel Infante (Corujito)
> 
> 
> 
> 
> -- 
> Kleber Manoel Infante (Corujito)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20110415/0152324d/attachment.html>


More information about the general mailing list