Skip to content

Commit

Permalink
Fix: Restructure to align with rest of RFCs
Browse files Browse the repository at this point in the history 
Signed-off-by: George J Padayatti <george.padayatti@igrant.io>
  • Loading branch information
@georgepadayatti
georgepadayatti committed Nov 18, 2024
1 parent 58c7879 commit e460844
Showing 1 changed file with 76 additions and 74 deletions.
150 changes: 76 additions & 74 deletions ewc-rfc004-individual-wallet-attestation.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,17 +3,15 @@
**Authors:**
* Mr Sebastian Bickerle (Lissi GmbH, Germany)
* Mr Edward Curran (Lissi GmbH, Germany)
* Mr George Padayatti (iGrant.io, Sweden)

**Reviewers:**
* Dr Andreas Abraham (ValidatedID, Spain)
* Mr George Padaytti (iGrant.io, Sweden)
* Mr Lal Chandran (iGrant.io, Sweden)
* Dr Andreas Abraham (ValidatedID, Spain)
* Dr Nikos Triantafyllou (University of the Aegean, Greece)

**Status:** Work in progress

Current: OAuth 2.0 Attestation-Based Client Authentication Draft 03 [[1](#60reference)]

**Table of Contents**
- [EWC RFC004: Individual Wallet Unit Attestation - v1.0](#ewc-rfc004-individual-wallet-unit-attestation---v10)
- [1.0 Summary](#10summary)
Expand All @@ -22,77 +20,84 @@ Current: OAuth 2.0 Attestation-Based Client Authentication Draft 03 [[1](#60refe
- [3.1 Wallet Unit Attestation JWT](#31-wallet-unit-attestation-jwt)
- [3.2 Wallet Unit Attestation PoP JWT](#32-wallet-unit-attestation-pop-jwt)
- [4.0 Messages](#40messages)
- [4.1 Wallet Unit Attestation within OID4VCI](#41-wallet-unit-attestation-within-oid4vci)
- [4.1.1 Token Request](#411-token-request)
- [4.1 Token request](#41-token-request)
- [4.2 Token response](#42-token-response)
- [5.0 Implementers](#50implementers)
- [6.0 References](#60references)

# 1.0 Summary

This specification defines a profile for using OAuth 2.0 Attestation-Based Client Authentication to provide Wallet Unit Attestation as defined within the implementing acts for the context of EWC Pilots.
This specification outlines how an individual wallet instance obtains a Wallet Unit Attestation from the Wallet Provider. It employs OAuth 2.0 Attestation-Based Client Authentication to deliver Wallet Unit Attestation to organisational wallets, as defined within the European ARF [1] and the EU Digital Identity Wallet Implementing Acts [2], in the context of EWC Pilots.

# 2.0 Motivation

An EUDI Wallet Instance's life cycle begins when the individual installs an EUDI Wallet app provided by an authorized EUDI Wallet Provider. Once installed, the EUDI Wallet Provider issues a Wallet Unit Attestation (WUA), and the instance is now operational [Ref: ARF 1.4, Chapter 6.5.3].
Using the WUA, an electronice attribute attestation (EAA) provider can authenticate a wallet unit and ensure that it is a valid EUDI wallet that has not been revoked before issuing an EAA.
An EUDI Wallet Instance lifecycle begins when an individual installs an EUDI Wallet app provided by a certified EUDI Wallet Provider. Upon installation, the EUDI Wallet Provider issues a Wallet Unit Attestation (WUA), enabling the instance to become operational.

An attestation provider must be able to determine if a wallet instance offers the requireed functional capabilities and meets the security requirements for issuance. For this purpose, the attestation provider must receive an attestation of the wallet’s capabilities and proof of non-revocation for the wallet instance.
Using the WUA, an Electronic Attribute Attestation (EAA) provider can authenticate a wallet unit and verify that it is a valid EUDI wallet that has not been revoked before issuing an EAA.

An attestation provider must be able to determine whether a wallet instance possesses the required functional capabilities and satisfies the security requirements for issuance. To achieve this, the attestation provider must receive proof of the wallet’s capabilities and evidence of non-revocation for the wallet instance.

# 3.0 Wallet Unit Attestation (WUA)

The attestation of a wallet's capabilities through Wallet Unit Attestation is based on the OAuth 2.0 Attestation-Based Client Authentication draft 03[1].
The attestation of a wallet's capabilities through Wallet Unit Attestation is based on the OAuth 2.0 Attestation-Based Client Authentication draft 03 [3].

## 3.1 Wallet Unit Attestation JWT

The following Wallet Unit Attestation JWT must be presented when sending the token request as defined in RFC001[7].
The following Wallet Unit Attestation JWT must be presented when sending the token request defined in RFC001[8] to issuers or when sending the authorisation response as described in RFC002 [9] to relying parties.

```
The header block is as given below:

```json
{
"typ": "wallet-unit-attestation+jwt",
"alg": "ES256",
"kid": "1"
"typ": "wallet-unit-attestation+jwt",
"alg": "ES256",
"kid": "1"
}
.
```

And the claim block:

```json
{
"iss": "https://attestation-service.com",
"sub": "https://wallet-solution.com",
"iat": 1541493724,
"status": {
"status_list": {
"idx": 0,
"uri": "https://example.com/statuslists/1"
},
},
"attested_security_context" : "https://eudiwalletconsortium.org/",
"cnf": {
"jwk" : {
"kty": "EC",
"crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
}
}
"iss": "https://attestation-service.com",
"sub": "https://wallet-solution.com",
"iat": 1541493724,
"status": {
"status_list": {
"idx": 0,
"uri": "https://example.com/statuslists/1"
}
},
"attested_security_context": "https://eudiwalletconsortium.org/",
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
}
}
}
```

This profile defines the following requirements for a Client Attestation JWT from [3] used as a WUA JWT in this context.

This profile defines the following additional requirements for a Client Attestation JWT from [1] used as a WUA JWT in this context.

1. The `alg` used to sign the attestation must be “ES256”
2. The `kid` must identify a JWK which must be resolvable as a JWK Set [https://datatracker.ietf.org/doc/html/rfc7517#section-5] by appending ./well-known/jwt-issuer to the value of the iss claim
1. The `alg` used to sign the attestation must be `ES256`
2. The `kid` must identify a JWK which must be resolvable as a JWK Set [5] by appending `./well-known/jwt-issuer` to the value of the `iss` claim
3. The `iss` claim must be the unique URL of the wallet solutions provider’s attestation service
4. All acceptable URLs for `iss` claim must be registered within section 5.
5. The `sub` claim must be the client_id of the wallet solution and registered within section 5.
6. The attestation should include a `status` claim which contains a reference to a status list as defined in [3] and which allows the attestation provider to check the state of revocation of the wallet instance
7. The value of `attested_security_context` must be “https://eudiwalletconsortium.org/”
4. All acceptable URLs for `iss` claim must be registered within wallet provider trust list.
5. The `sub` claim must be the `client_id` of the wallet solution and registered within wallet provider trust list.
6. The attestation should include a `status` claim which contains a reference to a status list as defined in [4] and which allows the attestation provider to check the state of revocation of the wallet instance
7. The value of `attested_security_context` must be `https://eudiwalletconsortium.org/`
8. The `cnf` claim must contain a Json Web Key (JWK) object `jwk` which must define the public key corresponding to the private key used for signing the WUA PoP JWT as defined in the following section.

## 3.2 Wallet Unit Attestation PoP JWT

A WUA Proof of Possession JWT must be provided as defined by section 4.3 of Attestation-based Client Authentication[1].
A WUA Proof of Possession JWT must be provided as defined by section 4.3 of Attestation-based Client Authentication [3].

See below the example payload:
```

```json
{
"iss": "https://wallet-solution.com",
"aud": "https://relying-party.com",
Expand All @@ -109,15 +114,16 @@ See below the example payload:

# 4.0 Messages

## 4.1 Wallet Unit Attestation within OID4VCI
The following messages of RFC001[7] must be extended with the corresponding wallet attestations.
The following messages of EWC RFC001 [8] must be extended with the corresponding wallet attestations to enable secure communication within OID4VCI. Wallet Unit Attestations (WUAs) are critical for ensuring the integrity and authenticity of token exchanges.

### 4.1.1 Token Request
Based on this profile and in conformance with HAIP section 4.3 [5] a wallet instance must send a WUA when sending the token request and use the same public key defined in the “cnf” claim of the WUA to create the Demonstrating Proof of Possession (DPoP) JWT [6]. The authorization server of the attestation provider must ensure that the JWK given in the header of the DPoP Proof JWT is equivalent to the JWK used within the `cnf` claim of the WUA JWT.
## 4.1 Token request

Based on this profile and in conformance with HAIP section 4.3 [6], a wallet instance must send a Wallet Unit Attestation (WUA) when sending the token request. It must use the same public key defined in the WUA's `cnf` claim to create the Demonstrating Proof of Possession (DPoP) JWT [7].

Request:
```
The authorization server of the attestation provider must ensure that the JWK given in the header of the DPoP Proof JWT is equivalent to the JWK used within the `cnf` claim of the WUA JWT.

Example Request:
```http
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Expand All @@ -131,8 +137,12 @@ grant_type=authorization_code
&authorization_details=...
```

Response:
```
## 4.2 Token response

The response to the token request includes an access token and additional details required for subsequent operations.

Example Response:
```json
{
"access_token": "eyJraWQiOiJqa3QiLCJhbGciOiJSUzI1NiJ9.eyJzdWIi...",
"token_type": "DPoP",
Expand All @@ -144,33 +154,25 @@ Response:
```

# 5.0 Implementers
<table>
<tr><th>Wallet</th><th>Qualified Redirect URL (client_id / sub)</th><th>Issuer (iss)</th>
<tr><td>Lissi Wallet</td><td>https://oob.lissi.io</td><td>https://wallet.lissi.io</td></tr>
<tr><td>Data Wallet by iGrant.io</td><td>https://igrant.io/datawallet.html</td><td>https://demo-business.igrant.io/</td></tr>
</table>

Please refer to the [implementers table](/~https://github.com/EWC-consortium/eudi-wallet-rfcs?tab=readme-ov-file#implementers).

# 6.0 References

[1] OAuth 2.0 Attestation-Based Client Authentication Draft 03 https://www.ietf.org/archive/id/draft-ietf-oauth-attestation-based-client-auth-03.html
Accessed: 2024/06/17
[1] European Commission. (2023). The European Digital Identity Wallet Architecture and Reference Framework (ARF). Available at: https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework (Accessed: 15-Nov-2024)

[2] European Commission. (2023). Commission Implementing Regulation (EU) 2023/XXXX of 2023 on the technical specifications and procedures for ensuring the integrity and core functionalities of the European Digital Identity Wallet under Regulation (EU) 910/2014 of the European Parliament and of the Council.

[3] OAuth 2.0 Attestation-Based Client Authentication Draft 03, Available at: https://www.ietf.org/archive/id/draft-ietf-oauth-attestation-based-client-auth-03.html (Accessed: 17-June-2024)

[2] OpenID for Verifiable Credentials Issuance Draft 13 https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-5.1.4
Accessed: 2024/06/17
[4] Token Status List, Available at: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-02 (Accessed: 17-June-2024)

[3] Token Status List https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-02
Accessed: 2024/06/17
[5] RFC 7571 JSON Web Key, Available at: https://datatracker.ietf.org/doc/html/rfc7517#section-5 (Accessed: 17-June-2024)

[4] RFC 7571 JSON Web Key https://datatracker.ietf.org/doc/html/rfc7517#section-5
Accessed: 2024/06/17
[6] OpenID High Assurance Interoperability Profile, Available at: https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.html#section-4.3 (Accessed: 17-June-2024)

[5] OpenID High Assurance Interoperability Profile
https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.html#section-4.3
Accessed: 2024/06/17
[7] RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP), Available at: https://www.rfc-editor.org/rfc/rfc9449.html (Accessed: 17-June-2024)

[6] RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
https://www.rfc-editor.org/rfc/rfc9449.html
Accessed: 2024/06/17
[8] EWC RFC001: Issue Verifiable Credential - v2.0, Available at: /~https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/ewc-rfc001-issue-verifiable-credential.md (Accessed: 17-June-2024)

[7] EWC RFC001: Issue Verifiable Credential - v2.0 /~https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/ewc-rfc001-issue-verifiable-credential.md
Accessed: 2024/10/24
[9] EWC RFC002: Present Verifiable Credentials - v1.0. Accessible from: /~https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/ewc-rfc002-present-verifiable-credentials.md (Accessed: 2024/10/24)

0 comments on commit e460844

Please sign in to comment.