Skip to content

Commit

Permalink
Merge pull request #127 from flare-gr/main
Browse files Browse the repository at this point in the history 
RFC-010: Review
  • Loading branch information
@andreasabr
andreasabr authored Jan 23, 2025
2 parents 14b6607 + b4e1a8d commit 4343a30
Show file tree
Hide file tree
Showing 2 changed files with 44 additions and 31 deletions.
2 changes: 1 addition & 1 deletion README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,7 @@ These are the approved RFCs identified to be specified towards wallet providers,
| RFC-004 | [Individual Wallet Unit Attestation - v1.0](ewc-rfc004-individual-wallet-attestation.md) |
| RFC-005 | [Issue Legal Person Identification Data (LPID) - v1.0](ewc-rfc005-issue-legal-person-identification-data.md) |
| RFC-007 | [Payment Wallet Attestation - v1.0](payment-rfcs/ewc-rfc007-payment-wallet-attestation.md) |
| RFC-010 | [Document Signing using Long-Term Certificates](ewc-rfc010-long-term-certifice-qes-creation.md) |
| RFC-100 | [EWC Interoperability Profile Towards ITB - v2.0](ewc-rfc100-interoperability-profile-towards-itb-v1.0.md) |

### RFCs Under Development
Expand All @@ -57,7 +58,6 @@ Following are the candidates' RFCs taken up. Note that the title, etc, may chang
| RFC-006 | [Organisational Wallet Unit Attestation - v0.9](/ewc-rfc006-organisational-wallet-unit-attestation.md) |
| RFC-008 | [Payment Data Confirmation - v1.0](payment-rfcs/ewc-rfc008-payment-data-confirmation.md) |
| RFC-009 | Payment Transaction Initiation |
| RFC-010 | [Document Signing using Long-Term Certificates](ewc-rfc010-long-term-certifice-qes-creation.md) |
| RFC-011 | Payments with verifiable receipts |

## EWC Wallet Implementers (ITB - Compliant to EWC 2.1)
Expand Down
73 changes: 43 additions & 30 deletions ewc-rfc010-long-term-certifice-qes-creation.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,8 @@

**Reviewers:**

TBA
- Mr. Andreas Abraham (ValidatedID, Spain)
- Mr. Leone Riello (Infocert, Italy)

**Table of Contents:**

Expand Down Expand Up @@ -89,38 +90,51 @@ The architecture will be broken down in 6 main phases:
participant Signing Service
participant RQES Provider
end
Note over User, Signing Service: Phase 1: Signing Service User Registration
User->>Signing Service: User Login/Registration to Signing Service (eg. via Username, Password, VCs)
Signing Service->>User: PID Presentation (Binding) Request via OID4VP
EUDI Wallet->>Signing Service: PID Presentation
Note over User, Signing Service: At this point the user has been strongly authenticated.
Signing Service->>User: Credential Offer Deeplink for QESAC
EUDI Wallet->>Signing Service: Credential Request for QESAC
Signing Service->>EUDI Wallet: QESAC Issuance
Note over User, Signing Service: Phase 1: Service Provider Access & User Authentication
Note over User, Signing Service: Phase 2: Service Provider Access
User->>Service Provider: Service Access
Service Provider->>Signing Service: Request Signing of Document
Signing Service->>User: PID Presentation Request via OID4VP
EUDI Wallet->>Signing Service: PID Presentation
Signing Service->>User: PID, QESAC Presentation Request (Authentication)
EUDI Wallet->>Signing Service: PID, QESAC Presentation
Note over Signing Service, RQES Provider: Phase 2: Certificate Listing and Selection
Note over Signing Service, RQES Provider: Phase 3: Certificate Listing and Selection
Signing Service->>RQES Provider: POST /csc/v2/credentials/list
RQES Provider->>Signing Service: { credentialIDs: [...], credentialInfos: [...] }
Note over User, RQES Provider: Phase 3: Signature Confirmation & Private Key Unlocking (Credential Authorization)
Signing Service->>User: PID Presentation Request (Signature Confirmation)
EUDI Wallet->>Signing Service: PID Presentation
Note over User, RQES Provider: Phase 4: Signature Confirmation & Private Key Unlocking (Credential Authorization)
Signing Service->>User: PID, QESAC Presentation Request (Signature Confirmation)
EUDI Wallet->>Signing Service: PID, QESAC Presentation
alt oauth2code Credential Authz
User->>RQES Provider: Credential Authorization (for oauth2code flow)
activate RQES Provider
else explicit Credential Authz
activate Signing Service
User->>Signing Service: Credential Authorization (for explicit flow)
deactivate Signing Service
Signing Service->>RQES Provider: POST /csc/v2/credentials/authorize
deactivate RQES Provider
RQES Provider->>Signing Service: SAD
end
Note over Signing Service, RQES Provider: Phase 4: Signature Creation
Note over Signing Service, RQES Provider: Phase 5: Signature Creation
Signing Service->>RQES Provider: POST /csc/v2/signatures/signHash
RQES Provider->>Signing Service: Signed Hash
Note over User, Signing Service: Phase 5: Signed Document Formation and Retrieval
Note over User, Signing Service: Phase 6: Signed Document Formation and Retrieval
Signing Service->>Service Provider: Signed Document
Service Provider->>User: Signed Document
```
Expand All @@ -133,24 +147,23 @@ The architecture will be broken down in 6 main phases:
participant EUDI Wallet
participant Signing Service
User->>Signing Service: Request registration
Signing Service->>User: PID Presentation Request via OID4VP
User->>Signing Service: User Login/Registration to Signing Service (eg. via Username, Password)
Signing Service->>User: PID Presentation (Binding) Request via OID4VP
EUDI Wallet->>Signing Service: PID Presentation
Note over User, Signing Service: At this point the user has been strongly authenticated.
Signing Service->>User: Credential Offer Deeplink for QESAC
EUDI Wallet->>Signing Service: Credential Request for QESAC
Signing Service->>EUDI Wallet: QESAC Issuance
```

