CodeList - Errore 400

[mladuDPA]

Salve sto avendo problemi con l'interrogazione di un qualsiasi servizio.

Ho seguito la guida per ottenere un voucher. Una volta ottenuto ho inserito il voucher dentro l'auth token, e successivamente ho generato un jws con una struttura conforme alle specifiche ed inserito nell'header Agid-JWT-TrackingEvidence dopo aver eseguito un base64 encode.

Il jws è firmato con la medesima chiave usata per l'ottenimento del voucher quindi anche il kid è coerente. Ovviamente è stata generata una finalità per il servizio CodeList. Sto provando a richiamare https://apigw-test.anticorruzione.it/modi/rest/CodeList/v2/recupera-elenco-tipologiche in GET con i entrambi i token richiesti Sto comunque ricevendo il seguente errore

{
    "type": "https://govway.org/handling-errors/400/InteroperabilityInvalidRequest.html",
    "title": "InteroperabilityInvalidRequest",
    "status": 400,
    "detail": "Received request is not conform to the required interoperability profile",
    "govway_id": "a50182b8-69c4-11ee-a061-0050568e9679"
}

[labruno]

Segnalo il medesimo problema. Come mai riceviamo questo errore? La mia risposta ad una richiesta

400 Bad Request: " {"type":"https://govway.org/handling-errors/400/InteroperabilityInvalidRequest.html", "title":"InteroperabilityInvalidRequest", "status":400, "detail":"Received request is not conform to the required interoperability profile", "govway_id":"06f3792c-6a0e-11ee-a061-0050568e9679" }"

[FedericaSicchiero]

Buongiorno, mi confermate che avete concluso con esito positivo la richiesta di certificazione ad AgID e l'iscrizione al registro dei gestori delle piattaforme di ANAC? PDND riceve l'autorizzazione all'adesione delle imprese solo a conclusione, con successo, di questo processo.

[mladuDPA]

@FedericaSicchiero Si attualmente abbiamo concluso l'iter per la richiesta di certificazione. Abbiamo avuto accesso alla piattaforma PDND, dalla quale lato BE abbiamo generato le varie finalità per i vari servizi. Abbiamo generato un client e inserito una public key e associato il client alle varie finalità.

Posso elencare i vari step che ho seguito per la generazione dei vari header.

• Generato un jwt contente un header con kid alg e typ. Generato un body con le informazioni complementari (quindi la struttura definita qui. Per i vari codici Ausa e userCodiceFiscale abbiamo inserito gli example del file dato che non abbiamo avuto indicazioni su questi dati. Il campo aud è compilato con il servizio richiesto
• Generato un header e un payload per l'assertion da inviare a pdnd con il campo pourposeId compilato con il servizio richiesto.
• Aggiunto al body dell'assertion il campo digest, con nel value lo sha256 del jwt delle informazioni complementari
• Inviata richiesta get verso https://apigw-test.anticorruzione.it/modi/rest/CodeList/v2/recupera-elenco-tipologiche inserendo come Bearer Token il campo access_token ricevuto da https://auth.uat.interop.pagopa.it/token.oauth2 e come header Agid-JWT-TrackingEvidence il base64 encode del jwt delle informazioni complementari creato al primo step, che se ho capito bene verrà base64 decodificato, hashato con uno sha256 e comparato con quello presente nel campo digest del body del jwt inserito nel Bearer Token (restituitoci da https://auth.uat.interop.pagopa.it/token.oauth2)

Il risultato è sempre un errore 400 di quel tipo.

Vorrei anche far notare che inserendo un valore non consono nel bearer token e interrogando https://apigw-test.anticorruzione.it/modi/rest/CodeList/v2/recupera-elenco-tipologiche mi restituisce correttamente un error 401, inoltre abbiamo provato ad inserire nell'header Agid-JWT-TrackingEvidence sia il jwt dopo un base64encode, sia con sha256, sia raw ma il risultato rimane il medesimo 400

[mladuDPA]

Servirebbe avere un feedback il prima possibile in modo tale da poter utilizzare le api. Anche solo sapere se ci sia un errore negli step che ho svolto aiuterebbe. Ricordo che dopo l'iter di richiesta certificazione si hanno solo 60 giorni per portarla a termine, in più la data del primo gennaio è sempre più vicina.

[FedericaSicchiero]

Buongiorno, stiamo controllando che lato nostro funzioni tutto correttamente e appena concluso torniamo da voi con una risposta più completa, grazie

[FedericaSicchiero]

Vi inoltro il processo corretto per l'elaborazione del digest in modo da confrontare i vari step:

Lato Fruitore:

1. preparare il JWS destinato all’header Agid-JWT-TrackingEvidence
2. calcola lo sha256 del JWS del punto 1
3. prepara la client assertion destinata pdnd inserendo il claim digest che conterrà "digest": { "alg": "SHA256", "value": "" }
4. firma la client assertion
5. con la client assertion firmata al punto 4 invoca l’endpoint di PDND per ottenere il Bearer Token
6. invoca l’api dell’erogatore passando come headers Agid-JWT-TrackingEvidence="" e Authorization="Bearer "

Lato Erogatore:

1. verifica la bontà del bearer token contenuto nello header Authorization
2. verifica la bontà del JWS contenuto nello header Agid-JWT-TrackingEvidence
3. se i controlli dei punti 1 e 2 sono andati a buon fine, va calcolato l’hash del JWS del punto 2 utilizzando l’algoritmo definito nel claim digest del bearer token (digest.alg => SHA256)
4. recupera dal bearer il valore del digest (digest.value)
5. confrontare l’hash ottenuto nel punto 3 con quello recuperato nel punto 4
6. se l’esito del confronto al punto 5 è positivo si può procedere con l’erogazione del servizio, altrimenti è tornato un errore

[FedericaSicchiero]

In ogni caso se avete inserito il digest nella client assertion e ottenuto il token da PDND allora lato Interoperabilità non ci sono anomalie

[mladuDPA]

Confermo che ho seguito questi step, con l'aggiunta di un base64 encode del jws inserito nell'header Agid-JWT-TrackingEvidence come descritto al punto 6. In ogni caso ho fatto una prova anche senza il base64encode ma l'errore permane. Grazie per aver cambiato la label, spero che l'anac risponda al più presto.

[mpizziconi]

confermiamo che la procedura corretta da seguire è quella riportata nel commento precedente https://github.com/anticorruzione/npa/issues/352#issuecomment-1765975709

Per i tentativi fatti in precedenza l'accesso non è andato a buon fine perché la piattaforma non possedeva l'iscrizione nel registro dei gestori o non era stato completata la fruizione della versione 2 dei servizi

In questo momento l'errore in accesso è determinato dal doppio encoding base 64 del token JWS

[mladuDPA]

Questo issue non è risolto!! Vedere issue