Pim,
Yes - there are two parts to this - ebMS and Registry - as you note.
The IHE folks are moving to adopt v3.0 registry and ebMS - so that is good.
I don't think we need a native SMTP interface for registry - that use case turned out to be weakly used - because people already have SMTP servers and they just use those directly if they need to via their platform/language tools.
I do believe though that a simple request/response ebMS interface for registry would be useful - especially for federated queries - to compliment the Web service one.
This would also address your concerns about security and access - et al - because those profiles the registry can keep itself using XUA, SAML and so on - separate to the messaging transport. And IHE/XDS are already doing that - creating use cases for XUA, SAML and those profiles.
For direct CRUD access - I believe the REST interface is the most likely choice for people - for UI interfacing - so again that simplifies the access model and security by limiting the use case there.
So I agree that providing v3.0 ebMS push/pull would be useful in support of registry. Also - S2S alerting and notification messages based on triggers inside registry (non-SMTP).
Easiest way to do that would be to publish a non-normative note on V3 ebMS and registry use profiles?
DW
"The way to be is to do" - Confucius (551-472 B.C.)