...
Q: Does the Google OpenID Gateway assert eduPersonPrincipalName?
A: To our knowledge, no social IdP asserts a true scoped identifier like eduPersonPrincipalName (ePPN). However, the Google OpenID Gateway may be configured to compute a value for ePPN based on the user’s email address (user@gmail.com), which is known to be a stable attribute for the user. Currently, one of two ePPN formats may be configured:
user@gmail.comuser+gmail.com@gateway.incommon.org
Other ePPN configurations are possible but a basic issue remains: what scope value(s) are asserted in IdP metadata and will those scope value(s) be accepted at the SP? There are no easy answers to these questions. See the wiki topic Google OpenID Gateway Attributes for further discussion.
Q: Does the Google OpenID Gateway assert eduPersonTargetedID?
A: Yes, the Gateway will compute a value for eduPersonTargetedID (ePTID) in addition to eduPersonPrincipalName. Fortunately, we have a better story for ePTID. Google asserts an identifier called a Private Personal Identifier (PPID), defined by the Federal ICAM OpenID 2.0 Profile (which the Google OpenID IdP supports). As it turns out, a PPID is a great fit for ePTID since both are targeted (per-SP) privacy preserving identifiers. See the wiki topic Google OpenID Gateway Attributes for examples.
...
Q: Does the Google OpenID Gateway persist user attributes or identifiers?
A: No, the Google OpenID Gateway is a stateless gateway. Depending on how you configure the Gateway for ePPN and ePTID, the Gateway can function as a 100% passthru gateway. It is extremely lightweight by design.
...
Q: What if Google decides to join InCommon in the future? Wouldn’t there be two Google IdPs in metadata in that case?
A: Yes, it’s remotely possible that Google itself might want to submit IdP metadata to InCommon in the future. If that were to happen, the entityID of the IdP would have to change, so for all practical purposes the two IdPs would be distinct . Moreover, even (and of course the DisplayNames would have to be different). Even if Google did join InCommon, it’s doubtful Google would be willing to assert any eduPerson attributes. If you’re concerned that Google might join InCommon and break your deployment, the best thing you can do is ignore the eduPerson attributes asserted by the Google OpenID Gateway and rely only solely on the user’s email address.
Q: Is there a level of assurance associated with the Google OpenID IdP?
A: A handful of social identity providers are certified by OIX to be US ICAM LoA-1 Certified Identity Providers. (Like InCommon, OIX is an ICAM-approved Trust Framework Provider.) In particular, the Google OpenID IdP is a certified ICAM LoA-1 identity provider.
That said, the the Google OpenID IdP?
A: The Google OpenID Gateway does not assert any particular level of assurance (LoA) value (unspecified); it just echos the attributes that Google provides and computes a couple of its own (ePPN and ePTID). Nothing can be said about the trustworthiness of these attributes, which are not covered by any InCommon Federation policy. Thus service providers must make their own determination regarding LoA on a per-transaction basis at their own risk.A handful of social identity providers are certified by OIX to be US ICAM LoA-1 Certified Identity Providers. (Like InCommon, OIX is an ICAM-approved Trust Framework Provider.) In particular, the Google OpenID IdP is a certified ICAM LoA-1 identity provider.
Q: What is this thing called a “realm” that appears on the Google consent page?
A: A realm is strictly an OpenID construct (there is no such thing in OAuth flows). In a Google OpenID flow, the realm is synonymous with the hostname of the OpenID endpoint at the RP. Google uses this hostname in the same way SAML IdPs use MDUI SP DisplayName.
Q: Does the use of the Google OpenID Gateway violate Google’s license agreement?
A: The short answer is no. If there were any chance we might be in violation of some license agreement, we certainly wouldn’t be suggesting advocating for a central gateway service. The risk would simply be too great.
...