-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need a way to define confidence or assurance levels #116
Comments
Clarifying questions:
|
NIST clearly differentiates between IAL and AAL. Both should be supported. |
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 @tlodderstedt you don't think this is needed? |
@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? Information like authentication/identification/documents presented can be implicit. Vocabulary needs to be defined by the trust framework anyway. |
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. |
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:
VS something like the following ...
IMO, it makes no sense to provide the authenticator assertion directly to the verifier.
The text was updated successfully, but these errors were encountered: