We're working hard on Luno.io, and have our MVP almost ready. We're building an API to enable developers to use advanced User Management and Authentication systems without having to build and maintain them themselves. Alongside the Authentication API's, we offer Subscription Management API's and advanced analytics for detailed insights into your userbase!
We're expecting some questions and concerns - especially around trust and security, which is of course something we take exceptionally seriously. As well as focusing heavily on security and reliability, we're planning on having an escrow service so our customers can be confident that we won't disappear with their data, which they can migrate away from us at any time. We'll also have a strict SLA from day one.
Feel free to throw any questions in here, or email us - hello@luno.io
We've considered this option, but not for our immediate future. Although we do aim to make Luno as extensible as possible for the developer, we haven't got becoming a Shibboleth service provider in our roadmap.
We would love to hear your thoughts on the benefits of this integration. Please drop us a line on hello@luno.io
It's really interesting to see services like this emerge.
In my opinion, the merchant processing/gateway revolution happened when providers (Stripe, Braintree, et al) started providing quality APIs for user/profile/subscription management and took the burdens of PCI compliance off of the companies building consumer products.
On the surface, I feel like this is a great way to offload the liability of storing sensitive user data -- though it also creates a central source of failure. Success is predicated on Luno securing their data; if they can't, the model would die.
If they can, it's possible we'll start to see a mass-migration of authentication-based apps switching to these service, if only for the legal intention of offloading liability.
Definitely a fascinating model and there are other doing it too, but the founder's (rbin's) post pretty much read "blah... blah.. blah.. trust and security.. blah blah.. sersiously.. blah blah blah.. "
Until there is a service that has shown it has the chops it takes to securely store user data for a third party, its an uphill battle for these services.
PCI also comes with a bunch of rules that companies that store card data need to adhere to. Obviously the idea is that adhering to these rules ensures (there are arguments for and against, but lets skip those. :P) that data cannot be hacked.
With PI, if you're data is hacked, there is no penalty from a consortium, like in the case of PCI data being hacked, but it is ludicrous to say that there is no penalty at all. When a website is hacked and loses customer data, it also loses customer trust. The websites revenue is based on it's users trusting the site and coming back to it over and over again. A data leak would (rather has the potential) to be disastrous to the site and it's business. (Ashley Madison is the most recent example I could think of).
I do agree with the fact that for a lot of small sites that just want to identify the user, leaking PI will have almost no negative result. But then, such sites have already moved over to OAUTH, and there purpose is already served.
9 comments
[ 3.4 ms ] story [ 33.5 ms ] threadWe're working hard on Luno.io, and have our MVP almost ready. We're building an API to enable developers to use advanced User Management and Authentication systems without having to build and maintain them themselves. Alongside the Authentication API's, we offer Subscription Management API's and advanced analytics for detailed insights into your userbase!
We're expecting some questions and concerns - especially around trust and security, which is of course something we take exceptionally seriously. As well as focusing heavily on security and reliability, we're planning on having an escrow service so our customers can be confident that we won't disappear with their data, which they can migrate away from us at any time. We'll also have a strict SLA from day one.
Feel free to throw any questions in here, or email us - hello@luno.io
Thanks!
[1]: https://auth0.com
Don't get me wrong, I think this is great. If companies serve a common API then they can compete on service rather than lockin.
We would love to hear your thoughts on the benefits of this integration. Please drop us a line on hello@luno.io
In my opinion, the merchant processing/gateway revolution happened when providers (Stripe, Braintree, et al) started providing quality APIs for user/profile/subscription management and took the burdens of PCI compliance off of the companies building consumer products.
On the surface, I feel like this is a great way to offload the liability of storing sensitive user data -- though it also creates a central source of failure. Success is predicated on Luno securing their data; if they can't, the model would die.
If they can, it's possible we'll start to see a mass-migration of authentication-based apps switching to these service, if only for the legal intention of offloading liability.
Really, a fascinating model.
Until there is a service that has shown it has the chops it takes to securely store user data for a third party, its an uphill battle for these services.
PCI is the main reason to use something like Stripe.
Right now, if you store pi and get hacked, you just apologize in a post mortem blog post and move on.
With PI, if you're data is hacked, there is no penalty from a consortium, like in the case of PCI data being hacked, but it is ludicrous to say that there is no penalty at all. When a website is hacked and loses customer data, it also loses customer trust. The websites revenue is based on it's users trusting the site and coming back to it over and over again. A data leak would (rather has the potential) to be disastrous to the site and it's business. (Ashley Madison is the most recent example I could think of).
I do agree with the fact that for a lot of small sites that just want to identify the user, leaking PI will have almost no negative result. But then, such sites have already moved over to OAUTH, and there purpose is already served.