Terrell Russell wrote:
> On 4/8/09 12:33 AM, Martin Atkins wrote:
>> And with all that said, I would love to see a mechanism for my OpenID
>> provider to accept messages on my behalf. Years ago I specced out a
>> protocol simply called "Send a Message Protocol" which was intended to
>> solve this
On 4/8/09 12:33 AM, Martin Atkins wrote:
> And with all that said, I would love to see a mechanism for my OpenID
> provider to accept messages on my behalf. Years ago I specced out a
> protocol simply called "Send a Message Protocol" which was intended to
> solve this problem, but it was never mig
Breno de Medeiros wrote:
> 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
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.
I
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' th
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 myinvalidem...@myrogueop.com and getting into web s
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
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 throu
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 l
Hi Allen,
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 c
That depends, Paul. Yes, it certainly means that multiple RPs can't
correlate a user's activities. But if I visit the site once, establish a
relationship and then terminate it by revoking my OAuth token, and then
visit that site again and re-establish its ability to contact me, a new
OAuth token
Andrew, I assume you mean that with this model multiple RPs can't
correlate the user's activities (or at least not trivially), and not
that a single RP can't correlate the user's activities (over time)?
paul
Andrew Arnott wrote:
> One more benefit of this system:
> The RP has no idea who you a
Hi Andrew,
I really like the idea of an OAuth protected messaging service that
protects the user's inbox from spam, and allows users to selectively
authorize (and revoke) permission for 3rd parties to send messages to
them. This is exactly why Facebook messaging is free of spam.
As George has
Comments inline...
Andrew Arnott wrote:
> Deep in another OpeNID thread I suggested part of this idea, but I've
> expanded on that idea in my head and think it deserves its own thread
> besides to *get some feedback from you*.
>
> First the problems:
>
> * Email verification is a step many
One more benefit of this system: The RP has no idea who you are (unless you
tell it by other means). It can push messages to the user by POSTing to an
SP's URL that is the same for all users, and the SP only knows which user is
the recipient by the OAuth token. Thus, the RP cannot correlate users
15 matches
Mail list logo
