The last part of my series on apps and privacy has gone up over at Gartner.
|
|||
|
I had let Privacy Mirror languish for a bit, and having found a free few hours, I decided to update Privacy Mirror to take advantage of Facebook’s Graph API. (For those of you not familiar with my Privacy Mirror experiment, it is a very basic app that explores what personal data apps can see via your friends.) Since I last updated Privacy Mirror, Facebook rolled out two major features. The first was the previously mentioned Graph API, which is a RESTful API that results Facebook data as JSON. The second, and frankly the more interesting, was extended permissions. The newish extended permissions govern how apps can access data and how users are informed of this use. It is these extended permissions at the bottom of the recent kerfuffle over Facebook allowing app developers access to phone numbers and addresses. (Ars Technica did a good job over covering this, and here is Facebook’s current response.) Extended permissions work like this. First, an app developer encodes a request for access to various pieces of your profile data, as well as pieces of your friends’ profile data. Second, when you add the app to your profile, the app asks you for your permission. The following is a picture of what it looks like when Privacy Mirror asks for access to your and your friends’ information.  An example of extended permissions I’ve posted the second part of my ‘I “like” you, but I hate your apps’ series over on my Gartner blog. I’ve been doing a lot of thinking lately about how the apps on our smartphones and Facebook profiles introduce strangers into our interactions. I’ve broken my thoughts up into a three-part post over on my Gartner blog. Check out part 1 and give me your thoughts on it. These are my raw notes put here for reference purposes. – Attendees
What is mean by identity oracle? * An oracle provides an answer to a question but not a specific attribute ** If you ask an Oracle, is Peter over 21 it says yes. It does not hand back an attribute – birthdate Peter: The Federal Govt is authoritative for very few attributes – State Dept – passport #, citizenship. State govt are authoritative for driver’s license number. SSA for SSN. eVerfify is an example of an oracle, says Gerry. Peter – what will drive this is the requirement for LOA3 credentials needed to access to medical records. P – “We do not have an attribute infrastructure.” A lot of attributes are simply issued via IdP’ I – our examples so far have shown organizations that are authoritative for identifiers but not attributes P – raises need for back end attribute exchange Gerry – Problem with authoritative attribute provides is that the PDP makes a decision as to what is truly authoritative for a given context. Authoritative data source must provide SLA or MOU so that relying party can establish trust. P – BAE is 1/2 of the equation and attribute provider (market?) is the other half A – is there a business model for attribute providers? |
|
||
|
Copyright © 2013 tuesdaynight - All Rights Reserved Powered by WordPress & Atahualpa |
|||
what others say