2012/11/21 Martin Paljak <mar...@martinpaljak.net>: > On Wed, Nov 21, 2012 at 8:55 PM, Andreas Jellinghaus > <andr...@ionisiert.de> wrote: >> 2012/11/21 Martin Paljak <mar...@martinpaljak.net>: >>> On Thu, Nov 15, 2012 at 7:12 PM, Anders Rundgren >>> <anders.rundg...@telia.com> wrote: >>> >>>> Another hurdle is that the GP security model is incompatible with the >>>> Internet: GP presumes mutual authentication AFAIK. This is how the >>>> Google Wallet currently works (Google holds the master keys to the SE) >>>> but that's not really cutting it. >>> >>> I don't believe that the industry players would want to give up their >>> current position easily. >>> Appstores (authority over what can be installed without hurdles), keys >>> to the empire (GP-style approach) or monetary gatekeepers (who can >>> charge a certain % for what is happening in their gardens) make money. >>> Telcos would prefer to kill data based instant messaging providers >>> without hesitation, if they could - SMS makes golden eggs... >> >> are you sure that is still the case? SMS flat is down to 5€/month over here. >> and I use google talk all the time instead of SMS, unless it is >> someone who doesn't have an android phone. > > Even public sources estimate a "nice business" > > "And text messaging is still a big business, accounting for an > estimated $21 billion in U.S. revenue for telecom companies last year > and an estimated $23 billion this year, according to the Consumer > Federation of America." > > Source: > http://articles.latimes.com/2011/aug/21/business/la-fi-texting-20110822
http://ovum.com/press_releases/ovum-estimates-that-operators-lost-13-9bn-in-2011-due-to-social-messaging/ other source wine about "lost revenue" due to people using facebook chat and friends instead of sms. (no statement relating to increased revenue for the data tarif so people can use facebook of course...) > The ROI on SMS is not comparable to the investments and increasing > traffic for data services (where messaging is accounts only for a <1% > of traffic, I believe) yes, the stories about price per bit for a sms are quite old. but if 2011 already 9% of chat moved from sms to facebook&friends, that is a strong development and guess that trend increases. >>> Interenet as an ideal is one thing, "business as usual" must still >>> live on, unfortunately. >> >> thats a bit harsh I think - its not like the mobile carriers e.g. >> aren't trying to sell payment systems on top >> of their infrastructure or similar, but at the end it doesn't gain >> wide acceptance it seems. maybe too expensive? > > Sure, as long as they can get a % of the business happening in their > "walled garden". Then again, financial services and payments are > important parts of the overall "who controls the money routes, > controls the business" play, so I don't expect any of the carriers or > handset platform providers to open up a loophole that would allow for > some 3rd party to easily take their market, without paying. There's > just no commercial interest. > > So yes, harsh, but I believe realistic. > >> I cannot comment on many things discussed here, but as someone living >> in an SSO world, where I have one >> place to authenticate, and every app I use gets the authentication >> from that central place via OAuth: that is real >> nice. Thus my personal goal would be no longer to be able to get many >> credentials from many places, but only >> to handle one credentials with one service on the other side, and >> handle that very, very well. every other place >> can use OAuth with that central place. (remember how I opposed using >> openid in the past? seeing how nice it >> is to have such infrastructure changed my view on that....) > > Sure. But that should be an *option* rather than requirement. > Eventually you still would want to separate your bank account from > your google account, for example. Sure, I want several different authentication options, one for work, one for home, but causal things, and one for very important things like banking. but if I have accounts at several banks, all could use a shared very-secure authentication mechanism, I wouldn't mind. the problem is each bank wants to have their own mechanism I guess. how is the experience with the eID in estonia? I thought that was the one case where people used one central eID card for many things, like authenticating to banks for online banking - and it is not tied to one bank only? > Maybe in 10 years this sounds like a > stupid idea for the younger generation, but this moment in time I > still would prefer the option to choose my credentials and identities > (but would love to re-use them as *I* want, not how some vendor wants > it (what makes OpenID better than peered implementations like saml or > facebook connect or..) I love the idea of having more control. if there is a secure clearing provider for authentication, I might prefer to have him in the loop, rather than the bank. some of them don't seem to do a good job with basic things like a useable web page, or asking me for strangely limited passwords, etc. I'm not advocating the "one for everything", but rather the option of having some hub in the middle. e.g. if you want to buy something, do you prefer to create a account at some new webstore, do you prefer to have a middle man for everything but shipping of the good (e.g. amazon marketplace, ebay buying at fixed price. ...) or a mix of that vendors web-.page, but the account tied to your google / facebook / .... account? my favorite is not opening an account at a webstore - but very few webstores offer to buy without opening an account. my least favorite option an account on their page - very likely they will both and some hacker extracts all data. so using amazon.com or ebay as middle man can help, or only create an account connected to my google apps account, so I don't need to enter/remember some password. Andreas > > Sorry to hear about the OpenID thing though ;) > > Martin _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
