how cnf claim can be used with any other types of "binding"

[Sakurann]

like biometrics-based binding

Torsten started with this example in this PR in sd-jwt repo but i do not think it's viable anymore:

    "binding":
      [
        {
          "type": "CryptographicBinding2022",
          "cnf":
            {
              "jwk":
                {
                  "kty": "RSA",
                  "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4cbbf
                    AAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMst
                    n64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_F
                    DW2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n9
                    1CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHa
                    Q-G_xBniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
                  "e": "AQAB",
                },
            },
        },
        { "type": "BiometricBinding2022", "template": "..." },
      ]

[awoie]

That is similar to the holder binding proposal in W3C that @paulbastian and myself authored. I'm wondering if you would expect binding to be defined by the SD-JWT VC spec, or is this a domain-specific claim? If we want to add something like this to SD-JWT VC and express some sort of holder authentication based on cryptographic binding, then this would relate to this: #116

Questions:

1. What does binding express in that case? Is it Holder authentication?
2. Is the idea to add binding to SD-JWT VC?

Regarding your example, I think there is no reason to have the cnf claim so many levels down in the JSON. I'd keep it a top-level claim.

What about the following?

{
  "cnf": {
    "kid":"some-kid-123",
    "jwk": { // OR
      "kid":"some-kid-123",
      "x", "...", "y":"...", ...
    }
  },
  "binding":[{
    "kid": "some-kid-123",
    "some_metadata": "..."
  }]
}

Note that kid is a valid cnf method.

OR

{
  "cnf": {
    "jwk": {
      "kid": "some-kid-123",
      "...",
    }
  },
  "binding":[{
    "kid": "some-kid-123",
    "some_metadata": "..."
  }]
}

OR

{
  "cnf": {
    "jwk": {
      "kid": "some-kid-123",
      "...",
    }
  },
  "binding":{
    "kid": "some-kid-123",
    "some_other_binding_method": { "..." }
  }
}

Note that the approach above uses a similar extensibility model to cnf.

[tlodderstedt]

@awoie I created that example based on you proposal ;-)

Have you implemented any of the proposed options? I'm asking since I have come to the conclusion that it is to pre-mature to standardize the representation of bindings. I would like to see more requirements, concrete use cases and implementations before.

[awoie]

@awoie I created that example based on you proposal ;-)

Have you implemented any of the proposed options? I'm asking since I have come to the conclusion that it is to pre-mature to standardize the representation of bindings. I would like to see more requirements, concrete use cases and implementations before.

We have only an implementation based on the W3C VCDM. Back then we used the binding in the VP actually. So, no, we don't have an implementation.

[awoie]

@Sakurann what do you want to have changed, or was this just a question and we can we close this issue?

[paulbastian]

We had a Session on this topic at IIW#37.
I still support the ideas that Oliver, I and others described at RWOT#11 Holding Binding Paper.

In my opinion, the cnf claim is the form of binding for cryptogaphic keys.
The alternative binding mechanisms are either claim-based bindings or biometric (claim-based) binding.
Today, there is no equivalent for these claim-based bindings in the SD-JWT-VC Data model and I would suggest something like cbb for claim-based bindings.

Lets take an example as a diploma. The trivial data model could look like:

{
  "title" : "Master of Science in Physics",
  "grade" : "excellent",
  "given_name" : "Erika",
  "family_name" : "Mustermann",
  "date_of_birth" : "1970-01-01"
}

However, this does not communicate which claims are "actually" about the diploma and which ones the diploma issuer used to authenticate the subject and are intended for a relying party to validate user binding of the diploma. The fact that firstname, lastname and birthdate are used for "binding" the diploma is just common human knowledge but not explicitly communicated, the semantic meaning is missing.

A simple approach therefore could be:

{
  "title" : "Master of Science in Physics",
  "grade" : "excellent",
  "cbb" : {
    "given_name" : "Erika",
    "family_name" : "Mustermann",
    "date_of_birth" : "1970-01-01"
  }
}

Other approaches inside cbb are possible.

cbb is not anything mandatory for the Relying Party and things might be different in various jurisdictions. One of the key questions is wehther these policy shall be inside vc or in metadata. I would prefer to have some guidance inside the VC.

[awoie]

I know we discussed this in our paper but can we summarize what we want to achieve @Sakurann @paulbastian. Is this about specifying how the RP wants to verify the holder authenticated the transaction?

