A temporary email address is probably more immediately deployable. However, if there's interest, providing a POST endpoint to send something like an Atom Entry to, guarded by OAuth via the Authorization: header, is pretty well understood standards-based technology with libraries already written. It could also be used for "out of band" communications to an end user as well.<br>
<br>The Achilles Heel of email based communication of all kinds is spam filtering -- if the temporary email address just forwards, and nothing else special is done, I would guess that a lot of the emails sent will end up in a spam folder.<br>
<br><div class="gmail_quote">On Tue, Apr 7, 2009 at 7:00 AM, Paul Madsen <span dir="ltr"><<a href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
because the RP would still have a whitelist .....<br>
<br>
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 ....<br>
<br>
But the RP still has to start with 'trusting' the OP, through a
whitelist or something more flexible.<br>
<br>
paul<div><div></div><div class="h5"><br>
<br>
Andrew Arnott wrote:
<blockquote type="cite">Allen,
<div><br>
</div>
<div>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
<a href="mailto:myinvalidemail@myrogueOP.com" target="_blank">myinvalidemail@myrogueOP.com</a> and getting into web sites without a valid
email address?<br clear="all">
--<br>
Andrew Arnott<br>
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - Voltaire<br>
<br>
<br>
<div class="gmail_quote">On Mon, Apr 6, 2009 at 9:34 PM, Allen Tom <span dir="ltr"><<a href="mailto:atom@yahoo-inc.com" target="_blank">atom@yahoo-inc.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">Currently, Google OpenID
users can be exempted from Email verification
when the Google OP returns an @<a href="http://gmail.com" target="_blank">gmail.com</a> address, because
the Google OP
will only return the @<a href="http://gmail.com" target="_blank">gmail.com</a> address that is tied to the Google
Account.<br>
<br>
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?<br>
<font color="#888888"><br>
Allen</font>
<div>
<div><br>
<br>
<br>
Andrew Arnott wrote:
<blockquote type="cite">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.<br clear="all">
--<br>
Andrew Arnott<br>
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - Voltaire<br>
<br>
<br>
<div class="gmail_quote">On Mon, Apr 6, 2009 at 8:42 PM, Allen
Tom <span dir="ltr"><<a href="mailto:atom@yahoo-inc.com" target="_blank">atom@yahoo-inc.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
Andrew Arnott wrote:<br>
><br>
> Thanks. Incidentally, the grief I have with Facebook is that I
have<br>
> to visit Facebook in order to pick up my "mail" which may just be a<br>
> poke or prod. *grumble* But yes, I'd like to see us provide a<br>
> general solution. And my personal queuing SP of choice would
likely<br>
> be one that sends copies of my messages in the email it sends me,
as<br>
> well as organizes them within its own web site for my review later.<br>
><br>
<br>
</div>
What if the OP generated a unique disposable email address for each RP<br>
that the user wants to allow email, and the OP just forwards it on to<br>
the user's real mailbox (or cell phone or IM, depending on the user's<br>
preference). If and when the user no longer wants to receive messages<br>
from the RP, the user can just deactivate the disposable email address.<br>
<br>
This might be easier to deploy than defining a standard messaging API<br>
and putting OAuth in front of it.<br>
<font color="#888888"><br>
Allen<br>
</font>
<div>
<div><br>
<br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<br>
</blockquote>
<br>
<br>
</div>
</div>
</div>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<br>
</blockquote>
<br>
</div></div><pre cols="72"><font color="#888888">--
Paul Madsen e:paul.madsen @ <a href="http://gmail.com" target="_blank">gmail.com</a></font><div class="im">
m:613-282-8647
web:<a href="http://connectid.blogspot.com" target="_blank">connectid.blogspot.com</a> </div></pre>
<br>
--~--~---------~--~----~------------~-------~--~----~<div class="im"><br>
You received this message because you are subscribed to the Google Groups "OAuth" group. <br> To post to this group, send email to <a href="mailto:oauth@googlegroups.com" target="_blank">oauth@googlegroups.com</a> <br>
To unsubscribe from this group, send email to <a href="mailto:oauth%2Bunsubscribe@googlegroups.com" target="_blank">oauth+unsubscribe@googlegroups.com</a> <br> For more options, visit this group at <a href="http://groups.google.com/group/oauth?hl=en" target="_blank">http://groups.google.com/group/oauth?hl=en</a><br>
-~----------~----~----~----~------~----~------~--~---<br>
</div></div>
<br>
</blockquote></div><br>