added wallet attestation scheme #52
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -139,7 +139,42 @@ Note: Issuers should be mindful of how long the usage of the refresh token is al | |||||||||||||||
|
|
||||||||||||||||
| ### Wallet Attestation Schema {#wallet-attestation-schema} | ||||||||||||||||
|
|
||||||||||||||||
| Wallets MUST use attestations following the definition given in [@!I-D.looker-oauth-attestation-based-client-auth]. | ||||||||||||||||
|
There was a problem hiding this comment. Now I-D.ietf-oauth-attestation-based-client-auth |
||||||||||||||||
|
|
||||||||||||||||
| In addition to the claims, the Wallet Attestation MUST contain the following claims: | ||||||||||||||||
|
There was a problem hiding this comment.
Suggested change
made optional following the conversation below. |
||||||||||||||||
|
|
||||||||||||||||
| * `key_type`: this claim asserts the security mechanism the wallet can use to manage private keys. This capability is based on the capabilities of the execution environent of the wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud wallet). This specification defines the following values for `key_type`: `Software`, `TEE`, `Strongbox`, `Secure Enclave`, `Secure Element` and `External-HSM`. | ||||||||||||||||
|
There was a problem hiding this comment.
Suggested change
should be clear if a string or array of strings. chose array of strings for the case when ["hardware", "secure_element"]. There was a problem hiding this comment. Each of the terms defined by this spec need to be expanded upon and given a clear definition following https://fidoalliance.org/specs/common-specs/fido-registry-v2.2-rd-20210525.html#key-protection-types. strongbox and secure enclave are just particular implementations of TEE (confirmed with john bradley) There was a problem hiding this comment. I agree with the proposal to create bullets for every type value. I stripped the definitions as we now do only have a single value. I changed the definition of SE to refer to Secure Elements. Secure Enclaves and Secure Elements might be a certain kind of trusted execution environment, but they have distinct properties differentiating them from TEEs in general. As far as I understand, a security module qualifies as TEE already if the process is isolated from the user processes. Secure Element have hardware isolation. I added Secure Enclave and Strongbox. There was a problem hiding this comment. I wouldn't include spaces in the values. They can cause quirky problems, in practice. There was a problem hiding this comment. I would propose to use snake_case for the key values, then
|
||||||||||||||||
| * `user_authentication`: this claim asserts the security mechanism the wallet can use to authenticate access to private keys. This specification defines the following values for `user_authentication`: `System-Biometry`, `System-PIN`, `Internal-Biometry`, `Internal-PIN`, and `SecureElement-PIN`. | ||||||||||||||||
|
There was a problem hiding this comment. 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 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 There was a problem hiding this comment. 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. Therefore, I'm voting to keep them in for now and offer both possiblities There was a problem hiding this comment. 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 There was a problem hiding this comment. JohnB suggested There was a problem hiding this comment.
Suggested change
Is it a string or array of strings?? There was a problem hiding this comment. I honestly do not know what any of the following values for |
||||||||||||||||
|
|
||||||||||||||||
| These additional claims inform the issuer about the security capabilities of the wallet and allows the issuer to refuse credential issuance if the achievble security level of a certain wallet does not fulfil the issuer's requirements. | ||||||||||||||||
|
There was a problem hiding this comment. Do we have to defined error codes and messages for that? There was a problem hiding this comment. you mean in the credential issuance response? There was a problem hiding this comment. yes, do we have to give a ref to openid4vc? There was a problem hiding this comment. once this PR goes in (https://github.com/openid/OpenID4VCI/pull/64/files), we should probably add |
||||||||||||||||
|
|
||||||||||||||||
| To obtain the issuer's Public key for verification, wallet attestions MUST support web-based key resolution as defined in Section 5 of [@!I-D.terbu-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key. | ||||||||||||||||
|
|
||||||||||||||||
| This is an example of a wallet attestation: | ||||||||||||||||
Sakurann marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||||
|
|
||||||||||||||||
| ```json | ||||||||||||||||
| { | ||||||||||||||||
| "typ": "wallet-attestation+jwt", | ||||||||||||||||
| "alg": "ES256", | ||||||||||||||||
| "kid": "1" | ||||||||||||||||
| } | ||||||||||||||||
| . | ||||||||||||||||
| { | ||||||||||||||||
| "iss": "https://wallet.example.com", | ||||||||||||||||
| "sub": "https://wallet.example.com", | ||||||||||||||||
|
There was a problem hiding this comment. 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? There was a problem hiding this comment. 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 There was a problem hiding this comment. With regard to eIDAS terms: There was a problem hiding this comment.
There was a problem hiding this comment. yes, anonymous instances should be RECOMMENDED in my opinion There was a problem hiding this comment. According to the underlying draft-looker-oauth-attestation-based-client-auth, the Does this sound reasonable? There was a problem hiding this comment. I'm in favor of having sub as optional and without any constraint about its value the current proposal is concerning to me There was a problem hiding this comment. in the call yesterday we came to the conclusion that the fundamental question is: 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:
There was a problem hiding this comment. @peppelinux making the There was a problem hiding this comment. in the implementation I'm working on the
Sakurann marked this conversation as resolved.
Show resolved
Hide resolved
There was a problem hiding this comment.
Suggested change
There was a problem hiding this comment. I think that you found the best editorial compromise for this annoying issue of the sub There was a problem hiding this comment. I would also like to add to this discussion that we agreed that the claim client_id represents the unique client identifier, even if there are divisions about who is the real client: the wallet solution or the wallet instance. I'm in favour of the latter, by having the distinction between However, "client_id" is not always used to specify a client identifier since there are many way in OAuth2 to uniquely identify a client within a flow, below I mention for instance methods like:
even if these are not relevant for the wallet solution, I'd try to not mandate too many details within the specs at this current phase, by giving more flexibility in the material implementations on the way. There was a problem hiding this comment. incorporated Kristina's suggestion |
||||||||||||||||
| "exp": 1516247022, | ||||||||||||||||
| "key_type": "STRONGBOX", | ||||||||||||||||
| "user_authentication": "APP_PIN_6_DIGITS", | ||||||||||||||||
| "cnf": { | ||||||||||||||||
| "jwk": { | ||||||||||||||||
| "kty": "EC", | ||||||||||||||||
| "crv": "P-256", | ||||||||||||||||
| "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", | ||||||||||||||||
| "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" | ||||||||||||||||
| } | ||||||||||||||||
| } | ||||||||||||||||
| } | ||||||||||||||||
| ``` | ||||||||||||||||
|
|
||||||||||||||||
| ## Credential Endpoint | ||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would be better to set it as SHOULD, since it is not normative HOW the attestation could be provisioned and obtained. The MUST should be considered for the verification of the attestation, not to the way it was provisioned
I say this because there are several ways to provision a signed JWT and I would keep the door open with a good guidance (SHOULD) without forcing the usage of a particular specification
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rewrote the paragraph and changed it to SHOULD as with the new revision we have options on different abstraction levels to convey information about the security of the wallet and the key.