Intercambio de atributos OpenID (AX)

22 Abril 2010 Comentar »

El Intercambio de Atributos OpenID puede ser utilizado para intercambiar cualquier tipo de información entre la Parte Consultante y el Proveedor del Servicio, siempre y cuando ambas partes se hayan puesto de acuerdo en definirlo como atributo. Este es el motivo principal por el que he parado el desarrollo del sistema de micropagos con OAuth que llevaba en marcha y lo estoy adaptando a OpenID, mediante esta extensión del protocolo se puede intercambiar la información de la transacción entre las partes.

Como me encanta matar varios pájaros de un tiro estoy aprovechando el tiempo invertido para desarrollar un proveedor OpenID que utilice el DNI electrónico como mecanismo de autentificación, mecanismo que pienso utilizar en el sistema de recogida de firmas y votaciones no anónimas dniesign. Quise presentarlo al desafio abredatos, pero mi manejo de Grails todavía no es fluido … todavía =)

He aprovechado el cambio para adoptar como framework de desarrollo GrailsGrails es con diferencia el mejor framework para desarrollo web que he visto hasta la fecha. No se de ningún framework que maneje con más claridad la persistencia de objetos que GORM.

Usuarios como observadores o como protagonistas

29 Marzo 2010 Comentar »
Aplicaciones en las que el usuario es un observador: aquellas en las que el usuario simplemente se dedica a observar/comentar una información.
Aplicaciones en las que el usuario es protagonista: aquellas en las que la interactuación con la aplicación tiene un impacto claro sobre algún asunto concreto.
Uno de los retos del momento consiste en crear aplicaciones que hagan al usuario protagonista directo, sin delegaciones, de cada vez más procesos de toma de decisión … seguro que así se acaba para siempre con las crisis.

OAuth y Administraciones Públicas

23 Marzo 2010 Comentar »
Oauth es un estándard abierto para el control de la privacidad de los datos. Si un usuario tiene información personal almacenada en un determinado sitio web , OAuth proporciona un mecanismo para que pueda  autorizar a ese sitio web a compartir datos con otro sitio web. También hace posible ese intercambio de información sin que sea necesario que el sitio que usa los datos sepa nada de la identidad del usuario. Resuelve el problema de la forma más elegante posible, compartiendo los datos sólo si el usuario da su permiso.
¿Cómo podrían aprovecharse los usuarios de las Administraciones Públicas de OAuth?
Por ejemplo, si la Agencia Tributaria necesitase para la tramitación de un determinado servicio online de información gestionada por la Seguridad Social el problema se podría solucionar recreando este escenario:
• Poniendo la seguridad social los servicios de información requeridos en red protegidos con OAuth (la identificación del usuario para su aprobación se podría hacer con el DNI electrónico)
• Creando la Agencia Tributaria el servicio online que al necesitar los datos de la seguridad Social redireccionase al usuario para que este diera su aprobación.
OAuth también podría usarse como pasarela de pagos para automatizar y estandarizar el pago de tasas.
Esto sería un paso más a la oficina sin papel y al ahorro en muchos conceptos.

Revueltas sociales

17 Marzo 2010 Comentar »
Acabo de leer una noticia en la que se comenta:
‘El director del Fondo Monetario Internacional, Dominique Strauss-Kahn, ha advertido hoy de que “el público está impaciente” ante las anunciadas reformas en el sistema financiero pero que no acaban de llegar. Durante una intervención ante la Eurocámara en Bruselas, el banquero francés ha afirmado que si los cambios se siguen retrasando, la expectación podría desembocar en “revueltas sociales”, por lo que ha animado en seguir adelante con las negociaciones en pos de un mayor control y supervisión que eviten que una recesión como la actual pueda repetirse.’
Tal y como está escrita la noticia parece que en esas reuniones sólo hay algo en lo que todos están de acuerdo, y es que deben crearse herramientas que proporcionen un mayor control y supervisión, el problema se da cuando deben decidir cómo se consigue eso, ¿cada uno suelta su discurso van pasando los días y no se consigue nada?
Los tiempos de los mensajeros a caballo intercambiando manuscritos entre bancos nacionales han pasado, la única forma de conseguir esas herramientas es creando sistemas informáticos abiertos que monitorizen los intercambios monetarios. El objetivo se conseguirá cuando se tengan esos sistemas, las reuniones deberían ser para la toma de requisitos y el seguimiento de avances. Habrá gente que diga, la cosa va más allá de un programa … ok, de acuerdo, pero mientras no se tenga el programa no se pondrá nada en marcha ni habrá ningún cambio.
No me puedo creer que no existan ya esos sistemas.

