Need a way to define confidence or assurance levels

[awoie]

If SD-JWT holder binding is focusing on key (device/wallet) binding in terms of cloning/replay protection, we will need some mechanism to define how we want to communicate how the holder was authenticated if certain claims are presented to verifiers. To verifiers it will be also interesting to understand the confidence (ISO 23220-5) / assurance levels (eIDAS) especially if credentials and wallets support multiple levels. This information could be conveyed by another claim, or it could be just some annotations in form of new members of the specific cnf method.

For example:

"cnf": {
  "jwk": {
     ... JWK members ...,
     "trust_framework": "some-ecosystem",
     "profile": "some-configuration-type"
  }
}

VS something like the following ...

"cnf": {
  "jwk": {
     ... JWK members ...
  }
},
"holder_authentication": {
  "trust_framework": "some-ecosystem",
  "profile": "some-configuration-type"
}

IMO, it makes no sense to provide the authenticator assertion directly to the verifier.

[tlodderstedt]

Clarifying questions:

• Do I understand correctly that you want to convey from the issuer through the VC to wallet and verifier what requirements the issuer has regarding holder authentication?
• Why is this need caused by the focus of SD-JWT on key binding?
• To my knowledge the eIDAS assurance levels do not differentiate identification and authentication. Do you think this is a suitable vocabulary?

[alenhorvat]

NIST clearly differentiates between IAL and AAL. Both should be supported.

[awoie]

• To my knowledge the eIDAS assurance levels do not differentiate identification and authentication. Do you think this is a suitable vocabulary?

if key binding is about wallet authentication, then we need something else that tells the verifier that the holder was authenticated when the data was shared. IMO, this could be done in form of claims. We could essentially just define one claim "holder_authentication". A verifier might then be able to request specific members of holder_authentication in the response such as assurance levels, form factors etc. Perhaps something like acr and amr is sufficient?

@tlodderstedt you don't think this is needed?

[alenhorvat]

@awoie, what you're describing is "key attestation" or x509 cert today without the holder information. In terms of eIDAS, it is the signature "assurance level" - only 'qualified' is expressed.

How to get the qualified tag is defined within the framework. So question boils down to: How to express the key attestation? IMO it should be a separate credential.

Information like authentication/identification/documents presented can be implicit. Vocabulary needs to be defined by the trust framework anyway.

[awoie]

As discussed on the editor's call on June 22, we won't define any normative requirements but we will add some language to some considerations section.

[danielfett]

We revisited this issue on the editors' call and agreed to not add considerations for now. The exact encoding of assurance or confidence levels will be left to the profiles of the specification.