Fwd: Wikispaces: Monitored Discussion: "MU2 Compliance, Trust Bundles, and Java RI Releases"

[George Lilly]

---------- Forwarded message ----------
From: Wikispaces <do-not...@wikispaces.com>
Date: Tue, Dec 18, 2012 at 1:18 PM
Subject: Wikispaces: Monitored Discussion: "MU2 Compliance, Trust Bundles, and Java RI Releases"
To: gli...@glilly.net

A Wikispaces user has posted a message to a discussion you are monitoring. Please visit the url below to respond; do not reply to this email.

Subject	MU2 Compliance, Trust Bundles, and Java RI Releases
From	gm2552
Date	Dec 18, 2012 1:18 pm
URL	http://wiki.directproject.org/message/view/Java+Reference+Implementation/59250336#59250336

As I mentioned a few weeks ago in a previous post [1], the Java RI team is committed to providing an MU2 certifiably Direct implementation. As promised, although a few weeks late, we are completing our work and will publish a fix release version of the Java RI before the holiday is upon us. We have run the RI against each transport and certificate discovery test, and, with one exception (more on that in a moment), have passed every test.

You may have also heard rumblings regarding trust bundle distribution from the Direct scalable trust forum a few weeks back. We are still waiting on the official kick off of the workgroup, but there has already been some preliminary work going on in the field to satisfy the accelerated timetable of the Automate BlueButton Initiative (ABBI). The hope is that our initial work will be picked up by the trust bundle workgroup, so our efforts will not be a demo or otherwise throw away implementation/code. The plan is to release a trust bundle configuration and anchor store in both .Net and Java RIs by the end of January so pilots can be ready in time for HIMSS.

So.... below is the timetable for the next Java RI releases:

Dec 18: Java RI 2.0.1-SNAPSHOT [2].... SNAPSHOT version currently in validation
Dec 20: Java RI 2.0.1... Release of fixes for MU2 compliance
Jan 31: Java RI 2.1.0... Initial trust bundle support

Back to the failed MU2 test: Certificate discovery test DTS 517 currently fails in the both the .Net and Java RIs. After review of the test description, we have been in contact with Nitor Group and have questioned the validity of the test. This test is based on an unclear interpretation of the certificate discovery implementation guide for Direct [3], and Nitor Group has requested clarification from ONC. We will not providing a fix to the test failure until we get clarification from ONC.

[1] http://wiki.directproject.org/message/view/Java+Reference+Implementation/58358370

[2] https://oss.sonatype.org/content/repositories/snapshots/org/nhind/direct-project-stock/2.0.1-SNAPSHOT/direct-project-stock-2.0.1-20121218.180956-1.tar.gz

[3] https://docs.google.com/document/d/1igDpIizm7CTfV-fUw_1EnrCUGIljFEgLPRHpgK5iaec/edit

---

To change what you are monitoring, visit your monitoring page. Please email he...@wikispaces.com if you have any questions.

[George Lilly]

---------- Forwarded message ----------
From: Wikispaces <do-not...@wikispaces.com>
Date: Wed, Dec 19, 2012 at 4:52 AM
Subject: Wikispaces: Monitored Discussion: "MU2 Compliance, Trust Bundles, and Java RI Releases"
To: gli...@glilly.net

A Wikispaces user has posted a message to a discussion you are monitoring. Please visit the url below to respond; do not reply to this email.

Subject	MU2 Compliance, Trust Bundles, and Java RI Releases

From	bachmanp
Date	Dec 19, 2012 4:52 am
URL	http://wiki.directproject.org/message/view/Java+Reference+Implementation/59250336#59269604

So here's my take on why the MU2 test on certificate discovery fails from my perspective.

This is a result of not getting the modular specifications right leading to some explicit assumptions in the Applicability statement.

I have even had this bite me in the certification stage when I have been quoted back requirements on Direct Applicability incorrectly vis a vis what we worked on, (namely every query always had to go thru DNS each time a certificate was used to send a mail message) and a couple of excellent phone calls with you and John Hall before the latest version of the applicability statement.

If one encounters an SRV load balancing configuration, then the data should be the same no matter which server is contacted. It should look like one server. One is looking at the servers from the point of view of DNS and why SRV was designed. But there is more...

In the case of the test scenario it was misconfigured with different data for DTS-517 either by mistake or intentionally to explore this concept based on the question posed in test scenario.

To me the question was to what extent to continue the chain of responsibility pattern or to stop?

The first server reached due to the SRV value with the DTS 517 query had no user certificate attribute whatsover. Connection, but no attribute. That's a fail in configuration. I remember similar fails in DNS round robin.

That's a limitation on how SRV was intended to work, same data but load balanced.

So a simple misconfiguration giving invalid results solved by replication between the instances, so they converge, or just copying over the correct data for the attribute and certificate. But the real issue is the combination of two patterns.

