[OpenID] Reconsidering http://openid different fromhttps://openid

[Peter Williams]

Lets see where the line is drawn, for the $50 consumer-size financial risk.
 
1. Email ping is often used to access account with stored credit cards. Consumer credit card risk (in the US) is very consumer friendly. Merely half-reasonably claim a fraud within 30 days of receiving your credit statement, and your risk of loss comes way down to the level that most people can accept. If you cant, you should not be using a credit card. Just use it in visa debit mode.
 
2. A visa merchant RP accepting myopenid for credit/debit is indirectly accessing the work myopenid did earlier, to register the user (using an email ping!). It may also issue certs and verify them during SSL client auth  (tho I cannot find any longer the myopenid cert-issuing feature)
 
3. Given the RP is in charge of openid associations - and can easily profile the protocol so that essentially all security is delegated to SSL - surely the RP can reasonably accept openid assertions from myopenid ... when consumers want to use OP-asserted or SP-stored credit card info for a visa transactions. While the sp-initiated websso (checkid/id_res) flow over the foreground channel is not identical with visa's own 3dsecure (VerifiedByVISA brand), it has many similarities. (!Patent warning! folks. Disclosure: VISA US was a founding shareholder in VeriSign.)
 
But this all kind of assumes 
 
(a) whitelisting OPs (accepting those OP who in turn are bearing the visa logo, as an "icon" of trustworthiness ?) 
 
(b) the RP is astute enough to apply SSL countermeasures rather than rely on certain of the common, conforming but deliver security services that are rather "less-than-SSL" 
 
One way to whitelist openid is... of course to do what browsers do, concerning SSL. They whitelist the TTP CA roots that Microsoft does a bit of due diligence on - taking no fees but obviously appropriately concerned to preserve its ownconsumer brand's trustworthiness. 

________________________________

From: general-bounces at openid.net on behalf of Christopher St John
Sent: Fri 9/21/2007 6:11 AM
To: OpenID List
Subject: Re: [OpenID] Reconsidering http://openid different fromhttps://openid



On 9/20/07, Paul C. Bryan <email at pbryan.net> wrote:
>
> I believe the question should be framed around what solution can be
> (primarily) secure and (secondarily) intuitive.
>

I think the disconnect is the assumption that OpenID should be secure
against every conceivable form of attack and appropriate for the most
sensitive financial transactions.

It's not.

It's a widely applicable but very simple and limited replacement for
those stupid email verification thingies. As such, it's more important
that it be intuitive than ultimately secure.

If you need the former, then Oasis has some technology for you. It's
pointless to try and reinvent it here.

Limiting the scope makes it possible to ignore lots of hard
problems.

For example, I suspect that the DNS attack is a red herring. If you
had control of someone's access to DNS you could do much
evil-er things than mess with their OpenID. And the fact that their
OpenID is a relatively low-value target (compared to bank logins)
makes it less likely to be attacked.


-cks

--
Christopher St. John
http://artofsystems.blogspot.com <http://artofsystems.blogspot.com/> 
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general