search

italia / eudi-wallet-it-python

Python toolchain for building an OpenID4VP RP with a SATOSA backend compliant with the Italian Wallet implementation profile
Apache License 2.0
17 stars 14 forks source link

[Satosa] Richiesta chiarimento identificazione flusso same device vs cross device #268

Open Zicchio opened 2 months ago

Zicchio commented 2 months ago

Quando il satosa backend deve provare a distinguere tra flusso cross device e same device, nel pre-auth endpoint fa questa cosa (1) https://github.com/italia/eudi-wallet-it-python/blob/1cad07f7bb3ae8d6958d3b1cb3b65bea168ff866/pyeudiw/satosa/default/openid4vp_backend.py#L210-L216 mentre nel response endpoint si fa questa cosa (2) https://github.com/italia/eudi-wallet-it-python/blob/1cad07f7bb3ae8d6958d3b1cb3b65bea168ff866/pyeudiw/satosa/default/response_handler.py#L189-L195

Mi chiedo: a. C'è un motivo per la quale le due strategie son diverse? Non si potrebbe usare il metodo (1) in entrambi gli endpoint? b. Come fa (2) a funzionare? Se non ho capito male, (2) verifica che l'ID di sessione di satosa di inizio autenticazione (sessione aperta con il browser e recuperabile dai cookie) sia uguale alla sessione della chiamata HTTP della wallet instance (chiamata proveniente da un backend) ma mi verrebbe da dire che queste due sessioni sono sempre diverse (sia cross device che same device). È così? Purtoppo non mi viene in mente un metodo per verificare questa ipotesi.

@peppelinux tu sai qualcosa in merito?

Zicchio commented 3 weeks ago

Espando l'issue con informaizoni emerse a seguito di una analisi successiva.

a. C'è un motivo per la quale le due strategie son diverse? Non si potrebbe usare il metodo (1) in entrambi gli endpoint?

Le due strategie devono essere diverse.

  1. Quando sono nel pre-auth endpoint, la richiesta potrebbe provenire da mobile (same device) o da desktop (cross device). Una analisi dello user agent nell'header della chiamata http è sufficiente per distinguere tra mobile (→same device) e desktop (→cross device). AFAIK un flusso un cross device con due diversi dispositivi mobile non è previsto ne supportato, quinidi questo approccio, in questo endpoint, va bene.
  2. Quando sono nel response endpoint, la richiesta avviene sempre da mobile (richiesta proveniente dall'app dell'holder: IT wallet) e quindi una discrimazione tramite user agent non può funzionare essendo sempre mobile; in questo stadio, il verifier (RP) deve, in qualche modo, capire quale flusso era stato iniziato nel punto 1. sopra

b. Come fa (2) a funzionare?

Questo dubbio persiste. L'implementazione suggerisce che solo nel flusso same device lo user agent è in grado di preservare i cookie di sessione. Ho notato che jogu (fonte IMO autorrevole) fornisce una soluzione simile quando ne parla in questa issue del tutto analoga su openid4vp https://github.com/openid/OpenID4VP/issues/265#issuecomment-2365067310

Mi chiedo però se sia vero, dubbio che sorge da lacune tecniche mie lato mobile. Intuitivamente, mi verrebbe da dire che l'app IT Wallet non ha modo di conoscere i cookie di sessione originali (trattenuti dal browser) quando fa una chiamata HTTP al verifier.

peppelinux commented 3 weeks ago

L'approccio da implementare è di seguito proposto e documentato https://github.com/italia/eudi-wallet-it-docs/pull/465

complessivamente consolidiamo il comportamento implementato per cross device, mediante l'uso di una web page con js anche per same device, considerando che anche in samedevice lo user agent usato per la navigazione web sia diverso, o utilizzi una sessione diversa, rispetto allo user agent usato dalla wallet instance per il flusso di presentazione