diff --git a/ewc-rfc005-issue-legal-person-identification-data.md b/ewc-rfc005-issue-legal-person-identification-data.md index da03b3b..60a5220 100644 --- a/ewc-rfc005-issue-legal-person-identification-data.md +++ b/ewc-rfc005-issue-legal-person-identification-data.md @@ -172,10 +172,10 @@ Not included in the diagram is the revocation information that must be published 3. Authorization request. The PID provider wallet requests the Client wallet for WIA, WTE, PID using the endpoint either submitted by the natural person in the first step or by information in the redirect url if the LPID process started in a wallet application with a redirect. 4. Authorization response. Client wallet returns presentations of WTE, WIA, (PID). 5. Authorization request. Client wallet requests WIA and PID from PID provider wallet. -6. Authorization response. PID provider wallet returs presentations of PID and WIA. -7. PID provider wallet requests information from VDR for verifiacation and validation. +6. Authorization response. PID provider wallet returns presentations of PID and WIA. +7. PID provider wallet requests information from VDR for verification and validation. 8. VDR returns requested information. -9. Client wallet requests information from VDR for verifiacation and validation. +9. Client wallet requests information from VDR for verification and validation. 10. VDR returns requested information. 11. PID provider wallet verifies and validates presentations and issuer of WTE and WIA (and PID). 12. Client wallet verifies and validates presentations and issuer of WIA and LPID. @@ -317,52 +317,6 @@ Upon resolving the well-known endpoints, the **identity provider** responds with ``` -> [!NOTE] -> In order to support all EBSI conformant wallets, the following format for the response is also valid, but **optional** to be supported: - -```json -{ - "credential_issuer": "https://identity-provider.gov", - "authorization_server": "https://identity-provider.gov", - "credential_endpoint": "https://identity-provider.gov/credential", - "deferred_credential_endpoint": "https://identity-provider.gov/credential_deferred", - "display": { - "name": "Government Identity Provider", - "location": "Country", - "locale": "en-GB", - "cover": { - "url": "https://identity-provider.gov/cover.jpeg", - "alt_text": "Government Identity Provider" - }, - "logo": { - "url": "https://identity-provider.gov/logo.jpg", - "alt_text": "Government Identity Provider" - }, - "description": "For inquiries about how we manage your personal identification data, please contact our Data Protection Officer." - }, - "credentials_supported": [ - { - "format": "jwt_vc", - "types": [ - "VerifiableCredential", - "PersonIdentificationData" - ], - "trust_framework": { - "name": "ewc-issuer-trust-list", - "type": "Accreditation", - "uri": "Link to the trust framework accreditation" - }, - "display": [ - { - "name": "Person Identification Data", - "locale": "en-GB" - } - ] - } - ] -} -``` - Once the well-known endpoint for **authorisation server** configuration is resolved, the response is as given below: ```json @@ -430,8 +384,6 @@ Once the well-known endpoint for **authorisation server** configuration is resol ] } ``` -Currently, we retain the trust framework specified by EBSI. Subsequently, we will specify an additional RFC defining the EWC trusted issuer list. - ## 5.3 Credential offer For LPID credential issuance, the member state LPID issuer will adopt RFC001 for credential offer pre-authorised code flow, using the credential_offer_uri parameter as shown below: @@ -461,34 +413,6 @@ On resolving the `credential_offer_uri` query parameter, the issuer responds wit } ``` -> [!NOTE] -> To ensure compatibility with all wallets conforming to the European Blockchain Services Infrastructure (EBSI) standards, the following response format is also valid but **optional** to support: - -```json -{ - "credential_issuer": "https://identity-provider.gov", - "credentials": [ - { - "format": "jwt_vc", - "types": [ - "VerifiableCredential", - "PersonIdentificationData" - ], - "trust_framework": { - "name": "ewc-issuer-trust-list", - "type": "Accreditation", - "uri": "Link to the trust framework accreditation" - } - } - ], - "grants": { - "authorization_code": { - "issuer_state": "eyJhbGciOiJSU0Et...FYUaBy" - } - } -} -``` - The holder's wallet retrieves this JSON response and processes it accordingly. The format of the credential (e.g., jwt_vc, vc+sd-jwt) is specified, focusing on the LPID. This process ensures that the credential issuance aligns with the stringent requirements for LPID within the EWC ecosystem. For the pre-authorized flow, the credential response format is adapted to include the necessary grants for LPID issuance: @@ -541,7 +465,7 @@ GET https://identity-provider.gov/auth/authorize? Host: https://identity-provider.gov ``` -Query params for the authorisation request are given below: +Query parameters for the authorisation request are given below:
authorization_details
|
- As specified in OAuth 2.0 Rich Authorization Requests specification to specify fine-grained access [4]. An example is as given below: - - ```json - { - "type": "openid_credential", - "locations": [ - "https://credential-issuer.example.com" - ], - "format": "jwt_vc_json", - "credential_definition": { - "type": [ - "VerifiableCredential", - "PersonIdentificationData" - ] - } - } - ``` - > [!NOTE] - > You may also use the earlier version as supported by EBSI. - - ```json - { - "format": "jwt_vc", - "locations": [ - "https://issuer.example.com" - ], - "type": "openid_credential", - "types": [ - "VerifiableCredential", - "VerifiableAttestation", - "PersonIdentificationData" - ] - } - ``` + | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Attribute | -Data element identifier | -Definition | -Presence (Mandatory/Optional) | -Proposition | +||||
Attribute identifier | +Definition | +Attribute identifier Definition Comment and example | +Encoding format | |||||
---|---|---|---|---|---|---|---|---|
LegalPersonIdentifier | -legal_person_identifier | -Unique id for legal persons | -M | -EUID* | +legal_person_id | +Unique id for organisations in EUID structure (see example). | +
+ The EUID is an existing unique id for legal persons, regulated in COMMISSION IMPLEMENTING REGULATION (EU) 2015/884 and later replaced with COMMISSION IMPLEMENTING REGULATION (EU) 2021/1042 section 9, and is defined as this technical structure: +<Country code><Business register code>.<Domestic registration number>_<optional validation character>
+ Examples: +
|
+ string |
LegalPersonName | legal_person_name | -Name of the legal person | -M | -One statutory name | +Official current legal person name(s) as registered in the business register | +Can be several names in some countries. + Ex: Royal Ravintolat Oy, Pizzeria Luca (same legal person id, two officially registered names). + | +string |
Attribute | -Data element identifier | -Definition | -Presence (Mandatory/Optional) | -Comments | +||||
Attribute identifier | +Definition | +Attribute identifier Definition Comment and example | +Encoding format | |||||
---|---|---|---|---|---|---|---|---|
Issuer Name | -issuer_name | -Name of the issuer derived from the MS that has issued the LPID. | -M | -E.g. Bolagsverket | +issuing_authority | +Name of the administrative authority that has issued this LPID instance, or the ISO 3166 Alpha-2 country code of the respective Member State if there is no separate authority authorized to issue LPIDs. | +Ex: Bolagsverket | +string |
Issuer id | -issuer_id | -Id of the issuer | -M | -EUID of issuer or did | +issuing_authority_id | +EUDI of the issuing authority | +Ex: SEBOLREG.5560678965 | +string |
Issuer trusted list/VDR | -TBD | -Location for verification information of issuer. | -M | -+ | issuing_country | +Alpha-2 country code, as defined in ISO 3166-1, of the PID Provider’s country or territory. | +Ex: SE | +string |
Issuing country | -issuing_country | -Alpha-2 country code as defined in ISO 3166-1 of the issuing country or territory. | -M | -+ | issuing_jurisdiction | +Country subdivision code of the jurisdiction that issued the PID, as defined in ISO 3166-2:2020, Clause 8. The first part of the code SHALL be the same as the value for issuing_country. | ++ | string |
Issuing date | issuance_date | -Date and time when the LPID was issued. | -M | -+ | Date (and possibly time) when the PID was issued. | ++ | date-time or full-date | |
Date of expiration | expiry_date | -Date and time when the LPID expires. | -M | -+ | Date (and possibly time) when the PID will expire | ++ | date-time or full-date | |
Schema id | -TBD | -Id of the schema the LPID is based on. | -M | -+ | schema_id | +ID to find information about the structure of the LPID | ++ | string |
Schema version | -TBD | -The version of the schema the LPID is based on. | -M | -+ | schema_version | +Information about the version of a schema used for validation of the LPID | ++ | number |
Schema location | -TBD | -The location for schema verification information. | -M | -+ | schema_location | +Location to access schema for LPID | ++ | string |
Revocation id | -TBD | -Information used for validation of LPID. | -M | -+ | ||||
revocation_id | +Unique index in the revocation list | ++ | string | |||||
Revocation list location | -TBD | -The location for revocation information for the LPID. | -M | -+ | ||||
revocation_location | +Location to access revocation information | ++ | string | |||||
Authentic source | -TBD | -The authentic source for the attributes in the LPID. | -M | -+ | ||||
authentic_source_id | +EUID for the public sector body or private entity responsible for an authentic source that is a repository or system, considered to be the primary source of information or recognized as authentic in national law. | +Can be different from issuing_authority. + Optional + |
+ string | +|||||
authentic_source_name | +Name of the public sector body or private entity responsible for an authentic source that is a repository or system, considered to be the primary source of information or recognized as authentic in national law. | +Optional | +string |