Claves de cliente
Todas las solicitudes de cliente en Open Payments se firman con una clave exclusiva que identifica al cliente ante los servidores de autorización y de recursos. Todas las solicitudes, salvo las de nuevas concesiones, incluirán un token de acceso vinculado con la clave.
Registro de claves
Sección titulada «Registro de claves»Un registro de claves es una lista de claves, que son generadas y almacenadas por el cliente, para los casos en que necesite acceder a recursos protegidos de Open Payments. Las solicitudes de concesión se realizan en varias solicitudes HTTP firmadas. Por consiguiente, es importante que el cliente pueda identificarse de manera sistemática ante un servidor de autorización. El registro de claves permite al servidor de autorización verificar que el cliente es quien dice ser.
Cada cliente se representa con una dirección de billetera. El registro de claves de un cliente es de acceso público a través de su dirección de billetera mediante un punto final jwks.json. El servidor de autorización puede recuperar el registro de claves del cliente accediendo a la WALLET_ADDRESS/jwks.json.
https://wallet.example.com/alice/jwks.jsonEstructura del registro
Sección titulada «Estructura del registro»El registro de claves debe exponer las claves públicas en formato de conjuntos de claves web en JSON (JWKS). Las claves deben generarse con el algoritmo Ed25519 y el documento JWKS resultante debe contener los siguientes campos y valores.
{ alg: 'EdDSA', kty: 'OKP', crv: 'Ed25519'}Además, el documento debe incluir los campos x y kid (identificador de clave) para que el cliente pueda identificarse en una firma.
{ "keys": [ { "kid": "3724c845-829d-425a-9a0d-194d6f12c336", "x": "_Eg6UcC8G-O4TY2cxGnZyG_lMn0aWF1rVV-Bqn9NmhE", "alg": "EdDSA", "kty": "OKP", "crv": "Ed25519" } ]}Generación de claves
Sección titulada «Generación de claves»Para inicializar un SDK de cliente de Open Payments autenticado, debe disponer de un par de claves pública-privada y de un identificador de clave.
- El SDK del cliente genera un par de claves con el algoritmo ED25519. El registro de claves del cliente expone la clave pública en formato de JWKS.
- La clave pública se proporciona a la entidad que administra la cuenta (account servicing entity, ASE) del cliente. La ASE es responsable de ofrecer a los clientes un medio para cargar claves. La ASE agrega la clave a su servidor de recursos.
- Se crea un
keyIdpara identificar el par de claves. Por lo general, la ASE es responsable de la creación delkeyId. - El cliente almacena la clave privada para la firma de solicitudes en el futuro. La clave firma el contenido descrito en la sección Método de validación de claves a continuación.
La red de pruebas de Interledger ofrece un ejemplo funcional de obtención de un par de claves y un identificador de clave.
Solicitudes de clientes
Sección titulada «Solicitudes de clientes»Dado que las solicitudes de clientes se realizan en varias solicitudes HTTP firmadas, es importante que el cliente pueda identificarse de manera sistemática en todas esas solicitudes. Por lo tanto, los clientes deben incluir lo siguiente al realizar solicitudes:
- Encabezados
- Un encabezado
Signature-Inputque incluya elkeyIdasociado al par de claves del cliente. Este encabezado es una lista separada por comas de encabezados que corresponden a valores de los datos firmados. - Un encabezado
signaturegenerado en función de laSignature-Input, usando el algoritmo de firmaEdDSA.
- Un encabezado
- Cuerpo
- Una propiedad
clientque contenga la dirección de billetera del cliente.
- Una propiedad
La protección de las solicitudes de clientes sigue un perfil definido en la especificación del GNAP.
Open Payments no admite tókenes de portador.
Solicitudes de concesión
Sección titulada «Solicitudes de concesión»Al recibir una solicitud de concesión firmada, el servidor de autorización obtiene el dominio del cliente de la propiedad client. El servidor de autorización vincula el dominio con la concesión para poder usarlo al adquirir el conjunto de claves en solicitudes posteriores.
Luego, el servidor de autorización realiza una solicitud GET al punto final JWKS del cliente en WALLET_ADDRESS/jwks.json. A cambio, el servidor obtiene el registro de claves del cliente. El servidor encuentra la clave pública que contiene el keyId en el encabezado Signature-Input de la solicitud. Luego, el servidor usa esa clave para descifrar y validar la firma de la solicitud. Esto vincula al cliente con la concesión y permite que el servidor continúe con el proceso de solicitud de la concesión.
Método de validación de claves
Sección titulada «Método de validación de claves»Firmas de mensajes HTTP
Sección titulada «Firmas de mensajes HTTP»Open Payments usa el método de validación de claves mediante firmas de mensajes HTTP (httpsig).
Este método de validación httpsig debe declararse como parte del material de la clave al usar una clave directamente para solicitar una concesión. El material de claves que se muestra es solo ilustrativo. En Open Payments, se espera que la dirección de la billetera se utilice en la solicitud de concesión.
"key": { "proof": "httpsig", "jwk": { "kid": "3724c845-829d-425a-9a0d-194d6f12c336", "x": "_Eg6UcC8G-O4TY2cxGnZyG_lMn0aWF1rVV-Bqn9NmhE", "alg": "EdDSA", "kty": "OKP", "crv": "Ed25519" }}Cuando se usa httpsig, el firmante (el cliente) crea una firma de mensaje HTTP. Los clientes de Open Payments a menudo protegen sus solicitudes a los servidores presentando un token de acceso y la validación de una clave que poseen. La excepción son las llamadas a un servidor de autorización para iniciar una concesión. En ese caso, se utiliza una validación de clave sin token de acceso y se trata de una solicitud firmada no autorizada.
Consulte la página de firmas de mensajes HTTP para obtener más información específica sobre Open Payments. También encontrará información adicional en la especificación de firmas de mensajes HTTP.
Diagrama de secuencia
Sección titulada «Diagrama de secuencia»Se requiere una concesión interactiva para crear un recurso outgoing-payment. Este diagrama muestra la secuencia de llamadas necesarias entre un SDK de cliente de Open Payments y los servidores del lado del emisor para obtener la concesión.
Antes de inicializar el SDK de cliente, debe disponer de un par de claves pública-privada y de un identificador de clave.
La red de pruebas de Interledger ofrece un ejemplo funcional de obtención de un par de claves y un identificador de clave.
sequenceDiagram
autonumber
participant C as SDK de cliente de Open Payments
participant AS as Servidor de autorización
participant RS as Servidor de recursos
C->>C: Inicializar el SDK de cliente con la URL
de la dirección de billetera, el keyId y la clave privada
C->>AS: Envía una solicitud POST de concesión (pago saliente interactivo),
firmada con la clave privada.
AS->>AS: Extrae el keyId del encabezado signature-input de la solicitud de concesión
y obtiene el dominio del cliente del cuerpo de la solicitud.
AS->>RS: Realiza una solicitud GET de las {client_domain/jwks.json} claves públicas
desde el punto final JWKS del cliente.
RS-->>AS: 200, documento JWKS encontrado,
devuelve la clave pública.
AS->>AS: Valida la firma de la solicitud original del cliente
usando la clave pública, vincula el dominio del cliente con la concesión.
AS-->>C: 200 OK
note over AS: Se recoge el consentimiento explícito del usuario del cliente, facilitado por el cliente, el servidor de autorización y el IdP (no se muestra).
C->>AS: Envía una solicitud POST de continuación de concesión,
firmada con la clave privada.
AS->>AS: Extrae el keyId del encabezado
signature-input de la solicitud de concesión, obtiene el dominio del cliente
de la entrada en la base de datos correspondiente a la concesión.
AS->>RS: Realiza una solicitud GET {client_domain/jwks.json} de la clave pública vinculada
con el dominio desde el punto final JWKS del cliente.
RS-->>AS: 200, documento JWKS encontrado,
devuelve la clave pública.
AS->>AS: Valida la firma con la
clave encontrada en el registro.
AS-->>C: 200 correcto, se emite el token de acceso,
solicitud de continuación de concesión completada.