1.1 EFC specific scope<\/b><\/p>\n
ISO 17573 defines the roles and functions as well as the internal and external entities of the EFC system environment. Based on the system architecture defined in ISO 17573, the security framework describes a set of requirements and security measures for stakeholders to implement and operate their part of an EFC system as required for a trustworthy environment according to its basic information security policy. In general, the overall scope is an information security framework for all organisational and technical entities and in detail for the interfaces between them.<\/p>\n
Figure 3 below illustrates the abstract EFC system model used to analyse the threats, define the security requirements and security measures of this Technical Specification. This Technical Specification is based on the assumption of an OBE which is dedicated to EFC purposes only and neither considers value added services based on EFC OBE, nor more generic OBE platforms (called in-vehicle ITS Stations) used to host the EFC application.<\/p>\n
The trust model comprises all basic assumptions and principles for establishing trust between the stakeholders. The trust model forms the basis for the implementation of cryptographic procedures to ensure confidentiality, integrity, authenticity and partly non-repudiation of exchanged data.<\/p>\n
The scope of this security framework comprises the following:<\/p>\n
general information security objectives of the stakeholders;<\/p>\n<\/li>\n
threat analysis;<\/p>\n<\/li>\n
definition of a trust model;<\/p>\n<\/li>\n
security requirements;<\/p>\n<\/li>\n
security measures \u2013 countermeasures;<\/p>\n<\/li>\n
security specifications for interface implementation;<\/p>\n<\/li>\n
key management;<\/p>\n<\/li>\n
security policies;<\/p>\n<\/li>\n
privacy-enabled implementations.<\/p>\n<\/li>\n<\/ul>\n
The following is outside the scope of this Technical Specification:<\/p>\n
a complete risk assessment for an EFC system;<\/p>\n<\/li>\n
security issues rising from an EFC application running on an ITS station;<\/p>\n<\/li>\n<\/ul>\n
\nNOTE Security issues associated with an EFC application running on an ITS station will be covered in a CEN Technical Report on “Guidelines for EFC-applications based on in vehicle ITS Stations” that is being developed at the time of publication of this document.<\/p>\n<\/blockquote>\n
\n
- \n
entities and interfaces of the interoperability management role;<\/p>\n<\/li>\n
- \n
the technical trust relation of the model between TSP and User;<\/p>\n<\/li>\n
- \n
a complete specification and description of all necessary security measures to all identified threats;<\/p>\n<\/li>\n
- \n
concrete implementation specifications for implementation of security for EFC system, e.g. European electronic toll service (EETS);<\/p>\n<\/li>\n
- \n
detailed specifications required for privacy-friendly EFC implementations.<\/p>\n<\/li>\n<\/ul>\n
The detailed scope of the bullet points and the clause with the corresponding content is given below:<\/p>\n
\n
- \n
General information security objectives of the stakeholders (informative, Annex C)<\/p>\n
To derive actual security requirements and define implementations, it is crucial to gain a common understanding of the possible different perspectives and objectives of such stakeholders of a toll charging environment.<\/p>\n<\/li>\n
- \n
Threat analysis (informative, Annex D)<\/p>\n<\/li>\n<\/ul>\n
The threat analysis is the basis and motivation for all the security requirements resulting in this framework. The results from two complementary approaches will be combined in one common set of requirements. The first approach considers a number of threat scenarios from the perspective of various attackers. The second approach looks in depth on threats against the various identified assets (tangible and intangible entities).<\/p>\n
\n
- \n
Definition of a trust model (normative, Clause 5)<\/p>\n<\/li>\n<\/ul>\n
The trust model comprises all basic assumptions and principles for establishing trust between the stakeholders. The trust model forms the basis for the implementation of cryptographic procedures to ensure confidentiality, integrity, authenticity and partly non-repudiation of exchanged data.<\/p>\n
\n
- \n
Security requirements (normative, Clause 6)<\/p>\n<\/li>\n<\/ul>\n
Based on the threat analysis, security requirements are defined (e.g. for organisational and technical entities, interfaces, information etc) from which a system operator can draw its own applicable set according to the actual security policy. No concrete implementation specifications will be given as they are strongly dependent on the actual context of the toll charging environment and the relations between the stakeholders. A basic risk analysis of the interfaces shown in Figure 4 introduces the minimum set of security requirements for the protection of these interfaces.<\/p>\n
\n
- \n
Security measures – countermeasures (normative, Clause 7)<\/p>\n<\/li>\n<\/ul>\n
A set of security measures mainly for data protocol layer of interfaces according to Figure 4 based on the requirements is defined to support actual EFC system implementations and as a base for the security specifications for interoperable interface implementation.<\/p>\n
\n
- \n
Security specifications for interface implementation (normative, Clause 8)<\/p>\n<\/li>\n<\/ul>\n
To support the future implementation of (interoperable) toll charging environments, this specification provides precise implementation specifications for the interfaces, e.g. the detailed definition of message authenticators. These specifications represent an add-on for security to the corresponding standards. Figure 4 shows the relevant interfaces and the corresponding standards which need to be enhanced by proper security provisions.<\/p>\n
\n
- \n
Key management (normative, Clause 9)<\/p>\n<\/li>\n<\/ul>\n
The toll charging environment uses cryptographic elements (keys, certificates, revocation lists etc) to support security services like confidentiality, authenticity, integrity and non-repudiation. This section of thespecification covers the initial setup of key exchange between stakeholders and several operational procedures like key renewal, certificate revocation etc.<\/p>\n
specification covers the initial setup of key exchange between stakeholders and several operational procedures like key renewal, certificate revocation etc.<\/p>\n
\n
- \n
Implementation conformance statement (ICS) proforma (Annex B)<\/p>\n<\/li>\n<\/ul>\n
Annex B defines the implementation conformance statement proforma to be used by an equipment supplier, a system implementation or an actor of a role declaring his conformity to this Technical Specification.<\/p>\n
\n
- \n
Security policies (informative, Annex E and Annex F)<\/p>\n<\/li>\n<\/ul>\n
As an aid for using this Technical Specification to build up a secure system, some examples are provided of what security policies could look like for a concrete interoperability framework (including European electronic toll service).<\/p>\n
\n
- \n
Privacy-enabled implementations (informative, Annex G)<\/p>\n<\/li>\n<\/ul>\n
Respecting privacy is crucial for the implementation of every toll charging environment. However, different Toll Chargers may have different requirements on the level of privacy. This Technical Specification supports implementations with respect to privacy, but does not mandate one specific implementation. Therefore, it summarises the general requirements and conditions in relation to data privacy.<\/p>\n
1.2 Scope in relation to other security frameworks<\/b><\/p>\n
In general the overall scope is an information security framework for all organisational and technical entities of an EFC environment and in detail for the interfaces between them. This Technical Specification covers only the EFC specific aspects and not general IT security aspects. A general and complete IT security guideline, the Information Security Management System, is provided in the ISO 2700x family of standards.<\/p>\n
A corresponding ISO\/IEC 27001 certification of a TC or Toll Service Provider (TSP) organisation may be used to demonstrate fulfilment of this Technical Specification provided that the scope and the Statements of Applicability (SoA) include the EFC business processes specified in ISO 17573 and the security measures provided by this Technical Specification are applied, e.g. by using them as part of the so-called catalogues containing the security measures and control objectives.<\/p>\n
PDF Catalog<\/h4>\n
\n
\n PDF Pages<\/th>\n PDF Title<\/th>\n<\/tr>\n \n 3<\/td>\n CEN\/TC 278
CEN\/TS 16439:2012
CEN\/TC 278
Electronic fee collection \u2014 Security framework
ICS: <\/td>\n<\/tr>\n\n 9<\/td>\n 0 Introduction
0.1 Reader’s guide <\/td>\n<\/tr>\n\n 10<\/td>\n 0.2 EFC role model <\/td>\n<\/tr>\n \n 11<\/td>\n 0.3 Relation to other security standards <\/td>\n<\/tr>\n \n 13<\/td>\n 1 Scope
1.1 EFC specific scope <\/td>\n<\/tr>\n\n 16<\/td>\n 1.2 Scope in relation to other security frameworks <\/td>\n<\/tr>\n \n 17<\/td>\n 2 Normative references <\/td>\n<\/tr>\n \n 18<\/td>\n 3 Terms and definitions <\/td>\n<\/tr>\n \n 24<\/td>\n 4 Symbols and abbreviations <\/td>\n<\/tr>\n \n 26<\/td>\n 5 Trust model
5.1 Introduction
5.2 Stakeholders trust relations <\/td>\n<\/tr>\n\n 27<\/td>\n 5.3 Technical trust model
5.3.1 General
5.3.2 Trust model for TC and TSP relations <\/td>\n<\/tr>\n\n 29<\/td>\n 5.3.3 Trust model for TSP and User relations
5.3.4 Trust model for Interoperability Management relations
5.4 Implementation
5.4.1 Setup of trust relations
5.4.2 Trust relation renewing and revocation <\/td>\n<\/tr>\n\n 30<\/td>\n 5.4.3 Issuing and revocation of sub CA and entity certificates
5.4.4 Certificate and Certificate Revocation List profile and format
5.4.5 Certificate extensions <\/td>\n<\/tr>\n\n 31<\/td>\n 6 Security requirements
6.1 Introduction
6.2 Information Security Management System <\/td>\n<\/tr>\n\n 32<\/td>\n 6.3 Communication interfaces
6.3.1 General <\/td>\n<\/tr>\n\n 33<\/td>\n 6.3.2 Generic interface requirements
6.3.3 DSRC profile <\/td>\n<\/tr>\n\n 34<\/td>\n 6.3.4 TC to TSP profile
6.3.5 Communication provider profile <\/td>\n<\/tr>\n\n 35<\/td>\n 6.4 Data storages
6.4.1 General
6.4.2 OBE data storages
6.4.3 RSE data storages <\/td>\n<\/tr>\n\n 36<\/td>\n 6.4.4 Back End data storage
6.5 Toll Charger <\/td>\n<\/tr>\n\n 37<\/td>\n 6.6 Toll Service Provider <\/td>\n<\/tr>\n \n 39<\/td>\n 6.7 User <\/td>\n<\/tr>\n \n 40<\/td>\n 6.8 Interoperability Management
6.9 Limitation of requirements
7 Security measures – countermeasures
7.1 Introduction <\/td>\n<\/tr>\n\n 41<\/td>\n 7.2 General security measures
7.3 Communication interfaces security measures
7.3.1 General
7.3.2 DSRC-EFC interface <\/td>\n<\/tr>\n\n 42<\/td>\n 7.3.3 CCC interface
7.3.4 LAC interface <\/td>\n<\/tr>\n\n 43<\/td>\n 7.3.5 Front End to TSP Back End interface
7.3.6 TC to TSP interface
7.4 End-to-end security measures <\/td>\n<\/tr>\n\n 45<\/td>\n 7.5 Toll Service Provider security measures
7.5.1 Front End security measures
7.5.2 Back End security measures <\/td>\n<\/tr>\n\n 46<\/td>\n 7.6 Toll Charger security measures
7.6.1 RSE security measures
7.6.2 Back End security measures
7.6.3 Other TC security measures <\/td>\n<\/tr>\n\n 47<\/td>\n 8 Security specifications for interoperable interface implementation
8.1 General
8.1.1 Subject
8.1.2 Signature and hash algorithms
8.1.3 MAC algorithm <\/td>\n<\/tr>\n\n 48<\/td>\n 8.1.4 MAC key derivation
8.1.5 Key encryption algorithm
8.1.6 Padding algorithm
8.2 Security specifications for DSRC-EFC
8.2.1 Subject
8.2.2 OBE <\/td>\n<\/tr>\n\n 49<\/td>\n 8.2.3 RSE
8.3 Security specifications for CCC
8.3.1 Subject
8.3.2 OBE
8.3.3 RSE
8.4 Security specifications for LAC
8.4.1 Subject
8.4.2 OBE
8.4.3 RSE <\/td>\n<\/tr>\n\n 50<\/td>\n 8.5 Security specifications for Front End to TSP interface
8.5.1 General
8.5.2 ChargeReport message authentication <\/td>\n<\/tr>\n\n 51<\/td>\n 8.6 Security specifications for TC to TSP interface
8.6.1 General
8.6.2 Secure communication channel
8.6.3 Message authentication <\/td>\n<\/tr>\n\n 53<\/td>\n 8.6.4 Proof of message delivery
8.6.5 TSP ChargeReport authentication <\/td>\n<\/tr>\n\n 54<\/td>\n 9 Key management
9.1 Introduction
9.2 Asymmetric keys
9.2.1 Key exchange between stakeholders
9.2.2 Key generation and certification <\/td>\n<\/tr>\n\n 55<\/td>\n 9.2.3 Protection of Keys
9.2.4 Application
9.3 Symmetric keys
9.3.1 Introduction
9.3.2 Key exchange between stakeholders <\/td>\n<\/tr>\n\n 56<\/td>\n 9.3.3 Key lifecycle
9.3.3.1 General
9.3.3.2 DSRC keys <\/td>\n<\/tr>\n\n 57<\/td>\n 9.3.3.3 MAC keys <\/td>\n<\/tr>\n \n 58<\/td>\n 9.3.4 Key storage and protection
9.3.4.1 Master keys
9.3.4.2 OBE keys <\/td>\n<\/tr>\n\n 59<\/td>\n 9.3.5 Session keys <\/td>\n<\/tr>\n \n 60<\/td>\n Annex A (normative) Data type specification <\/td>\n<\/tr>\n \n 64<\/td>\n Annex B (normative) Implementation Conformance Statement (ICS) proforma
B.1 Guidance for completing the ICS proforma
B.1.1 Purposes and structure
B.1.2 Abbreviations and conventions <\/td>\n<\/tr>\n\n 66<\/td>\n B.1.3 Instructions for completing the ICS proforma
B.2 Identification of the implementation
B.2.1 General
B.2.2 Date of the statement
B.2.3 Implementation Under Test (IUT) identification <\/td>\n<\/tr>\n\n 67<\/td>\n B.2.4 System Under Test (SUT) identification
B.2.5 Product supplier <\/td>\n<\/tr>\n\n 68<\/td>\n B.2.6 Applicant (if different from product supplier)
B.2.7 ICS contact person <\/td>\n<\/tr>\n\n 69<\/td>\n B.3 Identification of the standard
B.4 Global statement of conformance
B.5 Roles
B.6 Trust Model functionalities <\/td>\n<\/tr>\n\n 70<\/td>\n B.7 Profiles
B.8 Requirements <\/td>\n<\/tr>\n\n 73<\/td>\n B.9 Security measures <\/td>\n<\/tr>\n \n 76<\/td>\n B.10 Specifications for interoperable interfaces security <\/td>\n<\/tr>\n \n 78<\/td>\n Annex C (informative) Stakeholder objectives and generic requirements
C.1 Introduction <\/td>\n<\/tr>\n\n 79<\/td>\n C.2 Toll Chargers
C.2.1 Toll chargers and their main interests
C.2.2 Security service requirements for a Toll Charger <\/td>\n<\/tr>\n\n 80<\/td>\n C.3 Toll Service Providers
C.3.1 Toll service providers and their main interests
C.3.2 Security service requirements for a Toll Service Provider <\/td>\n<\/tr>\n\n 81<\/td>\n C.4 Users
C.4.1 Users and their main interests
C.4.2 Users requirements
C.5 Interoperability Management
C.5.1 Interoperability management and its main interests <\/td>\n<\/tr>\n\n 82<\/td>\n C.5.2 Security service requirements for interoperability management <\/td>\n<\/tr>\n \n 83<\/td>\n Annex D (informative) Threat analysis
D.1 General introduction
D.2 Attack trees based threat analysis
D.2.1 Introduction <\/td>\n<\/tr>\n\n 84<\/td>\n D.2.2 System model <\/td>\n<\/tr>\n \n 85<\/td>\n D.2.3 Presentation of attack trees <\/td>\n<\/tr>\n \n 86<\/td>\n D.2.4 Attacker class 1: User
D.2.4.1 General
D.2.4.2 Intention: Avoiding payment of toll <\/td>\n<\/tr>\n\n 88<\/td>\n D.2.4.3 Intention: Foiling the system
D.2.4.4 Intention: Protecting the Users own privacy
D.2.5 Attacker class 2: Toll Service Provider
D.2.5.1 General <\/td>\n<\/tr>\n\n 89<\/td>\n D.2.5.2 Intention: Increase revenue from customer \/ overcharge customer
D.2.5.3 Intention: Profiling of customer
D.2.5.4 Intention: Resale of data about customers <\/td>\n<\/tr>\n\n 90<\/td>\n D.2.5.5 Intention: Reduction in payments to Toll Charger <\/td>\n<\/tr>\n \n 91<\/td>\n D.2.5.6 Intention: To allow the use of cheaper (substandard) equipment
D.2.6 Attacker class 3: Toll Charger
D.2.6.1 General
D.2.6.2 Intention: To increase revenue <\/td>\n<\/tr>\n\n 92<\/td>\n D.2.6.3 Intention: To resell user data for revenue <\/td>\n<\/tr>\n \n 93<\/td>\n D.2.7 Attacker class 4: Hacker
D.2.7.1 General
D.2.7.2 Intention: To demonstrate a system vulnerability <\/td>\n<\/tr>\n\n 94<\/td>\n D.2.7.3 Intention: To obtain respect amongst their peers <\/td>\n<\/tr>\n \n 95<\/td>\n D.2.7.4 Intention: To Improve understanding of the system or to research its operation
D.2.7.5 Intention: Provide fake OBE <\/td>\n<\/tr>\n\n 96<\/td>\n D.2.8 Attacker class 5: Activist
D.2.8.1 General
D.2.8.2 Intention: Societal destabilisation through manipulation of the tolling system <\/td>\n<\/tr>\n\n 97<\/td>\n D.2.8.3 Intention: Raise in profile of the activists cause
D.2.8.4 Intention: Direct furthering of activists cause
D.2.8.5 Intention: Reduction in credibility of the system
D.2.9 Attacker class 6: Communication provider
D.2.9.1 General
D.2.9.2 Intention: Increase network utilisation <\/td>\n<\/tr>\n\n 98<\/td>\n D.2.9.3 Intention: Decrease network utilisation
D.2.9.4 Intention: Collecting travel behaviour
D.2.10 Attacker class 7: Enterprise
D.2.10.1 General <\/td>\n<\/tr>\n\n 99<\/td>\n D.2.10.2 Intention: Movement tracking
D.2.10.3 Intention: Creation and distribution of cloned equipment
D.2.10.4 Intention: Disable\/compromise system encryption <\/td>\n<\/tr>\n\n 100<\/td>\n D.2.10.5 Intention: Steal equipment
D.2.10.6 Intention: Extortion <\/td>\n<\/tr>\n\n 101<\/td>\n D.2.11 Attacker class 8: Government
D.2.11.1 General
D.2.11.2 Intention: In theatre commercial advantage
D.2.11.3 Intention: Political targeting of individuals and organisations <\/td>\n<\/tr>\n\n 102<\/td>\n D.2.11.4 Intention: Tracking of Individuals <\/td>\n<\/tr>\n \n 103<\/td>\n D.2.12 Attacker class 9: Foreign power
D.2.12.1 General
D.2.12.2 Intention: Societal destabilisation
D.2.12.3 Intention: Movement tracking
D.2.12.4 Intention: Extortion <\/td>\n<\/tr>\n\n 104<\/td>\n D.2.12.5 Intention: International prestige
D.3 Asset based threat analysis
D.3.1 General
D.3.2 Threatened Assets <\/td>\n<\/tr>\n\n 106<\/td>\n D.3.3 Compliance matrix <\/td>\n<\/tr>\n \n 108<\/td>\n D.3.4 Presentation of threats <\/td>\n<\/tr>\n \n 109<\/td>\n D.3.5 Generic threats
D.3.5.1 Information assets <\/td>\n<\/tr>\n\n 110<\/td>\n D.3.5.2 Infrastructure assets <\/td>\n<\/tr>\n \n 111<\/td>\n D.3.6 Asset: Billing details <\/td>\n<\/tr>\n \n 112<\/td>\n D.3.7 Asset: OBE Charge Report <\/td>\n<\/tr>\n \n 113<\/td>\n D.3.8 Asset: Customisation information
D.3.9 Asset: User contract information <\/td>\n<\/tr>\n\n 114<\/td>\n D.3.10 Asset: Exception List
D.3.11 Asset: “Help, info, complain” <\/td>\n<\/tr>\n\n 115<\/td>\n D.3.12 Asset: OBE <\/td>\n<\/tr>\n \n 117<\/td>\n D.3.13 Asset: User privacy
D.3.14 Asset: RSE <\/td>\n<\/tr>\n\n 118<\/td>\n D.3.15 Asset: EFC stakeholders image and reputation <\/td>\n<\/tr>\n \n 119<\/td>\n D.3.16 Asset: TC and TSP central system
D.3.17 Asset: Transit information <\/td>\n<\/tr>\n\n 120<\/td>\n D.3.18 Asset: Trust object <\/td>\n<\/tr>\n \n 122<\/td>\n D.3.19 Asset: User identification
D.3.20 Asset: Context Data <\/td>\n<\/tr>\n\n 123<\/td>\n D.3.21 Asset: Payment means <\/td>\n<\/tr>\n \n 124<\/td>\n D.3.22 Asset: Limited autonomy
D.3.23 Asset: EFC Schema <\/td>\n<\/tr>\n\n 125<\/td>\n D.3.24 Asset: Contractual conditions <\/td>\n<\/tr>\n \n 126<\/td>\n D.3.25 Asset: Operational rules <\/td>\n<\/tr>\n \n 127<\/td>\n D.3.26 Asset: Complaint <\/td>\n<\/tr>\n \n 129<\/td>\n D.3.27 Asset: Certification <\/td>\n<\/tr>\n \n 130<\/td>\n D.3.28 Asset: Operational report <\/td>\n<\/tr>\n \n 131<\/td>\n Annex E (informative) Security Policies
E.1 Introduction
E.1.1 Scope of the annex
E.1.2 Motivation for the need of security policies
E.2 Example EFC scheme security policy
E.2.1 Motivation for information security <\/td>\n<\/tr>\n\n 132<\/td>\n E.2.2 Purpose of the security policy
E.2.3 Scope <\/td>\n<\/tr>\n\n 134<\/td>\n E.2.4 Policy statements
E.2.4.1 General
E.2.4.2 General policy statements <\/td>\n<\/tr>\n\n 135<\/td>\n E.2.4.3 Organisation of information security
E.2.4.4 Asset management <\/td>\n<\/tr>\n\n 136<\/td>\n E.2.4.5 Violations and sanctions
E.2.4.6 Review and evaluation
E.2.4.7 Audits
E.3 Development of operators security policies
E.3.1 General <\/td>\n<\/tr>\n\n 137<\/td>\n E.3.2 Interface requirements
E.3.3 Data storage requirements <\/td>\n<\/tr>\n\n 138<\/td>\n Annex F (informative) Example for an EETS Security Policy
F.1 Introduction
F.2 Basic laws and regulations
F.3 Organisation of EETS Information Security
F.3.1 General
F.3.2 Steering Committee
F.3.3 Trust Model <\/td>\n<\/tr>\n\n 140<\/td>\n Annex G (informative) Requirements on privacy-focused implementation
G.1 Introduction
G.2 Legal basis
G.2.1 EU Directive 95\/46\/EC
G.2.2 European data protection supervisor (EDPS) <\/td>\n<\/tr>\n\n 141<\/td>\n G.3 Users\u2019 requirements <\/td>\n<\/tr>\n \n 142<\/td>\n Bibliography <\/td>\n<\/tr>\n<\/table>\n","protected":false},"excerpt":{"rendered":" Electronic fee collection. Security framework<\/b><\/p>\n
\n\n
\n Published By<\/td>\n Publication Date<\/td>\n Number of Pages<\/td>\n<\/tr>\n \n BSI<\/b><\/a><\/td>\n 2013<\/td>\n 146<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"featured_media":230919,"template":"","meta":{"rank_math_lock_modified_date":false,"ep_exclude_from_search":false},"product_cat":[698,2641],"product_tag":[],"class_list":{"0":"post-230912","1":"product","2":"type-product","3":"status-publish","4":"has-post-thumbnail","6":"product_cat-35-240-60","7":"product_cat-bsi","9":"first","10":"instock","11":"sold-individually","12":"shipping-taxable","13":"purchasable","14":"product-type-simple"},"_links":{"self":[{"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/product\/230912","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/product"}],"about":[{"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/types\/product"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/media\/230919"}],"wp:attachment":[{"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/media?parent=230912"}],"wp:term":[{"taxonomy":"product_cat","embeddable":true,"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/product_cat?post=230912"},{"taxonomy":"product_tag","embeddable":true,"href":"https:\/\/pdfstandards.shop\/wp-json\/wp\/v2\/product_tag?post=230912"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}