The verification flow for Present Proof with the credential format SD-JWT

[kieutuan218]

Is this a regression?

Yes

Description

I am implementing the flow from https://hyperledger.github.io/identus-docs/tutorials/credentials/present-proof with a Verifiable Credential (VC) of type SD-JWT.

My VC currently has the following content.

{
    "recordId": "99cb9a38-c4a9-41db-9218-df82e1a363cd",
    "thid": "a55b1440-3f5e-4494-a879-c25a34dbce3c",
    "credentialFormat": "SDJWT",
    "subjectId": "did:prism:be27e392e595cf36416f6140558ce991068cc17efad7640dadfbfb2f24215757",
    "claims": {
        "birthday": "04/10/1991",
        "location": "vinh phuc"
    },
    "createdAt": "2024-11-03T04:12:42.17442Z",
    "updatedAt": "2024-11-03T04:14:03.136847Z",
    "role": "Holder",
    "protocolState": "CredentialReceived",
    "credential": "ZXlKaGJHY2lPaUpGWkVSVFFTSjkuZXlKZmMyUWlPbHNpUlcweFptRjNWVVJrUkdrd1gweHBjV3BrVVdKamJFTlNaVTlrT0dGMGFsVlJUV0pwYTA4eUxUQTBZeUlzSWs1eGNUQm9iVmx1TTJZdFgxcG5UVGhUWlVJM1YzRXhZbWRhZEhkcmFqVllZa1pyU3pGblQzZE1VRGdpTENKcU5XSnBVV1pmZEhsWVJ6RnVNakZ5YW1GVVdITm1VbTg1Tm1wMFZsWlZWMWt6YzI5Vll6TTFlRmM0SWwwc0lsOXpaRjloYkdjaU9pSnphR0V0TWpVMklpd2lhWE56SWpvaVpHbGtPbkJ5YVhOdE9qSXdaV1V4WmpNM01XVmlaRFJrWWpKa05tVmtZVEpqWVdWbU16TXpNRFkxWTJWaE1HWmhORE5rWXpjNE5qSTJZalUzT0RkbVlqQTVNak5oTkdVMk0yTWlMQ0pwWVhRaU9qRTNNekEyTURjeU5ESXNJbVY0Y0NJNk1UY3pNekU1T1RJME1uMC5wMzhXbjUtVkE2Yjh2eTFKVWhPTl9PUXhMaVN3VXljR1NKc0gyV0piTXlrYUVnWGRQRVR6VXFoV052OVVoWDJlbzN3MGVXWXd1eEFuTjQ1S3hnWmdEQX5XeUphZDNSWFZsUjJUMnA1ZVZaUVVGRmlielZFTVRsbklpd2dJbUpwY25Sb1pHRjVJaXdnSWpBMEx6RXdMekU1T1RFaVhRfld5SmxUWFpuY1VKWFgwbHhNbTVxV2w4dGJFRnNNMjlSSWl3Z0lteHZZMkYwYVc5dUlpd2dJblpwYm1nZ2NHaDFZeUpkfld5SjFjbUY0YTJKbE1GRllPVTlOTWxWbFdraGtWa3AzSWl3Z0luTjFZaUlzSUNKa2FXUTZjSEpwYzIwNlltVXlOMlV6T1RKbE5UazFZMll6TmpReE5tWTJNVFF3TlRVNFkyVTVPVEV3Tmpoall6RTNaV1poWkRjMk5EQmtZV1JtWW1aaU1tWXlOREl4TlRjMU56cERkRzlDUTNSalFrVnJXVXRHVjBZeFpFZG9iR0p1VW5CWk1rWXdZVmM1ZFV4WGFIWmlSMUpzWTJoQlJWTnBjMHRDTUZaclRXcFZNVTFVYTFOSlJXVXlUVEJST0ZFeU5rRTJNR00xZGtkMFNtRm9USEZGTmt0bmIzWnhaMjk1YjB4bU4ycDJhRGRsWDBWcWMwdENNakZvWXpOU2JHTnFRVkZCVlc5MVEyZHNlbHBYVG5kTmFsVXlZWHBGVTBsUlRFaGFhVzl5ZGkxRk5uRjVialJ3TUhOVE4wRXdWV2xDUTI1dFZIbDFTbnBRTkVoYVZVMUNZVjlRYmxKd1VVTm5OV2hhTWxaMVpFTXhhVmxZVG14TVdGWjVZa0pKVVZSSGJIVmhNbFpyVlcxV2VtSXpWbmxaTWxaWFRWSnZjMkZJVWpCalJHOTJUREpvZG1NelVYVmFSemxxWVRKV2VVeHRiSFZrUjFaNVltMUdjMDlxYTNkTlJFRjJXVEo0ZG1SWFVYUlpWMlJzWW01UklsMH4=",
    "metaRetries": 5
}

Create a Presentation Request where the VC does not contain that information.

{
    "connectionId": "{{connectionId}}",
    "proofs": [],
    "claims": {
        "email": {}
    },
    "credentialFormat": "SDJWT"
}

I am testing the following cases.

