[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Further thoughts on XML Signature on Registry
Here are some further thoughts on vanilla SOAP and ebXML MSG signing for Registry. 1. Envelope: Envelope has the <ds:/> elements as the last element of <SOAP-ENV:Header> This will work for both MSG and vanilla SOAP. In the vanilla SOAP we don't need to use <eb:Manifest/> (what this results is in an ability to check conformity with ebXML schemas -which is not reqd anyway). In the ebXML case, use <eb:Manifest/>. Signatures are optional, and is primarily used for source authentication - data integrity is done thru payload signing. 2. Payloads: Payloads of requests to Registry have the RegistryRequest as the first payload. If we design it this way, it will work for both vanilla SOAP and ebXML MSG. It is possible to have the RegistryRequest signed as per Registry.xsd, if we enhance Registry.xsd with <ds:/>. The other payloads need to be signed with enveloping signatures if non-XML, and enveloped signatures if XML. 3. Contracts: ebXML MSG can refer to a CPAId, whereas vanilla SOAP can refer to a Registry Profile - can we enhance Registry.xsd (<Registry Profile>) to include <ds:KeyInfo>? 4. Positioning: use of vanilla SOAP does not give the sophisticated features (reliable messaging, in particular) of ebXML MSG. ebXML MSG also has some advanced features (security profiles and such) that are useful for a sophisticated user. This message, I hope you agree, should be a basic principle. Like to thank Farrukh for an enjoyable conversation on the topic. Regards, -Suresh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC