search

italia / eudi-wallet-it-docs

Italian EUDI Wallet Technical Specifications
Creative Commons Zero v1.0 Universal
56 stars 20 forks source link

[Clarification request] [Relying Party Solution] Role of request_uri_method in Request Object #381

Closed Zicchio closed 1 week ago

Zicchio commented 3 months ago

Secondo le specifiche attuali, nel flusso di autenticazione il Relying Party espone un Request URI endpoint /request_uri?id=xxx che il wallet chiama per acquisire un Request Object. Questo Request Object contiene gli effettivi parametri della chiama /authorize come da RFC9101. Il Relying Party comunica sia il request_uri che il request_uri_method nella stessa "trasmissione" - vedi https://github.com/italia/eudi-wallet-it-docs/blob/8c38c23beba1150211364bab53acc7fef01377e4/docs/en/remote-flow.rst?plain=1#L163

Uno dei claims presenti nel Request Object JWT è proprio request_uri_method che contiene il metodo della chiamata HTTP che è già stata effettuata per reperire il Request Object stesso. https://github.com/italia/eudi-wallet-it-docs/blob/8c38c23beba1150211364bab53acc7fef01377e4/docs/en/remote-flow.rst?plain=1#L314-L315 A cosa serve questa informazione se il wallet l'ha già consumata? È un refuso o mi sfugge qualcosa?

Ringrazio per la disponibilità.

peppelinux commented 3 months ago

consente al wallet di conoscere se il RP supporta il metodo POST e di conseguenza se fosse possibile fornirgli i wallet metadata ed informare il RP delle funzionalità, e degli algoritmi, supportati dal wallet prima che il RP emetta la richiesta di presentazione

supponiamo che il RP supporti alcuni sign alg non supportati dal wallet o richieda credenziali in un formato non supportato dal wallet

elisanp commented 3 months ago

Il parametro request_uri_method si presenta in due occasioni:

  1. nella richiesta di authorize come query parameter. Consente al wallet di conoscere se l'RP può ricevere i suoi metadati (presenza del metodo POST). https://github.com/italia/eudi-wallet-it-docs/blob/8c38c23beba1150211364bab53acc7fef01377e4/docs/en/remote-flow.rst?plain=1#L163
  2. nel Request Object come claim. A cosa serve in questo caso? Il wallet ha già comunicato eventuali metadati nella request precedente. https://github.com/italia/eudi-wallet-it-docs/blob/8c38c23beba1150211364bab53acc7fef01377e4/docs/en/remote-flow.rst?plain=1#L314-L315
peppelinux commented 1 week ago

request_uri_method è definito in openid4vp, qui: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-request_uri_method

la sua presenza nel request object serve notificare il supporto di questo parametro quando il qrcode non lo include.

Zicchio commented 1 week ago

la sua presenza nel request object serve notificare il supporto di questo parametro quando il qrcode non lo include.

Per me puoi chiudere l'Issue di chiarimento come risolta. Il dubbio originale emergeva dall'ipotesi che request_uri_method fosse ridondante perché presente in due trasmissioni (qr code e request object). Questa ipotesi non è necessariamente vera: la trasmissione nel QR code è infatti opzionale e serve, in caso, a notificare funzionalità extra (nel caso di POST), mentre la sua inclusione nel Request Object è normata da openid4vp.

peppelinux commented 1 week ago

ti confermo che è ridondante perché è opzionale nella request object SE supportato

mentre è anticipato nel qrcode per le wallet instance che vogliono evitarsi la doppia issuance di request object