Micropagos III – Flujo de operaciones que se producen en una transacción

3 Marzo 2010 Comentar »

Introducción

OAuth es un protocolo abierto que busca estandarizar la forma en la que las aplicaciones acceden a datos privados albergados en servicios remotos. Este documento explica como se puede utilizar OAuth para realizar transferencias de dinero a través Internet.

El documento se puede descargar desde aquí.

Flujo de operaciones

En el flujograma de ejemplo participan:

  • El banco, prestador del servicio.
  • La entidad/persona beneficiaria de las transacciones, consumidora del servicio.
  • El usuario que dispone de una cuenta en el banco prestador del servicio y autoriza al consumidor del servicio a realizar un cargo.

Premisas:

  • Para que una entidad/persona pueda ser consumidora de servicio debe primero abrirse una cuenta con los bancos prestadores del servicio con los que quiera colaborar.
  • El usuario debe disponer de una cuenta en alguno de los bancos que el consumidor del servicio le ofrezca.

El usuario está navegando en el portal de un consumidor de servicio y decide hacer click en alguno de los enlaces que facilitan un micropago. El consumidor del servicio le ofrece los canales de los que dispone para poder recibir el micropago:

Para que el consumidor de servicio pueda utilizar el Banco de Internet debe disponer de una cuenta en el mismo. Durante el procedimiento de alta de cuenta se le ha proporcionado una clave de consumidor y un secreto de consumidor con los que podrá iniciar los intercambios de información con el banco.

Después de que el usuario haya seleccionado un banco empieza el intercambio de información. El consumidor de servicio solicita del banco un token de petición, en este punto de la conversación ese token todavía no tiene nada que ver con el usuario.

Cuando el consumidor de servicio recibe el token de petición envía al usuario con el mismo a la página del banco en la que se debe autorizar la transacción indicándole la URL a la que tiene que devolver al usuario una vez haya terminado la operación.

Una vez en la página del banco OAuth requiere que los proveedores de servicio autentifiquen a los usuarios antes de preguntarles si garantizan la operación.

OAuth hace posible las transacciones sin que los consumidores del servicio tengan que manejar información sensible (ni la contraseña ni el número de tarjeta).

Después de haberse identificado correctamente. El banco informa al usuario del beneficiario y la cantidad de dinero de la transacción que debe autorizar. Se puede usar el mismo mecanismo para autorizar pagos periódicos.

Una vez autorizada la operación por el usuario, el token pasa a estado autorizado en el proveedor de servicio y se redirecciona al usuario a la página del consumidor del servicio que inició la conversación.


Mientras el usuario espera el consumidor de servicio intercambia con el proveedor del servicio (el banco) el token de petición autorizado por un token de acceso.

En terminología OAuth los tokens de petición son sólo válidos para obtener el consentimiento del usuario mientras que los tokens de acceso se utilizan para acceder a recursos protegidos. En el caso que trata este documento el token de acceso tiene el siguiente uso:

  • La primera vez que se acceder con un token de acceso se finaliza la transacción autorizada por el usuario.
  • La segunda y sucesivas veces que se utilize el token de acceso el banco devolverá un recibo.

Referencias:

Guía para principiantes del protocolo OAuth


Tormenta perfecta

1 Marzo 2010 Comentar »
Hace un par de días vi en Informe Semanal un reportaje en el que los editores de los periódicos hablaban de que la crisis actual unida a lo que está suponiendo internet como medio de difusión de contenidos estaba suponiendo para ellos una especie de tormenta perfecta.
Se me hace muy difícil, imposible diría, llegar a imaginarme pagando por una subscripción mensual a un periódico. Lo que no se me hace para nada difícil imaginar es pagar por ejemplo 50 céntimos por tener acceso durante un día a los contenidos de un periódico … ó 30 céntimos por una mañana, ó 20 céntimos por una hora ó 10 céntimos por un contenido …
Los micropagos son fundamentales para poder encontrar el tipo de transacciones que pueden funcionar en Internet. Es un problema que no está resuelto … y dudo que acabe la tormenta mientras no se desarrollen al máximo, y de forma abierta, este tipo de fórmulas.