Case 1

Input:
Accept the request with body claims matching the Presentation Request.

{
    "action": "request-accept",
    "proofId": [
        "{{holderRecordId}}"
    ],
    "claims": {
        "email": {}
    },
    "credentialFormat": "SDJWT"
}

Output:
The Presentation Request is always in a Pending state. There are error logs in the cloud agent.

zio.FiberFailure: invalid state: Requested claim doesn't exist
        at sdjwtwrapper.FfiConverterTypeSDJWTError.read(sdjwtwrapper.common.kt:989)

Expect:
The Presentation Request should transition to the status of Presentation Verification Failed.

Case 2

Input:
Accept the request with body claims matching the VC I currently possess.

{
    "action": "request-accept",
    "proofId": [
        "{{holderRecordId}}"
    ],
    "claims": {
        "birthday": {},
        "location": {}
    },
    "credentialFormat": "SDJWT"
}

Output:

The Presentation Request changes to the status of Presentation Verified.
{
    "presentationId": "846137b1-0911-4a28-9820-9fa0a13db417",
    "thid": "6b95a518-9a6d-4fd2-ad8d-35b84ac264e0",
    "role": "Verifier",
    "status": "PresentationVerified",
    "proofs": [],
    "data": [
        "eyJhbGciOiJFZERTQSJ9.eyJfc2QiOlsiRW0xZmF3VURkRGkwX0xpcWpkUWJjbENSZU9kOGF0alVRTWJpa08yLTA0YyIsIk5xcTBobVluM2YtX1pnTThTZUI3V3ExYmdadHdrajVYYkZrSzFnT3dMUDgiLCJqNWJpUWZfdHlYRzFuMjFyamFUWHNmUm85Nmp0VlZVV1kzc29VYzM1eFc4Il0sIl9zZF9hbGciOiJzaGEtMjU2IiwiaXNzIjoiZGlkOnByaXNtOjIwZWUxZjM3MWViZDRkYjJkNmVkYTJjYWVmMzMzMDY1Y2VhMGZhNDNkYzc4NjI2YjU3ODdmYjA5MjNhNGU2M2MiLCJpYXQiOjE3MzA2MDcyNDIsImV4cCI6MTczMzE5OTI0Mn0.p38Wn5-VA6b8vy1JUhON_OQxLiSwUycGSJsH2WJbMykaEgXdPETzUqhWNv9UhX2eo3w0eWYwuxAnN45KxgZgDA~WyJlTXZncUJXX0lxMm5qWl8tbEFsM29RIiwgImxvY2F0aW9uIiwgInZpbmggcGh1YyJd~WyJad3RXVlR2T2p5eVZQUFFibzVEMTlnIiwgImJpcnRoZGF5IiwgIjA0LzEwLzE5OTEiXQ~"
    ],
    "requestData": [
        "{\"claims\":{\"email\":{}}}"
    ],
    "connectionId": "12b7dc7b-8fa0-46b7-9fb1-3608d808f5a1",
    "metaRetries": 5
}

Expect:
The Presentation Request should result in an error because the holder did not send a VC with the correct information that the verifier requires.

And when I tried to decode the data, there is no claims information available.

Please provide the exception or error you saw

No response

Please provide the environment you discovered this bug in

ghcr.io/hyperledger/identus-cloud-agent:1.39.1-102-5830a7e

Anything else?

No response

[mineme0110]

Case 1: The current behavior in the Agent does not allow processing if the claim being disclosed is not present in the Verifiable Credential (VC). While this is not ideal, it reflects the current status. This can be improved

Case 2:
SDJWT allows values to be revealed based on claim attributes without needing the exact value. The API checks if the claim can be disclosed
In SDJWT, the presentation is verified only means that the claims have been disclosed to the verifier (unlike JWT). Additionally, there is a separate endpoint allowing the verifier to accept or reject the disclosed claims.

[kieutuan218]

Case 1: The current behavior in the Agent does not allow processing if the claim being disclosed is not present in the Verifiable Credential (VC). While this is not ideal, it reflects the current status. This can be improved

Case 2: SDJWT allows values to be revealed based on claim attributes without needing the exact value. The API checks if the claim can be disclosed In SDJWT, the presentation is verified only means that the claims have been disclosed to the verifier (unlike JWT). Additionally, there is a separate endpoint allowing the verifier to accept or reject the disclosed claims.

For Case 2:

Which API is used to view the disclosed claims information?
If the Holder submits claims different from those that the Verifier expects, then what is the purpose of creating a presentation with these claims?

[mineme0110]

For case 2: Verifier will reject the claim in that case using the Api Endpoint I mentioned,
{{baseUrlVerifier}}/present-proof/presentations/{{VERIFIER_PRESENTATION_ID}}

https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

Internet-Draft                   SD-JWT                     October 2024

   When presenting to a Verifier, the Holder sends only the selected set
   of the Disclosures in the SD-JWT.

   The Holder MAY send any subset of the Disclosures to the Verifier,
   i.e., none, some, or all Disclosures.  For data that the Holder does
   not want to reveal to the Verifier, the Holder MUST NOT send
   Disclosures or reveal the salt values in any other way.  A Holder
   MUST NOT send a Disclosure that was not included in the issued SD-JWT
   or send a Disclosure more than once.

   To further illustrate the SD-JWT format, the following examples show
   a few different SD-JWT permutations, both with and without various
   constituent parts.  

