Re: [dss] Re: comments on XAdES profile wd-02

[Juan Carlos Cruellas Ibarz <cruellas@ac.upc.es>]

>It's for use in the 'Profile' attribute of SignRequest or VerifyRequest.
>
>Since this profile is abstract, it doesn't need one.  However, Paul has 
>proposed that abstract profiles define URIs so that sub-profiles can extend 
>the abstract profile's URI.
>
>So you could leave the URI if you want, but it's not really needed.
>
OK...we will think about it...
>
>
>The template uses "Scope" in a very narrow way, just to say whether this 
>profile applies to the Signing protocol, the Verifying protocol, or 
>both.  It would be more consistent with the other profiles if you used 
>"Scope" in this way, and move the more descriptive text to an Overview
section.
>
>
I see... then I will take the latest template and move text accordingly


>I didn't explain that well:  It's fine to use <ClaimedIdentity>.  However, 
>in 3.1.1.3 it sounds like the *only* way of selecting a certificate is 
>through <ClaimedIdentity>, or through <KeySelector>.  I think that's too 
>restrictive.  So I would rephrase to mention that using <KeySelector> is 
>one way to indicate which certificate to use, but there's others (like 
><ClaimedIdentity>, or maybe the client only has one certificate associated 
>with his account, so neither <KeySelector> nor <ClaimedIdentity> are needed).
>
I see your point...I will rephrase the text

>(Also: I just noticed that 3.1.1.3 is the only place where 
><ClaimedIdentity> is mentioned.  You should mention it on its own within 
>3.1.1).
>

agreed

>
>> >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?
>
>There's a reason tucked away in the 2nd paragraph of 3.4.5.  It's subtle 
>and odd-seeming, but I think it makes sense.  URI and Type are "aspects of 
>the input document".  ID is an "aspect of the reference to the input
document".
>
What I can recall from the SignedReferences mechanism is that it was good for
allowing the production of different ds:Reference elements from one input
document.... I agree that somehow the URI and Type are aspects of the
input document and the Id is in fact the identifier of hte ds:Reference
element
but even the names of the attributes in the core clearly reflect the true
fact: all of
them are attributes of the ds:Reference element (that is why in the text
appears
RefURI,  RefType and RefID).... 

>If <SignedReferences> is not present, then every input document corresponds 
>to a single <ds:Reference>, and we could put RefID in the input documents.
>

I do not understand this sentence, what "we could put RefID in the input 
documents" mean? there is no such attribute in the schema.. the only thing
we can put is the ID attribute and this one is for making references to the
document from the same document...
If <SignedReferences> is not present there may be a need for specifying the
RefID from the client's side...
If we leave the core as it is there may be cases where we will have to 
add only one <SignedReference> just for instructing the server in adding the
Id attribute to thet ds:Reference... I 

>However, if <SignedReferences> *is* present, then a single document may 
>correspond to multiple <ds:Reference>s.  So it would not make sense to have 
>RefID attached to the input document.
>
Sure, I agree in that, but this fact is something that one always may make
explicit
in the text. What I am supporting is to allow the inclusion of the RefId in
the
InputDocument for those cases where no <SignedReference> elements appear
for that Input document

>
>> >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...
>
>Right, that's what I meant.  This sounds better to me, for some reason.. 
>though I can't explain why.
>

I see... well, we may change them

Regards and thanks

Juan Carlos.
>
>Trevor 
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php.
>