#

Issue

Comment

1

Social Provider Policy (SPP)

What policy does each of the social providers put on proxies between the IdP and ultimate SP? The gateways are proxies in some sense in all models before us, though Roland Hedberg's model ultimately connects IdP and SP on the basis of the SPs credentials.

2

SPP

Will each social IdP have to be scrutinized by the legal team for the Gateway operator?

3

SPP

SPP policy must be assumed to be susceptible to change

4

Multiple IdPs per user

As insurance agains a social IdP "going away", users should register with more than one

5

Need for account linking

If users have more than one IdP (social or otherwise), they may forget which one they used to access a given resource. Without some form of self-service account linking this problem is hard to solve

6

Instability in provided attributes

Attribute values from an IdP may change at whim of social provider

7

Minimal reliance on social IdP

As a general principle, the less dependent systems are on the social IdP the better. Authentication plus an undecorated identity are the smallest set of useful things a social IdP can provide

8

Lightweight gateway

As a general principle, gateways should be designed to be as lightweight as possible

9

Conflicting principles

Principles 7) and 8) are incompatible in practice

10

Central service or shared code

Either approach would yield valuable commonality of practice

11

Same IdP different Gateway, different results

If our gateways are more than pass-throughs, there is the danger that users and service providers will see different results even with the same SP and IdP if the gateway is different.

12

 

 

13

 

 

14

 

 

15