allow use of other wallet attestations formats?

[jogu]

Split out of #188

[jogu]

Discussed on this morning's WG call:

1. What is signed into the attestation JWT is undefined
   2.Who is authenticating can be unclear (is it the wallet app or the backend, can the backend authenticate directly to issuer given spec says subject of authenticate has to be wallet app - but some implementations are already attesting the server rather than the app which isn't permitted/intended in current spec?)

There are existing formats, forcing them to be wrapped into a JWT can introduce new security/privacy issues. Forcing a particular format certifications - e.g. if an application is in a secure element and uses a particular format and wants to attest itself, if you can't directly use that then re-wrapping it in a backend may make security/privacy worse. However using this attestation directly may expose a device specific identifier to the credential issuer?

Also what if you don't have a wallet backend? Is a wallet backend mandatory in HAIP?

If we have language that's too strong in HAIP 1.0 it may be difficult to relax that later without creating a HAIP 2.0.

[paulbastian]

I didn't understand this:

What is signed into the attestation JWT is undefined
Could you elaborate on what is undefined?

What other formats exist that could be used?

I also believe having a wallet backend for high assurance wallets is very much realistic, I have no clue how to science version security levels otherwise.

[jogu]

What other formats exist that could be used?

For example, a secure elements native attestation format for an application hosted on a secure element.

I also believe having a wallet backend for high assurance wallets is very much realistic, I have no clue how to science version security levels otherwise.

I think there's a typo in the end of that sentence?

[paulbastian]

What other formats exist that could be used?

For example, a secure elements native attestation format for an application hosted on a secure element.

This is a key attestation. I didn't believe everything OpenID assumes to be a wallet is implemented in a secure element, but usually only the key storage, maybe some auxiliary logic but not more.

I also believe having a wallet backend for high assurance wallets is very much realistic, I have no clue how to science version security levels otherwise.

I think there's a typo in the end of that sentence?

I have no clue how to achieve certain security levels otherwise.

[Sakurann]

wg discussion:

• strong concerns if wallet attestations as defined in annex E of VCI is not mandated, since wallet attestations differ from key attestations, so arguments that led to making key attestations optional do not apply for the wallet attestations.
• on one hand, wallet attestations are part of client authentication mechanism of OAuth 2.0 and leaving it undefined is security issue
• on the other hand, some implementations want to create wallet attestations locally within the mobile device? but wallet attestations as defined in annex E allows for this?
• is there an alternative to annex E wallet attestation?

[Sakurann]

wg discussion:

• one option is to mandate wallet attestations and allow freedom on how the content of wallet attestations look like. something like:

Wallets MUST authenticate to the issuer at the PAR/token endpoints. Ecosystems that desire wallet-issuer interoperability on the level of wallet attestations SHOULD require Wallets to support the format specified in Annex E of [OIDF.OID4VCI]. When doing so, they might need to define additional claims. Alternatively, ecosystems MAY choose to rely on other wallet attestation formats.

• strong concerns that the text above would limit interoperability. alternatively,

For wallet attestation,s Wallets MUST support the format specified in Annex E of [OIDF.OID4VCI]. When doing so, they might need to define additional claims.

• @martijnharing please elaborate why you are not comfortable mandating Annex E for wallet attestations.

[sorotokin]

To reiterate, I do not understand why a device which is capable of holding key-bound digital credentials would not be capable of using wallet attestation. If it is not a burden, it should be mandated. Less permutations of HAIP features = more interoperability.

[martijnharing]

Some of the challenges with mandating the wallet attestation structure as defined in Appendix E.

• Appendix E is especially designed for authentication of ‘native app wallets’, but the actual entity that authenticates to the authorization server is not necessarily a ‘native app wallet’. It could be a server, an OS component, a secure area application etc etc. Neither HAIP nor VCI prescribes which of these items will be attested, therefore it’s not clear what is meant with a mandate to support the wallet authentication structure in Appendix E. Because of that, there is ambiguity in what it means to be compliant with HAIP. Some examples:

  
- What if you want to attest the server but Appendix E mandates that you authenticate the ‘native app wallet’.
  
- What is the ‘native app wallet’ when issuing involves a server, a phone with applications, os components and secure areas and a watch with applications, os components and secure areas, all of these with relevant code running.
• The sub claim is mandatory and is defined as the client_id of the wallet instance. Since OAuth defines the client_id as being issued by the authorization server, this can easily lead to a cumbersome process where you need to retrieve a client_id from each authorization server (and for each ‘wallet type’) you interact with.
• The client_id should be the same across wallet instances of the same type, but it’s not defined nor clear what is meant with type. With such a large potential variety of components that can be involved with issuance and presentment, type can potentially be quite unique.
• The authorization server is mandated to verify the wallet attestation and reject issuance if it cannot verify it, independent of whether the wallet attestation structure is required for the security model used for issuance. This means it’s not a choice to use the wallet attestation structure even if not needed.
• Since the authorization server must verify the trust chain and must be an entity that the credential trusts, it becomes very difficult or almost impossible to do issuance without a wallet server. Since the wallet attestation structure itself is mandatory, issuance without a wallet server involved can only be done if the device is able to create the wallet attestation structure in a trustworthy way in the exact format. This can be quite a challenge with the hardware capabilities of relevant devices.
• If the wallet attestation structure is created by a device that is not capable of (securely) generating the format is not defined in appendix E, it is now required by the wallet server component to re-issue the structure, which can impact the security proposition of using the attestation.


[sorotokin]

Perhaps I am confused, but the client_id is effectively what names the wallet. Issuance server in HAIP context must always know which wallet it talks to, right? If there is a problem managing client_id, it is probably an indication of some real issue of what is the "identity" of the wallet.

My observation is that wallet attestation issuance is directly parallel to a credential issuance and wallet attestation PoP generation is directly parallel to presentment. A wallet that is capable of these two operations with credentials should be able to work with wallet attestation.

Wallet attestation should be issued by the back-end or some kind of secure hardware - but this is an infrequent operation, can be done as a part of wallet installation/sign-in/provisioning. this would "bless" some secure key(s) (the same way credential provisioning does). At credential issuance time, all is required is attestation PoP generation, which can be done locally using one of the "blessed" secure keys, no need for the back-end at that point.