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

[Zicchio]

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/dev/pyeudiw/satosa/default/openid4vp_backend.py#L203
mentre nel response endpoint si fa questa cosa
(2)

eudi-wallet-it-python/pyeudiw/satosa/default/response_handler.py

Lines 189 to 195 in 1cad07f

	if stored_session['session_id'] == context.state["SESSION_ID"]:
	# Same device flow
	cb_redirect_uri = f"{self.registered_get_response_endpoint}?response_code={response_code}"
	return JsonResponse({"redirect_uri": cb_redirect_uri}, status="200")
	else:
	# Cross device flow
	return JsonResponse({"status": "OK"}, status="200")

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]

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
openid/OpenID4VP#265 (comment)

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]

L'approccio da implementare è di seguito proposto e documentato
italia/eudi-wallet-it-docs#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

[Zicchio]

Nella soluzione attuale non mi è chiaro come faccia il Wallet (che non sa se è nel flusso same device o cross device) a sapere, una volta inviate le credenziali dell'utente all'RP, se poi bisogna uscire o meno dall'applicazione. In generle, nel caso cross device l'utente resta nell'app del wallet, mentre nel caso same device l'utente deve ovviamente uscire dall'app per proseguire su quella dell'RP.

Nelle specifiche italiane 0.8.1 alla chiamta HTTP numero 20, per risolvere il problema sopra si discriminavano due risposte diverse: nel caso cross device non si include un redirect uri, nel caso same device si include un redirect URI che informa il wallet che si deve uscire dall'app per proseguire la navigazione

Da quanto capisco, l'approccio di interoperabilità Potential è lo stesso delle specifiche italiane 0.8.1: nel caso cross device il redirect URI deve essere omesso dalla risposta http, mentre nel caso same device deve essere presente (IMO il wording non è 100% chiaro in merito).

Nelle specifiche 0.8.2 il nuovo approccio rimuove questa distinzione: la risposta è sempre la stessa.

Quindi la mia domanda è la seguente: è corretto avere una risposta HTTP alla richiesta 20 senza redirect uri in tutti i flussi come da specifiche 0.8.2? Il Wallet riesce a proseguire correttamente la navigazione?

La domanda nasce dal fatto che la differenza tra i due approcci non è solo superficiale: nel caso specifiche 0.8.1, per poter fornire la risposta corretta alla richiesta HTTP 20, l'RP deve saper reperire l'informazione su quale flusso sono allo step 20 e questo richiede dettagli implementativi diversi che tracciano o recuperano questa informaizone (vedi ad esempio PR #300).

[peppelinux]

@Zicchio le regole tecniche di riferimento sono state aggiornate come segue all'interno della PR in corso di revisione e a seguito dei riscontri avvenuti nella presente issue
italia/eudi-wallet-it-docs@23ab8d7