Before the user can get access to the Signing Service to be able to sign documents, the user will need to be registered with the Signing Service.

The registration process should be accessible only to users who are strongly authenticated with the service.
Before the user can get access to the Signing Service to be able to sign documents, the user will need to be registered and authorized with the Signing Service.

During the registration procedure, the Signing Service must request the user's PID to be presented with, at least, the [mandatory attributes](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/1.4.0/annexes/annex-3/annex-3.01-pid-rulebook/#23-pid-attributes) (`family_name`, `given_name`, `birth_date`, `age_over_18`, `issuance_date`, `expiry_date`) included in the presentation.
During the registration flow, the signing service should request identification and authentication data from the user in a way that the unique identification of the user is ensured (eg, a combination of Username, Password, VCs).

Checks should be performed in order to make sure the presented document is valid and current (out of scope).
During the registration procedure, the Signing Service must also request the user's PID to be presented with, at least, the [mandatory attributes](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/1.4.0/annexes/annex-3/annex-3.01-pid-rulebook/#23-pid-attributes) (`family_name`, `given_name`, `birth_date`, `age_over_18`, `issuance_date`, `expiry_date`, `issuing_authority`, `issuing_country`) included in the presentation.

The Signing Service should then use these attributes, along with data from the authentication context of the user to issue a QES Auth Credential (QESAC), including in its `token` claim a unique identifier or token, binding the user's profile to this VC.
The Signing Service should bind the user’s PID to its corresponding and uniquely identified user (by utilizing the authentication data) and issue a QES Auth Credential (QESAC). The QESAC must contain a `token` claim, bound to the user's profile.

For the issuance of the QESAC, the process detailed in [RFC-001 (Issue Verifiable Credential)](ewc-rfc001-issue-verifiable-credential.md) must be used.

Expand Down Expand Up @@ -179,7 +192,7 @@ If needed, the user's credential ID can also be included in the QESAC to assist

Since each Signing Service has its own requirements and processes and should not be used by another Signing Service, the `vct` of the QESAC can be set by each Signing Service accordingly.

## 4.2 Phase 2: Service Provider Access & User Authentication
## 4.2 Phase 2: Service Provider Access & User Authentication for Signing

#### Overview:

Expand All @@ -196,21 +209,21 @@ Since each Signing Service has its own requirements and processes and should not
EUDI Wallet->>Signing Service: PID, QESAC Presentation
```

In the first part of the signing procedure, the **User** accesses (through their browser) the **Service Provider** to request a document to be signed.
In the second part of the signing procedure, the **User** accesses (through their browser) the **Service Provider** to request a document to be signed.

### 4.2.1: Service Access by User:

Initially, the User accesses the Service Provider through their browser. Upon arrival, the user should be presented with an Authentication screen, requesting presentation of their PID.
Initially, the User accesses the Service Provider through their browser. Upon arrival, the user should be presented with an Authentication screen, should they not have already been strongly authenticated (during phase 1).

### 4.2.2: User Authentication
### 4.2.2: User Authentication for Signing

The Signing Service should require the user is authenticated. Authentication of the user happens through a presentation of their PID and their QESAC.

The Signing Service should, at minimum, make the following verifications during authentication:

- The VPs of the QESAC, PID are valid.
- The `token` inside the QESAC is valid and not recalled.
- The PID attributes presented match the attributes presented during the issuance of the QESAC.
- The user profile binded to the presented PID matches the profile binded to the QESAC.
- If a `credential_id` is included in the QESAC, the credential with the specified ID exists.

## 4.3 Phase 3: Certificate Listing and Selection (Optional)
Expand Down Expand Up @@ -333,25 +346,25 @@ The actual process of the certificate selection is not detailed in this RFC, as

During this step of the process, the Signing of the Signer's Document (SD) must be confirmed by the user and the Private Key of the User's Certificate will need to be unlocked (authorized for use), in order to obtain the `Signature Activation Data (SAD)`.

### 4.4.1: Signing Confirmation as Willful Act
### 4.4.1: Signing Confirmation

In order to confirm that the signature approval is a willful act, a second PID Presentation must be requested by the Signing Service:
In order to confirm that the signature approval is a willful act, a second PID and QESAC Presentation must be requested by the Signing Service:

```mermaid
sequenceDiagram
participant User
participant EUDI Wallet
participant Signing Service
Signing Service->>User: PID Presentation Request via OID4VP
EUDI Wallet->>Signing Service: PID Presentation
Signing Service->>User: PID, QESAC Presentation Request via OID4VP
EUDI Wallet->>Signing Service: PID, QESAC Presentation
```

During this step, the Signing Service must confirm that the PID attributes presented exactly match the PID attributes presented in Phase 1. Any deviation should result in the immediate termination of the process.
During this step, the Signing Service must confirm that the PID and QESAC attributes presented exactly match the PID, QESAC attributes presented in Phase 2. Any deviation should result in the immediate termination of the process.

### 4.4.2: Private Key Unlocking (Credential Authorization)

The Signing Service will need to parse the `auth.mode` object of the user's credential to determine the mode of credential authorization:
The Signing Service will need to parse the `auth.mode` object of the user's credential to determine the mode of credential authorization (see `credentials/list` response example in Phase 3). Credential Authorization can support either of the following methods, according to the CSC API Spec:

#### Authorization Code Flow (oauth2code):

Expand Down

0 comments on commit 4343a30

Please sign in to comment.