because the RP would still have a whitelist ..... I see Allen's example as a specific case of 'for a given trusted OP, I am more willing to trust attribute X than Y'. In his case its because the asserted email address matched the OP's domain ....
But the RP still has to start with 'trusting' the OP, through a whitelist or something more flexible. paul Andrew Arnott 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 [email protected] 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 <[email protected] > <mailto:[email protected]>> wrote: > > Currently, Google OpenID users can be exempted from Email > verification when the Google OP returns an @gmail.com > <http://gmail.com> address, because the Google OP will only return > the @gmail.com <http://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 <[email protected] >> <mailto:[email protected]>> 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 >> >> >> >> >> >> > > > > > > > -- Paul Madsen e:paul.madsen @ gmail.com m:613-282-8647 web:connectid.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
