OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-security message

[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