Ok, I've been giving this some more thought and I think a hybrid approach works very well. As has been pointed out a number of times in this thread, there are existing elements in other namespaces that provide a algorithm/hash pairing. I think that the Link Extensions Draft can provide a attributes for the most basic hash algorithms and applications that require hash algorithms that are not covered can fall back to the extension elements.
e.g. <link href="foo" md5="abc...xyz"> <media:hash algo="GOST">123...456</media:hash> </link> This would allow for the most common cases to be easily covered while allowing for the full range of possible cases to be handled as well. - James On Wed, May 12, 2010 at 8:50 PM, Richard Salz <[email protected]> wrote: >> So the key question is: what are the main algorithms we need to >> provide attributes for? > > This is a hard question to answer -- especially for hash/digest algorithms > which tend to fall more rapidly than vetted crypto algorithms. > > It's more verbose, but I strongly recommend using a pair of attributes to > represent algorithm/value. Use the URI's defined in the latest XML DSIG > document, perhaps with the "trick" that relative URI's ar a shorthand for > the xmldsig namespace. > > /r$ > > -- > STSM, WebSphere Appliance Architect > https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ > > -- - James Snell http://www.snellspace.com [email protected]
