24425703: Apple ID Authentication Framework

[openradar-mirror]

Description

Many apps require the user to provide at least an email address and a password as part of their sign up process.

The users email address is already attached to their Apple ID and is typically available via the Contacts Framework (though not programatically identifiable to the app).

A unique password is also easily generated by the Shared Web Credentials SecCreateSharedWebCredentialPassword() call in the Security Framework.

Additionally, using the same Shared Web Credentials is it possible for a developer to get access to login details associated with an app and a website.

These technologies could be bought together into a new, powerful, but simple and secure, way for users to allow apps to generate accounts for them.

Additionally, in a similar manner to how the user has control over the data they share in the Apple Pay sheet, it should be possible for the user to choose what data they share with the app beyond the critical. For example; age, gender, location, address.

The steps would be quite simple

• The user starts the app
• The app asks the authentication framework for the known login details for the existing user and this app bundle
• The framework either returns the previously associated details (perhaps requiring TouchID authentication using first) or asks the user what to do next
• The user can then inspect the details the app would like to access and grant/deny or change what is to be provided
• Users will no longer have to type laborious email addresses or generate and remember secure passwords.
• As an additional level of security, iCloud email addresses could allow for aliases, which could also be auto-generated by this framework meaning that in many cases a user can sign up for an app without giving away any personal data but still be connected to that service and vice-versa (e.g. for welcome emails and the like).

A new option in the Settings for the app would allow the user to revoke access, which the app would be requited to respect as part of the app review process/agreement.

I understand that some of this information is available via the CloudKit CKDiscoveredUserInfo class, which is a definitely help but still does achieve the full purpose this change, which is to facilitate rapid, secure and shared logins for apps and websites. Such a framework would conceivable be tied into this class.

Product Version: Created: 2016-01-30T15:41:34.015420 Originated: 2016-01-30T00:00:00 Open Radar Link: http://www.openradar.me/24425703

[openradar-mirror]

Modified: 2016-01-30T16:11:06.342990

[openradar-mirror]

Modified: 2016-01-30T16:11:06.342990

[openradar-mirror]

Modified: 2016-01-30T16:11:06.342990