[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Feedback on DSS-core v2.0
Hello, I've found some issues some inconsistencies with the XML and their respective JSON and OpenApi (aka Swagger) definitions available here: https://docs.oasis-open.org/dss-x/dss-core/v2.0/cs01/schema/ 1. The transformation of XML-Choice loses information In the XML-Schema, SignatureObjectType consists of a compulsory XML-Choice (elements Base64Signature and SignaturePtr) und two optional elements (SchemaRefs and WhichDoc). In the JSON-Schema, dss2-SignatureObjectType declares four properties and otherwise only requires the existance of at least one property. That means a JSON object with only 'schemaRefs' or 'whichDoc' will satisfy this definition, which does not correspond to the XML-schema. This problem does not appear where the XML-Choice is the sole child element of a complex type, such as UseVerificationTimeType, AdditionalKeyInfoType, KeySelectorType. The JSON-definition of the following types containing choices are also transformed with information loss: SignaturePlacementType, Base64DataType. I can imagine that one solution would be to introduce a dedicated type that only contains the respective choice, and to use it. 2. Element name capitalization There seems to be some problem with prefixes. When I look for XML element names that do not strictly follow PascalCase naming convention, but have a fully capitalized prefix (such as XPath; OCSPResponse in AdditionalKeyInfoType, but not X509Digest), I can find two candidate properties in the corresponding JSON definition instead of the expected one. For example: dsb-SignaturePtrType, dsigrw-TransformType (XPath as xpath and xPath), dss2-SignaturePlacementType (XPathAfter as xpathAfter and xPathAfter; XPathFirstChildOf as xpathFirstChildOf and xPathFirstChildOf), dss2-AdditionalKeyInfoType (OCSPResponse as ocspresponse and ocsp). 3. Numbers in element names. Numbers in element names lead to seemingly arbitrary property names in the corresponding JSON schema, where an entire prefix and/or suffix is dropped in the corresponding JSON schema. For example: DetailType contains the element Base64Content, dss2-DetailType has the property b64Content. Another example: AdditionalKeyInfoType contains X509Digest, X509SubjectName, X509SKI, X509Certificate, X509CRL; dss2-AdditionalKeyInfoType has x509Digest, sub, ski, cert, name, crl. Sub-note: this may be related to the previous issue 2., as both sub and name correspond to X509SubjectName. This issue should otherwise not lead to problems when using the schemas, as long as a lossless transformation exists (every JSON schema property maps only to a single XML-schema element), but a reader of the JSON and XML schemas should still be aware of this. Â 3. Date/Date-time The JSON schema and Swagger schema are consistent in their modelling of date-time: Swagger: https://swagger.io/docs/specification/data-models/data-types/#string JSON schema draft 4 validation: https://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-7.3.1 JSON schema latest validation: https://json-schema.org/latest/json-schema-validation.html#rfc.section.7.3.1 That is, time is represented as a string with a specific format. The JSON schema declaration looks like this: Â type: 'string' Â format: 'date-time' Instead, dss-core consistently employs the following: Â type: 'number' Â format: 'utc-millisec' The use of number instead of string does not conform to the standard. While a lossless transformation is possible, I would like to point out that this is a custom, non-standard declaration that may not always be supported by the employable tools. 4. Binary content The SimpleContent declaration is consistently mapped to an optional property in the JSON schema. Strictly speaking, this leads to a different semantic expressiveness in the resulting JSON schema. Consider a valid XML instance of X509DigestType - it's content is always present, but possible empty. However, a JSON object instance of dss2-X509DigestType may have no value property, or it's property 'value' may contain the empty string. Both JSON objects are valid but not necessarily or obviously equivalent. 5. xs:anyURI as a formatted string JSON schema and swagger support declaring strings with URI formatting. Swagger: https://swagger.io/docs/specification/data-models/data-types/#string JSON schema draft 4 validation: https://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-7.3.6 JSON schema latest validation: https://json-schema.org/latest/json-schema-validation.html#rfc.section.7.3.5 Random sampling of xs:anyURI in the DSS-X definitions makes it obvious that this information is often lost in the corresponding JSON schema. For example, DetailType has the anyURI-typed element Code and attribute Type, but only type keeps the uri formatting after the transformation. Another example: none of the attributes of DocumentBaseType keep their URI type. Regards, Neil -- ########################################################### 22.03.19 â BSI zertifiziert Open eCard - erster Open Source âeID-Kernelâ https://openecard.org/v1.3-vom-BSI-gemaess-TR-03124-zertifiziert ########################################################### 08.01.19 â identity AG setzt fÃr eIDAS auf Open eCard Technologie https://openecard.org/identity-AG-setzt-fÃr-eIDAS-auf-Open-eCard ########################################################### 13.12.18 â SkIDentity ermÃglicht go.eIDAS in nur zwei Minuten https://skidentity.de/ermoeglicht-go.eIDAS-in-nur-2-Minuten ########################################################### 04.12.18 â Open eCard wird mobil und unterstÃtzt eIDAS https://openecard.org/wird-mobil-und-unterstuetzt-eIDAS ########################################################### 27.09.18 â ecsec unterstÃtzt go.eIDAS-Initiative https://ecsec.de/unterstuetzt-go.eIDAS ########################################################### 14.08.18 â ecsec unterstÃtzt vertrauenswÃrdige Digitalisierung https://ecsec.de/unterstuetzt-vertrauenswuerdige-Digitalisierung ########################################################### 22.03.18 â ecsec ermÃglicht Signatur mit Personalausweis https://ecsec.de/ermoeglicht-Signatur-mit-Personalausweis ########################################################### 20.09.17 â SkIDentity aktiviert eIDAS https://skidentity.de/aktiviert-eIDAS ########################################################### 07.06.17 â Sicheres Login fÃr Trusted Cloud mit nPA Ãber SkIDentity https://skidentity.de/sichert-Login-fuer-Trusted-Cloud-mit-nPA ########################################################### 16.02.17 â ecsec und LuxTrust bringen QES Ãber OASIS in die Cloud https://ecsec.de/und-LuxTrust-bringen-QES-ueber-OASIS-in-die-Cloud ########################################################### 22.11.16 â SkIDentity erhÃlt Innovationspreis Bayern 2016 https://skidentity.de/erhaelt-innovationspreis-bayern-2016 ########################################################### 29.09.16 â SkIDentity ist gemÃÃ ISO 27001 und TCDP zertifiziert https://skidentity.de/zertifiziert-nach-iso27001-und-tcdp ########################################################### 12.01.16 - BSI zertifiziert Open eCard App gemÃÃ TR-03124 https://openecard.org/bsi-zertifiziert-open-ecard-app ########################################################### -- Neil Crossley ecsec GmbH Sudetenstrasse 16 96247 Michelau Telefon +49 9571 6048015 neil.crossley@ecsec.de ecsec GmbH Sudetenstrasse 16 96247 Michelau Amtsgericht Coburg HRB 4622 GeschÃftsfÃhrer: Tina HÃhnlein Dr. Detlef HÃhnlein Diese E-Mail kann vertrauliche Informationen enthalten. Falls Sie diese E-Mail irrtÃmlich erhalten haben, informieren Sie bitte unverzÃglich den Absender und lÃschen Sie diese E-Mail von jedem Rechner, auch von den Mailservern. Jede Verbreitung des Inhalts, auch die teilweise Verbreitung, ist in diesem Fall untersagt. AuÃer bei Vorsatz oder grober FahrlÃssigkeit schlieÃen wir jegliche Haftung fÃr Verluste oder SchÃden aus, die durch Viren befallene Software oder E-Mails verursacht werden. This e-mail may contain strictly confidential information and is intended for the person to which it is addressed only. Any dissemination, even partly, is prohibited. If you receive this e-mail by mistake, please contact the sender and delete this e-mail from your computer, including your mailserver. Except in case of gross negligence or wilful misconduct we accept no liability for any loss or damage caused by software or e-mail viruses.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]