[awoie]

IMO, cnf and its definition "Cryptographic Key Binding" is currently also a bit underspecified in our specification.

[paulbastian]

I know we discussed this in our paper but can we summarize what we want to achieve @Sakurann @paulbastian. Is this about specifying how the RP wants to verify the holder authenticated the transaction?

I would frame it as "give the RP guidance on how to verify legitimate ownership of the credential". RPs are free to do whatever, they may also ignore a cnf.

My main argument is that the key for keybinding could be in any random claim, but people chose to standardize what the issuer of a token intended to be used for verification. There is no difference to claim-based binding. Our intuition that name, surname, date of birth on a diploma shall be used for binding or totally arbitrary despite seeming "common knowledge".

I believe many Issuers will want to use claim-based binding as this is a 1:1 match of what they have been doing with physical documents and it would mean little changes to their processes, so this is actually very important. Same for biometric binding, e.g. mdL portrait like.

How can we move this forward?

[paulbastian]

Do we need a separate IETF Draft for biometric+claim-based bindings in JWT or shall this go in here?

[paulbastian]

A Draft was proposed at OAuth Security Workshop 2024, showing the examples above, advice was more in this direction:

{
  "title" : "Master of Science in Physics",
  "grade" : "excellent",
  "given_name" : "Erika",
  "family_name" : "Mustermann",
  "date_of_birth" : "1970-01-01",
  "cbb" : [ "given_name", "family_name", "date_of_birth" ]
}

Discussion was around whether things should be in policies or metadata, a good argument for this approach/putting it into the JWT is that data available to the Issuer for binding may not always be the same based on the quality of his user database.

The approach would work really well for countries like Estonia that have a unique national identifier in the PID.

{
  "title" : "Master of Science in Physics",
  "grade" : "excellent",
  "given_name" : "Erika",
  "family_name" : "Mustermann",
  "some-memberstate.eu/credentials/schemas/pid/national_id" : "572047251836",
  "cbb" : [ "some-memberstate.eu/credentials/schemas/pid/national_id" ]
}

[danielfett]

FYI, I created in issue in eKYC-IDA to see if there is some overlap: https://bitbucket.org/openid/ekyc-ida/issues/1414/discuss-a-way-to-express-binding-claims

[peppelinux]

WDYT about using an object like

"binding": {$type: {claim: ..., any other required by future proof binding type}}

example

{
  "title" : "Master of Science in Physics",
  "grade" : "excellent",
  "given_name" : "Erika",
  "family_name" : "Mustermann",
  "some-memberstate.eu/credentials/schemas/pid/national_id" : "572047251836",
  "credential_binding" : {
     "claims": ["some-memberstate.eu/credentials/schemas/pid/national_id" ]
  }
}

this may open the possibility to specify other types, likecredential_binding.hkb referencing cnf.jwk or any other key binding type

[awoie]

I believe @paulbastian is working on a proposal.

[bc-pi]

I am not convinced this should be in the JWT itself or that this spec is the appropriate place to define such a thing. Having said that, something like the "cbb" : [ "given_name", "family_name", "date_of_birth" ] seems the most reasonable/logical of the ideas in this issue thus far.

[bc-pi]

cross comment from openid/OpenID4VP#161 -> This is a somewhat tangential friendly reminder that the cnf claim specified in Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) is strictly about representing a proof-of-possession key and is therefore entirely inappropriate as a means of conveying 'claims based binding'.

[danielfett]

I talked to Mark Haine today and during the call we identified two ways to stretch the ekyc-IDA spec a bit:

① Introduce a new element claims_ptrs to point to the relevant claims:

{
  "iss": "https://server.example.com",
  "exp": 1544645174,
  "given_name": "Max",
  "family_name": "Mustermann",
  "verified_claims": {
    "verification": {
      "trust_framework": "example"
    },
    "claims_ptrs": [
      ["given_name"],
      ["family_name"]
    ]
  }
}

② Define a new special "claim" (like _ptrs) to point to the verified claims:

{
  "iss": "https://server.example.com",
  "exp": 1544645174,
  "given_name": "Max",
  "family_name": "Mustermann",
  "verified_claims": {
    "verification": {
      "trust_framework": "example"
    },
    "claims": {
        "_ptrs": [
          ["given_name"],
          ["family_name"]
      ]
    }
  }
}