Account Sharing at the IDP (Identity Provider)

Session Topic: Account Sharing at the IDP

Tuesday 1D

Convener: William Denniss

Notes-taker: William Denniss

Tags for the session - technology discussed/ideas considered:

It is a fact today that many people share accounts, particularly within their own household (family, housemates, etc). They do so for convenience, to share streaming content, for paying shared bills, and other reasons. Today people typically achieve this by sharing their username and passwords.

Identity Providers (IDPs) are trying to move people away from the username and password model and towards federated sign-in. Should IDPs support the account sharing use-case by allowing multiple people to login to one Relying Party (RP) through a single IDP->RP identity relationship?

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

The session was an open discussion with many interesting points raised by the participants, including:

• If IDPs don't explicitly support account sharing, people will continue to share their accounts anyway. Sharing either their full IDP credentials, or continuing with username/password at the RP as they are today.

• IDPs need to offer the same value as username/password in regards to sharing

• Some concern that IDPs enabling sharing would be "changing the deal" for RPs

• Most media sites already have clearly defined rules around sharing, that are unrelated to the number of people signed in to a single account (e.g. Spotify: 1 stream at a time, Netflix 2 streams at a time). If sites that care about multiple users already implement rules to control sharing, changes at the IDP layer may not impact them greatly.

• While the best approach would be for RPs to all implement their own sharing mechanisms, most sites don't seem to care

• Strong support for an idea to declare that a user is being impersonated by adding an extra claim to the ID token, allowing RPs to optionally take action on it.

• By declaring that the user is being impersonated, all RPs by default will get sharing support, but those who don't want it can opt-out by detecting this claim.

• Discussion about whether the id token should declare the user being impersonated, or the user doing the impersonation as the 'sub', but most people settled on the former to achieve sharing with zero-implementation by the RP

• Discussion on whether the impersonation field should contain the user's own sub, a directed identifier, or no identifier at all

• With a valid identifier of the user doing the impersonation, RPs could use the impersonation claim to do other interesting things, like recommendation tracking (e.g. Netflix recommendations) which could be revenue positive. This could help sell the feature to RPs

• There are added security benefits of this approach too – by knowing the actual human-user, you can build a better security profile (multi-city access by two people sharing an account looks less suspicious)

• Participants noted several cases of username/password sharing even within the sensitive medical medical context, for example a nurse that logs in as the doctor to add notes. This proposal is not trying to address that use-case however.

• Impersonation at the IDP layer doesn't solve use-cases needing granular Access Control Lists (ACLs), although if the id token does contain the user doing the impersonation, RPs could log an audit trail that includes the actual user, which is still a large improvement over the username/password sharing that happens today.

Follow Up

• William to continue the discussion with interested parties, and to consider drafting and extension to JWT for subject impersonation claims.