Micropagos II – Modelo de datos

27 Febrero 2010 Comentar »

La mejor manera de empezar una aplicación es haciendo su modelo de datos, para esta aplicación me he basado en este

Aunque hay varias opciones claras para poder usar clientes OAuth en Java, el tema de montar el proveedor es otra cosa, no hay mucha información y todavía no he visto nada claro, es aquí donde está el peligro. Ahora estoy jugando con una librería del proyecto Spring Security.
El modelo de datos sería para montar la entidad que prestaría el servicio de micropagos, por lo pronto lo he dejado sencillo, cuando tenga totalmente resuelto el tema del prestador de servicios le añadiré certificados electrónicos.

Micropagos I

22 Febrero 2010 Comentar »

Oauth es una técnica que utilizan prestadores de servicios de Internet como Twitter, OpenSocial, Flickr, Yahoo, Google, Youtube, para exponer de forma segura a terceros los servicios que ofrecen a sus usuarios sin que tengan que viajar de un lado a otro las contraseñas.

Por lo pronto sólo he visto que se use en temas de redes sociales, pero no hay nada que impida que ese mismo patrón de interactuación pueda ser utilizado para ofrecer otro tipo servicios más ‘físicos’, me vienen a la cabeza aplicaciones de logística.

Dándole caña a la aplicación de gestión de firmas con DNIE electrónico traté con información que me hizo ver la posibilidad y ahora estoy cociendo un prototipo de sistema de micropagos que haría usando APIs OAUTH. El tema sería hacer ver una forma de crear aplicaciones que permitan hacer pagos de 50 céntimos o un euro sin cobrar comisiones a los usuarios … a ver lo que sale.

Poniéndose a imaginar lo que se puede conseguir con aplicaciones de este tipo, se puede llegar a formas de distribución de ayudas que podrían funcionar más o menos así:
• Creando un fondo que se repartiría entre todos los que quisieran participar, al final cada usuario dispondría de una cuenta con una asignación semanal que sólo podría gastar online siguiendo una serie de reglas acordes al problema concreto que se quiera solucionar.
• Cualquiera que quisiera acceder a los cobros se tendría que dar de alta en la aplicación y se tendría que buscar la vida explicando a los usuarios en su portal por qué se merecen la aportación.
• El sistema dejaría perfectamente reflejado donde y cuando ha ido hasta el último céntimo.
• En función de la evolución se podría crear un sistema de Karma que premiase asignando más recursos a aquellos usuarios que mejor hubieran distribuido su asignación en semanas anteriores.

… una especie de máquina de movimiento continuo autoregulada.

Si parte de los miles de millones de ayudas que han dado los gobiernos con el tema de la crisis se hubieran repartido de esta forma se sabría mucho mejor donde han ido.

Subiendo montañas

18 Febrero 2010 Comentar »

Si uno tiene que subir una montaña muy alta no se puede plantear hacerlo de una, debe hacer escalas.
Ahora mismo en Internet se dan 3 tipos problemas que cuanto más tiempo se tarden en resolver será peor:
– La privacidad de los usuarios.
– Los sistemas de micropagos (la única vía lógica que le queda a los de los contenidos).
– La segmentación de la red y los controles de acceso para que los menores de edad no tengan acceso a determinados contenidos.

Para resolver todos esos problemas son necesarios los dispositivos criptográficos como el DNI electrónico, se tiene que poder identificar a las partes e intercambiar información de forma segura.

Firma electrónica reconocida

10 Febrero 2010 Comentar »

Información extraida del portal oficial sobre el DNI electrónico:

” La Ley distingue entre firma electrónica avanzada y firma electrónica reconocida:
(Art. 3.2) La firma electrónica avanzada es la firma electrónica que permite identificar al firmante y detectar cualquier cambio ulterior de los datos firmados, que está vinculada al firmante de manera única y a los datos a que se refiere y que ha sido creada por medios que el firmante puede mantener bajo su exclusivo control.
(Art. 3.3) Se considera firma electrónica reconocida la firma electrónica avanzada basada en un certificado reconocido y generada mediante un dispositivo seguro de creación de firma.
(Art. 3.4) La firma electrónica reconocida tendrá respecto de los datos consignados en forma electrónica el mismo valor que la firma manuscrita en relación con los consignados en papel.