[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss-x] FW: Late comments on OASIS DSS-X Profile on visible signatures Committee Draft
Hello Ezer, Since I cannot attend tomorrow's meeting due to travel, this email is to indicate that I agree with your replies. Kind regards, Pim -----Original Message----- From: Ezer Farhi [mailto:Ezer@arx.com] Sent: 15 November 2009 08:38 To: Juan Carlos Cruellas Cc: dss-x Subject: RE: [dss-x] FW: Late comments on OASIS DSS-X Profile on visible signatures Committee Draft Hello Juan Carlos, The intention was to get the members' opinion on this matter. Thanks, Ezer -----Original Message----- From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu] Sent: Sunday, November 15, 2009 1:45 AM To: Ezer Farhi Cc: dss-x Subject: Re: [dss-x] FW: Late comments on OASIS DSS-X Profile on visible signatures Committee Draft Hi Ezer, Sorry for my late reply... I agree with your answers. May I suggest that the members of the committee take a look to this so that we may resolve the issue at the next call? Regards Juan Carlos Ezer Farhi escribió: > Hi, > > > > Follows a list of requirements raised by Denis Pinkas. > > Every requirement has a matching response of the DSS-X committee. > Please pay attention to the third item, which I did not mention in the > last committee call. I think the address of this item might by the > STF-364 or other ETSI's advanced signature committees. > > Please raise any comment you have. > > Thanks, > > Ezer > > > > " > > > > 1. Request: The Visible Signature profile should not be bounded by > any existing implementation of visible signature. A standard body > should define the standard according to its judgment. > > Answer: The visible signature profile as well as any standard > defined by the DSS-X committee defines the protocol for sending > request/response to a signature/verification service. The scope of > the committee does not handle document formats. > The profile supports several exiting implementations of visible > signatures in existing documents types. > There is no fundamental reason why any future document > implementation that supports visible signatures, will not be > supported by the visible signature profile. It may that some > adjustments will need to be made to the Visible Signature profile > to support such future document types. > > 2. Request: Visible information will be encoded as a Meta data into > the document. Upon verify requests certain level of information > will be displayed in the visible signature. Also, depending on > lingual environment or other context textual information will be > displayed according to the context. > > Answer: Such document implementation or standard does not exist > today, and it is not in the scope of the committee to define such > standard or document type. > As specified in item number 1, when such a standard or document > type exists, the committee thinks that the visible signature > profile will not require extensive modifications to support such > document standard. > > 3. Request: In addition to item 2, a detached Visible Signature that > goes along with the digital signature itself and that does not > care which the underlying document type is is a better approach > than embedding a visible signature into the document. This way you > do not have to define a different standard of embedding a visible > signature into different document types. > One of the solutions might be to extend the advanced signature > standard to support visible information. > > Answer: Again, this issue is not in the scope of the committee. If > indeed the advanced signature standard to any other "detached > signature" standard will include visible content, the visible > signature protocol will be adjusted to support this standard. > The request should probably be directed to other standardization > bodies such as ETSI's committees that handles the standardization > of advanced electronic signatures. > > 4. Request: All visible items must be included in the digital > signature > > Answer: The committee agrees with this concept except for a > certain element type, which is a visible representation of the > digital signature itself, which might be represented as a barcode > image or any other encoded image. > This certain image cannot be protected by the document's digital > signature. > There are some existing implementations that involve external > scanners that will be able to decode the barcode image and perform > signature verification. > The committee found no reason not to support such implementations > that use this exception. > > " > > <http://www.arx.com/> > > > > -----Original Message----- > *From:* Denis Pinkas [mailto:denis.pinkas@bull.net] > *Sent:* Wednesday, November 04, 2009 6:56 PM > *To:* Ezer Farhi > *Cc:* Juan Carlos Cruellas; dss-x > *Subject:* RE: Late comments on OASIS DSS-X Profile on visible > signatures Committee Draft > > > > Ezer, > > > > It seems that we have rather different approaches. > > > > You make the assumption that visible signatures are in the signed > document. I don't make the same assumption. > > > > Anyway, if it is in the signed document, how is it possible to make > the difference between a "real visible signature field" > and fake one that is burried in the text ? Does it mean that such a > field is interpreted/presented in a different window and does not > appear in the displayed text, video or recording ? > > > > Another problem is that, IMO, there should be different ways to > display a visible signature field (remember my proposal with different > levels of view). This is not possible if it is within the document. > > > > You are talking of "existing product that implement visible signatures" > > You are making the assumption that the approach from Adobe and > Microsoft is correct. > > These two companies have build their products originally by not > supporting AdES formats. > So their approach is not necessarilly correct. > > > > We do not speak the same language. I asked a question and instead of > responding to it, your raise a different question. > > > > My question was: "Do you believe that the document does not support > visible signature for detached signatures and embedding signatures ? " > > > > Your answer to my question was another question: Can you refer me to > a standard, a document format or a data format that enables > encoding/embedding a digital signature along with a matching visible > content or pointing to a detached signature? > > > > I presume that your opinion is the following: since visible signatures > are embedded in the document they can be supported with any kind of > signatures, e.g. detached signatures or embedding signatures. > > > > I believe that it is possible to define extensions to the current > formats of AdES to incorportae visible signatures. > > > > The implications, which are _very important_, are the following: > > > > a) with my approach, it is possible to present the visible signature > without "opening" the document. > this means that they can be supported with any kind of document, e.g. > a tiff document or some recording. > > > > b) with your approach, there is the need to open the document to be > able to present the visual signature. > > The way to present the visual signature would be restricted to the two > formats you consider: PDF/A and OOXML. > > If more formats need to be supported, more satndardization work wil be > needed. I believe it will be very difficult to support visible > signatures on video or on recordings. > > > > Then you said: > > the potocol does address this issue by enabling the client > specify the ID of the item > to be incorporated to the visible content (in this case the > identity of the label is <xs:enumeration value="SignatureTime" />). > It is up to the server implementation and the type of > relevant document to use to either incorporate a real text or an OID. > > > > The probem is when interpreting the field. An OID can easily be > translated in any foreign language exactly in the same way. > > If it is a text, this will not necessarilly be the case. I do not want > to include in the visible signature field all the languages that exist > on the Earth. > > > > But the important point is the following: I claim that a visible > signature presented in China will be different from a visible > signature presented in the UK. It does NOT follow the property "what > you see is what you sign". > > > > Later on you say: > > As said, there is no existing implementation that enables > you to visualize different > visible signature depending on the current language the > user is using. > > > > I don't care what the existing implementations are doing. > Standardization groups (like ETSI or OASIS) try to lead the way, they > do not necessarilly follow what has been done outside a > standardization group. > > > > Then you say: > > > > You may require that the protocol will enable future > implementations to support such functionality by supplying different > text for the same item as part of the > /ItemValueStringType/ type > > > > I do'nt want to require this. See my explanations above. > > > > Finally, when you said: > > > > I refer to a scanning image of the digital signature itself (not a > scanning of the signer's handwritten signature). For example, this > visible string 12389413824388123468ABABABAB728342732379. This item can > be signed by the same digital signature. > > > > I was completely lost. What is the advantage of presenting a string > like > 12389413824388123468ABABABAB728342732379 ? > > How can it be useful ? Will a user notice the difference with > 12389413824388123468ABABABABA28342732379 (where I changed one digit) ? > > > > Denis > > > > ----- Message reçu ----- > > *De :* Ezer Farhi <mailto%20:Ezer@arx.com> > > *À :* denis.pinkas <mailto%20:denis.pinkas@bull.net> > > *Date :* 2009-10-15, 12:52:15 > > *Sujet :* RE: Late comments on OASIS DSS-X Profile on visible > signaturesCommitteeDraft > > > > Hello Denis, > > > > Some remarks below. I'm sorry for the late response. > > > > Thanks, > > Ezer > > > > -----Original Message----- > *From:* Denis Pinkas [mailto:denis.pinkas@bull.net] > *Sent:* Monday, September 21, 2009 2:58 PM > *To:* Ezer Farhi > *Cc:* Juan Carlos Cruellas; dss-x > *Subject:* RE: Late comments on OASIS DSS-X Profile on visible > signatures CommitteeDraft > > > > Ezer, > > > > I am fine after the surgery,working from home. > > > > See my responses embedded in the text. > > > > Denis > > ----- Message reçu ----- > > *De :* Ezer Farhi <mailto%20:Ezer@arx.com> > > *À :* Denis Pinkas <mailto%20:denis.pinkas@bull.net> > > *Date :* 2009-09-14, 18:54:33 > > *Sujet :* RE: Late comments on OASIS DSS-X Profile on visible > signatures CommitteeDraft > > > > Hello Denis, > > > > If by any chance you did not receive this email, it is right ahead. > > > > Appreciate any remark. > > > > Thanks, > > Ezer > > -----Original Message----- > *From:* Ezer Farhi > *Sent:* Sunday, August 02, 2009 10:07 AM > *To:* 'Denis Pinkas' > *Cc:* Juan Carlos Cruellas; stefan; dss-x@lists.oasis-open.org > *Subject:* FW: Late comments on OASIS DSS-X Profile on visible > signatures Committee Draft > > > > Hello Denis, > > > > I'm very sorry for the late response. > > > > Please see my comments below. > > > > Thank you very much for the detailed review and the detailed > remarks. > > > > Ezer > > > > -----Original Message----- > *From:* Denis Pinkas [mailto:denis.pinkas@bull.net] > *Sent:* Friday, July 24, 2009 10:38 AM > *To:* Juan Carlos Cruellas; stefan; Ezer Farhi > *Subject:* Late comments on OASIS DSS-X Profile on visible > signatures Committee Draft > *Importance:* High > > > > I sent the comments below to Juan-Carlos, but I got no reply > from him. > > > > So I send them directly to the people that have their e-mail > address on the front page of the document. > > > > BTW, the e-mail address from Juan-Carlos on teh front page is > wrong: it should end with "edu" rather than "ede". > > > > Regards, > > > > Denis > > > > ======================================================= > > Juan Carlos and all, > > > > Please find below late comments. > > > > Juan-Carlos would you be able to post them to the DSS-X committee > since the link indicated in the mail does not work ? > > > > Denis > > > > ======================================================= > > > > *Late comments on version 1.0 of the "Visible Signature Profile". > * > _Source_: Denis Pinkas. Bull SAS. > > After two readings of the document, I still have difficulties to > understand > how the protocol may be usable in practice with signature > formats like CAdES and XAdES. > > > > EZER - The Visible Signature profile performs is aimed to embed > visible information upon a given content such as PDF document, > MS Office documents, etc in addition to the actual digital > signature operation that is handled through the DSS core protocol. > > In the case that the client wishes to use an advanced signature > (CAdES, XAdES), the client will need to use two profiles in > addition to the core: > > The Advanced signature profile, which is specified at > http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-AdES- spec-v1.0-os.html > and the visible signature profile. > > As an example, you can incorporate a visible signature to a PDF > document in addition to an advanced digital signature embedded > in the PDF document (at the level of conformance that is > applicable today by PDF). > > The current ETSI standardization process that is aimed for > enabling advanced signatures in PDF files will probably > incorporated into a new version of the advanced signature > profile (which also in combination with the visible signature > profile, enable supporting visible advanced signature in PDF files). > > > Whatever the protocol may be, the end result should be > incorporated either into the signed document itself > or in the electronic signature. > > > > EZER - the protocol tries to be aligned with existing document > implementations such as PDF or Office 2007. And indded it is > incorporated into the signed document itself. > > [Denis] We are in disagreement here. > As I said: "... should be incorporated either into the signed > document itself **or in the electronic signature itself**. > > [Denis] I see difficulties to incorporate the visible > signature inside the document. It means that the visible signature > API must be applied before the document is signed. It modifies the > document to be signed and the "What you see is what you sign" > property is no more applicable. Or should the visible signature > become part of "What you see is what you sign" property ? Does it > mean that the end user should be able to "see" the document with the > visible signature field before the document is signed ? > > EZER - I see it differently and it is also implemented that way in > existing product that implement visible signature such as > Adobe-PDF and MS Office. > As part of the digital signature ceremony both visible and non > visible content will be incorporated into the document (BTW, many of > the existing documents implementation contained non visible data > this is also signed as part of the digital signature operation - the > "What you see is what you sign" claim...). > The visible signature profile goes along with this direction (which > I believe is a correct one) and performs the both adding of visible > content that is related to the digital signature act and performs a > digital signature operation within a single transaction. > > The abstract is only addressing the embedding of "visible > signature characteristics into documents". > Should the abstract be left unchanged, then this would mean that > support of visible signatures > would not be supported for detached signatures and embedding > signatures. > > EZER - The protocol mainly addresses documents types and not > native XML, that inherently addresses visibility of information. > > [Denis] You do not answer to my question. Do you believe that the > document does not support visible signature > for detached signatures and embedding signatures ? > > EZER - Denis, Can you refer me to a > standard, a document format or a data format that enables > encoding/embedding a > digital signature along with a matching > visible content or pointing to a detached signature? > Currently the only existing > implementations/standards that I'm aware > of are the PDF standard and the Microsoft > OOXML standard (along with some additional existing implementation). > The aim of the profile is not to create a > standard for encoding visible signature content. > > Secondly, the internationalization of such visible signatures is > not addressed. Since electronic signatures > are intended to be made visible, an electronic signature > generated in one country using a given language > should be made visible in another country using a different > language. Each field should thus be made visible > using a local language. This document is silent about this aspect. > > > > EZER - It is possible to include textual information in a > variety of languages by indicating fonts for every textual > element. Text can be either supplied by the client or > incorporated by the server (for example, a common name can be > extracted by the server from the user's certificate). > > [Denis] This is not what I was thinking.The idea is to include only > OIDs into the visible signature that can be locally translated into > any language. > As an example an OID for the "claimed signature time", that will be > translated into "date présumée de la signature" if the French > language is being used by the viewer of the visible signature field. > > EZER - Your remark is mainly relevant to "static" information such > as the above example, and the protocol does address > this issue by enabling the client specify > the ID of the item to be incorporated to the visible content (in > this case the identity > > Of the label is <xs:enumeration value="SignatureTime" />). > It is up to the server implementation and the type of relevant > document to use to either incorporate a real text or an OID. > > However, in the case of a dynamic type of data (such as the > signature time itself or a reason for signing), it is a bigger > problem to implement a multi lingual solution. > Maybe you actually mean that you expect the protocol that in any > case that a string is passed from the client, the client will have > the possibility to pass the string in several languages (for > example, a reason in English and French), so that the server > and document implementation will be able to incorporate several > strings into the documents? > > > > > > > Usually the visible content is signed by existing implementation > that forbids any modifications to the visible content, therefore > it will not be possible to translate visible content from one > language to another. > > So basically, I think that supporting different languages based > on universal strings is possible. > > > > [Denis] See my comment above. I got the impression > that you want to be backwards compatible with existing implementations. > However, it does not mean that existing > implementations are "good". :-) > > > Thirdly, all the characteristics of a signature should not > necessarily be made visible at once. There should be > a concept of a first level of visibility, and for each first > level, a second level of details. At the very end, > all the visible characteristics (as requested by the signer) > should be made visible. > > > > EZER - This "visibility level" is not embedded in the protocol > since currently no existing implementation (PDF, MS Office) > enables that. The protocol does enable you to control (in the > time of the digital signature act) which information should be > incorporated to the visible signature. > > It is possible to incorporate such a parameter to the protocol, > which may be used by future applications/implementations. > > [Denis]. Once again, I got the feeling that you want only to support > existing implementations whether teh approach they have taken is > "good" or "bad". > > EZER - Right. However, the protocol is not > limited only for these implementations, so it is possible to > incorporate additional > functionality. However, it is important to > separate between the protocol and the implementation of the server > along with the > Certain document standard. > > > > > These observations let me to conclude that the signer should be > able to incorporate a /template /for the visible signature > which will describe the first level, secondary level, etc ... > of the visible signature in a language independent manner. > Applications able to handle these visible signatures fields > should be able to interpret the template in a local language. > > > > EZER - Please see previous remarks about languages. Since most > existing and future implementations sign the visible content, I > think that the protocol should handle actual textual content and > not templates. > It is possible to bind a "display level" for every displayable > field (as described above). > > > > [Denis] Since all people do not understand English, > I do not see how the approach you are taking may work. > Incorporating all languages would not be acceptable > either. > > EZER - I do not see any problem of using any language. > The issue that you raised is how a certain visible signature can > address several languages in parallel. As said, there is > no existing implementation that enables you to visualize different > visible signature depending on the current language the > user is using. > You may require that the protocol will enable future > implementations to support such functionality by supplying different > text for the same item as part of the > /ItemValueStringType/ type. > > As already stated above, whatever the protocol may be, the end > result should be incorporated either into the signed document itself > or in the electronic signature. > > > > EZER - yes. > > > > [Denis] Do you really agree: "into the signed document > itself **or into the electronic signature**" ? > > EZER - I think it will be more accurate to say that the visible > signature is incorporated into the document. This is dependant on > the document format/standard. > > > > If incorporated into the electronic signature, the basic > question is where to place that information ? > > EZER - The protocol address that by either supplying a position > or an existing signature field, which is a placeholder for the > visible signature. > > > Should it be as signed attributes (or signed properties) or as > unsigned attributes (or signed properties) ? > > > > EZER - If you referring to whether the visible content is > signed. It is very much depended on the document implementation. > The protocol addresses both implementation types (that sign the > visible content and do not sign the visible content). One of the > implementations that do not sign the visible content actually > incorporate to the visible content the actual digital signature > in bar-code representation or other type of representation. In > this case the visible signature content cannot be signed. > > [Denis] I am confused here.You mean that there are two > flavors. One that is signed, the other one that is unsigned. > The unsigned one can be chahged by anybody and so is not > trustable. Do you plan to add a visible information > saying whether it is signed or unsigned ? Anyway, I do not > see the value of an unsigned visible signature: it can fool a verifier. > > EZER - There are existing implementations that include a > certain particle of the visible information that is a direct output > of the digital signature itself (for example, a bar-code > image that is a representation of the digital signature itself). > This certain element cannot be signed. > I will change the profile description to be more precise > in this case, so that only this type of element can be not signed. > > > > Whatever the response to the question is, this means that new > signed attributes (or signed properties) > or new unsigned attributes (or signed properties) should be > defined respectively for CAdES and XAdES. > > > > EZER - This issue will be covered as well by the implementation > and not the protocol. In most existing applications today (PDF, > Office), the visible signature is incorporated into the > document's content and not to the digital signature content (for > example, signed attributes). > > > > [Denis] If so, then the visible signature is signed > > EZER - Yes, in most implementation. Please read my previous remark. > > > > If incorporated into the document, the incorporation depends > upon the type of document. However, this approach > would be restricted to some types of documents and would not be > as general as the other approach. > Even if the electronic signature is embedded into the document > (as it is the case for PDF signatures), it appears better > to add the information related to the visible signature into the > electronic signature itself (placed within the document), > rather than placing it somewhere else in the document. > > > > EZER - This issue should be addressed by the documents > standards. The specification (which is also true for other > aspects of the DSS specification) addresses the protocol and not > the actual implementation. As I know there is an ETSI committee > that will address aspects of incorporating visible content into > the PDF specification that may address the issue that you raise. > > > > > > [Denis] I do no beleive that is possible to define a > protocol without thinking at the same time what will/may be done > by implemtations. The actions should be done in parallel. > > > > As stated above, this means that new signed attributes (or > signed properties) or new unsigned attributes > (or signed properties) should be defined respectively for CAdES > and XAdES. > > > > EZER - As said above, this direction should be handled by the > document standards themselves. The protocol is not aimed only > for documents types that use advanced signatures, but if the > documents types do support CAdES/XAdES, the DSS server > implementation may use signed properties to include visible content. > > > > In the draft document, there is intent to add information like a > "scanned image of the user's hand-written signature". > While this is an interesting idea, this information, if added > should be incorporated as a signed attribute and a signed property. > > > > EZER - As said above, it is up to the document implementation. > Today, both PDF and Office sign this content as well as any > other content in the visible signature. > > > > The visible signature fields should not contain any value. > Values should always be computed by a verification service > using the signed attributes (or signed properties) or/and the > unsigned attributes (or signed properties), so that > there is no conflict or ambiguity between values placed in the > electronic signature and asserted values that would be placed > in the visible signature fields. > > > > EZER - In most of the cases the claim is correct and most > existing implementation assure that by signing the visible > content and make sure it is aligned with values that are not > part of the visible content. As I said, above, the protocol also > addresses implementation that produces a digital signature > image. In this case this image is not signed and content data. > > > > [Denis] This does not work. The verification MUST > always be done by the signature verification software. > The signature creation software MAY also do it, but the > verification software cannot know whether that software was "good" > or "bad" > > EZER - I agree with you. I will be more specific about the digital > signature image, which is the only possible visible item that may be > unsigned since it is a direct representation of the digital > signature itself. > > To summarize the suggested approach: > > when used by a signer in a signing protocol, the service should be > able to incorporate a "visible signature template" > into the electronic signature, preferably as a signed attribute or a > signed property. This template would support > different levels of visibility. > > > > EZER - Please see the comments above. We can highly consider > incorporation a visible display level attribute for every item > in the visible content. The application can use this attribute > to define the level of visibility. > > > > [Denis] Adding the notion of a visible display level > would only solve one of my concerns. > > > > when used by a verifier in a verifying protocol, the service should > be able to interpret in a local language > the "visible signature template" placed into the electronic > signature, to the desired level of visibility and say > whether the information that has been retrieved has been verified or > has simply been copied and pasted > from the unverified signature. In the later case, if the signature > is not verified as being valid, this would allow > to know more about the electronic signature. This interpretation > would also be faster in practice. > Application displaying the visible signature fields should take care > to make the difference between "verified values" > and "unverified values". > > > > EZER - The visible signature profile mainly addresses the > digital signature operation and has limited functionality in the > validation processing. > > > > [Denis] I have difficulties to understand what you mean here. I > believe that what is important is what a verifier will see. Any > field that is displayed should be marked verified or claimed. Let us > take the example of a scanned manual signature. If can simply be > part of the document (or of the signature) and is whatever manual > signature has been added by the signer (so it is unverified). > Another possibility is to include the jpg of the scanned signature > and verify that it matches a hash included into the signer's > certificate. In such a case, if the digital signature has been > verified, then the scanned manual signature has been verified. > > EZER - I refer to a scanning image of the digital signature itself > (not a scanning of the signer's handwritten signature). For > example, this visible string > 12389413824388123468ABABABAB728342732379. This item can be signed by > the same digital signature. > > > > Currently, the only processing that is included is to mark the > verification status of the digital signature, but this act by > itself is mainly aimed for documents types that will not violate > the digital signature. > > [Denis] I don't understand what you mean here. > > EZER - The DSS core performs that actual digital signature > verification act. The profile is currently doing some limited > functionality, which is to add some visible marking to the document > that specifies whether the digital signature is valid. We have some > debates on this issue, since adding this marks will invalidate the > digital signature in existing implementations. > > > > The proposal you raise is interesting, but I need to consult > with the DSS committee to whether this approach should be > defined and described in the visible signature profile. > > Are you familiar with such an implementation? What types of > documents are used? > > > > [Denis] I don't understand your questions. > > > > EZER - You described functionality in the above paragraph ("when > used by a verifier in a verifying protocol, the service should...."). > I asked whether you are familiar with any implementation or standard > that describes or implement it. > > > > > > Denis > > > ---------- > > *De :* esi : etsi tc esi (electronic signatures and > infrastructures) <mailto%20:ESI@LIST.ETSI.ORG> > > *À :* ESI <mailto%20:ESI@LIST.ETSI.ORG> > > *Date :* 2009-06-10, 17:57:55 > > *Sujet :* [ESI] Deadline for commenting OASIS DSS-X Profile > on visible signaturesCommittee Draft > > > > Dear all, > > Just these few lines to remark that the window for raising > comments on > the the DSS-X Profile on Visible Signatures **ENDS THE 30TH > OF JUNE 2009**. > > The OASIS DSS-X Technical Committee strongly encourages feedback > from you for the sake of improving the interoperability and > quality of > OASIS work. Please feel free to distribute this announcement > within > your organization and to other appropriate mail lists. > > This profile is aimed to incorporate visible information > into documents > as part of the digital signature operation. > > Incorporating a visible signature as part of a digital signature > operation is mandatory for the acceptance of digital > signatures in many > business scenarios and applications. > > Today, there is an existing support in several document > types such as > PDF and MS Office 2007, as well as non standard support in other > documents types. Eventually, many document types will > support the both > visible and non-visible digital signature embedded in the > document. > > The target of the Visible Signature profile is to provide a > general > interface to a digital signature service for incorporating a > visible > signature to any type of document. > > To ease the collaboration of a visible signature into > applications, the > profile defines several types of scenarios/policies. Two of > the most > outstanding usages of implementing a digital signature into > documents > are application workflow scenario and a document submission > scenario. > > The committee will appreciate any submitted component as part of > reviewing the profile specifications. > > For more information of how to access the content of the > profile use the > following details: > > The specification document and related files are available here: > Editable Source: > > http://docs.oasis-open.org/dss-x/profiles/visualsig/v1.0/cd0 1/oasis-ds > sx-1.0-profiles-visualsig-cd1.doc > > PDF: > > http://docs.oasis-open.org/dss-x/profiles/visualsig/v1.0/cd0 1/oasis-ds > sx-1.0-profiles-visualsig-cd1.pdf > > HTML: > > http://docs.oasis-open.org/dss-x/profiles/visualsig/v1.0/cd0 1/oasis-ds > sx-1.0-profiles-visualsig-cd1.html > > Schema: > > http://docs.oasis-open.org/dss-x/profiles/visualsig/v1.0/cd0 1/oasis-ds > s-vissig-schema-v1.0-cd1.xsd > > > > Non-normative information about the specification and the > technical > committee may be found at the public home page of the TC at: > > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=d ss-x. > > Comments may be submitted to the TC by any person through > the use of the > OASIS TC Comment Facility which can be located via the > button marked > "Send A Comment" at the top of that page, or directly at: > http://www.oasis-open.org/committees/comments/index.php?wg_a bbrev=dss-x. > > Submitted comments (for this work as well as other works of > that TC) are > publicly archived and can be viewed at: > http://lists.oasis-open.org/archives/dss-x-comment/. > <http://lists.oasis-open.org/archives/dss-x-comment/> All > comments > submitted to OASIS are subject to the OASIS Feedback > License, which > ensures that the feedback you provide carries the same > obligations at > least as the obligations of the TC members. > > OASIS and the DSS-X TC welcome your comments. > > > Best regards, > > Juan Carlos > > ------------------------------------------------------------ ------- > Mail archive for ESI can be browsed at the following url: > http://list.etsi.org/ESI.html > > ------------------------------------------------------------ ------- > ------------------------------------------------------------ --------- 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_work groups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]