Mi experiencia con OpenBadges en Python Madrid (de momento)

Un par de antecedentes:

• OpenBadges: un estándar para certificaciones seguras y verificables (II).
• OpenBadges: un estándar para certificaciones seguras y verificables.

La web de OpenBadges de Python España pretende ser un portal que la propia Asociación Python España y los grupos locales puedan emplear para entregar OpenBadges a las personas que cumplan los criterios que se establezcan.

Tras madurar el asunto durante meses, invertir unas semanas en el desarrollo de OpenBadgesLib (en realidad, la mayor parte del trabajo lo ha hecho LuisGF) y preparar una web mínima de supervivencia, estábamos listos para salir.

Los primeros OpenBadges creados y entregados aprovechando esta infraestructura han sido los de Python Madrid. Entre el 16 y el 18 de diciembre de 2014 se generaron los OpenBadges correspondientes a los ponentes que han dado una charla en Python Madrid durante 2014, cumpliendo el criterio documentado al efecto. Utilicé la versión 0.2.1 de OpenBadgesLib y el proceso ha sido bastante indoloro y limpio.

Los puntos a mejorar son:

• Hay que corregir algunos problemas con la gestión del parámetro -o.
• Cada tipo de OpenBadge emitido por una entidad de emisión debería poder utilizar una clave criptográfica diferente. Ahora mismo hay una única clave criptográfica por emisor.
• Debería guardarse un registro de los OpenBadges emitidos: Timestamp, UID, correo electrónico y evidencia.
• El envío de los OpenBadges por correo electrónico debería ser más sencillo y automatizable. Ahora mismo es un proceso 100% manual y proclive a errores.
• La coordinación de las configuraciones guardadas en el ordenador local y en el servidor es un proceso manual. Hay que repetir lo mismo varias veces en diferentes lugares, y cualquier inconsistencia creará problemas que pueden no detectarse inmediatamente.
• En esta versión de OpenbadgesLib la evidencia es opcional. Es demasiado fácil olvidarse de ponerla.

El problema ahora es mostrar esos OpenBadges. En mi caso concreto, teniendo presencia Internet propia y con nociones básicas de CSS, lo tengo bastante resuelto. No sé cómo será cuando leas este texto, pero en diciembre de 2014 mis OpenBadges se muestran en la parte inferior de la página y responden al hover y al click. Mejorable, pero sirve para ir tirando.

Queda pendiente escribir artículos sobre los diferentes mecanismos de publicación. Esto es imprescindible para los receptores de OpenBadges que no tengan una web propia.

La emisión última de los OpenBadges ha sido fácil, pero el proceso hasta aquí no ha sido un camino de rosas ni mucho menos. Las herramientas disponibles están incompletas y plagadas de bugs.

Las cosas han sido más difíciles porque LuisGF y yo nos hemos empeñado en avanzar el estado del arte: Python 3.4, uso de gráficos vectoriales SVG, OpenBadges con firma digital en vez de hospedados y el intento fallido de emplear criptografía de curvas elípticas. Al final nos hemos tenido que conformar, de momento, con utilizar RSA.

Algunos de los problemas que hemos encontrado son:

• https://github.com/mozilla/openbadges-backpack/releases/tag/v2.0.3:

  El soporte SVG llegó apenas unos días antes de la presentación oficial de la versión 0.2.0 de OpenBadgesLib. Hasta ese momento no podíamos subir los OpenBadges generados al Backpack de Mozilla.

• De hecho el soporte SVG aún está incompleto:

  • Backpack not support SVGZ but yes SVG. #1038.
  • SVG Badge with enconding not work #1036.

• Empleamos una librería JWS que parece abandonada y que no funciona en Python 3. La hemos modificado para que funcione en Python 3 y la estamos distribuyendo internamente como un componente de OpenBadgesLib. Eso tendrá que cambiar en algún momento. Nos apetece muy poco mantener esa librería por nuestra cuenta. Veremos.

• Tanto el OpenBadges Metadata Validator como el Backpack de Mozilla soportan OpenBadges firmados con criptografía de curvas elípticas... pero aparentemente lo están implementando mal:

  • OpenBadges Metadata Validator: Elliptic Curve signed assertions are not following the JWS draft standard #30.
  • Backpack: Elliptic Curve signed assertions are not following the JWS draft standard #1042.

• Aunque la criptografía de curvas elípticas es la nueva criptografía de clave pública y el estándar JWS la soporta explícitamente, lo cierto es que me ha sido imposible encontrar ejemplos de tokens JWS usando ECC. Tampoco he encontrado validadores JWS compatibles con ECC. En cuanto a librerías, lo único que he visto es jsjws pero mis conocimientos de Javascript son mínimos.

  Si no podemos garantizar la interoperatividad nos arriesgamos a emitir OpenBadges que fallen la verificación de terceros. Por eso hemos decidido salir primero usando firmas RSA. Con ellas la interoperatividad está garantizada.

  Esta situación es un poco triste pero es de esperar que cambie pronto si se populariza OpenID Connect.

  Nosotros seguimos interesados en la criptografía de curvas elípticas y estaremos al tanto de la situación.

• Issuer URL is truncated #1041:

  Aunque nosotros indicamos que el emisor de los OpenBadges emitidos por Python Madrid es https://openbadges.es.python.org/python-madrid/, en el Backpack de Mozilla aparece como https://openbadges.es.python.org/. Se pierde la comunidad.

  Pulsad sobre mis OpenBadges al final de la página para ver lo que quiero decir (ahí están en diciembre de 2014, es posible que los haya movido).

• Falsification: exact same assertion, different image #1039:

  El Backpack de Mozilla confirma que la certificación contenida en el OpenBadge sea correcta y que se haya emitido para ti. Pero no comprueba que el gráfico OpenBadge que contiene ese certificado sea el correcto.

  Idealmente el Backpack debería coger el certificado enviado en el OpenBadge, extraerlo y verificarlo, descargar la imagen original del servidor y mostrar en pantalla dicha imagen. No la subida por el usuario.