[needs-PR] Clarify the usage of self-signed VCs in OpenID4VP
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?
}
]
Comments (8)
-
reporter -
reporter - changed status to open
-
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
-
reporter 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 passingpresentation_definition
in OpenID4VP does not useclaims
parametergood 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.
-
reporter - changed title to [needs-PR] Clarify the usage of self-signed VCs in OpenID4VP
-
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 :)
-
reporter OAuth picked up
claims
parameter in RAR work definingauthorization_details
which we use in the issuance spec. -
- changed status to resolved
Migrated to GitHub
- Log in to comment
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.