Mailing-List: contact dev-help@santuario.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@santuario.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4EF1CD91.4010209@itumi.biz>
Date: Wed, 21 Dec 2011 07:14:09 -0500
From: Chad La Joie <lajoie@itumi.biz>
Organization: Itumi, LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: dev@santuario.apache.org
Subject: Id Resolution Observations and Suggestions
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

So, last night I spent some time digging in to the new code and
discussing with some things with Scott.  Here's where we ended up.

The IdResolver is not designed in a manner that would allow alternative
implementations to be used.  Though, given that it is only used by the
ResourceResolver implementations, those could be replaced by the user of
the library

The new code does use the Document.getElementById method to look up IDs
in the general case.  This may be overridden by explicitly placing
ID-to-Element mappings into the IdResolver, but since doing this is
neither documented nor shown in the examples it is fairly safe to assume
this isn't happening out in the wild.

Given the above, this code does not guard against any issues that may
arise from duplicate IDs.

In the case of signatures, there seems to be nothing that a library can
do in order to ensure that the "right thing" is covered by the signature
since the "right thing" is use-case specific.

In the case of encryption, there is no way for the application to know
whether the dereferenced encrypted encryption key is what the document
author actually intended.  If it's not, however, the worst that would
happen is that encrypted data would not decrypt.

Given this, I believe the following things should be done:
- The use of Document.getElementById and the potential issue caused by
the lack of a strong guarantee on ID uniqueness should be documented.
- The documentation for XMLSignature and all the examples should be
updated to make it clear that the user of the library needs to check
that what they thought was covered by the signature actually was.
- Attempting to update the examples in this way will make it clear that
better APIs need to be provided to expose the content indicated by
<Reference>s.

In addition, given the manner in which the IdResolver currently works, I
believe it could be done away with entirely. The
IdResolver.registerElementById method could simply be replaced by the
appropriate Element.setIdAttribute* method.  Doing so would remove a
potentially large in-memory data structure as well as various
synchronization points that currently prevent concurrent ID resolutions.

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered