...
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.com
user+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.
...