This page captures relevant criteria upon which External ID providers might be assessed (actual assessment results are perhaps unlikely to fit in one table!)
Should Required vs. Desired vs. Optional answers be identified separate from assertions? Note that if so, which answers are Required, etc. will vary based on which solution approach is taken.
Service |
Reassign |
Pwd Policies |
MFA |
ID Proof |
Attributes |
Attr Stability |
Release |
Consent |
Consent Expr |
MFA Expr |
Directed vs. Static |
Mission |
Stability |
EULA/ Terms |
Cost |
Audits |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yahoo! |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"user_id" (numeric, directed identifier) is not reassigned? |
Six characters. Some complexity reqt or minimal dictionary check; specifics not clear. |
App or SMS. |
Limited to people with large numbers of followers. |
ID; Name(s); gender; locale; timezone, link (to profile); Email; Friends (that also use this App) |
Many are user-managed |
Release generally by bundles. Apps request groups of data. |
Granular at the "bundle" level. [Some elements also controlled by profile visibility settings in FB] |
Lack of consent expressed with OAuth exceptions? |
Not expressed? |
Directed (older APIs versions=static) |
For profit; social networking. |
Reasonably strong |
[https://www.facebook.com/legal/terms |
None |
|
|
Amazon |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Twitter |
Yes, accounts can be reassigned. This depends on if they were deleted, deactivated, or suspended but it is possible. |
Must be at least 6 characters. No specific requirements for special characters, capitalization, or numeric. |
Yes. 2 Options: SMS Code, or challenge to Mobile App (Accept / Deny). |
Limited to "highly sought after users." They "do not accept requests for verification from the general public". |
Username, Language, TimeZone, Short Bio, Location, Website Link, Profile Photo, Verification Status, |
Unstable. User controlled w/ little or no validation. |
Bundled. |
Controlled through application privacy settings. |
Implied through availability. |
No. |
|
Public. |
Strong. |
None |
|
|
LinkedIn |
|
Must be at least 6 characters. No requirements for special characters, capitalization, or numeric. Recommendations are made. |
Yes. Code sent via SMS. |
No. |
Depends on privacy settings but many are available: id, first name, last name, email, location. |
Unstable. User controlled w/ little or no validation. |
Bundled. |
Controlled through application privacy settings. |
Implied through availability. |
|
|
Public. |
|
None. |
|
|
Microsoft |
If account is closed, email address or user name (not the Microsoft account itself) may be recycled and assigned to another user. |
User can opt to force password change every 72 days. |
Phone app, Text msg. or phone call for accessing sensitive account information such as password change. Two step verification can be set up when signing in on a new device. Security code to app, phone or alternate email address. |
None, except to verify control of 3rd party email address. |
Display name; |
User controlled |
Bundles. Varies depending on service being accessed. |
Subject to privacy practices for each app accessed. |
Implied through availability. |
? |
Static |
Public: |
Strong |
http://windows.microsoft.com/en-us/windows/microsoft-services-agreement |
None |
|
UnitedID |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Desired Reponses from... |
Reassign |
Pwd Policies |
MFA |
ID Proof |
Attributes |
Attr Stability |
Release |
Consent |
Consent Expr |
MFA Expr |
Directed vs. Static |
Mission |
Stability |
EULA/ Terms |
Cost |
Audits |
Eric Goodman |
No reuse/ |
Ideally Silver compatible |
Ideally |
Varies by use case |
Required: UserID; |
Indefinite |
Ideally granular |
Ideally |
SAML Attribute |
SAML AuthnContext (and/or attribute?) |
Static preferred. In some use cases static is required. |
Non-user tracking/privacy preserving is ideal |
Always good |
??? |
$0 or low |
NIST LoA 1 |
David Walker |
Non-reassigned identifier available |
Silver / LoA-2, but depends on use case. |
Yes, but depends on use case |
Depends on use case |
Non-reassigned identifier, email |
Documented |
Documented |
Yes |
Documented |
SAML AuthnContext (and/or attribute?) |
Documented |
Non-user tracking/privacy preserving is ideal |
Always good |
Documented |
$0 or low |
NIST LoA 1 (LoA 2 desired) |
Mary Dunker |
never reassign unique identifier |
Comparable to Bronze or Silver - depending on use case |
a desirable option |
Varies by use case. Important to publish ID Proofing, if any is done |
R&S attributes |
Document |
Document |
yes - required |
SAML Attribute |
SAML AuthnContext (and/or attribute?) |
Document |
Non-user tracking/privacy preserving is ideal |
Good - Document |
Document |
$0 |
NIST LoA 1 |
John Breen |
No reuse |
Depends on use case. |
Support Required |
By use case |
non-reassigned id |
Documented |
Documented |
Case by case. Some attr. no consent (unique id). |
SAML attribute |
SAML AuthnContext (and/or attribute?) |
Documented |
Non-user tracking/privacy preserving is ideal |
Good - provable via documentatioin/metrics |
Documented |
$0 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Legend
- Service: Name of External ID service provider
- Account Management Policies
- Reassign: Policies around reassignment of accounts. Specifically, whether the "key identifier") reassigned to different users.
- Pwd policies: Overview of password requirements (related to complexity, guessing resistance, etc.)
- MFA: Does the vendor offer Multi-Factor support.
- Account Identity Vetting
- ID Proof: Is there any identity proofing done by the External provider that would allow a campus to trust attributes other than Ext ID-sourced IDs (like "Account Name" and "email")
- Attributes: Related to ID Proofing, what attributes are collected and how are they proofed.
- Attr Stability: Stability of the External ID and attributes over time
- AuthN Policies
- Release: Attribute release practices, including
- What attributes are released?
- What is the granularity of data release? (Attributes vs. bundles)
- Consent: Is there a user consent process before data is released to SPs.
- Consent Expr: How does the provider express that user consent was provided for release
- MFA Expr: How do they express whether Multifactor has been used?
- Directed vs. Static: Does the External ID provider release a directed (per SP) or static (correlatable across SPs) identifier?
- Release: Attribute release practices, including
- Company Details
- Mission: Mission of the company, including:
- Private vs. public
- Privacy focus
- Stability: Stability of the vendor and the service that the vendor offers
- Likely this is not directly measurable, and would be more along the lines of
- "how long in business"
- "how long service has been operational"
- "how many users using their IDs"
- etc.
- Mission: Mission of the company, including:
- Other Concerns
- EULA: Are there terms the External provider applies that are potentially in conflict with general campus policies?
- Cost: Is there a cost to the user or the organization to leverage the IDs?
- Audits: What 3rd party certifications or audits are available to confirm function of service?
References
https://support.twitter.com/articles/101299-why-can-t-i-register-certain-usernames#
https://support.twitter.com/articles/14609-changing-your-username#
https://www.schneier.com/blog/archives/2013/08/twitters_two-fa.html
https://support.twitter.com/articles/119135-faqs-about-verified-accounts#
"we do not have a reliable system for identifying and counting duplicate or fraudulent accounts"http://investors.linkedin.com/secfiling.cfm?filingID=1271024-14-34
https://developer.linkedin.com/documents/profile-fields
Microsoft