- From: <kuehne@trustable.de>
- Date: Wed, 7 Apr 2010 15:00:02 +0200 (MEST)
- To: Frederick.Hirsch@nokia.com, tlr@w3.org
- Cc: public-webapps@w3.org
Hi Frederik, hi Thomas ! I don't want to critisize the decisions taken by your group. To keep implementations and testing easy is a good reason ! But from my outside view it's a bit suprising : Seeing that XMLDSig is used let's me expect a complex solution. So it would be good to read at the introduction level that the use of XMLDSig is limited to a small subset and doesn't necessarily implies a huge infrastructure. Another aspect of XMLDSig's complexity is the way people used work with it. For example I would add a canonicalization step to each external XML document without thinking about it ... So I would mandate an explicit note in the spec and maybe a special error definition in case a canonicalization is used or other widget specific constraints are violated. Greetings Andreas ----- original Nachricht -------- Betreff: Re: Widget Signature modification proposal (revised) Gesendet: Mi, 07. Apr 2010 Von: Frederick Hirsch<Frederick.Hirsch@nokia.com> > Andreas > > The intent of the proposed change is to remove ambiguity and thus > enable interop - not to make it more complicated. > > I think having a clear profile with fewer choices should make it > simpler for implementation. > > This may be on the agenda for the call this Thursday. > > regards, Frederick > > Frederick Hirsch > Nokia > > > > On Apr 7, 2010, at 6:04 AM, ext Thomas Roessler wrote: > > > kuehne@trustable.de wrote: > >> from the implementors perspective these modifications don't > >> introduce too much trouble. But I'm a little bit concerned about > >> the explicit ban of canonicalizations for 'external' documents like > >> config.xml. > > > > It is, in the first place, the default behavior of the XML Signature > > Reference Processing Model for external documents. > > > > You're right that there's a possible design choice here to *permit* > > (not > > mandate) canonicalization regardless. It sounds like you suggest that > > the WG make that choice, by not prohibiting use of C14N for XML > > content, > > but simply leaving it open? > > > > > --- original Nachricht Ende ----
Received on Wednesday, 7 April 2010 13:00:33 UTC