added wallet attestation scheme

[tlodderstedt]

Closes # 51

📑 Description

This PR adds a Wallet Attestation scheme to the spec.

Preview Link

click here for rendered preview of PR

[tlodderstedt]

The PR is not complete yet. It lacks the list of values allowed (or at least ore-defined) for user authentication and key type. I would also like to suggest to adopt the WebAuthn attestation claims instead of defining new claims and values.

key-protection-types

user-verification-methods

[paulbastian]

For a start I would recommend to limit the possible values as follows.
Key protection Types:

• Software
• TEE
• Strongbox
• Secure Enclave
• Secure Element

User Verification Methods:

• System-Biometry
• System-PIN
• Internal-Biometry
• Internal-PIN
• SecureElement-PIN

[Sakurann]

In addition to what? To the claims defined in draft-ietf-looker?

[tlodderstedt]

In addition to "the definition given in [!I-D.ietf-looker-key-attestation-client-authentication]"

[Sakurann]

are the values taken from somewhere or defined in HAIP? If the latter, why not use snake case?

[tlodderstedt]

We define it in HAIP. I'm neutral on the style. Snake case would be consistent with https://fidoalliance.org/specs/common-specs/fido-registry-v2.2-rd-20210525.html#key-protection-types.

[Sakurann]

Again, where are the values being defined..? If not in HAIP should it point somewhere?

[tlodderstedt]

I would prefer to reuse WebAuthn values. Let's discuss.

[peppelinux]

if WebAuthn values are used I'm ok with that, we then need a ref to them

[tlodderstedt]

@paulbastian can you please provide descriptions for the different values of key type and user authentication?

[peppelinux]

if WebAuthn values are used I'm ok with that, we then need a ref to them

[peppelinux]

Do we have to defined error codes and messages for that?

[tlodderstedt]

you mean in the credential issuance response?

[peppelinux]

yes, do we have to give a ref to openid4vc?

[Sakurann]

once this PR goes in (https://github.com/openid/OpenID4VCI/pull/64/files), we should probably add insufficient_wallet_security or something as an error code? for now, let's open an issue on this.

[peppelinux]

#62

[peppelinux]

I'm not in favor of duplicating iss to sub

I have the strong assumption that the wallet provider and the wallet instance are different entities

In my current implementation we have decided to use the jwk thumbprint to identify the wallet instance and then we use this value in the sub

there's a good agreement to simply remove the sub claim, WDYT about this?

[tlodderstedt]

It's not a duplication. It represents the fact that the wallet provider issues an attestation about itself. Whatever component uses this attestation with a valid proof of possession of the key in cnf can be considered a valid "representative" of the wallet provider. That is sufficient for authentication and authorization.
This value is especially used a client_id. If you want to make the client id instance specific, you can do so. I would prefer to have a client_id identifying the wallet provider. This information can be used in self service and customer care and makes sense to the user.

[paulbastian]

With regard to eIDAS terms: iss describes the Wallet Solution Provider and sub descibes the specific Wallet Solution of a Wallet Instance

[tlodderstedt]

sub descibes the specific Wallet Solution of a Wallet Instance
which includes the option to leave instances anonymous, right?

[paulbastian]

yes, anonymous instances should be RECOMMENDED in my opinion

[tlodderstedt]

According to the underlying draft-looker-oauth-attestation-based-client-auth, the iss is the entity the AS (here the wallet) trusts for the purpose of the issuance of attestations and the sub is the client id. The wallet can establish the trust be looking the iss value up in a trusted list, for example. The actual wallet product could be the sub value. The attributes (including capabilities and perhaps even authorization) need to be conveyed through claims in the attestation.
The difference between attester and wallet provider would be that if the wallet provider is in the iss, it needs to be entitled by the trusted list to issue it's own attestations whereas in the case of the attester, it's the attester who has that entitlement.

Does this sound reasonable?

[peppelinux]

I'm in favor of having sub as optional and without any constraint about its value

the current proposal is concerning to me

[paulbastian]

in the call yesterday we came to the conclusion that the fundamental question is:
"Is the Wallet Provider always the Attester of the Wallet Instance?"

Indeed, we have already seen the reality that wallet providers may not have the capacity/willingness to run an attestation service on their own. And nobody will force an wallet provider to use a different attestation service. But we should keep this option open. Therefore I am voting to use:

• iss as the issuer of the wallet attestation
• sub as the client id
  The version should not be referenced in there as this is responsibility of the wallet provider and not a burden to the issuer. If the Wallet Provider runs the attestation service on his own, we have two possibilities:
• a) iss equals sub
• b) sub may be omitted
  I'm in favor of a)

[Sakurann]

@peppelinux making the sub optional cannot be done in HAIP and needs to be discussed in the IETF on the client attestation draft. For HAIP, I suggest we remove the concrete values and put in letter what the values are expected to be: code suggestion below.

[peppelinux]

in the implementation I'm working on the sub value is the thumbprint of the cnf.jwk since this latter uniquely identify, anyway, the wallet instance

[tlodderstedt]

feedback from the GAIN call: would it make sense to make user_authentication a multi value to carry all capabilities? WebAuthn does it this way for user authentication (userVerificationDetails) and key types (keyProtection).
https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-metadata-statement-v2.0-rd-20180702.html#widl-MetadataStatement-userVerificationDetails

[peppelinux]

do we assume that a single wallet provider may own multiple wallet solution?

I assume that a single wallet provider owns a single wallet solution.
If we don't have agreement on how the sub value should be valued, considering that it may have the same value of iss and that's misleading since provider and instance are different entities, I suggest to get sub out by simply removing it from the required attributes

[TakahikoKawasaki]

In the discussions in this PR,

