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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: comments on XAdES profile wd-02


Trevor, 
Thank you for your comments. As I have been on holidays, I have
not managed to read them before...
Below my answers.
>
>
>The title should probably include "Abstract", like: "XAdES Abstract Profile 
>of the..."
>
Agreed.

>The abstract could be updated to match the current template, which no 
>longer refers to protocol profiles: "This draft profiles the OASIS DSS core 
>protocols for the purpose of creating and verifying XAdES signatures".
>
The document does not have an abstract section, so I guess that I have
used an old template... I will do that. Agreed.

>The Introduction could be updated too.
Agreed.
>
>The schema namespace URL could be made consistent with the core, by 
>changing the filename to "oasis-dss-1.0-profiles-XAdES-wd-02".
>
Agreed.

>Line 100 can be deleted.
>
Agreed.


>Section 2.1 could be changed to say: "This profile does not specify a URI 
>Identifier".
What is exactly the purpose of this identifier? If it is for identifyihng
the profile,
then I guess that the namespace's URI would serve... should I then give the
same value of the namespace or just say  what you suggest?

>
>Line 122: remove both occurences of "to" from this sentence.

Agreed
>
>Section 2.2: I would move all of the text here except the first sentence to 
>a new section "1.3 Overview (Non-normative)".
>
Is it because it woudl be not normative? My idea of the scope was to
indeed give details on the scope of the profile (ie, what is covered...)

>Issue 1.1: it seems like this draft does have the ability to add arbitrary 
>signed properties?

Well, in fact it is not completely prepared for doing that: only a few
properties
are individually managed; the rest are incorporated by means of identifying
a specific "form" (a form is a signature containing a specific combination of 
properties).

>
>Sections 2.5 and 2.6: Since this is an abstract profile, you can just say: 
>"This profile does not specify or constrain the XXXX binding."
>

It is true.... agreed.

>Line 200: <SignatureType> has no type attribute.
>
Oooops... yes: you are right... I missread(?) the spec.
I will change the text.

>Issue #3: I'm not sure what this version applies to.  But you could always 
>introduce new URIs to do versioning, so I'd say you could leave it out.
>
Versions of the standards... standards are updated from time to time and
between versions may appear differences...
You point another way of doing versioning: uris.

>Section 3.1.1.3: It's not necessary to use <ClaimedIdentity> for the server 
>to know which certificate to use.  For example, maybe you authenticate with 
>a username/password, and the server automatically knows which certificates 
>goes with your account.  I think you should reword this and omit 
><ClaimedIdentity>.

But we have this element in the protocol just for the cases where the clien
wants to pass this information to the server... I do not see the point of not
using this element precisely in a situation where one needs to inform
of the identity to the server...


>
>Line 320: "DocsToB[e]TimeS[t]amped" misspelled.
>

True.. I will fix it.

>Issue #4: The <dss:SignedReferences> optional input has a RefId attribute, 
>that can be used to set ds:Reference/@Id.  However, I think it would be 
>better to refer to the input document with WhichDocument, like you're 
>doing, and let the server set ds:Reference/@Id automatically.
>

My point was that in the core document, the DocumentBaseType allows you to 
instruct the server to assign URI and Type to the ds:Reference, but not the
Id attribute.
What is the reason why dss:SignedReference has  the RefID and DocumentBaseType
does not have it?


>Lines 404 and 407: Maybe rephrase using "SHALL" instead of "MUST".
>
In fact, RFC 2119 say that both are equivalent: both imply an absolute
requirement.. another issue is whether one is better from the english language
point of view...

>Section 4.1.2.2: Is this a mistake?
>

Yes...it should say that this flag will be provided when an operation of
updatign is requested.
I will rephrase the sentence..
>

Again, thank you very much for your comments Trevor

Juan Carlos.
>Trevor
>
>
>
>
>
>
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]