Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security

W3C Recommends XML Signature Syntax 110

Posted by michael from the sealed-with-a-kiss dept.
__past__ writes: "The W3C released a recommendation on XML Signature Syntax and Processing. The interesting point is not only that this is quite an important step for secure XML processing (esp. with regarding to web services), but also because there are some possibly ugly patent issues."
This discussion has been archived. No new comments can be posted.

W3C Recommends XML Signature Syntax More

W3C Recommends XML Signature Syntax

Comments Filter:

  • scary (Score:4, Interesting)

    by SirSlud ( 67381 ) on Friday February 15, 2002 @11:12AM (#3013489) Homepage
    Patents really have shifted from implementation to idea in the software world, it seems.

    And doesn't the W3C accept RAND licensed patents now a W3C endorsed standards? (I can't recall if that went through or not.)

    • Re:scary (Score:2, Informative)

      by chrisP_999 ( 559160 )
      I think there's a note out there saying that royalty free (rf) licensing should be the "preferred" method.

    • Re:scary (Score:3, Insightful)

      by j7953 ( 457666 )

      It's even more scary for me. I live in Germany, where digital signature are treated almost equally to normal signatures in many areas (the laws are based on European legislation, so other European Union member countries should have similar laws). Digital signatures aren't widely used yet, but I think you'll agree that such laws have lots of potential uses.

      I am, however, very worried about legally binding signatures being subject to patent issues. Signatures are commonly used to sign contracts of high legal importance, where at least one party wants to have written proof of the contract. Having digital signatures convered by patents will make free software implementations more difficult or even impossible, and the idea that signing a contract will be possible only in ways that the signees don't completely undestand and cannot fully control (because the implementation is proprietary) certainly doesn't sound like a good idea for a democracy.

    • You mean, it's unlawful to patent "the signing of electronic documents", because it's only legally possible to patent "the addition of a PGP-standard base-64 signature to the 'signature' property of an XML document"

      Or along those lines. Any patent covering an idea is, by definition, invalid.

  • Don't get me wrong, I like XML (Score:1, Funny)

    by Anonymous Coward
    but I don't see how the W3C should have any jurisdiction over it. They are a Web standards body and they should leave satellite radio alone.
    • Don't get me wrong, I like XML but I don't see how the W3C should have any jurisdiction over it. They are a Web standards body and they should leave satellite radio alone.

      Actually, I'd give this a +0.5 funny and a +0.5 obscure [xmradio.com], but it totals to +1 both ways.

      Besides, my rating system is just a figment of my imagination, right?

      -- MarkusQ

    • Yeah i agree why should W3C have the patent on XML It seems it's more about book sales than advancing coders skills afeter all the open source movement are just pit ponyies for commercial wankers

  • W3C / XML brain damage (Score:3, Insightful)

    by brenfern ( 260941 ) on Friday February 15, 2002 @11:25AM (#3013534)
    Yet another dull-as-dish recommendation from the W3C, not even a reference implementation to play with.

    Ever since they have gone XML-with-everything they have produced ineffectual standards that are not followed by anybody as they are a pain in the ass to implement. It is no wonder that M$ and Sun prefer to create de facto standards instead of waiting for these guys to actually do anything. The killer app is the way to create standards and it's been a dozen years since we've seen one from the W3.
    • XML is a very convenient standard for defining and parsing documents. This makes it a very useful framework to extend upon (ooh, so that's where the X comes from).

      Also XML is easy to validate. This should put an end to invalid web documents.

      'The killer app' is not the way to make standards, since the app needs to be available for everybody you want to communicate with.
      --
      • A useful framework for some types of data it may be (specifically, markup data), but I feel that XML is too often used outside the scope of its main strengths. Specifically, object serialisation, transmission and other such protocols are handled more elegantly by ASN.1 [elibel.tm.fr], Java serialisation (which can just as easily become a standard for other languages) or just rolling your own, program semantics by LISP syntax etc.

        Far too often W3 encourage the blinkered approach that XML is the only way to express things. Stuffing base64-encoded strings into markup tags to be parsed at the other end is just not convenient and I think it can be done better.
    • Umm - no. You don't know what you're talking about. Why would W3C produce a reference implementation - they're a standards body, not a software house.



      And a lot of their XML standards have had a far reaching impact on real software development. What was your message supposed to mean, again?

      • Why indeed would the W3C produce a reference - but that's not what he said. He simply said "there was no reference implementation" by ANYONE (or at least that was the impression I got).

        When the XML standard was being hammered out, there were a number of refence implemnetations. What he's complaiing about (and I agree with) is standards developed out of thin air, without any kind of reference to help give the thing solid footing. A lot of ideas sound great on paper but need to be tweaked to make implementations practical AND USABLE. I'm not sure I've seen a single standard I liked that did not have a reference implementation developed along with the standard.

        That said, I've not looked at the spec itself (yet) so it might be great for all I know.
      • The web browser was the W3's (or, as it was, CERN's) big killer app. In the good old days they used to actually make things to prove that their standards would lead to useful technology. Do you really believe that the W3 should solely chair committee meetings and never get their hands dirty? Can good technology be designed in a vacuum? There is no seperate world of "standards bodies" here and "software houses" there - the most successful way to create a standard is to lead by example, and release a reference implementation. Presumably the W3 must have a prototype implementation somewhere; if they released it, more people might take their standards seriously. As it stands, a standard with no implementation can only be evaluated on by speculating about its theoretical merits - which is a risky strategy.

    • There is XML digital signature support in .NET. Since it was released prior to the W3C recommendation it may not be fully compliant but it looks similar. Hopefully now they will update their implementation (what were they supposed to do, delay .NET until W3C got around to publishing the recommendation?).

      See this page [microsoft.com] for more info and sample code.

      • Since it was released prior to the W3C recommendation it may not be fully compliant

        Since when does that matter?
        (-:
      • The XMLDSIG implementation in the .NET Framework is fully compliant with the final XMLDSIG Recommendation. (I'm a co-author of the XMLDSIG standard and my group at Microsoft owns the XMLDSIG implementation in the .NET Framework.) The .NET Framework implementation was one of the original four to participate in interop testing at the Pittsburgh IETF (July 2000) and we tracked every change in the spec since then.

        The classes implementing XMLDSIG are located in the System.Security.Cryptography.Xml namespace in the System.Security.dll assembly.

        --bal

    • see http://www.w3.org/Signature/ for implementation

  • Free the ideas or drop it (Score:2, Interesting)

    by Anonymous Coward
    The W3C should eather get unrestricted free rights the XML Signature or find a new way of doing it. "Most patents are just logical extensions of existing ideas wrapped in legaleze to sound different"

    Shaun
    • W3C are not programmers they sit around taking
      about data structures

      Then when they decide that a certain data structure looks ok so they implement it

      It's laughable but that's how it happens, and then some programmer say's you can't do that because of such and such, then they go away and think again and come up with an even more ridiculous solution that gets approved

      What a load of bollox, if this is the future of the internet god help us

  • what made the web work (Score:4, Insightful)

    by Alien54 ( 180860 ) on Friday February 15, 2002 @11:39AM (#3013591) Journal
    with the progress towards XML, etc. the WWW is moving away from those things that made the explosion of the WWW possible. The inherent simplicity in HTML, as something you could get the basics of in a few days of mild effort, or in a morning, if you were ambitious, is disappearing.

    What I am nervous about is that with the advance towards the more sophisticated technologies, the earlier simpler technologies will be "obsoleted". This may have implications for the democracy of the web slowing going away because only experts can do what used to be an everyman task.

    • Re:what made the web work (Score:5, Insightful)

      by NineNine ( 235196 ) on Friday February 15, 2002 @11:43AM (#3013611)
      Simplicity? XML is about as simple as you can get. XML is just straight text in tags similar to HTML. Of course, it's only go to do with data transfer, but XML is generally very simple. And for those people who don't know "data" from a hole in thr ground, there's no reason to use XML in the first place.

      • Re:what made the web work (Score:3, Insightful)

        by Anonymous Coward
        Let me disagree here. Sure the syntax is relatively simple - although even that could be dumbed down - but what it describes is kind-of complicated. XML describes a graph, but it does so with three kinds of edges. Subelement relationships let one define a tree, attribute relations are a different type of edge that can only be used at the end of the tree, and then one can introduce cycles with IDREFs.

        From a semi-structured data point of view, all that's needed is one type of edge, which would make things much easier to reason about.

        Ordering is another point of contention. Attributes are not ordered, but subelements are. Messy.

        The crux of the problem with XML is that it was invented by structured document folks (as a simplified successor to SGML) and then later latched on to by the database folks who realized that it looked like semi-structured data. The design is something that I don't think database folks would have come up with if they were the ones designing it

        Of course, all of the terrible committee-made standards that are being layered on top of it don't help, but I suppose that's not a complaint with the core of XML.

        cheers!


        • Out of personal interest, would you know a good source on semistrucured data? It seems common consensus that semistructured data can be modelled as graphs with labels on edges, whereas XML has labeled nodes. Is there a such thing as a definition of semistructured data other than "schemaless, self-describing"?

          Thanks.

      • XML is no longer simple (Score:5, Insightful)

        by Carnage4Life ( 106069 ) on Friday February 15, 2002 @01:11PM (#3014043) Homepage Journal
        Simplicity? XML is about as simple as you can get. XML is just straight text in tags similar to HTML. Of course, it's only go to do with data transfer, but XML is generally very simple. And for those people who don't know "data" from a hole in thr ground, there's no reason to use XML in the first place.

        In the good old days, XML was simple but this is no longer the case as the W3C has created more and more complex standards that seem to require a P.hD to understand.

        • Want to specify a structure for your XML? XML [w3.org] Schemas [w3.org]
        • Want to query XML? XQuery [w3.org]
        • Want to transform XML to some other format? XSLT [w3.org]
        • Want to use XML as a transfer format for RPC calls? SOAP [w3.org].
        • Want to create links between XML documents? XPointer [w3.org], XLink [w3.org], and XML:Base [w3.org] are all needed.
        • Want to include XML files in each other? XInclude [w3.org]
        Many of the above standards are rather complex and difficult for most people to understand completely. This is besides the stuff one has to understand about XML infoset [w3.org] and XML namespaces [w3.org] to fully understand how to use XML properly.

        DISCLAIMER: The opinions in the above post are MINE ALONE and do not reflect the opinions, intentions or strategies of my employer.
        • XML is intended to by manipulated by software-- not by people directly. In the future, you will not need to "see" the xml or its gritty details. It will be possible to manipulate XML comprehensively using standards-compliant toolsets. That is what the w3c is in the process of engineering now and because of the scope and generality of the project it MUST be complex.

          It may indeed be necessary to have a PHD to grasp the inner workings of XML and all its related technologies. However, the end result of all of these efforts will be software tools made by many many software vendors that only require elementary school education to use.

          -H.
          • So I will need to purchase XML Spy, Microsoft .NET Framework, or learn to use Emacs in order to process information. That cuts out 99% of the population.

            Do you think more or fewer people create their own websites now that we have FrontPage?
            • So I will need to purchase XML Spy, Microsoft .NET Framework, or learn to use Emacs in order to process information. That cuts out 99% of the population.

              You need to make a distinction between those that process information and those that create the tools that others use to process information. If you are creating tools, yes, you do need to spend a lot of time learning complicated XML details and you do need to use some annoying technology. If you are not a programmer and you just need to "process information", XML will and is already transparently making your life easier.

              Do you think more or fewer people create their own websites now that we have FrontPage?

              Yeah more, so?

          • XML is just another, complicated, file format. Whoopee shite.
        • In the good old days, XML was simple but this is no longer the case as the W3C has created more and more complex standards that seem to require a P.hD to understand.

          To create complex things, chances are you're going to either need:
          1) A simple set of tools too basic for your needs, which requires a lot of work on your part to customize
          OR
          2) A complex set of tools made specifically for your needs, which requires knowledge of the appropriate tool to do the job effectively.

          True the standards that are out there may be complex but who is going to use ALL of them, honestly? People will learn as much as they need to know about a standard and use that. They don't need to know the entire scope of every technology they use.

          I'm sure you know that Microsoft .NET extensively uses SOAP for web services. Does that mean that someone using VS.NET needs to know SOAP? No, the tool they are using encapsulates that knowledge. Maybe they have to customize it in some way, but most of the dirty work is done by the IDE. Beautiful.

          And better yet since the standard is open, anyone or any program can read the SOAP data transferred by that server or client, and knowledgable people can use it to create a complimentary client or server on another platform. Wonderful.

          So John Q. Developer won't give a flying patootie about all of those standards if the tools that exist that USE those standards are easy to use. The standards are there so the programmers can interoperably hack with them between platforms. And this level of hacking will be at a level most developers won't see once the tools are out there, kind of like how most people don't have to hack the kernel of an OS to get their software running.

        • You have it backwards (Score:3, Insightful)

          by fm6 ( 162816 )
          All these complicated technologies actually show how simple XML remains. None of them does anything to "make XML more complicated". XML is just a specification for encoding information -- and that specification is still on version 1.0. If the XML designers did their job right, there never be an XML 2.0 or even an XML 1.1.

          The beauty of XML lies not just in its simplicity, but also its flexibility. Naturally people are using this flexibility to implement sophisticated applications -- and writing complicated descriptions of these applications. But none of these things makes XML itself more complex. You might as well say that RISC chips, such as PowerPC, stopped being simple when people started using them to emulate Pentiums!

      • No. The XML encoding might be simple, but the semantics of the various applications of XML get increasingly complex.

        E.g. take a look at the XML Schema standard. Take a look at the RDF standard. Take a look at XML Formatting Objects. I agree with the original poster, the web standards are getting more and more complex, but on the other hand, I don't think this is necessarily a bad thing -- the standards are still available publicly, and anyone is free to use them (well, except for the patent issues). If the W3C simply stopped creating new, more complex standards, other companies would do that, potentially creating standards that are much less open.

        And, let's be serious, writing HTML code with a plain text editor is not exactly democratic technology anyway.

      • Any concept sounds simple at first; for example, football (in England) is about "kicking a ball into a net". Similarly, putting "straight text in tags" seems straightforward at first but the complexity comes from the process required to implement a system around XML. Firstly, you need an XML parser - which is surprisingly non-trivial to write as there are many rules. Secondly, if you need to encode binary data, you have to use MIME or similar. Next, you need to write objects to receive XML data from the parser, as data cannot be read directly from the XML document itself (e.g. you have entities). XML-based programs, in my experience, tend to be unnecessarily unwieldy as XML is poor for representing data structure and does need parsing/serialisation to be used. For these reasons, a binary tag/length/data random access format will always win out eventually in terms of simplicity.
    • Hmmm here is quick course <Really att="not" >That_Hard</Really>

      XML is simpler than HTML.

      The new standard released is to make XML secure, since before this there is no guidlines for securing XML data. Think of it as https.
      • Nothing has really changed. A soon-to-be webmaster would start at html before they started on perl, or python wouldn't they? Its the same, learn html, then move on to the more complicated technologies(asp/php/jsp/cgi/db's etc) XML "can" be simpler than XML. There really isn't anything to worry about tho. If you have an html background and are familiar with it, you'll pick up xml/xsl/dtd fairly quickly.
      • What a load. HTTPS is a transport protocol. This spec is about signing stuff so that it can be authenticated against a key, not encrypting it during transmission.
    • What can be simpler? Once you put up the infrastructure? I'm dealing now with an intranet. it has an xml "template", you just replace the "content" area to change it. Want a new menu item in the dynamic menu on top? Let's see, I bet I just put a new
      blah

      users love it. No problem.

      What's that? Some PHB wants a new "look and feel"? I just write a new XSL stylesheet, replace it on the server, and I'm done.
      • sorry, forgot to change to "code" mode:

        I meant:
        <menuitem linkto="blah.xml">BLAH MENU ITEM</menuitem>

      • What's that? Some PHB wants a new "look and feel"? I just write a new XSL stylesheet, replace it on the server, and I'm done.

        Do you have any references for doing this type of thing? I've seen many things and people such as yourself claiming it's easy, but whenever you get to actually doing it, you end up with lots of hacks if you have a complicated design.
        • http://www.zvon.org/xxl/XSLTreference/Output/index .html

          is a good one. Particularly the xlab interactive tester to learn various Xpath things.

          I wouldn't say it is easy. It's actually a LOT of work up front, which is why it isn't widespread yet. There's a lot of work on the front end First, you define a template schema that has sections want (menu, header, content, form, footer, etc., Then, you have to write objects (java, vb, whatever) to produce XML snippets rather than scripting code to produce HTML. Usually another object assembles the snippets/nodes into the XML template. This isn't an easy change.

          Then, you have to get a grasp on XSL. This takes awhile. It's a strange language and at first you want to do everything like you would do in functional language like Java or C. You can do some basic stuff, but then it gets hard. Then I (slowly) realized it's more like SQL in terms of you get a set, then transform that etc (like a subquery).

          Short answer: it is a LOT more work up front. But later it is sweet. You let your graphic stud come up with a new layout in HTML (dreameweaver or whatever) and you write an XSL to translate into that. Maybe have him export a netscape compatible one (browser sniffing dishes out a different transform) and you have a plain text one as well (section 508 compliance becomes very easy. That's what is driving the current conversion).

          • Short answer: it is a LOT more work up front. But later it is sweet. You let your graphic stud come up with a new layout in HTML (dreameweaver or whatever) and you write an XSL to translate into that. Maybe have him export a netscape compatible one (browser sniffing dishes out a different transform) and you have a plain text one as well (section 508 compliance becomes very easy. That's what is driving the current conversion).

            Thanks for the info. The correct url is http://www.zvon.org/xxl/XSLTreference/Output/index .html [zvon.org]. Unfortunately, it sounds exactly like what I thought. Just another way of doing something, not necessarily better :(

            We use HTML templates for everything, where you basically have HTML with variables in it, that get replaced by the code. It gets complicated when you tables and such, or when you do anything that changes the ordering of the templates. That's what I haven't been able to find a good way of doing: specifying a template order separate from the code, while using templates that are displayed by code (such as displaying all rows in a table). Though you don't change the entire layout too often, and when you do, it's not that much code to change. I can see the advantage to using XML and XSL for everything, but it seems that it might be easier to just change the little bit of code necessary when changing layouts.

    • With XML, we are losing many useful syntaxes in the quest for a one-size-fits-all syntax that is actually quite bloated and hard to parse. Plus, the temptation to put everything into the same model is overwhelming. Just look at the readability of XSL - pure madness.

      Many XML advocates try to kill 3 birds with one stone:
      • For structured data representation & code
      • For markup
      • for data storage

      Personally I wish that if there had to be one standard syntax for human-readable data representation & code it was at least something sensible like LISP - at least then I can do paren-matching in my text editor. As for markup, SGML does have many advantages (the only disadvantage from XML is its alleged complexity), and as for storage, you can use actual databases to put our data in (you can argue the toss about RDBMS vs ORDBMS/XMLDBMS, though I think traditional RDBMS are fine really).

      Really though I hope people will learn to use lex/Yacc and choose a syntax or structure most appropriate for their needs. I have seen many a programming team replace a syntax that works with XML syntax because it is seen to be more modern. To me this is throwing out the baby with the bathwater.
      • I have seen many a programming team replace a syntax that works with XML syntax because it is seen to be more modern.

        Well, to be honest, that's another variant of "let's do it because we can" without asking why in the first place. It is not really a problem with XML in itself.

        OTOH, the perspective (the promise) of being able to use (at some point in the future) a rich set of well-known multiplatform tools and libraries to validate, manipulate and transform all sorts of XML data is so sexy that some of these "enthusiastic" moves are at least understandable...

        In the meanwhile, if the data is meant to be entered/read by a human with a text editor (i.e. configuration files), designing a grammar appropriate for the job and then using flex and bison (or the usual quick hack in Perl) to implement a translator into an equivalent XML representation (and possibly an XSLT sheet to do the opposite) is still a good idea, IMHO.

    • You forget XHTML (Score:2, Insightful)

      by Kingpin ( 40003 )

      Those who say that XML is simple are IMO not correct. XML can be veru complex, you cannot just make up new tags - they have semantic value in respect to a given target. This means that you have to have a target application that understands your XML, not much simplicity there. XML is not a language, it's a syntax. The syntax is easy, agreed, but implementations may have any complexity level.

      XHTML is an XML schema. It's HTML that's valid XML, ie. it conforms to the XHTML DTD/Schema. For most it suffices that it's well-formed XML and as such can be parsed into a DOM tree by any XML parser.

  • An Introduction to XML Signatures (xml.com) (Score:5, Informative)

    by ditoudi ( 559192 ) on Friday February 15, 2002 @11:39AM (#3013596)
    If you want more information about XML Signature, just check this article [xml.com]
    http://www.xml.com/pub/a/2001/08/08/xmldsig.html

  • Conflict of interest? (Score:5, Interesting)

    by bunyip ( 17018 ) on Friday February 15, 2002 @11:45AM (#3013619)
    So, as I understand it, a working group (WG) member creates a standard and then says, "Oh, hey, great standard guys, but now you're all going to have to pay me for it".

    Is this not a conflict of interest? Should the WG member be immediately voted off? Perhaps they should be tarred and feathered, run out of town on a rail?

    I prefer the latter approach, it may reduce the number of bogus patent claims.

    Alan.
    • So, as I understand it, a working group (WG) member creates a standard and then says, "Oh, hey, great standard guys, but now you're all going to have to pay me for it".

      The problem is... if you look at the patents that are applicable in this case... no xml signature standard would EVER not violate them.

      I'll go a long way towards talking about W3C patent reform... but this one happens to be a case of needing USPTO reform.

      -jbn

    • That's why the W3C got into such big trouble with RAND licenses. They were having situations like the one you describe. So, they tried to make an explicit policy about what their contributors were allowed to do with regards to patents. Their first effort generated quite a stir, as you might remember.

      Remember, despite the aura of benevolence surrounding the W3C, it is necessarily made up of the big players in IT--Microsoft, IBM, Adobe, etc. Those companies are big enough to have departments that want to play fair and other departments that want to make loads of cash on the patents they own. Most of those companies have done something unpopular as regards intellectual property at some point.

      It's quite a hard balance for the W3C to strike. They want to make standards that are interesting and that the big players will adopt, or they will become a useless body. On the other hand, those big companies own lots of patents and don't always want to give them up just for some lofty ideals about standards. That's why it's taking the W3C quite a while to formulate a policy that everyone is willing to work under.

  • Non-adoptable Standards (Score:5, Funny)

    by jfrumkin ( 97854 ) on Friday February 15, 2002 @11:59AM (#3013687) Homepage
    So, you release a standard that has a number of patent questions surrounding it...hmmmm, let's see how many people jump at the opportunity to adopt something for which they could be sued or made to pay unknown license fees....

    Another thought: Can I patent the idea of patentable standards? Sounds like a business model to me...

  • Wow, who would have thought this !? (Score:3, Funny)

    by shiva600 ( 323459 ) on Friday February 15, 2002 @12:15PM (#3013773)
    XML Signatures can be applied to any digital content (data object), including XML.

    Surprise !

  • I would hope that the community and the possible "patent holders" allow for this to go forward. There really is a need for such a technology the XML/Web Services space.

    Having the ability to sign a document, or even a fragment of a document, allows for customers to "trust" that document and its contents. Sure https/ssl is a good way to "secure" the data during transit. But how can you be sure (currently) that the document I am sending you contains the proper information?

    Think of this in a b2b ecommerce setup. I can send you my pricing sheets, in xml format, you can be sure that they are really the proper pricing, and can be assured of the "current" availablity. In the same XML document, I can include reviews and any other pertanant infromation about a given product. Digitally signed and verified from a trusted third party source. My customers are now not worried that I am trying to push a product line by falsifing results, and I am providing them with content for there catalogs...

    To me, if it makes it through any "patent problems" this could be a very good thing ;)

    -ryan
  • This thread has carried some interesting questions regarding XML Signature. I hope this will answer some of them.

    Implementation Experience for XML Signature

    http://www.w3.org/Signature/2001/04/05-xmldsig-i nt erop.html

    XML Signature has at least 11 known implmentations at the time of publication, including an open source implementation as part of the XML Apache work. (I am resisting the urge to use the subject line, "This one goes up to 11.")

    See Apache for more info on their implementation.

    http://xml.apache.org/security/

    Patent Policy/ Patents in general:

    This is an older WG and a joint WG with the IETF and it follows the policies of the (early) W3C and IETF requirements: both of these require disclosure first and foremost. If you think IETF bans RAND, you need to read this document:

    http://www.ietf.org/rfc/rfc2026.txt

    It's how the IETF does its work; and section 10 is all about IPR.

    10.3.2. Standards Track Documents

    (A) Where any patents, patent applications, or other proprietary rights are known, or claimed, with respect to any specification on the standards track, and brought to the attention of the IESG, the IESG shall not advance the specification without including in the document a note indicating the existence of such rights, or claimed rights. Where implementations are required before advancement of a specification, only implementations that have, by statement of the implementors, taken adequate steps to comply with any such rights, or claimed rights, shall be considered for the purpose of showing the adequacy of the specification.

    (B) The IESG disclaims any responsibility for identifying the existence of or for evaluating the applicability of any claimed copyrights, patents, patent applications, or other rights in the fulfilling of the its obligations under (A), and will take no position on the validity or scope of any such rights.

    In short, anything in the IETF is okay, provided you document, and the IESG claims no responsibility for either searching for patents which may be relevant to the work, or in evaluation of others claims. Forking the work to the IETF won't make any difference, given their policy is more permissive than the developing W3C policy.

    Speaking of which...

    The W3C chartered the sister WG (XML Encryption) as an explicit Royalty Free WG. See the charter:
    http://www.w3.org/Encryption/2001/10/xmlenc-charte r.html#_IPR

    Patent Disclosures

    The key thing is that both organizations do place emphasis on disclosure, though none of these members have stated that they hold patents directly relevant to this spec. The analysis, as you know, takes time.

    Quoting from elsewhere, a statement from Joseph Reagle, the co-chair of the XML Signature and XML Encryption WGs:

    http://xmlhack.com/read.php?item=1539&v=1&t=comm en t%3A309

    Re: XML-Signature Recommendation, Exclusive Canonicalization
    Candidate (Joseph Reagle (W3C Co-Chair) - 15:26, 15 Feb 2002)

    Unfortunately, it's difficult for the patent status of *anything* to be very clear.
    (It's like proving a negative: God doesn't exist.) The only clear patent status IMHO is one that has been upheld in court or otherwise considered uncontestable, and it's license has been publically excercised by many implementors.

    Regardless, there are a few ambigous statements from a few years back that folks should be aware of, but I'm not personally aware of any specific claims of infringement or licenses with respect to the 12+ implementations.

Slashdot Top Deals

God help those who do not help themselves. -- Wilson Mizner

Close