Por qué Google dice no al OpenID

code_sm.png
La implementación de SAML como marco para manejar usuarios confirma implicitamente el rechazo de OpenID
English Version
Es bien conocido en el mundo de los blogs que el sistema para administrar usuarios en Google deja mucho que desear. Al igual que la mayoría de los servicios basados en la red, el correo electrónico siempre a sido el punto de partida, pero una vez que Google decidió entrar el campo con Gmail, las cosas se han vuelto complicadas. En realidad no hay conexión si un usuario utiliza un e-mail diferente para Google Analytics o si utiliza su cuenta reciente de Gmail para acceder a Google Docs. Con la enorme base de usuarios, el problema no es fácil de solucionar, pero puede señalar problemas que la gigante empresa no necesita ahora. Al introducir Google Apps para empresas medianas y pequeñas, Google tiene que solucionar este problema immediatamente ya que Gmail constituye una parte central del servicio. Sin embargo, dudo que nadie quiera dejar atrás una larga presencia establecida en la red bajo la rúbrica de tu email, y adoptar el Gmail tan solo por querer utilizar el Google Apps.
Casi paralelo al anuncio de Google Apps (con el subsiguiente mensaje a Redmond de que vamos a abrir otro frente), se reveló en Google Code, la disponibilidad de un API que permitetener un solo usuario para acceder todos los servicios, o sea, vamos a solucionar la raíz del problema. Dicho API, bajo la rúbrica SAML Single Sign-On (SSO) Service, revela sorprendentemente por qué Google no quiere al Open ID. Explicamos:

  • SAML se define como un estándard para intercambiar información del usuario para acceder contenido confidencial. Exactamente la misma función que OpenID.
  • Al utilizar el API, Google destaca que es solamente el proveedor del servicio, o sea, la vía entre el usuario y un proveedor de identidad, claramente identificado como una empresa asociada con Google que va a cobrar al usuario por dicho servicio.
  • La diferencia está clara. En OpenID, cualquier entidad (empresa, grupo, asociación, quien sea) baja el código necesario de su servidor y se convierte en una entidad para proveer la identidad imediatamente. Este no es el caso bajo el modelo Google; en realidad Google da la apariencia de serlo, pero en realidad depende de una tercera empresa para verificar dicho usuario. ¿Quién es la beneficiaria en este caso? en Google Apps, una empresa llamada SXIP.
    SXIP, como única proveedora de Google Apps en este campo, han acceptado el estándard OpenID bajo la versión 2 de su producto,pero por alguna razón misteriosa, la versión de Google Apps no incluye tecnología de OpenID, quizá para evitar un conflicto con la licencia GPL de OpenID. Otra teoría puede ser que estén buscando compatibilidad con Salesforce.com, la compañía más grande de aplicaciones en línea de los EEUU. Un sistema común de identificación entre Google Apps y Salesforce beneficiarían enormemente a las dos empresas, aunque sea al precio de conveniencia al usuario.
    Ahora que Microsoft y Verisign han adoptado OpenID, en realidad solo queda la adopción de Google y Yahoo para que se realice un enorme paso en el avance del Web 2.0, pero al parecer, todavía queda mucho para eso. Una vez que se popularize el uso de Google Apps para las empresas medianas y pequeñas, dudo que OpenID cuente con el apoyo que necesite para facilitar el acceso fácil a cualquier aplicación que Google ofrece.

    2 Comment

    1. […] como ma.gnolia.com , wordpress.com, Digg , AOL incluso MicroSoft, y como excepción, se rumorea que Google no usara OpenID […]

    Leave a Reply

    13 + fourteen =