11°

Sandbox del lab

Sandbox de Finanzas Abiertas

Chile tiene la norma y no tiene un lugar público donde probarla. Este es uno, con la receta para enchufar tu propia implementación.

Qué se puede probar aquí

Todo lo que el Anexo Técnico exige en el cable: descubrimiento contra un directorio, registro dinámico a partir de una declaración de software firmada, PAR obligatorio llevando un objeto de petición firmado y cifrado, mTLS con token ligado al certificado, consentimiento con su detalle completo y segundo factor, y authorization_details llegando hasta el token emitido.

Probarlo en un minuto

La aplicación solicitante de demostración recorre el flujo completo en el navegador y muestra, al final, cada paso que dio y las entradas de RAR que llegaron al token. Escribe tu propio correo: el segundo factor va a la dirección que ingreses.

Dónde vive cada pieza

ServidorRol
directory.efraingaray.comDirectorio de Participantes. Las rutas bajo /public no exigen certificado.
auth.efraingaray.comServidor de autorización. Tramo del navegador.
mtls.efraingaray.comEl mismo servidor por mTLS: PAR, token y registro dinámico.
api.efraingaray.comAPIs de recursos del banco. Exige certificado de cliente.
banco.efraingaray.comBanco Fantasma: pantalla de consentimiento y segundo factor.
psbi.efraingaray.comAplicación solicitante de demostración. Empieza aquí.

Enchufar tu propia implementación

Cuatro pasos. Los tres primeros se hacen una vez; el cuarto es el flujo en sí.

  1. 1 · Consigue tus certificados

    Cada participante necesita tres: transporte para el mTLS, firma para PS256 y cifrado para el objeto de petición. El sandbox trae un script que los emite desde su propia CA, que es la única en la que este sandbox confía.

    git clone https://github.com/efraingaray/sfa-sandbox
    cd sfa-sandbox && ./pki/crear-pki.sh mi-psbi
    
    # Deja tres pares en pki/out/mi-psbi/:
    #   transport-cert.pem  transport-key.pem   -> mTLS
    #   signing-cert.pem    signing-key.pem     -> PS256
    #   encryption-cert.pem encryption-key.pem  -> RSA-OAEP
  2. 2 · Inscríbete en el Directorio

    Crea una declaración de software con tus URLs de redirección, sube los certificados de firma y de cifrado, y recoge la declaración firmada. Esa declaración es lo que sustituye al trámite.

    DIR=https://directory.efraingaray.com
    CERT="--cert pki/out/mi-psbi/transport-cert.pem --key pki/out/mi-psbi/transport-key.pem"
    
    # a) la declaracion de software
    curl -s $CERT -X POST $DIR/organisations/org-psbi-0000002/softwarestatements \
      -H 'Content-Type: application/json' \
      -d '{"ClientName":"Mi PSBI","RedirectUri":["https://mi-app.example/callback"]}'
    
    # b) los certificados de firma y de cifrado
    for USO in sig enc; do
      case $USO in sig) F=signing;; enc) F=encryption;; esac
      curl -s $CERT -X POST \
        $DIR/organisations/org-psbi-0000002/softwarestatements/$SSID/certificates/$USO \
        -F "publicKeyFile=@pki/out/mi-psbi/$F-cert.pem"
    done
    
    # c) la SSA firmada en PS256 por el Directorio
    curl -s $CERT \
      $DIR/organisations/org-psbi-0000002/softwarestatements/$SSID/assertion
  3. 3 · Regístrate dinámicamente en el servidor de autorización

    Presenta la declaración. Antes de crear el cliente, el sandbox verifica su firma, su vigencia, su jti y que tu participante siga Activo en el Directorio.

    curl -s $CERT -X POST \
      https://mtls.efraingaray.com/realms/sfa/clients-registrations/openid-connect \
      -H 'Content-Type: application/json' \
      -d "{\"software_statement\":\"$SSA\"}"
    
    # Devuelve client_id y client_secret. Si el Directorio marco al
    # participante Inactivo, esta llamada falla: es el punto del Directorio.
  4. 4 · Corre el flujo

    Crea el consentimiento, pide sus authorization_details, arma el objeto de petición, empújalo y manda al cliente final a autorizar. La aplicación solicitante del repositorio es una referencia funcionando de exactamente esto.

    API=https://api.efraingaray.com/open-finance
    
    # 1. el consentimiento nace ANTES del PAR, en AWAITING_AUTHORISATION
    curl -s $CERT -X POST $API/consents/v1/consents \
      -H 'Content-Type: application/json' \
      -d '{"permissions":["ACCOUNTS_READ","BALANCES_READ","TRANSACTIONS_READ"],
           "accountIds":["CL-ACC-000001"],
           "notificationEmail":"tu@correo.cl"}'
    
    # 2. su RAR, que va DENTRO del objeto de peticion firmado y cifrado
    curl -s $CERT $API/consents/v1/consents/$CID/authorization-details
    
    # 3. PAR obligatorio: el objeto entero como un solo parametro
    curl -s $CERT -u $CLIENT_ID:$SECRET -X POST \
      https://mtls.efraingaray.com/realms/sfa/protocol/openid-connect/ext/par/request \
      --data-urlencode "client_id=$CLIENT_ID" \
      --data-urlencode "request=$JWE"
    
    # 4. y el cliente final va al navegador con el request_uri

El contrato de las APIs

OpenAPI 3.1, describiendo solo lo que el sandbox sirve de verdad. Si una ruta no está implementada, no aparece en el documento. Declara mutualTLS donde hace falta certificado de cliente, que es para lo que la 3.1 lo incorporó.

Opiniones, correcciones y lo que creas que falta van aquí abajo. Es el mismo hilo para los dos idiomas.

Comentarios

Todavía no hay comentarios. El primero es tuyo.

Se revisa antes de publicarse. El correo no se guarda ni aparece en ninguna parte.