OASIS Digital Signature Services eXtended (DSS-X) TC

Hi all, finally found some time to go on working on our DSS conformance checker. Recently added a schema validator for requests and responses. A first surprising finding is that the 'Profile' attribute of the ResponseBaseType is 'required'. There was once a notice from Pim regarding this attribute that made it into the errata. But this comment underpins the 'required' state of the attribute. But I can see no reason why an implementor shouldn't just implement the core. Without any specific profile. So why should this attribute be 'required'? Greetings, Andreas -- Andreas Kühne phone: +49 177 293 24 97 mailto: kuehne@trustable.de Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868 Directors Andreas Kühne, Heiko Veit Company UK Company No: 5218868 Registered in England and Wales

Hi Andreas, Am 16.01.13 19:32, schrieb Andreas Kuehne: ... finally found some time to go on working on our DSS conformance checker. Recently added a schema validator for requests and responses. A first surprising finding is that the 'Profile' attribute of the ResponseBaseType is 'required'. There was once a notice from Pim regarding this attribute that made it into the errata. But this comment underpins the 'required' state of the attribute. But I can see no reason why an implementor shouldn't just implement the core. Without any specific profile. So why should this attribute be 'required'? ... thanks for adding the validator. I am curious, if I could somehow have a look at it or its sources ... :-?) With respect to your finding: In retrospect some differences between elements appear to be inconsistencies. We will have to look. Maybe there was a clever idea of one of the cooks involved when we prepared that meal in the years before 2007 ;-) I like to amend your question with the following: As a ResponseBaseType[2] in dss version 1 makes sense, if and only if a RequestBaseType[1] has been instantiated, it looks a bit misaligned, that the client may optionally set a Profile attribute on the element based on RequestBaseType he is sending, but the server is required to set a Profile attribute inside the corresponding response element derived from ResponseBaseType. Also since the type of the attribute in both cases is xs:anyURI the cardinality is fixed to one. I sguugest, that we SHOULD investigate by digging through the mail archives and our minds what lead us there and how we SHOULD proceed. References: [1]: "2.10 Type <RequestBaseType>", http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html#_Toc157225013 [2]: "2.11 Type <ResponseBaseType>", http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html#_Toc157225014 All the best, Stefan.

Hi Stefan, > thanks for adding the validator. I am curious, if I could somehow have > a look at it or its sources ... :-?) > it's build on top of the Apache Cocoon framework. This is based on Java, but the major programming work is done in xslt. And here the work of the TAML perfectly fits in, as it is done in xslt, too. But it may need some time to get used to this environment. Our work is open source, generally. But the current state isn't publicly available, yet. Major refactoring underway to fit into the Java repository world ... Maybe we could meet in Bonn and we could walk thru the major building blocks? > With respect to your finding: > > In retrospect some differences between elements appear to be > inconsistencies. We will have to look. Maybe there was a clever idea > of one of the cooks involved when we prepared that meal in the years > before 2007 ;-) > > I like to amend your question with the following: > > As a ResponseBaseType[2] in dss version 1 makes sense, if and only if > a RequestBaseType[1] has been instantiated, it looks a bit misaligned, > that the client may optionally set a Profile attribute on the element > based on RequestBaseType he is sending, but the server is required to > set a Profile attribute inside the corresponding response element > derived from ResponseBaseType. > Also since the type of the attribute in both cases is xs:anyURI the > cardinality is fixed to one. > I sguugest, that we SHOULD investigate by digging through the mail > archives and our minds what lead us there and how we SHOULD proceed. > Ok, let's start our new profession as standards archaeologist :-) I would guess it's ten years back when we designed these foundations of our structures ... Greetings, Andreas > References: > > > [1]: "2.10 Type <RequestBaseType>", > http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html#_Toc157225013 > > [2]: "2.11 Type <ResponseBaseType>", > http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html#_Toc157225014 > > All the best, > Stefan. > -- Andreas Kühne phone: +49 177 293 24 97 mailto: kuehne@trustable.de Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868 Directors Andreas Kühne, Heiko Veit Company UK Company No: 5218868 Registered in England and Wales

