[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] MINUTES FROM EUROPE ASIA UBL WORKING SESSION WEDNESDAY 6th JULY at 0800 UTC
Hi all, Pls see our comments below. "The CrimsonLogic approach defines a uniform and standard way of attaching the signature within the COML document. The novelty of this solution is that the signature is independent of any single messaging layer security, such as ebXML, AS2 or Rosettanet. Any messaging layer can carry the standard COML document which follows the standard W3C DSIG standard. Most importantly, the signature stays within the COML document thus enabling no significant further processing or storage requirement that need to link the document and the signature. The main problem we are trying to address here is that no current available messaging layer security that address for multiple signers within a single XML document." Rgds Kamarudin Tambi Manager, Technology Development CrimsonLogic Pte Ltd -----Original Message----- From: Diego Ballve [mailto:diego.ballve@digital-artefacts.fi] Sent: Friday, July 15, 2005 12:07 AM To: Stephen Green Cc: ubl@lists.oasis-open.org Subject: Re: [ubl] MINUTES FROM EUROPE ASIA UBL WORKING SESSION WEDNESDAY 6th JULY at 0800 UTC 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/ --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]