Draft for wallet attestation #408
Conversation
Sakurann
requested review from
danielfett,
jogu,
pmhsfelix,
samuelgoto,
peppelinux,
selfissued,
c2bo,
tplooker,
awoie,
Sakurann,
bc-pi and
babisRoutis
| Directly using key, app, and/or device attestations to prove certain capabilities to a Credential Issuer is an obvious option. However, this at least requires platform mechanisms that issue signed assertions that third parties can evaluate, which is not always the case (e.g., iOS's DeviceCheck). Also, such an approach creates dependencies on platform specific mechanisms, trust anchors, and platform specific identifiers (e.g., Android `apkPackageName`) and it reveals information about the internal design of a Wallet. Implementers should take these consequences into account. | ||
|
|
||
| The approach recommended by this specification is that the Credential Issuer relies on the OAuth 2.0 Client Authentication to establish trust in the Wallet and leaves it to the Wallet to ensure its internal integrity using app and key attestation (if required). This establishes a clean separation between the different components and a uniform interface irrespective of the Wallet's architecture (e.g., native vs. Web Wallet). Client Authentication can be performed with assertions registered with the Credential Issuer or with assertions issued to the Wallet by a third party the Credential Issuer trusts for the purpose of Client Authentication. | ||
| **Wallet attestation** is a mechanism where the Wallet Provider asserts the client's software and device authenticity and genuinity. The Wallet can provide this data in the Pushed Authorization Request or Token Request to allow the Authorization Server to validate the Wallet's authenticity. Directly using key, app, and/or device attestations to prove certain capabilities to an Authorization Server is an possibility although existing platform attestations are partly intended for first party interactions, i.e. the Wallet Provider's backend service and create direct dependencies to these services. The approach recommended by this specification is that the Credential Issuer relies on the OAuth 2.0 Client Authentication to establish trust in the Wallet and leaves it to the Wallet to ensure its internal integrity using app and key attestation (if required). This establishes a clean separation between the different components and a uniform interface irrespective of the Wallet's architecture (e.g., native vs. Web Wallet). Therefore, this specification introduces a common format utlizing the mechanisms of Attestation-Based Client Authentication as defined in [@!I-D.ietf-oauth-attestation-based-client-auth] that may be used by Credential Issuers for improved interoperability, see [](#walletattestation). Beside this, other OAuth client authentication methods may be used, e.g. private-key JWT. |
There was a problem hiding this comment.
| **Wallet attestation** is a mechanism where the Wallet Provider asserts the client's software and device authenticity and genuinity. The Wallet can provide this data in the Pushed Authorization Request or Token Request to allow the Authorization Server to validate the Wallet's authenticity. Directly using key, app, and/or device attestations to prove certain capabilities to an Authorization Server is an possibility although existing platform attestations are partly intended for first party interactions, i.e. the Wallet Provider's backend service and create direct dependencies to these services. The approach recommended by this specification is that the Credential Issuer relies on the OAuth 2.0 Client Authentication to establish trust in the Wallet and leaves it to the Wallet to ensure its internal integrity using app and key attestation (if required). This establishes a clean separation between the different components and a uniform interface irrespective of the Wallet's architecture (e.g., native vs. Web Wallet). Therefore, this specification introduces a common format utlizing the mechanisms of Attestation-Based Client Authentication as defined in [@!I-D.ietf-oauth-attestation-based-client-auth] that may be used by Credential Issuers for improved interoperability, see [](#walletattestation). Beside this, other OAuth client authentication methods may be used, e.g. private-key JWT. | |
| **Wallet Attestation** is a mechanism where the Wallet Provider asserts the Wallet software and hardware authenticity and genuinity. The Wallet SHOLD provide this data in the Pushed Authorization Request or Token Request to allow the Authorization Server to validate the Wallet's authenticity. While it is possible to directly use key, application, and device attestations to demonstrate capabilities to an Authorization Server, this approach has limitations. Existing platform attestations are primarily designed for first-party interactions (such as between a device and the Wallet Provider's backend services). Using these attestations directly would create unwanted dependencies on these services and may not be suitable for third-party interactions. The approach recommended by this specification is that the Credential Issuer relies on the OAuth 2.0 Client Authentication to establish trust in the Wallet and leaves it to the Wallet to ensure its internal integrity using app and key attestation (if required). This establishes a clean separation between the different components and a uniform interface irrespective of the Wallet's architecture (e.g., native vs. Web Wallet). Therefore, this specification introduces a common format utilizing the mechanisms of Attestation-Based Client Authentication as defined in [@!I-D.ietf-oauth-attestation-based-client-auth] that may be used by Credential Issuers for improved interoperability, see [](#walletattestation). Beside this, other OAuth client authentication methods may be used, e.g. private-key JWT. |
I would move this While it is possible to directly use key, application, and device attestations to demonstrate capabilities to an Authorization Server, this approach has limitations. Existing platform attestations are primarily designed for first-party interactions (such as between a device and the Wallet Provider's backend services). Using these attestations directly would create unwanted dependencies on these services and may not be suitable for third-party interactions. The approach recommended by this specification is that the Credential Issuer relies on the OAuth 2.0 Client Authentication to establish trust in the Wallet and leaves it to the Wallet to ensure its internal integrity using app and key attestation (if required). This establishes a clean separation between the different components and a uniform interface irrespective of the Wallet's architecture (e.g., native vs. Web Wallet). Therefore, this specification introduces a common format utlizing the mechanisms of Attestation-Based Client Authentication as defined in [@!I-D.ietf-oauth-attestation-based-client-auth] that may be used by Credential Issuers for improved interoperability, see [](#walletattestation). Beside this, other OAuth client authentication methods may be used, e.g. private-key JWT. to a impl consideration section.
There was a problem hiding this comment.
I would not like to split up the information about wallet attestation too much
There was a problem hiding this comment.
It looks like a very long text mixing term definitions (wallet attestations) normative use and impl considerations
I would move wallet attestations to the defined term and not redefine It here, reducing this text
Co-authored-by: Giuseppe De Marco <[email protected]>
Co-authored-by: Giuseppe De Marco <[email protected]>
|
|
||
| * `wallet_name`: REQUIRED. A String containing a human-readable name of the Wallet. | ||
| * `wallet_link`: REQUIRED. A String containing a URL to get further information about the Wallet and the Wallet Provider. | ||
|
|
There was a problem hiding this comment.
| * `status`: OPTIONAL. Object compliant to IETF Status List draft. | |
There was a problem hiding this comment.
good point, an href would be appreciated
There was a problem hiding this comment.
I do not see anywhere in this draft that says that the wallet attestation should be displayable to the user, as a means of engendering the user's trust in the wallet app. The current text is concerned with transferring the wallet attestation between system components, which is important. But so is display to the user.
Co-authored-by: Kristina <[email protected]>
Co-authored-by: Giuseppe De Marco <[email protected]>
Closes #355
Closes #406