Sorry for jumping a bit late in the thread...two remarks: 1. Regarding the cardinality, it is true that beign an attribute its cardinality can only be one...but the core defines the common optinal input (for both the sign and the verify protocols) AdditionalProfile, which makes it possible to build up requests/responses that are conformant to more than one profile. 2. Regarding the mandatory/optional, I think that the issue is a bit more confussing if we look clause 3.2 <SignResponse>... in this clause the Profile attribute inherited from ResponseBaseType, appears as [Optional]....so there is inconsistency between the derived type and its supertype...not in the xml schema (and this should be the reason why Andrea got that error result) but at the level of the textual specification....By the way, other than this [Required] versus [Optional], the rest of the text devoted to this attribute is the same in both 2.10 and 3.2..... Regards Juan Carlos. El 18/01/13 10:15, Andreas Kuehne escribió: Hi Stefan, thanks for adding the validator. I am curious, if I could somehow have a look at it or its sources ... :-?) it's build on top of the Apache Cocoon framework. This is based on Java, but the major programming work is done in xslt. And here the work of the TAML perfectly fits in, as it is done in xslt, too. But it may need some time to get used to this environment. Our work is open source, generally. But the current state isn't publicly available, yet. Major refactoring underway to fit into the Java repository world ... Maybe we could meet in Bonn and we could walk thru the major building blocks? With respect to your finding: In retrospect some differences between elements appear to be inconsistencies. We will have to look. Maybe there was a clever idea of one of the cooks involved when we prepared that meal in the years before 2007 ;-) I like to amend your question with the following: As a ResponseBaseType[2] in dss version 1 makes sense, if and only if a RequestBaseType[1] has been instantiated, it looks a bit misaligned, that the client may optionally set a Profile attribute on the element based on RequestBaseType he is sending, but the server is required to set a Profile attribute inside the corresponding response element derived from ResponseBaseType. Also since the type of the attribute in both cases is xs:anyURI the cardinality is fixed to one. I sguugest, that we SHOULD investigate by digging through the mail archives and our minds what lead us there and how we SHOULD proceed. Ok, let's start our new profession as standards archaeologist :-) I would guess it's ten years back when we designed these foundations of our structures ... Greetings, Andreas References: [1]: "2.10 Type <RequestBaseType>", http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html#_Toc157225013 [2]: "2.11 Type <ResponseBaseType>", http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html#_Toc157225014 All the best, Stefan.

Hi Juan Carlos, > 1. Regarding the cardinality, it is true that beign an attribute its > cardinality can only be one...but the core defines the common optinal > input (for both the sign and the verify protocols) AdditionalProfile, > which makes it possible to build up requests/responses that are > conformant to more than one profile. > back in the early days we thought of the use of just one single profile. And we missed the opportunity to drop the Profile attribute completely when we introduced AdditionalProfiles. > 2. Regarding the mandatory/optional, I think that the issue is a bit > more confussing if we look clause 3.2 <SignResponse>... in this clause > the Profile attribute inherited from ResponseBaseType, appears as > [Optional]....so there is inconsistency between the derived type and > its supertype...not in the xml schema (and this should be the reason > why Andrea got that error result) but at the level of the textual > specification....By the way, other than this [Required] versus > [Optional], the rest of the text devoted to this attribute is the same > in both 2.10 and 3.2..... Pim already pointed out this inheritance problem. Nevertheless, if the requestor does not mandate a profile, the server must have the chance to respond without a Profile attribute. Or we apply the Null pattern and define an URN for a 'NoProfile' profile ... Greetings, Andreas

back in the early days we thought of the use of just one single profile. And we missed the opportunity to drop the Profile attribute completely when we introduced AdditionalProfiles. Yes...in some point in time we started to do some work on how to use different profiles simultaneously but we stopped that work...anyway, maybe some informative note clarifying the issue would be worth in the next version of the core.... Pim already pointed out this inheritance problem. Nevertheless, if the requestor does not mandate a profile, the server must have the chance to respond without a Profile attribute. Or we apply the Null pattern and define an URN for a 'NoProfile' profile ... I agree in giving the possibility of responding without any profile...this NoProfile URN would have the advantage of not breaking the xml schema of the core, which I guess it has been used for building a number of implementations, even it could be a bit extrange (but we could be completely transparent and add an informative note in the next version)..... Greetings, Andreas --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

On 21.01.13 16:54, Juan Carlos Cruellas wrote: back in the early days we thought of the use of just one single profile. And we missed the opportunity to drop the Profile attribute completely when we introduced AdditionalProfiles. Yes...in some point in time we started to do some work on how to use different profiles simultaneously but we stopped that work...anyway, maybe some informative note clarifying the issue would be worth in the next version of the core.... yes. I second this! In the upcoming next version / errata / comments of / to / for the core we SHOULD clarify this. Pim already pointed out this inheritance problem. Nevertheless, if the requestor does not mandate a profile, the server must have the chance to respond without a Profile attribute. Or we apply the Null pattern and define an URN for a 'NoProfile' profile ... I agree in giving the possibility of responding without any profile...this NoProfile URN would have the advantage of not breaking the xml schema of the core, which I guess it has been used for building a number of implementations, even it could be a bit extrange (but we could be completely transparent and add an informative note in the next version)..... Again: I am also in favour of adding such a NoProfile URN for the 100% core use case. All the best, Stefan