[OpenID] NyaLogin private beta invites, supporting OpenID movement
Andrew Arnott
andrewarnott at gmail.com
Wed Jul 6 16:24:33 UTC 2011
This strikes me as a free alternative to Janrain Engage (although with fewer
features perhaps). The auth proxying model seems identical.
Is that a fair assessment?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
On Tue, Jul 5, 2011 at 10:33 PM, SitG Admin <sysadmin at shadowsinthegarden.com
> wrote:
> Users are directly authenticated on providers' websites like Facebook,
>> Twitter, Google etc and we are only providing channel for authentication.
>>
>
> Then, as I understand this, you're acting as an ISP; if your service became
> successful, it would become a centralized point of eavesdropping for
> identity correlation. I understand tunneling secure connections over
> proxies; if you were concealing from users' main ISP's what sites they were
> authenticating to or what sites they were authenticating with, I could
> readily see what your service offers, but by not proxying communications
> between the user and RP, it seems that their ISP can still look at *those*
> OpenID strings to see what OP the user has. This wouldn't matter as much if
> delegation was used, but with most users accepting their OP's default, your
> service doesn't seem to add much in the way of privacy (and potentially
> takes away).
>
> Think of distributed trust (i.e. the decentralized model) as a small army
> of baskets, each carrying two or three eggs. It's easy to say "We can
> sacrifice the weakest members of our army at no loss if we give all their
> eggs to the strongest!", but even if you can find some volunteers brave
> (read: stupid) enough to try it, all those eggs will make them a prime
> target for so many snakes that they will be brought down anyway! You can
> easily say "potential risks to privacy don't matter", and even mean it, but
> the lure of such centralization will attract attackers you *cannot* stop.
>
> Risk management isn't just about preventing potential attacks. It's also
> about damage control; limiting the effects, once a compromise occurs.
> Looking at the diagram again, it looks like NyaLogin proxies the user's
> connection to their *OP* (whom they have already determined they can trust),
> and not to the *RP* (with whom they don't automatically have such a
> relationship), while letting the ISP determine RP but not OP (because of
> NyaLogin's proxy being the only IP address connected to), and letting
> NyaLogin determine RP, ISP, and OP.
>
> If the goal is to let users keep their OP/Identity secret from their main
> ISP, the tradeoff is letting NyaLogin have access to this information
> instead. You might want to market more towards disadvantaged users in
> countries under heavy censorship, though they might already be trying to
> work around site whitelists (and NyaLogin might not make it there any time
> soon).
>
>
> Regarding logo design, we have no clue of a company having similar logo.
>> If there is a company with similar logo, that is a coincidence but please
>> let us know the file sharing company you are talking about so that we can
>> take appropriate steps to avoid any violation.
>>
>
> I linked to their website in the last post. It was a simple enough
> description; "Why is that donkey sticking its tongue out at me?". I think I
> got lucky with the software name being so close, though. Alternatively, if
> there is software named after that candy bar, I gave up before finding it :)
>
>
> -Shade
> ______________________________**_________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/**mailman/listinfo/openid-**general<http://lists.openid.net/mailman/listinfo/openid-general>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20110706/e1c2c84a/attachment.html>
More information about the general
mailing list