Identity Binding in the Extended Enterprise

Identity Binding in the Extended Enterprise

Wednesday 5C

Convener: William K.

Notes-taker(s): Justin R.

Tags for the session - technology discussed/ideas considered:

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

There are multiple IdPs and RPs, and in a full mesh they connect to each other in different ways.

One IdP per RP

Multiple RPs per IdP (the common way to think about it)

Multiple IdPs per RP (this is what we're after)

User has accounts at multiple IdPs, uses both at one RP

Binding is opt-in and explicitly defined by the user.

• the user says "This is me. These are my identities."

• privacy-preserving

User logs in to IBS with multiple accounts simultaneously

RP queries the IBS to ask if it has seen the user by any other name

Code is: http://github.com/idbind/idbind

This has been done with RPs many times (Stack Exchange), this service externalizes that

How do users decide which identities go to which RPs? (idbind project only has single list)

What about unbinding?

[Demo of open source code]

What's out of scope of project: how do RPs use this information? Some basic thought experiments to do it.

Big UX question: how do you present IdP and federated identity information to a user in a way that makes any sense?

Next major dev task is to make a simple RP to consume the information

This approach keeps the authentication context of the IdP directly with the RP

Not all IdPs are created equally, different IdPs have different security contexts