Which API is used to view the disclosed claims information?

The API endpoint
{{baseUrlVerifier}}/present-proof/presentations/{{VERIFIER_PRESENTATION_ID}}
currently does not display disclosed claim information. We could update this endpoint to reveal disclosed claims for greater clarity
CC @elribonazo @FabioPinheiro @yshyn-iohk

[mineme0110]

#1487
This is fixed now
{{baseUrlVerifier}}/present-proof/presentations

 {
            "presentationId": "5c4d1bc1-3e2e-4a68-8f43-da7a0aab995f",
            "thid": "7ec2b2c6-27d3-4d31-89bb-fb55362672ef",
            "role": "Verifier",
            "status": "PresentationVerified",
            "proofs": [],
            "data": [
                "eyJhbGciOiJFZERTQSJ9.eyJfc2QiOlsiOXZnQXdieHF1S2tHb0I4cGl5Ujk2bnh3T0p4X0Q0NzBFWC1SYWVVcl9zOCIsIklSa2tPa1JiZjA3SU52QmFUckUyUkJNS3FGWVJZX2xLRGs1aWhqcW5qb1UiLCJJV0Z5TXJNYVBUd1NVaDJ3M0ZzNXJPQkVmeWFJeng2eGg2V3UwczZIQ1dRIiwiUEZRbWdHRUlqbzZaMWF6Nk4yYVZzMl9JT292QjB6ZDBISGtPUjh0eWhhSSIsIldWUVlGYjNpa2w1ZmdqWjdLT0RKWDVBUkhtVFU2VmxDemNydUtPcjQ1M0kiLCJaWnRUR1FIbjFjRVpBdk5FLTlmS3VBSl9pQ3VTUHg2ejhZczFrZ2xsR3pJIiwibTBBZmNHVDlXYUZlNTN1N3lVZXFwR0JwN1FKMVZtWERNRUJvNUJrY3IxdyJdLCJfc2RfYWxnIjoic2hhLTI1NiIsImlzcyI6ImRpZDpwcmlzbTowZjI2MTk5ZTEwZWFmZjRjZTdiMGY5NDU1ZWVmNWNlYWFkNzkzZTA3MDY1MTE5NDc0MmNkYzhlYWIxY2RjZjdmIiwiaWF0IjoxNzM2MTY0NTgwLCJleHAiOjE3Mzg3NTY1ODAsImNuZiI6eyJqd2siOnsia2V5X29wcyI6W10sImt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4IjoiVVpsSEpTd0NlcVZsNE9UUXJZZ1N5aVllVzE3d2hQUjVvelRyazlKa3hFdyJ9fX0.1dN_CjrPjyit6Fges4JF4NN6oEVnge1Tr1ro9GRQY0dPpcMN1LVYXNlH6oaehAvDyyDHHdNyuR-qy8ns4uthCA~WyJmcHhIYTh3VlhsMFhNNE02eWJ1M3Z3IiwgImdpdmVuTmFtZSIsICJBbGljZSJd~WyJ2SlZ3UUNtSUZDUFdXQ2N0ZGFxNW9nIiwgImVtYWlsQWRkcmVzcyIsICJhbGljZUB3b25kZXJsYW5kLmNvbSJd~eyJ0eXAiOiJrYitqd3QiLCJhbGciOiJFZERTQSJ9.eyJhdWQiOiJodHRwczovL3ByaXNtLXZlcmlmaWVyLmNvbSIsIm5vbmNlIjoiMTFjOTE0OTMtMDFiMy00YzRkLWFjMzYtYjMzNmJhYjViZGRmIiwiaWF0IjoxNzM2MTY0NjM5LCJzZF9oYXNoIjoiQjVFY1l0QnNNLWItTTFVeEFQSE55akczSHVZc2p2N1hHb08wcjdOV2dXayJ9.4qdn5_g9jBXgMgbWC29SIWe6MGhixFabDWcEyPXn8w4Cbl2pfbQ8A83WfmgaGhw9428zAvNRbFXBWD6-92dEAA"
            ],
            "requestData": [
                "{\"options\":{\"challenge\":\"11c91493-01b3-4c4d-ac36-b336bab5bddf\",\"domain\":\"https://prism-verifier.com\"},\"claims\":{\"emailAddress\":{},\"givenName\":{}}}"
            ],
            "disclosedClaims": {
                "iss": "did:prism:0f26199e10eaff4ce7b0f9455eef5ceaad793e070651194742cdc8eab1cdcf7f",
                "iat": 1736164580,
                "exp": 1738756580,
                "emailAddress": "[email protected]",
                "givenName": "Alice"
            },
            "connectionId": "47ae3953-fec3-4d61-9bed-6befbd1dfd7f",
            "metaRetries": 5
        },```