(Q)EAA issuance and data model #70
Conversation
Co-authored-by: Giuseppe De Marco <[email protected]>
Co-authored-by: Giuseppe De Marco <[email protected]>
docs/en/pid-eaa-data-model.rst
Outdated
| { | ||
| "verified_claims": { | ||
| "verification": { | ||
| "trust_framework": "eidas2", |
docs/en/pid-eaa-issuance.rst
Outdated
| @@ -192,13 +233,13 @@ The JWS payload of the request object is represented below: | |||
| } | |||
|
|
|||
|
|
|||
| **Steps 16-18:** The Wallet Instance creates a new key pair to which the new credential shall be bound. Then, it creates a proof of possession with the new key and the *c_nonce* obtained in **Step 15** and it creates a DPoP proof for the request to the PID credential issuance endpoint. | |||
| **Steps 16-18 (DPoP Proof for Credential Endpoint):** The Wallet Instance creates a new key pair to which the new credential SHALL be bound. Then, it creates a proof of possession with the new key and the *c_nonce* obtained in **Step 15** and it creates a DPoP proof for the request to the PID/(Q)EAA credential issuance endpoint. | |||
There was a problem hiding this comment.
How about using the same previously generated key for DPoP to bind to the new credential? Since both operations take place within seconds of each other, in my opinion, there is no need to generate a new key pair.
There was a problem hiding this comment.
Yes, the evidence I have in mind is that we should not mandate which key should be used, it's up to the wallet solution, the issuer doesn't have the control of this and I would not put any constraints but just a normative SHOULD indicating a good practice to use different keys for different scopes
There was a problem hiding this comment.
In principle, using the same key breaks the key separation principle of using different keys for different purposes. However in this case, I don't see any security issues. I will change in SHOULD as suggested by @peppelinux .
docs/en/pid-eaa-issuance.rst
Outdated
|
|
||
| **Step 19:** The Wallet Instance sends a PID issuance request to the PID Provider credential endpoint. It contains the *access token*, the *DPoP proof*, the *credential type*, the *proof* (proof of possession of the key) and the *format*. | ||
| **Step 19 (Credential Request):** The Wallet Instance sends a PID/(Q)EAA issuance request to the PID/(Q)EAA credential endpoint. It contains the *access token*, the *DPoP proof*, the *credential type*, the *proof* (proof of possession of the key) and the *format*. |
There was a problem hiding this comment.
In fact, here there could be confusion between DPoP proof and proof. See previous tip
Co-authored-by: Giuseppe De Marco <[email protected]>
…-it-docs into QEAA-issuance
| - **organization_name**: Name of the Organization handling the eID used by the User | ||
| - **organization_id**: Identification code for the Organization. It MUST be set to the *IPA Code* of the Organization | ||
| - **organization_name**: Name of the Organization acting as Authentic Source. | ||
| - **organization_id**: Identification code for the Organization. For public Organization, it MUST be set to the *IPA Code*, following the URN namespace ``urn:eudi:it:organization_id:ipa_code:<that-value>``. |
There was a problem hiding this comment.
urn:eudi:it:organization_id:ipa_code:<that-value>
must be included in the expert group sprints, can we do a review of the defined epics and push this accordingly?
Co-authored-by: Giuseppe De Marco <[email protected]>
Title
(Q)EAA issuance and data model
Content
This PR generalized the PID data model and issuance flow to the (Q)EAAs, under the following assumption:
Some editorial improvements are also given to the PID data model and PID issuance.
Review