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

Question

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

Sakurann opened this issue a year ago · comments

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": "..." },
      ]

Oliver Terbu · Answer 1 · Thu Jun 29 2023 16:59:04 GMT+0800 (China Standard Time)

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:

What does binding express in that case? Is it Holder authentication?
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.

Torsten Lodderstedt · Answer 2 · Fri Jun 30 2023 04:09:54 GMT+0800 (China Standard Time)

@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.

Oliver Terbu · Answer 3 · Fri Jun 30 2023 15:33:44 GMT+0800 (China Standard Time)

@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.

Oliver Terbu · Answer 4 · Wed Oct 04 2023 19:21:36 GMT+0800 (China Standard Time)

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

Paul Bastian · Answer 5 · Wed Oct 18 2023 16:56:12 GMT+0800 (China Standard Time)

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.

Oliver Terbu · Answer 6 · Mon Nov 27 2023 11:48:28 GMT+0800 (China Standard Time)

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?

Oliver Terbu · Answer 7 · Mon Nov 27 2023 11:50:15 GMT+0800 (China Standard Time)

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

Paul Bastian · Answer 8 · Thu Jan 18 2024 04:51:38 GMT+0800 (China Standard Time)

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?

Paul Bastian · Answer 9 · Thu Jan 18 2024 04:52:49 GMT+0800 (China Standard Time)

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

Paul Bastian · Answer 10 · Fri Apr 12 2024 20:47:43 GMT+0800 (China Standard Time)

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" ]
}

Daniel Fett · Answer 11 · Wed Apr 17 2024 23:18:50 GMT+0800 (China Standard Time)

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

Giuseppe De Marco · Answer 12 · Thu Apr 18 2024 02:23:42 GMT+0800 (China Standard Time)

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

Oliver Terbu · Answer 13 · Wed May 01 2024 01:10:04 GMT+0800 (China Standard Time)

I believe @paulbastian is working on a proposal.

Brian Campbell · Answer 14 · Wed May 01 2024 02:08:21 GMT+0800 (China Standard Time)

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.

Brian Campbell · Answer 15 · Fri May 03 2024 22:39:51 GMT+0800 (China Standard Time)

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'.