Re: Re: Widget Signature modification proposal (revised)

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.



----- original Nachricht --------

Betreff: Re: Widget Signature modification proposal (revised)
Gesendet: Mi, 07. Apr 2010
Von: Frederick Hirsch<>

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