[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)

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

Lines 210 to 216 in 1cad07f

	if is_smartphone(context.http_headers.get('HTTP_USER_AGENT')):
	# Same Device flow
	res_url = f'{self.config["authorization"]["url_scheme"]}://authorize?{url_params}'
	return Redirect(res_url)
	# Cross Device flow
	res_url = f'{self.client_id}?{url_params}'

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