Re: comments on XAdES profile wd-02

[Trevor Perrin <trevp@trevp.net>]

Hi Juan Carlos,

At 03:41 PM 4/14/2004 +0200, Juan Carlos Cruellas Ibarz wrote:


> >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?

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.


> >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...)

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.


> >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...

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).

(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).


> >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".

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

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.


> >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.


Trevor