[OpenID] openid query

Martin Paljak martin at paljak.pri.ee
Fri Feb 29 14:21:49 UTC 2008


On Feb 29, 2008, at 3:03 PM, Eddy Nigg (StartCom Ltd.) wrote:
>> In Estonia, when people say they don't trust the smart card  
>> technology
>> which the national eID is based upon or they don't trust the
>> government issuing them
> ...except in case the government also creates the private keys for  
> its citizens, which would be indeed a reason not to trust such cards  
> for  encrypted data exchange (and authentication).

Well, the government does 'create the keys'. They're supposed to be  
created on the card of course, but You Never Know The Big Brother And  
All The Lies They Tell...


>> For me, all technologies that imply some kind of universal built in
>> trust (like PKI)
> This is for what standards and definitions are here for....or for  
> that matter policies which govern CAs in software like browsers?!  
> Nothing is perfect, but is it broken by design?
EV certs seem to me like a 'moneymaking patchwork to fix web PKI'. But  
yeah, nothing is perfect...

>> So instead of building a uniform trust model into OpenID, lets give
>> all parties (users, consumers, providers) means to make a good trust
>> *decision* based on different inputs. Like PAPE.
>>
> Muhhhaaahaha....And who confirms to you (the RP) that the OP indeed  
> implements the PAPE assertions? What refrains an OP from returning  
> Physical Multi-Factor and NIST level 4 no matter what? That's like  
> hot air...The assertions made by both our OpenID providers (*) are  
> worthless because anybody can claim the same....it devalues our  
> efforts and gives to the RP (and user) at best a wrong sense of  
> trust and security...

Security *is* hot air indeed :) But PAPE allows to give signed  
attributes in addition to the casual 'yes, authenticated; no, not  
authenticated' information that is the core of OpenID Authentication.  
If you trust some provider to be capable of doing what they claim to  
do (out of band confirmation, whitelist) you have more information at  
hand to decide in your application what to do.

Lets take a real life example:

I know some online banks in Europe that work on usernames and  
passwords. In Estonia all banks allow to log on using your eID smart  
card - end to end authentication and SSL. Is it enough? No. Now two  
major banks require you to use two PIN codes and two different keys to  
operate your money - in addition to authentication to see your balance  
you have to digitally sign every transaction you make.

The same goes with OpenID and PAPE. OpenID authentication (yes/no) is  
extended with additional authentication strength information (PAPE).

If I would compare OpenID and smart cards, the similarities are pretty  
obvious:

* eID: Bank accepts only certain smart cards (Estonian ones). You  
can't connect with your generic crytoflex.
* OpenID: You can whitelist the OpenID providers you use. You don't  
want to accept http://www.jkg.in/openid/
* eID: Even though  smart card based authentication is way-way better  
than usernames and passwords, bank requires additional digital  
signatures to actually move money.
* OpenID: to do something 'more important' you can request different  
authentication from OpenID provider IF you already trust the provider  
to be good, in addition to bare 'yes/no'.

Lets say you trust OpenID.ee to do the right thing. We support 'Mobile  
ID' to open a session - this means a RSA signature on your phone via  
SMS and you get a session for XX minutes. This is good for 99% of  
websites and generic browsing. But if I was a bank with OpenID  
support, for transactions I'd like to be sure that the authentication  
age is not more than say, 3 minutes. This would result in another SMS  
to be signed and additional information to the RP to make the decision  
weather to move money or not.

As said, unless clearly defined what the terms 'security and trust'  
should mean in OpenID context, you can't leave a wrong impression.


-- 
Martin Paljak
http://martin.paljak.pri.ee
+3725156495





More information about the general mailing list