Re: [dss-x-comment] Additional comments on DSS-X core v2.0 CS

Dear Stefan,

    
Thank you very much indeed for your message.

    
After sending my comments, I noticed that the core v2.0 actually
      includes the ResultMinor URIs with a short explanation in a
      different clause than the one where the Result component is
      specified. I guess that this is the reason why I did not notice
      their inclusion...maybe you could consider inserting a reference
      to clause 9.2 within 4.1.7. Something like:

    

      The optional ResultMinorÂelement MUST
        contain a URI.ÂÂÂ[DSS-4.1.7-2] 
      . Clause 9.2 lists the set of values that are used in this
      document.

    
Best regards

    
Juan Carlos.

    

    

      

    

      

    
El 2/11/18 a las 17:41, Stefan Hagen
      escribiÃ:

    

    Dear
      Juan Carlos,
      

      

      the TC has received your comment and will kindly consider them.
      

      

      Thank you for taking the time to proide the feedback.
      

      

      On behalf of the OASIS DSS-X TC
      

      

      Stefan Hagen, Co-Chair
      

      

      Am 25.10.18 um 11:52 schrieb Juan Carlos Cruellas:
      

      Dear DSS-X TC,
        

        

        While re-reading DSS-X core v2.0 I have hit a couple of issues
        that I
        

        would like to share with you.
        

        

        1. Clause 4.1.7. Component Result.
        

        

        URIs for result major are given without a single explanation.
        

        Additionally, no URNs are given for result minor. This clause
        seems to
        

        underspecify the Result component. Could you please consider the
        

        possibility of incorporating in this clause all the contents
        related to
        

        URNs for result major and result minor present in DSS core v1.0?
        I do
        

        not see any reason for dropping them, as this could be
        interpreted as a
        

        voluntary wish of the committee to deprecate the aforementioned
        URNs
        

        and/or change their semantics, giving place to a backwards
        compatibility
        

        problem.
        

        

        

        2. Clauses 4.3.28.2 and 4.3.28.1 XML and JSON of
        AdditionalKeyInfo.
        

        Several comments here.
        

        

        a. There seems to be a mismatch between the XML and JSON schema
        pieces
        

        in these clauses and the contents of the XML and JSON schema
        files
        

        provided separatedly. In these files, both the XML and the JSON
        types
        

        contain components for including OCSP responses. However in the
        pieces
        

        in the word document, such components do not appear.
        

        

        b. In the JSON schema dss2-AdditionalKeyInfoType contains two
        components
        

        that seem to be related with OCSP somehow, namely:
        "ocspresponse" and
        

        "ocsp", both of base64 data type....as there is not any further
        

        explanation, it is difficult to conclude what must placed within
        each
        

        component. In addition to that, the XML schema only provides one
        

        component for carrying OCSP related material, the OCSPResponse.
        This
        

        leads me to think that maybe in the JSON schema there is a
        duplication
        

        of components and only one of the aforementioned should be kept.
        

        

        c. Clause 4.3.28 does not mention neither any component for
        transporting
        

        OCSP responses nor component for POEs. I think that an
        specification of
        

        the contents of the component for OCSP responses, and also for
        the POEs
        

        should be added.
        

        

        

        Best regards
        

        

        Juan Carlos Cruellas.
        

        

        --
        

        This publicly archived list offers a means to provide input to
        the
        

        OASIS Digital Signature Services eXtended (DSS-X) TC.
        

        

        In order to verify user consent to the Feedback License terms
        and
        

        to minimize spam in the list archive, subscription is required
        

        before posting.
        

        

        Subscribe: 
        

        Unsubscribe: 
        

        List help: 
        

        List archive:
        http://lists.oasis-open.org/archives/dss-x-comment/
        

        Feedback License:
        http://www.oasis-open.org/who/ipr/feedback_license.pdf
        

        List Guidelines:
        http://www.oasis-open.org/maillists/guidelines.php
        

        Committee:
        http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss-x
        

        Join OASIS: http://www.oasis-open.org/join/