[needs-PR] Clarify the usage of self-signed VCs in OpenID4VP

[Kristina Yasuda]

The Use-case is the following; the verifier wants to request the wallet to return certain user claims in the ID Token and not a VC, while also requesting presentation of a VC of a certain type). Verifier is using OpenID4VP and SIOP v2.

• option 1: use OIDC “claims“ parameter with “id_token“?
• option 2: using scopes to specify a claim value to be put in the ID Token? than how does the wallet know which type refers to a VC type and which one to an ID Token - can namescpes, etc. I guess

• option 3: use presentation_definition

  • define a "type" that describes an ID Token with certain user claims and request it in presentation_definition (without specifying it belongs in the ID Token). Wallet will have to know to include it in the ID Token and will indicate in presentation_submission that it is returning that type in an ID Token. But when working with examples I realized there is no claim in the ID Token that can be used to indicate it’s “type“ right now (which we could define I guess….) option 3 would look like the following? :

Request

"input_descriptors": [
        {
            "id": "id_credential",
            "constraints": {
                "fields": [
                    {
                        "path": [
                            "$.vc.type"
                        ],
                        "filter": {
                            "type": "array",
                            "contains": {
                                "const": "IDCredential"
                            }
                        }
                    }
                ]
            }
        },
        {
            "id": "id_token_liveness",
            "constraints": {
                "fields": [
                    {
                        "path": [
                            "$.type"
                        ],
                        "filter": {
                            "type": "string",
                            "contains": {
                                "const": "id_token_liveness"
                            }
                        }
                    }
                ]
            }
        }
    ]

Response

"descriptor_map": [
    {
      "id": "id_credential",
      "path": "$",
      "format": "jwt_vp",
      "path_nested": {
        "path": "$.vp.verifiableCredential[0]",
        "format": "jwt_vc"
      }
    },
    {
      "id": "id_token_liveness",
      "path": "$", //not sure what to use...
      "format": "siop_id_token",//need to define a new one?
    }
  ]

‌

[Kristina Yasuda]

SIOP Aug-18 call, we discussed that it might be a better path for an RP to request for a self-signed / user-signed VC with a self-attested claims.

I agree that might be a simplest way forward. I jusht have concerns that this will absolutely blur the line between SIOP ID Tokens and user-signed VCs, but guess that’s unavoidable.

I still have questions wrt how the RP differentiates btw a VC that needs holder binding (third party iss signed) and a VC that does not require holder binding (user-signed VC) as in Issue #1537.

[Thomas Bellebaum]

In a way, a SIOP ID Token IS a VP, just not with any VCs (would not matter, because self-signed) in it. It would be special in that it is not included in the VP Token, which I think is a good thing in terms of interoperability with existing systems.

But also in terms of interoperability, option 1 is likely to be supported already by any systems not written specifically for OpenID4VP. So keeping that option for RPs seems fine.

N.B. Please correct me If I’m wrong, but as I remember the claims parameter may be entirely or partially ignored by the OP, while OpenID4VP seems to be unclear on the matter. So that is a semantic difference.

@Kristina I do not think this is a problem, since the PR is writing the Presentation Definition. Quoting from PE:

The subject_is_issuer property could be used by a Verifier to require that certain inputs be self_attested

‌

[Kristina Yasuda]

I think SIOP ID Token is a self-signed VC, not a VP..

wrt ` claims` parameter, when we made a change to base OpenID4VP on OAuth and not OIDC, that meant that we cannot mandate the usage of a claims parameter which is OIDC specific. hence the current syntax of passing presentation_definition in OpenID4VP does not use claims parameter

good catch on The subject_is_issuer property could be used by a Verifier to require that certain inputs be self_attested. I would probably do a PR clarifying on the use of self-signed VCs in implementation considerations.

‌

[Thomas Bellebaum]

There had been an effort to port claims to OAuth before: https://www.ietf.org/archive/id/draft-spencer-oauth-claims-01.txt
Seems however that the OAuth WG at IETF had no interest on picking it up despite its de facto use by some companies for a variety of use cases. This may be another one if the WG wishes to go in that direction.

In a way, a SIOP ID Token is both a VC (contains claims about a subject) and a VP (is bound to an interaction via a nonce). If I imagine a structure of nested JWTs, where the inner one contains the claims (like a VC) and the outer one contains the nonce (like a VP) and both are signed by the subject, it is the inner signature that I would deem unneccessary. Hence I was mainly referring to the SIOP ID Token as a VP :)

[Kristina Yasuda]

OAuth picked up claims parameter in RAR work defining authorization_details which we use in the issuance spec.

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VP