[OpenID] [oauth] Re: Replacing email verification with RSS 'push' feeds and OAuth

[Breno de Medeiros]

Clearly, because of spam and other security issues, RPs cannot accept
email claims from any OP. The fact that the domain name and email
address match is not sufficient because it is often the case that an
email domain and an HTTP domain do not match. It is also too
restrictive a strategy because it prevents using OPs that are not
email providers (but that could otherwise be trusted to verify such
emails).

1. The community should define standard expectations about making
assertions about email addresses, and there should be mechanisms for
OPs to claim to satisfy such standard.
2. RPs should use a whitelist of OPs that they trust based on email
verification. This does not need to be excessively cumbersome: a
self-regulating reputation-based approach can work, provided people
can agree on what are the expectations for trust.

It may not be "any OP can play the game" but is still open in the
sense that reputation-based communities are. Clearly this game cannot
be played without reputation metrics, this is a trust issue, not a
protocol issue.

On Tue, Apr 7, 2009 at 6:46 AM, Andrew Arnott <andrewarnott at gmail.com> wrote:
> Allen,
> It sounds like you're proposing that an RP trust the email claim from an OP
> if the domain of the OP and the domain of the email match.  Is that right?
>  If so, what's to stop me from setting my myrogueOP.com, and asserting an
> email claim for myinvalidemail at myrogueOP.com and getting into web sites
> without a valid email address?
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - Voltaire
>
>
> On Mon, Apr 6, 2009 at 9:34 PM, Allen Tom <atom at yahoo-inc.com> wrote:
>>
>> Currently, Google OpenID users can be exempted from Email verification
>> when the Google OP returns an @gmail.com address, because the Google OP will
>> only return the @gmail.com address that is tied to the Google Account.
>>
>> If we generalize this, if the RP trusts the user's email provider to
>> always assert the user's true email address, then why wouldn't an RP trust
>> the OP to always return a valid disposable email address?
>>
>> Allen
>>
>>
>> Andrew Arnott wrote:
>>
>> True. This is a model I thought of a while back, when some credit cards
>> started generating one-time-use credit card numbers for use when shopping
>> online.  I think this has a much higher chance of working for people,
>> although it doesn't at all solve the problem of RP's needing to send the
>> user through email verification.
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death
>> your right to say it." - Voltaire
>>
>>
>> On Mon, Apr 6, 2009 at 8:42 PM, Allen Tom <atom at yahoo-inc.com> wrote:
>>>
>>> Andrew Arnott wrote:
>>> >
>>> > Thanks.  Incidentally, the grief I have with Facebook is that I have
>>> > to visit Facebook in order to pick up my "mail" which may just be a
>>> > poke or prod.  *grumble*  But yes, I'd like to see us provide a
>>> > general solution.  And my personal queuing SP of choice would likely
>>> > be one that sends copies of my messages in the email it sends me, as
>>> > well as organizes them within its own web site for my review later.
>>> >
>>>
>>> What if the OP generated a unique disposable email address for each RP
>>> that the user wants to allow email, and the OP just forwards it on to
>>> the user's real mailbox (or cell phone or IM, depending on the user's
>>> preference). If and when the user no longer wants to receive messages
>>> from the RP, the user can just deactivate the disposable email address.
>>>
>>> This might be easier to deploy than defining a standard messaging API
>>> and putting OAuth in front of it.
>>>
>>> Allen
>>>
>>>
>>>
>>
>>
>>
>>
>>
>> --~--~---------~--~----~------------~-------~--~----~
>> You received this message because you are subscribed to the Google Groups
>> "OAuth" group.
>> To post to this group, send email to oauth at googlegroups.com
>> To unsubscribe from this group, send email to
>> oauth+unsubscribe at googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/oauth?hl=en
>> -~----------~----~----~----~------~----~------~--~---
>>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)