Re: [ubl] MINUTES FROM EUROPE ASIA UBL WORKING SESSION WEDNESDAY6th JULY at 0800 UTC

[Diego Ballve <diego.ballve@digital-artefacts.fi>]

Stephen Green wrote:
>>In the WS Security case, the signature exists as long as the SOAP message
>>exists, after that the references might not make much sense (though you
>>could go complex and use your custom URI resolver that would point to
>>the right parts even without the SOAP message).
>>
> 
> 
> Good afternoon Diego,
> 
> I'd be interested in how the signature holds the references to the right
> parts
> and how you think a custom resolver might point to these downstream as this
> might be another potential solution to another problem of how to reference
> one attachment from another (at least as long as the SOAP exists but even
> after that too perhaps). Any help here would be appreciated.

Hi Stephen,

The wss:Signature, nested a few levels deeper, contains elements like:
- <ds:Reference URI="#MsgBody">, referencing element <S11:Body 
wsu:Id="myBody">.
- <ds:Reference URI="cid:foo";>, rerencing mime part with “Content-ID: 
<foo>” (read attachment "foo". You could then have another ref to 
attachment "bar" and so on). That "cid" is defined as [1].
- some other ref with XPath (I can't remember how it goes)

When signing/verifying some XML, you may need to tell your XMLDSIG API 
how to resolve those URIs if your API allows it. It should already 
handle the above examples if it is WSS compliant, but if it is 
extensible (Transformer API has setURIResolver, for instance) you code 
the resolver to return your document/attachment even if it is in a 
separate file, for instance. The resolver should return a stream (I have 
a concrete example using Java somewhere in ebxmlrr code, I can dig it 
out for you if you are interested).

That much for how the signature holds references, I'm not sure if this 
is the answer to your problem. WS Security TC might give you a better 
idea, though I believe they solve the problem of "security during 
transport" and not after that.

[1] "CID: Content ID scheme for URLs. Refers to Multipart MIME body 
part, that includes both MIME headers and content for that part. 
[RFC2392]", from wss-swa.

Regards,
Diego

-- 
Diego Ballve
Digital Artefacts Europe
http://www.digital-artefacts.fi/