...
Item | Description | Proposed syntax |
|---|---|---|
Gateway Identifier | A value that uniquely identifies the gateway used (if any) | URI |
Social Provider Identifier | A value that uniquely identifies one of the social providers (e.g., one for Google, Facebook, Twitter, Yahoo,....) | URI |
Display Name | A human-friendly representation of the authenticated user's name | displayName |
Given Name |
| givenName |
Surname | A surname or surname component | sn |
Principal Name | A scoped user identifier | ePPrincipalName |
Email Address | The user's email | |
Persistent Directed Identifier | A unidirectional identifier, unique to a triple of IdP, SP and user | ePTargetedId |
|
|
|
...
Discussion areas about the Social Identity Protocols being ingested and gatewayed to SAML:
...
Conversation Point | Applicable to any Context | Context 1: Federation centric ‘Social’ Identity Service | Context 2: Institutional centric ‘Social’ Identity Service | Context 3: Federated SP, SP centric ‘Social’ *Identity *Identity Service | Context 4: Standalone Service (non federated) |
|---|---|---|---|---|---|
What are the dimensions of ongoing support for the given context? (e.g costs borne by SP's, impact to end users...) |
| ||||
How should required attributes be dealt with? |
|
|
|
|
|
When 'user' is specified, what are the possible ways to appropriately identify them with a unique identifier? |
|
|
|
|
|
What is available as data is 'passed through' to the interior environment? |
|
|
|
|
|
What are the benefits / drawbacks of running a gateway in this context? |
|
|
|
|
|
What do I have to do as a Service Provider to leverage this particular model? |
|
|
| You may have additional registrations to perform for your service for each endpoint you want to allow in |
|