no way to add a ResourceResolver for cid: scheme

[GoogleCodeExporter]

What steps will reproduce the problem?
1. The Attachment Complete and Attachment Content transforms rely on URLs using 
the cid: scheme to retrieve the attachment with the matching Content-ID. 
Unfortunately, since XAdES4J does not expose the Santuario XMLSignature, it is 
not possible to register our own ResourceResolver to find the attachment. This 
will require new APIs in XAdES4J.

What is the expected output? What do you see instead?
Ultimately, we want to be able to use a Reference pointing to an attachment of 
the document using the Attachment Complete or the Attachment Content transform. 
This will execute user code to actually retrieve the attachment that matches 
the cid: URI in the Reference.

What version of the product are you using? On what operating system?
1.2.0
Windows 7

Please provide any additional information below.

Original issue reported on code.google.com by clementp...@gmail.com on 10 Nov 2011 at 9:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm not familiar with those transforms, but I'm assuming this can't be done 
using the existing resolvers and the transforms.

At which level do you need to register the resolver? Globally (probably using 
ResourceResolver.register(String className))? Per signer/verifier (i.e. on the 
signature/verification profiles)? Or per reference (i.e. a new DataObjectDesc 
for this case)?

The first option can always be done, even with apache configuration file. 
Nevertheless, having the possibility to override it is important. From the 
other 2 options, I think that the "per profile" is the one that makes more 
sense, since we already have anonymous references taken care of. Do you know 
any scenario where the last approach would be needed?

Original comment by luis.fgoncalv on 20 Nov 2011 at 3:37

[GoogleCodeExporter]

The bug is asking for registration of ResourceResolvers, but it should also be 
possible to register new transforms.

We implemented the Attachment transforms ourselves using JSR-105. I'm not sure 
how this is done in Santuario.

I think the registration can be on the profile. What ever you choose, this 
needs to be thread-safe. By that I mean, I should be able to run with a certain 
set of transforms/resolvers in one thread, while concurrently run with a 
different set of transforms/resolvers in another thread.

Clearly, global registration in static variables won't be good enough. It could 
still be done, but another mechanism to register in a smaller scope must be 
offered.

Original comment by clementp...@gmail.com on 23 Nov 2011 at 10:21

[GoogleCodeExporter]

Original comment by luis.fgoncalv on 24 Mar 2012 at 11:40

• Changed state: Started

[GoogleCodeExporter]

Clement, I've been looking into Santuario's API and I don't think there is a 
way to register Transforms as there is for ResourceResolver (per XMLSignature). 
The  TransformSpi is always initialized from a static map.

The code is a bit twisted on 1.4.5:
http://svn.apache.org/viewvc/santuario/xml-security-java/tags/1.4.5/src/org/apac
he/xml/security/transforms/Transform.java?view=markup

But better on trunk: 
http://svn.apache.org/viewvc/santuario/xml-security-java/trunk/src/main/java/org
/apache/xml/security/transforms/Transform.java?view=markup

Anyway, do you have any info I may be missing? Any other suggestion?

With respect to ResourceResolver..do you know why they have ResourceResolver 
and ResourceResolverSpi? When new resolvers are registered, the spi class/class 
name is used, but on getInstance they return ResourceResolver. I think I'm 
going with ResourceResolver on profile configuration since on Manifest class 
they actually wrap spi's when adding them:

this._perManifestResolvers.add(new ResourceResolver(resolverSpi));

Original comment by luis.fgoncalv on 27 Mar 2012 at 9:36

[GoogleCodeExporter]

I don't remember seeing APIs to register Transforms (but I never looked for 
them either). If they are missing, you can submit a patch to Santuario or leave 
it out of your API for now. I don't think there is a big demand for custom 
Transforms.

ResourceResolver/ResourceResolverSpi is probably patterned after the JCA (e.g. 
KeyStore/KeyStoreSpi) except the Spi classes have leaked into the public API of 
Santuario.

