OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x-comment message

[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]