...
Examples of services where account linking is happening now
- Educause
- NSF Fastlane
- NSF is using standard account linking pattern: the first time an individual come in with their federated id, the NSF ask them for their existing, local-to-the-NSF account and password, and the linking happens behind the scenes. Then the individual may log in with the new account and have all the standard information. Educause is also doing account linking this way. This method still leaves dangling issues: is the old account removed? What happens when the individual changes to a third institution? How are the two federated accounts linked?
- various NIH apps
- Google's experiences with its account system migration, merging previously silod account spaces into one, is a high-profile large scale example in the wild.
- At Indiana, because of the way email domains are constructed, they are requiring users to link their multiple institutional identities back to one another. This does not happen automatically for business reasons. This kind of institutional account linking is required when vendors allow a user to change their primary email address.
- At the University of Chicago Medical Center, the Medical Center continues to manage their own identities. They are a part of U. Chicago, so users may use their Medical Center identities without ever needing an additional U. Chicago identifiers. The account linking happens on a more fundamental level.
- Trusted Attribute Aggregation Service (TAAS) acts as a secure service to link multiple IdP or attribute authorities together. It does so by using persistent identifiers without requiring the service that is performing the linking to know anything about the user at all. The TAAS stores the attribute types that the IdPs return as part of the account. It can then work as a proxy IdP service that authenticates the user at an IdP and retrieves the user attributes that are requested by the SP from multiple AAs. A demo running for firefox browsers is available online at http://sec.cs.kent.ac.uk/demos/taas.html. Feedback more than welcome.
...
- Who is authoritative in data conflict situations?
Each attribute authority (AA) should be authoritative for data from its own domain. However, when multiple AAs are returning conflicting data it does not necessarily mean that any of the data is wrong. It is quite possible that there may be two sets of attributes that conflict if the individual works for two universities at the same time with two different roles but both sets will still be valid. When conflicts such as this occur it is up to the user to decide which data set they wish to present
to the SP as both sets may be valid. The underlying problem is more about how we provision IdPs and attribute authorities with information for which they should not be authoritative.
- Can accounts be linked and still preserve the privacy of the individual?
Yes absolutely, so long as the user is in control of the linking process and has the ability to decide which accounts he/she chooses to release to each requesting party. e.g. I may have linked two accounts my work account and a dating site. If i'm then trying to access a site for work I mightn't want to release the fact that I've signed upto a dating site to all and sundry and I also might not want to send work attributes to the dating site.
An example service that tries to do this is briefly described below:
The technology already exists and is well established to receive a persistent but otherwise unidentifiable string to identify a user between a single AA and SP, if we authenticate to multiple AAs as part of the same session then we have multiple persistent ids that can be used to identify the same user at multiple AAs. If the linking service is attacked it doesn't matter if the PIDs are stolen as they are only valid between the service and the AA and cannot be used by an external attacker and no personal information needs to be stored on the service. When an SP requires authn/attributes it redirects the user to the service with the linked accounts which authenticates the user (requesting no attributes). The service can then query all (or a selection) of the linked IdPs for attributes including a token identifying user via the stored PID. The IdP can then decide whether or not it trusts this linking service to authenticate/aggregate and if it does create an encrypted assertion (encrypted to the SP not the linking service) to be sent to the requesting SP. This does of course require a higher level of trust in the linking service than in a standard SP but unless collusion occurs between multiple parties the use of PKI can ensure that no attribute data is ever visable except to the intended recipient SP.
- When accounts at different LoAs are linked, is the resulting information at a higher, lower, or varied LoA overall?
- We need to differentiate between the login LoA and the registration LoA. The LoA of the actual authentication will then be the highest level of assurance for all the data returned as that is how sure at the time we are that the user is who they say they are. However if the registration process of the other AAs is lower than this threshold i.e. the authenticating IdP used a smartcard login and the second linked account registers its users via a web form then it cannot be presented as the same LoA value it must be downgraded to the registration LoA as that is how sure we are that the data is accurate.
...