1. the Wallet Provider and the Attester are competing for the iss claim, and
2. the Per-Application identifier, the Per-Version identifier and the Per-Device identifer are competing for the sub claim.

Each of the concepts should have a separate claim in order to avoid conflicts. Otherwise, we would encounter technically troublesome issues in the future.

[peppelinux]

these information increases the responsability to the issuer that should evaluate mixed variables to an qualitative index

I'm not in favor of this, since, as already made with ACR values (LoA) in SAML2 and OIDC, a trust framework just have to define the properties within which some attestation levels are achieved

that's why we're working with attested_security_context

the regulation should map key types and user auth types, by quality, inside different level (low, middle, high?)

very often the technology changes, with upgrades and deprecation, using a normalized and indexed approach is better than expose issuer to internal evaluation of the security properties that, not at least, then exposes also personal tastes like the user auth type or differently, the key_Type that in some cases are mobile-brand specific -> then discloses the hardware type

[paulbastian]

as discussed in the call yesterday, as long as we don't have a complete framework on attested security context and the mappings of key type and userauthentication to asc, it makes sense to offer key_type and user_authentication as this is a mechanism that is already working today and has been implemented.
Once we have a complete trust framework with asc mappings, we can add them to the client attestations

Therefore, I'm voting to keep them in for now and offer both possiblities

[Sakurann]

In general I agree with Giuseppe on the direction, but what Paul is saying that we are lacking those "normalized values" is also true.. so if we foresee that concrete key_type and user_authentication will be replaced by "normalized approach", I think at least we should not mandate key_type and user_authentication?

[Sakurann]

JohnB suggested external-multifactor

[peppelinux]

I'm in favor of having sub as optional and without any constraint about its value

the current proposal is concerning to me

[peppelinux]

I have a good opinion about the possibility to use the WIA to give more guidance about how a wallet instance metadata discovery can be made, thanks to it

that's why I'd propose the following OPTIONAL claims to attests the WI capabilities, exemplified below in a non normative way

  "attested_security_context": "https://trust-framework.example.org/LoA/basic",
  "authorization_endpoint": "haip:",
  "response_types_supported": [
    "vp_token"
  ],
  "vp_formats_supported": {
    "jwt_vp_json": {
      "alg_values_supported": ["ES256"]
    },
    "jwt_vc_json": {
      "alg_values_supported": ["ES256"]
    }
  },
  "request_object_signing_alg_values_supported": [
    "ES256"
  ],
  "presentation_definition_uri_supported": false,

[selfissued]

Now I-D.ietf-oauth-attestation-based-client-auth

[selfissued]

I wouldn't include spaces in the values. They can cause quirky problems, in practice.

[peppelinux]

I would propose to use snake_case for the key values, then

• software
• tee
• strongbox
• secure_enclave
• secure_element
• external_hsm

[tlodderstedt]

modified

[tlodderstedt]

In the discussions in this PR,

the Wallet Provider and the Attester are competing for the iss claim, and
the Per-Application identifier, the Per-Version identifier and the Per-Device identifer are competing for the sub claim.
Each of the concepts should have a separate claim in order to avoid conflicts. Otherwise, we would encounter technically troublesome issues in the future.

Looking onto it from an OAuth AS perspective, I think is important to define a) what kind of assertions the AS should process and b) how the client id is determined.

For a) all what matters is that the AS can look that value up and knows how to access the signing key. Whether that is a 3rd party or the wallet provider itself, can be determined by the deployment.

For b) I would stick to the definition of RFC 752 "For client authentication, the subject MUST be the "client_id" of the OAuth client." That basically means client id values are at the discretion of the wallet assertion issuer. If the issuer decides to use ephemeral values, that's fine, too.

[peppelinux]

Suggested change

	* `hardware`: It MUST be used when the wallet uses software-based key management.
	* `hardware`: It MUST be used when the wallet uses hardware-based key management.

[peppelinux]

Suggested change

	* `hardware`: It MUST be used when the wallet uses software-based key management.
	* `hardware`: It MUST be used when the Wallet uses software-based key management.

[peppelinux]

definition about Secure Enclave, Strongbox and TEE are required if any external reference is given to the reader

what they are or where they are defined is an editorial requirement

[Sakurann]

Suggested change

	* `user_authentication`: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to authenticate access to the private key associated with the public key given in the `cnf` claim. This specification defines the following values for `user_authentication`: `system_biometry`, `system_pin`, `internal_biometry`, `internal_pin`, and `secureelement_pin`.
	* `user_authentication`: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to authenticate access to the private key associated with the public key given in the `cnf` claim. This specification plans to define the following values for `user_authentication`: `system_biometry`, `system_pin`, `internal_biometry`, `internal_pin`, and `secureelement_pin`.

we need to define each of these values like for key_type. can be another PR, but would like to be clear we will keep working on it.

[tlodderstedt]

@paulbastian can you please provide definitions of the user authentication values?
@Sakurann I think we either don't define the claim at all or we fully define it.

[tlodderstedt]

@Sakurann Paul updated the PR with definitions. Please check.

[Sakurann]

happy to approve once my one suggestion is incorporated

[bc-pi]

shouldn't these values be lower cased to match the definitions above?

[Sakurann]

why was it merged? i still had request for changes

[advatar]

Sorry for being a bit late to the party.

What do you mean by internal_biometry? That the wallet has some kind internal implementation of face verification at some level of assurance? Then the level of the assurance is supplied by aal.

Is this correct?

I think that it might be the case that we will see an ecosystem of apps that, given a portrait, only verifies the presence (liveness) of the user. That would be more of external_biometry but maybe this distinction does not matter? What is important is that it is biometric authentication that is not by the system but by the portrait from the PID(passport/national id).