I don't think a clarification from ONC is required in this case, the test was just set up wrong, and then they also got some erroneous information from DirectTrust, which is not authoritative on setting up Directory certificate results in terms of the network plumbing but highly knowledgeable about the meaning of the certificates, policy, practices, governance, etc.

But this does bring up an interesting point in terms of the comments on the defect, which is how does one get to the built in advantages via SRV of the X.500/LDAP referral, chaining and replication features?

In short one does not. That's really more pertinent to the Law of Demeter software design concept, rather than Chain of Command pattern that we used in S&I for the Hybrid Model.

Where Chain of Responsibility pattern says "try this until you get an acceptable answer" the Law of Demeter says "talk to your friends, without going thru another step or object"

So we separated those two concepts based on knowledge. Global discovery worked really well with DNS SRV so an X.500/LDAP server could be found based on the only the knowledge of the Direct Address and or Domain in the subject alt field.

However the "talk to one's friends" concept really worked well to be making request within that structure in which the directories were themselves linked in the Directory Information Tree via what is called "superior knowledge".

So in that case once you knew the location of the Directory server entry point, one did not need to repeat the query to find it again, since one was within the design of the network tree.

For whatever reason, that did not make it over but was documented in S&I consensus and the error seems to come up around modular specifications ignoring the two different concepts of the design patterns.

http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern

http://en.wikipedia.org/wiki/Law_of_Demeter

http://www.x500standard.com/index.php?n=X500.Navigation

[George Lilly]

---------- Forwarded message ----------
From: Wikispaces <do-not...@wikispaces.com>
Date: Wed, Dec 19, 2012 at 12:07 PM
Subject: Wikispaces: Monitored Discussion: "MU2 Compliance, Trust Bundles, and Java RI Releases"
To: gli...@glilly.net

A Wikispaces user has posted a message to a discussion you are monitoring. Please visit the url below to respond; do not reply to this email.

Subject	MU2 Compliance, Trust Bundles, and Java RI Releases

From	edward.oconnor
Date	Dec 19, 2012 12:07 pm
URL	http://wiki.directproject.org/message/view/Java+Reference+Implementation/59250336#59279328

This was actually our position as well (same data but load balanced) in terms of our personal opinions (of the Nitor Group staff) - but that is based on how LDAP is deployed in the real-world (not particularly with Direct) as opposed to explicit specification support and what got stated in our community query/vetting process.

The role of spec analysis was not held by us so I can't speak to exactly who answered this originally. However, note that questions went out into the Direct community in general during mod-spec (not specifically to DirectTrust.org - that's just one of the WGs who was active and contained community members who answered in this case). Meaning: the spec folks asked anyone who would listen, documented what they heard, and vetted it publicly (ask all, document consensus or escalate disagreement, vet publicly, and fix what escapes publicly after release). We based the tool on the approved document and make changes when the foundation gets modified.

Meaning: it looked wrong to me too (once it got highlighted), but we're waiting for someone to overturn the original spec guidance before changing the tool.

I'd also ask what the chain of artifacts is that need to be changed and how those items are going to live -- e.g. - so IMO this should result in one or more of the following: 1) spec clarification, 2) mod-spec RTM change, 3) mod-spec test cases change, 4) tool change. For #2 and #3, I'd also ask how these artifacts will live down the road (who owns them, where their most current versions reside - assuming they are to be living documents vs. 1-time analysis bits) and what the change process for these specs is in general.

Thanks,

Edward O'Connor
(ONC contractor guy from Mod Spec and Cert Discovery Test Tool - and community member in various HIT-lands)

[George Lilly]

---------- Forwarded message ----------
From: Wikispaces <do-not...@wikispaces.com>
Date: Wed, Dec 19, 2012 at 3:21 PM
Subject: Wikispaces: Monitored Discussion: "MU2 Compliance, Trust Bundles, and Java RI Releases"
To: gli...@glilly.net

A Wikispaces user has posted a message to a discussion you are monitoring. Please visit the url below to respond; do not reply to this email.

Subject	MU2 Compliance, Trust Bundles, and Java RI Releases

From	agropper
Date	Dec 19, 2012 3:21 pm
URL	http://wiki.directproject.org/message/view/Java+Reference+Implementation/59250336#59286836

Direct depends on separate STAs for the sender and the recipient. The recipient controls only her own STA and can't control the STA of the data holder. If the patient has an absolute right to receive her own information via Direct then the sender's STA can’t just swallow the message because the patient would have no recourse. In other words, spam filtering is usually the job of the recipient’s service. Any email provider that refused to try and send my email would be considered broken.

Direct scalability does not have to rely on only a single mechanism. When a data holder’s STA decides that a patient-directed address may be sketchy, the STA can fall back to sending a verification Direct email to the patient prior to transmission. If the patient replies to the coded link via regular email, Direct or a Web browser interaction then the sending STA does not have to rely on the Trust Bundle and can discharge their responsibility to the data holder. In this 2-tier model, scalability is achieved through trust bundles and the data holder can service any STA the patient chooses.

Adrian