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.

ControlDatosGob

27 Enero 2010 Comentar »

Bueno del primer arreón que le he dado al desarrollo de la aplicación de control de datos ha salido http://bit.ly/deBh8V, ahora dejaré reposar un poco el tema y con lo aprendido retomaré el desarrollo de la aplicación de voto con DNI electrónico. El código se puede descargar desde aquí http://code.google.com/p/controldatosgob/ y cumple con la creo que es la mejor fórmula para desarrollar aplicaciones web -> GWT + Rest -Jersey + JPA Hibernate + Hibernate Search.

GWT como framework para desarrollar interfaces de usuario me garantiza que con muy pocos retoques el mismo código sirva para los principales navegadores.

No se los dispositivos que saldrán en los proximos años lo que si se es que tendrán conexión a Internet, eso quiere decir que tendrán acceso a todos los servicios REST que sea capaz de ofrecer. La mejor forma de asegurarse de que los servicios de tu servidor serán accesibles en el futuro desde el mayor número posible de programas o dispositivos es desarrollarlos siguiendo los principios REST, las arquitecturas REST están pensadas para sacarle el máximo partido a Internet.

No se la base de datos que usaré, lo que si que se es que la mejor manera de interactuar con una base de datos es usando un framework de persistencia de objetos, JPA es un estándar apoyado por los principales actores en el negocio de las base de datos. No está controlado por una única organización, es a día de hoy la opción más avanzada para realizar persistencia de objetos y con muy poco esfuerzo el mismo desarrollo se puede usar en la mayoría de las base de datos.

El DNI electrónico es la clave para poder garantizar que estás tratando con quien dice ser y para poder crear sistemas de mensajería seguros y de intercambio de archivos firmados … anda y que no hay cosas que hacer con esto.

De Hibernate Search hablé en el último post.

No se como será el futuro, lo que si se es que cada vez hay más gente que utiliza la red para informarse y hacer sus gestiones, la cantidad de gente y el número de horas que pasan conectados crece día a día. Conforme van apareciendo nuevos servicios las combinaciones para crear soluciones sobre ellos se multiplican y para hacer cosas lo único que se necesita es un ordenador con una conexión a Internet.

Hibernate Search

20 Enero 2010 Comentar »

Si tienes un montón de documentos digitalizados y quieres realizar búsquedas de texto sobre ellos, Hibernate search puede ayudarte a resolver muchos de los problemas con los que te vas a encontrar.

Hibernate Search resuelve las carencias de SQL para realizar búsquedas complejas de texto utilizando para ello como motor de búsqueda Apache Lucene. Permite:

  • Mantener actualizados y sincronizados el índice que se crea para la búsqueda de textos y los datos de la base de datos.
  • Obtener objetos persistentes a partir de las búsquedas de texto
  • Crear índices respetando relaciones entre objetos del modelo.

Dispone de un analizador que permite:

  • Hacer búsquedas por aproximaciones fonéticas, por sinónimos o palabras no acentuadas…
  • Puntuar los resultados de una búsqueda.

La mayor parte del esfuerzo consiste en la optimización de las consultas de búsqueda. Es la herramienta que tienes que utilizar si quieres añadir búsquedas profesionales del estilo Amazon o Google a los datos que manejan tus bases de datos.

Control de gastos de reuniones

9 Enero 2010 Comentar »

Mi amigo Oscar me comentó que estaría bien disponer de una aplicación que sirviera para poder hacerse una idea clara de los gastos de una reunión. De esa conversación ha nacido Control de gastos de reuniones, el código se puede descargar desde aquí.

Es un prototipo pero creo que la idea está clara, la evolución ahora dependerá de los estímulos que se reciban.

De esa forma cuando nos juntemos y no sepamos de qué hablar, cosa que nunca ha pasado, siempre podremos sacar la aplicacioncita y mejorarla en algo.

La mejor Haka

25 Diciembre 2009 Comentar »

¡Feliz Navidad!