Arien: I think the plan of attack makes sense. The one key phrase I'd like to emphasize from your post is "fit into a trust framework." Trust policy decisions can heavily influence the solution possibilities of the four component areas. It's a balancing act between making it "secure enough" that users and implementers trust it, but not so heavyweight that the implementation is awkward. David: I'd like to avoid assumptions, for the moment, about certificates and the trust framework. I took a shot at explaining my perspective in a thread [[http://nhindirect.org/message/view/Specifications+and+Service+Descriptions/21511939|here]], but I'm currently not happy with my attempt. I'm working on a simple way to express a realistic approach to the issue, or at least more clearly lay out what I see as the policy guidance that must occur. As far as packaging and payloading is concerned, I think multipart MIME is a viable candidate. It is standardized through many IETF RFCs and is well understood to the far edges of the network (even with existing tools). It doesn't assume anything about the transport (HTTP, SMTP, etc...) and it has standard capabilities for payload encryption/signing (S/MIME) that (depending on the NHIN Direct trust policies developed) could be useful. On the flip side, I don't think NHIN Direct should prescribe content beyond requiring IANA-approved (or on approval-track) media types for MIME Content-Type. Of course, any examples or suggested best practices that become associated with the NHIN Direct effort (or that come from commercial innovation) could drive practical usage. More on this debate can be found [[http://nhindirect.org/message/view/Specifications+and+Service+Descriptions/21511779|here]]. Brett

I posted a few comments related to this blog entry and Arien's previous entry ("Services strawcase and trust enablement") over on the discussion area of the "specifications and service descriptions" page of the wiki: http://nhindirect.org/message/list/specifications+and+service+descriptions If possible I'd like to see any detailed discussion happen on the wiki. Brett

I like the analogy above. While every effort should be made to streamline participation in the resulting exchange of information, we'll want to build a reasonably stringent identity verification process into the credentialing effort. It may be difficult to come to consensus on what "reasonably stringent" will mean, but the sensitivity of the information being transmitted argues strongly that possession of a credential communicates confidence that the holder is who he claims to be.