Since you can go from ResourceResolverSpi to ResourceResolver but not the other 
way around, you have to be careful you can always use the ResourceResolver in 
the context you need it. Luckily, XMLSignature has both 
addResourceResolver(ResourceResolverSpi) and 
addResourceResolver(ResourceResolver). I would probably be OK with 
StorageResolver if that's the only context you need it.

If you look at other resolvers, there is lots of confusion. StorageResolver 
accepts StorageResolverSpi and the rest of the API takes StorageResolver. 
KeyResolver accepts static KeyResolverSpi's, but the rest of the API takes 
KeyResolverSpi for internal resolvers. The rule is not clear and I don't 
understand it.

Why don't you ask your question on the Santuario mailing list?

Original comment by clementp...@gmail.com on 28 Mar 2012 at 8:03

[GoogleCodeExporter]

When you posted your first comment on this issue I understood that you needed 
to register custom transforms in a smaller scope, as with resource resolvers.

"while concurrently run with a different set of transforms/resolvers in another 
thread."

On the last comment you said "I don't think there is a big demand for custom 
Transforms". This means that global registration is enough? Why isn't it enough 
for resource resolvers? just to be sure..

I agree with you on ResourceResolverSpi vs ResourceResolver. I'm going with 
ResourceResoulver.. Santuario's addResourceResolver(ResourceResolverSpi) 
actually wraps it on a ResourceResolver and invokes the overload.

Original comment by luis.fgoncalv on 29 Mar 2012 at 5:20

[GoogleCodeExporter]

We used the JSR-105 API. I am familiar with the encryption API of Santuario, 
but not its signature API.

Registering Transforms is probably more common than I make it sound. To solve 
this problem we registered our own JCE provider and declared our 
TransformService mappings there. Maybe Santuario has a more direct solution, 
but I'm hoping this might continue to work.

In JSR-105, the URIs are resolved with a URIDerefencer that is registered in 
the DOMSignContext. Our URIDereferencer handles cid URIs or calls the default 
dereferencer for other URIs.

In Santuario, the ResolverFragment obtains the Document from the URI Attr. A 
cid ResourceResolver needs access to the Attachments. It cannot be a property 
on the sign context since it is not passed to the resolver. It could possibly 
be a UserData on the Document. It would be cleaner to pass the Attachments as a 
resolver property, or even better on the resolver constructor. I believe this 
requires local registration.

I don't have experience with Santuario's ResourceResolvers. This needs more 
investigation.

Original comment by clementp...@gmail.com on 30 Mar 2012 at 2:15

[GoogleCodeExporter]

I'm not familiar with the attachment transform, I need to read about it before 
going further. But on your last comment, by "local" do you mean "on each 
sign/verify operation"?

Original comment by luis.fgoncalv on 1 Apr 2012 at 8:16

[GoogleCodeExporter]

The need for the Attachment Transform becomes clearer after you read the SOAP 
with Attachment spec.

by local I mean: for each document signed or verified. If I can pass a new 
document, I should be able to pass the attachment context too. This might not 
be within the call, but then a previous call must always be possible. I don't 
expect XAdES4J to understand my attachment context, but I expect to be able to 
configure my own resolver so I can handle it myself.

Think of the attachment context as the JavaMail MultiPart object obtained by 
parsing the HTTP request entity containing a SOAP request and a binary image.

Original comment by clementp...@gmail.com on 2 Apr 2012 at 4:17

[GoogleCodeExporter]

So, the resolver needs to be configured per sign/verify operation, which is 
different from what we discussed on the first comments to the issue (we 
initially discussed per profile). For the sign operation, I think I'll go with 
a withResourceResolver method (or similar) on SignedDataObjects, meaning "also 
use these resolvers when processing these references".

Original comment by luis.fgoncalv on 5 Apr 2012 at 8:52

[GoogleCodeExporter]

Yes, you need to be able to set the resource resolver on the SignedDataObjects. 
Setting a ResourceResolver on the profile can also be interesting but it would 
not be sufficient.

Original comment by clementp...@gmail.com on 5 Apr 2012 at 4:28

[GoogleCodeExporter]

Original comment by luis.fgoncalv on 6 Apr 2012 at 11:21

• Changed state: Fixed