[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: FROM JUAN CARLOS: FIRST COMMENTS TO TREVOR SCHEMA
Forwarding on behalf of Juan Carlos Dear Trevor, I have been looking to your proposal. In general, and for summarizing, I think that the structure that you propose is far from the original structure that was initially worked out and agreed during the f2f meeting, and I do not agree with the grouping of certain elements. The proposal that I submitted to you was aligned with that structure and I still think that we can work on it and introduce some of your mechanisms I propose then that we go back to that proposal, which has the kind of grouping of elements that was agreed in the f2f and then to comment and agree how to incorporate some of your proposals. Specifically, I think that we could comment on how to accommodate your indirection mechanisms in the original structure. As the rest of the people in the list has not seen the proposal I sent you , below follows a very short descriptoin of the structure of this proposal and more specific comments on the structure you circulated on the list. GENERAL STRUCTURE OF THE MESSAGE AND GROUPS OF ELEMENTS: I will start with the first level structure of the message that you propose. After reading it, I have to say that I would prefer the one that I proposed to you.... I will make a comparison with the one I proposed, which in fact followed the general ideas that came up in the f2f meeting. In my proposal, the root element had six children elements, namelly: -RequestID, which, as Tim suggested should be converted in an attribute of the root element. -UserData, containing information of the data to be signed, and that you have renamed to InputDocuments. -KeySelector: element indicating to the server which key has to use. You propose to make it optional.... I guess that this optionality would match those environments where there is only one key by default. -ClaimedIdentity: optional element including the claimed identity of the requestor. -Properties: optional element for requesting signed and/or unsigned properties. -Options: optional element identifying different types of options: -On the signature production -On the result to be delivered to the requestor -On the processing to be done by the server -On the supporting information (profiles, signature policy, etc). In your proposal the root element has 8 children, and three of them include the term "Options" in their name: -RequestID. As I said before, I agree with Tim's proposal and make it an attribute of the root element. -ServerGuidance. Here you include things like: claimedIdentity, IntendedAudience, ApplicationProfile and Others...I do not agree nor with this grouping neither with the name. In terms of the grouping I think that the claimedIdentity, when required is something so important that deserves to be a direct child of the root element by itself, as it is related with an essential fact of the signing process: WHO WANTS TO SIGN THE DOCUMENT(S)!!!!. The qualitative nature of this information is radically distinct of other information as the ApplicationProfile, the IntendedAudience and the vague Others...In addition, APplicationProfile and IntendedAudience, nicely fit within other categories of elements already present in my proposal (IntendedAudience in ResultDelivery, and ApplicationProfile within the Processing options!!!!) In terms of the name, ServerGuidance seems too vague for me: I mean, almost anything in the request gives some kind of guidance to the server: the key selector, the signature placement, etc... so I do not like the term guidance as too vague. And this impression is reinforced by the completely different purposes of the three contained elements. -SignatureContents: I have some comments on this structure: First: I do not like very much the name. It seems to me that it is misleading. The element seems to contain indications on what processing the server has to perform on each document by using selectors and transforms. The term "SignatureContents" leads me to think of the different parts of the Signature structure more than what actually is within the element. Second: As you say, this element would allow to apply different transforms to the same document and then sign different outputs of these transformations. I think that this is something that could be good to incorporate to our request. Third: Obviously the WhichInputDocument would be better an attribute and I personally prefer to use the "reference" attribute as I proposed you, instead of indicating the order numbering of the documents.... Fourth: The Requirements document, in 3.4.2 explicitly mentions the situation where the requester has applied some transformations to the original data. Then it would be possible situations where the requester has applied certain transformations and wants the server to apply other set of transformations.... How does this structure accommodates such different groups of transformations? Would the transformations in your "SignatureContents" be the transformations to be applied by the server AND the transformations within InputDocuments the transformations applied by the requester? IF so, I would propose to rename the elements to accomodate the purpose. In my original proposal I distinguished between: PerformedTransformations and RequestedTransformations, both of ds:TransformsType. -SignatureOptions.You include here the information of the Key and the request for properties (signed and/or unsigned). First: I think that in the f2f meeting we had a sort of agreement in that the element containing the information on the key that the server should use would be KeySelector to stress the idea that in a service like ours this element would select one of the different keys that the server could use for signing the documents. I still thing that term "KeySelector" is more aligned with the operational context of the service. Second: I would say that the information of the key that the server has to use is something crucial to the service, whereas the addition of properties, the canonicalization method, etc. is something of a second level of importance: in the end, the key also identifies the signer!!!. So, I think that, just as I proposed with the claimedIdentity the element selecting the key should be a child of the root element. -SignaturePlacement. You put this element as a direct child of the root element. I disagree with that. For me it is far more relevant (from the perspective of the service we are defining) WHO requests to sign something and WITH WHICH KEY than whether the signature produced is enveloped, enveloping or detached. I find much more natural to make this element a child of a ResultOptions element, as in my proposal. -OutputOptions: I can not catch all the semantics there....I can only try to guess. Reading the contents, one question comes to my mind: Imagine that a requester sends five documents. He wants two enveloped (let us say the 2ond and the 4rth). He wants the third enveloping the signature. Then the requester puts the element ReturnDocumentWithSignature, but how the server can know that the requester wants the signature enveloped in the third document and detached from the first and the fifth? I have not seen any information in the whole structure indicating this... -ProcessingOptions: I can not say much on this element because there is not type there. In my proposal, it contained things like signature policy identifier (an identifier of a signature policy, not the XAdES property!!) and the serverprofile, as I understand that these two issues really determine the kind of processing that the server will have to implement. Related with this issue would also be the issue of stacking operations or whatever we call it: the capability for requesting not one but several operations in one request.... Finally, just comment again that I think that an approach where the root element would have only one child Options containing different children each one corresponding to different types of options is much cleaner than having three root children related to different options.... -InputDocuments. I also have a number of comments here: First: the name. In the XMLDSIG the term used for the data that are processed and signed is "data object" to emphasize the idea of that the XMLDSIG can be used to sign whatever binary information we want. That is why I used in my proposal hte name UserData, which seems to me that reflects precisely this idea. Second: In my proposal there was an optional element that could have more than one instance, called ReferenceRequestDetails. The content of each instance would contain a ds:Reference element. This definition allows to accomodate the situation where the requester performs the transformations and hash computations by herself and only wants that the server builds up the ds:Signature element and computes the digital signature. You have substituted that definition by a group of three elements: Transforms, digestMethod and digestValue. Well, with only these three elements, the server CAN FACE SITUATIONS WHERE IT CAN NOT BUILD UP THE ds:Signature. THE ds:Reference elements CAN HAVE UP TO THREE ADDITIONAL ATTRIBUTES, ONE OF THEM OF CAPITAL IMPORTANCE IN DETACHED SIGNATURES: Uri!!!! I think that if we have to accommodate situations where the requester wil have the capability of transforming data and computing hash, we should assume that she will be able to build up the corresponding ds:Reference elements (as she is the one who knows the Uri where to locate the data, and the type of the original data and even if she wants to give an Id to the data!!!)... IN SUMMARY, I THINK THAT THIS ELEMENT SHOULD HAVE THE CONTENTS OF ds:Reference... Regards Juan Carlos Yahoo! Messenger Nueva versión: Super Webcam, voz, caritas animadas, y más ˇGratis!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]