On Sun, Mar 10, 2013 at 3:34 AM, Anders Rundgren <[email protected]> wrote: > http://msdn.microsoft.com/en-US/library/windowsphone/develop/jj207032(v=vs.105).aspx > > Quote: > > "To deploy or submit an app that uses ID_CAP_WALLET_SECUREELEMENT > or ID_CAP_WALLET_PAYMENTINSTRUMENTS, you must request special > permissions and have that permission applied to your developer account. > For more info and for assistance, contact Dev Center support" > > We are still far away from ubiquitous security. :) I'm not opposed to protecting the assets.
>From an architectural standpoint, Secure Element Issuers (SEIs) and Service Providers (SPs) a two trusted groups. I say "trusted group" because both (SEIs and SPs) are populated like CAs in a browser. On one side are SEIs, and on the other side are SPs. The SEIs and SPs forge relationships in MxN fashion and we get to eat what falls out. We should not blindly trust based the offspring of two groups whose only criteria is maximizing profit. I would also *love* to see the end user license agreements of terms of services associates with the groups and the applications. I would bet they are as obscene as existing EULAs and ToS governing those cursed clouds. By the time the lawyers get done, I would expect all legal liability to be shed. Open question (for me): how many additional capabilities does an SEI or SP get when bestowed with ID_CAP_WALLET_SECUREELEMENT or ID_CAP_WALLET_PAYMENTINSTRUMENTS? Can they forge another relationship and implicitly receive permissions? How about if the additional relationship is added to an existing, trusted application? Jeff -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/android-security-discuss?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
