[Py-MAD] 3, 2, 1... OpenBadges!!
Julio Antonio Soto de Vicente
julio at esbet.es
Tue Dec 16 01:56:51 CET 2014
A mí me gustaría tocar un poquito (más) las... eso antes de sacarlas.
Meditando sobre el estándar de Mozilla, me he dado cuenta de que no existe un mecanismo que no te permita faslificar la imagen “en local” de una badge. Es decir, el SVG de la propia badge puede ser modificado, y aún así saldría verificada como correcta (puesto que has tocado el código de la tag <svg> y no el de la assertion, así que el verificador no se quejaría).
Supongo que la respuesta de Mozilla ante esto será: “bueno, pero en la assertion hay un campo que es el link a la imagen svg en los servidores del emisor de la badge. El señor que la está verificando no tiene más que irse a ese link, y ver que el svg que aparece ahí y el de la badge que está comprobando no es el mismo”.
Aún así, me parece que no han pensado en ello. Intuyo que en Mozilla realmente solo les preocupa el tema de la assertion, y el resto del “cuerpo” del svg, png... Son flores.
¿Solución? Se me ocurre que el signer haga dos cosas: embeder la assertion firmada en el svg (tal y como ya está haciendo), y embeder otra tag con otro campo (algo así como <image-sign>) con la firma del código de la tag <svg> firmado con la misma clave privada. Con esto se conseguiría:
1. Seguir cumpliendo con el estándar (cojo) de Mozilla y
2. Tener un verificador que no obligue a comprobar si el acreditado ha “tuneado” la imagen de la badge.
O igual es que pienso demasiado :P
> El 16/12/2014, a las 01:17, Jesus Cea <jcea at jcea.es> escribió:
>
>> On 15/12/14 20:18, Yamila Moreno Suárez wrote:
>> +1 a que el color indique si se dio o se asistió
>
> El mayor problema para los asistences es la "evidencia". La prueba de
> asistencia. Es algo a resolver antes de dar badges.
>
>> Como "ponente" no tiene su equivalente en "tallerente" (cuánto
>> palabrastro), proponía el cambio a: "taller en" / "charla en" o algo
>> así, pero no me parece en absoluto lo suficientemente importante :)
>
> Mando los tres badges. Echadle un ojo. "Ponente 2014" me parece mucho
> más molón que "Charla 2014". "Taller 2014" es aceptable a duras penas.
> Diría que los talleres deberían tener un badge personalizado por taller,
> en vez de uno genérico. Poner "Charla en 2014" en vez de "Charla 2014"
> sobrecarga el diseño sin aportar nada.
>
> Todo en mi opinión, claro :)
>
> La ventaja evidente de poner "Charla 2014" en vez de "Ponente 2014" es
> que se puede reutilizar el mismo badge, cambiando el fondo, para indicar
> ponente y asistente.
>
> Señores, yo creo que se puede salir ya con el Badge de "Ponente 2014" y
> el criterio de los 15 minutos en una sesión. ¿Alguien ha hablado en 2014
> y no ha llegado a esos 15 minutos?. El único caso que conozco es el mío
> de la semana pasada, y cumplo los 15 minutos de sobra con mi charla del
> calendario Python de Marzo 2014.
>
> ¿Os parece aceptable?. ¿Pablo?. Quiero salir YA :).
>
> --
> Jesús Cea Avión _/_/ _/_/_/ _/_/_/
> jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
> Twitter: @jcea _/_/ _/_/ _/_/_/_/_/
> jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/ _/_/ _/_/
> "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
> "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> <python-madrid-ponente2014_2.svg>
> <python-madrid-ponente2014_3.svg>
> <python-madrid-taller2014.svg>
> _______________________________________________
> Asociación Python España: http://www.es.python.org/
> Python Madrid: http://www.python-madrid.es/
> Madrid mailing list
> Madrid at lists.es.python.org
> https://lists.es.python.org/listinfo/madrid
More information about the Madrid
mailing list