ACTION-581: proposal around IDness of attributes

The issue I'm trying to address with this action is the same problem that
led to the creation of xml:id.

Without a DTD, there is technically no way to define IDness in an XML
document. In practice, this typing was extended to documents validated by an
XML Schema, and then to the creation of xml:id. Unfortunately, DTDs have
mostly fallen out of practice, and schemas are expensive, rarely used in
many runtime scenarios, and can't be counted in to be completely known by
the verifying entity in the presence of extensible XML scenarios.

xml:id has not seen wide adoption yet, mainly because a lot of the standards
that needed it (SAML, WS-Security) predated it.

The result of all this is that applications that rely on ID-based references
for signing have typically made insecure assumptions about the IDness of
attributes based on their name (ID, id, Id, etc.), or have to provide APIs
for applications to call before verification (which is also a problem for
extensibility). DOM level 3, which is now fairly widely implemented, also
provides the ability to identify attributes as an ID at runtime, although
often without guaranteeing the uniqueness property.

My suggestion is that we piggyback on the proposed <dsig2:PositionAssertion>
that Pratik just added to the draft and turn this into a generalized
IDAssertion that includes not only the positional XPath expression, but also
an optional list of elements:

	<dsig2:QualifiedID name="..." ns="..."/>
	<dsig2:UnqualifiedID name="..." parentname="..." parentns="..."/>

This is analagous to the proposed mechanism for the c14n QNameAware option
to identify QName attributes, but for IDness instead.

This would tell the verifier which attributes the signer believed to be IDs,
and thus give the verifier information it might not otherwise have about how
to perform the dereference process.

Both the XPath positional expression and the list of attributes would be
optional, or we could leave the PositionAssertion alone and add a new one
for this information. I suggest combining them simply because they both deal
with ID-based reference information.

I like using the Verification step as a container for this proposal because
it again pushes the complexity onto verifiers that want to use the
information without complicating applications that might have other ways of
dealing with IDs already.

-- Scott