Security+and+Privacy+Workgroup+Meetings+2011

TOC



**2011-09-30 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Ann Clarke
 * Andrew Weniger
 * Benson Chang
 * Bob Hall
 * Cbaba
 * - Chuck Hagen (Deloitte)
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris (LM)
 * - Dave Arvin (SSA)
 * - David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * James Rachin
 * Jeff Tunkel
 * Joe Lamy
 * Joan DuHaime
 * John Donnelly
 * - John Moehrke
 * Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * - Mike Levy (SSA)
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Sanjay
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Sourabh Pawar
 * Srinivasa Kukatla
 * Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: Announcements Working session to create OASIS SAML 2.0 core spec changes Any new blocking RI Team issues. Any new blocking T Team issues Results from surveys about  support by toolkits.

What is the root use case? Expression of a patient's consent to assure interoperability. Would need two attributes: 1) the generic policy OID, and 2) a pointer to the evidence instance (wet signature scanned image aka consent document) as an OID (so the document could be subsequently retrieved using an XCA request). It has been proposed at the IHE that these OIDs simpey be expressed as root level attributes in the SAML assertion. This would remove the ambiguity associated with a in an embedded SAML assertion. We are not using the embedded SAML document to it's full potential anyway at this time. The RI team agrees that the embedded SAML assertion is not being used other than as a container for the OIDs (policy and instance policy documents). In the future, if a more advanced use case is presented that requires the use of an embedded SAML assertion (below the or elements) we will revision this working decision.

From the IHE (as a draft change proposal that is not yet approved):  urn:oid:1.2.3.4.123456789 



urn:oid:1.2.3.4.123456789





urn:oid:1.2.3.4.123456789





urn:oid:1.2.3.4.123456789

</saml2:Attribute>

Next: Would like to get the perspective of the SSA on this issue to see if they agree to carrying the consent OIDs at the level of a SAML attribute and do they have a preference on which of the three attributes should be carried in the initial request from the initiating gateway to the responding gateway.

The IHE was/is considering an attribute within the user context.

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Authorization Framework working session Issue #6 (<Subject>) http://exchange-specifications.wikispaces.com/SAML+Subject+Usage+inside+Evidence+and+Advice+Elements Today, in saml-core-2.0-os, lines 1167-1168 say "Assertions containing elements MUST contain a  element". OASIS has asked us to propose new text for consideration for both the <Evidence> and <Advice> statements.

For discussion today:

Background: <AuthzDecisionStatement> may optionally contain <Evidence> element (lines 1316-1317). <Evidence> elements allow optional embedded <Assertion> elements (lines 1381-1382).

Also

<Assertion> statements may optionally contain <AttributeStatements> (as per the SAML schema). <AttributeStatements> can only contain one or more of either <Attribute> and <EncryptedAttribute> statements. Thus can we conclude that the SAML spec lines 1167-1168 MUST restated "<AttributeStatement> must be have a <Subject> sibling element"? And thus the same for other similar statements in the spec?

Also: <Assertion> elements may optionally contain

New terms: "Since SAML may have multiple <Assertion> statements, it's helpful to distinguish them. A 'Root <Assertion>' is the <Assertion> statement found at the apex of the <Security> element of a SOAP document. An 'Embedded <Assertion>' is a lower level assertion that can be found optionally in <Evidence> and <Advice> elements."

Option 1) (Required subject in root saml assertion) Change lines 1167-1168 from "Assertions containing elements MUST contain a element.". to "Assertions containing  elements MUST contain a element under the <Assertion> that contains said attribute statement." And modify lines 567-568 from "<Subject> [Optional] The subject of the statement(s) in the assertion." to "<Subject> [Conditional] The subject of the statement(s) in the assertion is optional unless <AttributeStatement> or <AuthzDecisionStatement> elements are used. If <AttributeStatement> or <AuthzDecisionStatement> element are used, then a sibling <Subject> element is required. <Assertions> that contain no other statements must contain the <Subject> element."

Option 2) (Required subject in embedded assertions) Change lines 1167-1168 from "Assertions containing elements MUST contain a element.". to "Assertions containing  elements MUST also contain a element under any optional <AuthzDecisionStatement>\<Evidence> and/or <Assertion>\<Advice> elements." And modify lines 567-568 from "<Subject> [Optional] The subject of the statement(s) in the assertion." to "<Subject> [Conditional] The subject of the statement(s) in the assertion is optional unless <AttributeStatement> or <AuthzDecisionStatement> elements are used. If <AttributeStatement> or <AuthzDecisionStatement> elements are used, then an embedded <Subject> element is required below the <AuthzDecisionStatement>\<Evidence> and/or <Assertion>\<Advice> elements. <Assertions> that contain no other statements must contain the <Subject> element."

Option 3) (Required subject element in both ) Change lines 1167-1168 from "Assertions containing elements MUST contain a element.". to "Assertions containing  elements MUST also contain a element under any optional <AuthzDecisionStatement>\<Evidence> and/or <Assertion>\<Advice> elements." And modify lines 567-568 from "<Subject> [Optional] The subject of the statement(s) in the assertion." to "<Subject> [Conditional] The subject of the statement(s) in the assertion is optional unless <AttributeStatement> or <AuthzDecisionStatement> elements are used. If <AttributeStatement> or <AuthzDecisionStatement> elemnts are used, then an embedded <Subject> element is required below the <AuthzDecisionStatement>\<Evidence> and/or <Assertion>\<Advice> elements. <Assertions> that contain no other statements must contain the <Subject> element."

Similar text would be proposed for lines 1049-1050 "Assertions containing <AuthnStatement> elements MUST contain a <Subject> element.". Also for lines 1279-1280 "Assertions containing <AuthzDecisionStatement> elements MUST contain a <Subject> element."

Status: As of the end of our call today, we agreed to continue to revise and improve the above text until we feel it is ready to submit to OASIS for their consideration. If you are going to modify the above text,, please make a new copy and edit it immediately below instead of changing the immediately above text (I'd like to keep the above text intact). Thx ejh.



**2011-09-16 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Ann Clarke
 * Andrew Weniger
 * Benson Chang
 * Bob Hall
 * Cbaba
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * - Dave Arvin
 * - David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * James Rachin
 * Jeff Tunkel
 * Joe Lamy
 * Joan DuHaime
 * John Donnelly
 * John Moehrke
 * Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Sanjay
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Sourabh Pawar
 * Srinivasa Kukatla
 * Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: Any new blocking RI Team issues. Any new blocking T Team issues Results from surveys about <Subject> support by toolkits.

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Authorization Framework working session Issue #6 (<Subject>) http://exchange-specifications.wikispaces.com/SAML+Subject+Usage+inside+Evidence+and+Advice+Elements Today, in saml-core-2.0-os, lines 1167-1168 say "Assertions containing elements MUST contain a  element". OASIS has asked us to propose new text for consideration for both the <Evidence> and <Advice> statements.

For discussion today:

Background: <AuthzDecisionStatement> may optionally contain <Evidence> element (lines 1316-1317). <Evidence> elements allow optional embedded <Assertion> elements (lines 1381-1382).

Also

<Assertion> statements may optionally contain <AttributeStatements> (as per the SAML schema). <AttributeStatements> can only contain one or more of either <Attribute> and <EncryptedAttribute> statements. Thus can we conclude that the SAML spec lines 1167-1168 MUST restated "<AttributeStatement> must be have a <Subject> sibling element"? And thus the same for other similar statements in the spec?

Also: <Assertion> elements may optionally contain

New terms: "Since SAML may have multiple <Assertion> statements, it's helpful to distinguish them. A 'Root <Assertion>' is the <Assertion> statement found at the apex of the <Security> element of a SOAP document. An 'Embedded <Assertion>' is a lower level assertion that can be found optionally in <Evidence> and <Advice> elements."

Option 1) Change lines 1167-1168 from "Assertions containing elements MUST contain a element.". to "Assertions containing  elements MUST contain a element under the <Assertion> that contains said attribute statement." And modify lines 567-568 from "<Subject> [Optional] The subject of the statement(s) in the assertion." to "<Subject> [Conditional] The subject of the statement(s) in the assertion is optional unless <AttributeStatement> or <AuthzDecisionStatement> elements are used. If <AttributeStatement> or <AuthzDecisionStatement> elemnt are used, then a sibling <Subject> element is required. <Assertions> that contain no other statements must contain the <Subject> element."

Option 2) Change lines 1167-1168 from "Assertions containing elements MUST contain a element.". to "Assertions containing  elements MUST also contain a element under any optional <AuthzDecisionStatement>\<Evidence> and/or <Assertion>\<Advice> elements." And modify lines 567-568 from "<Subject> [Optional] The subject of the statement(s) in the assertion." to "<Subject> [Conditional] The subject of the statement(s) in the assertion is optional unless <AttributeStatement> or <AuthzDecisionStatement> elements are used. If <AttributeStatement> or <AuthzDecisionStatement> elemnts are used, then an embedded <Subject> element is required below the <AuthzDecisionStatement>\<Evidence> and/or <Assertion>\<Advice> elements. <Assertions> that contain no other statements must contain the <Subject> element."

Similar text would be proposed for lines 1049-1050 "Assertions containing <AuthnStatement> elements MUST contain a <Subject> element.". Also for lines 1279-1280 "Assertions containing <AuthzDecisionStatement> elements MUST contain a <Subject> element."

Status: As of the end of our call today, we agreed to continue to revise and improve the above text until we feel it is ready to submit to OASIS for their consideration. If you are going to modify the above text,, please make a new copy and edit it immediately below instead of changing the immediately above text (I'd like to keep the above text intact). Thx ejh.



2011-07-22 T-con
Updates to Authorization Framework v 2.0.6 were reviewed and approved, version 2.0.7 to be created and presented to NTC.



**2011-07-07 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * - Ann Clarke
 * Andrew Weniger
 * - Benson Chang
 * Bob Hall
 * Cbaba
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris
 * - Dave Arvin
 * David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * James Rachin
 * Jeff Tunkel
 * Joe Lamy
 * Joan DuHaime
 * John Donnelly
 * John Moehrke
 * Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Sanjay
 * - Scott Robertson
 * - Seonho Kim
 * Sergei Haramundanis
 * Sourabh Pawar
 * Srinivasa Kukatla
 * Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * Tom Davidson
 * Wendy Laposata
 * - Eric Heflin



**2011-07-07 T-con**
Agenda: > Roll – 1 min
 * - Amram Ewoo
 * - Ann Clarke
 * Andrew Weniger
 * - Benson Chang
 * Bob Hall
 * Cbaba
 * Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris
 * Dave Arvin
 * David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * - Didi Davis
 * - Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * - James Rachin
 * Jeff Tunkel
 * - Joe Lamy
 * Joan DuHaime
 * John Donnelly
 * - John Moehrke
 * Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * - Sanjay
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * - Sourabh Pawar
 * Srinivasa Kukatla
 * - Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: Any new blocking RI Team issues. Authorization Framework working session Finished 2.0.6 and agreed to send it to the Sec and Privacy Workgroup for objections after the call. If not objections are received by COB today, then the 2.0.6 version will be send to the entire Spec Factory for a 1-week review period.



**2011-07-07 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Ann Clarke
 * Andrew Weniger
 * - Benson Chang
 * Bob Hall
 * Cbaba
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * - Dave Arvin
 * - David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * - Didi Davis
 * Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * James Rachin
 * Jeff Tunkel
 * - Joe Lamy
 * Joan DuHaime
 * - John Donnelly
 * - John Moehrke
 * Josh Abraham
 * Kanwarpreet Sethi
 * - Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * - Sanjay
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Srinivasa Kukatla
 * Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: Any new blocking RI Team issues Any new blocking Testing Team issues Decisional meeting to review the latest draft AF spec for a call for a vote for approval on the current spec posted at<span style="font-family: 'Times New Roman','serif'; font-size: 16px;"> http://exchange-specifications.wikispaces.com/Specifications+Updates+Summary, top of the page. A few changes were made and the current draft, as edited during the meeting, was approved. The version edited will be circulated to the WG for any final objections, and then will go to the entire NwHIN Spec Factory for review and approval.



**2011-06-24 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * - Ann Clarke
 * Andrew Weniger
 * - Benson Chang
 * Bob Hall
 * - Cbaba
 * Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * - Dave Arvin
 * - David Degroot
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * - Didi Davis
 * - Ed O'Connor
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * - James Rachin
 * Jeff Tunkel
 * - Joe Lamy
 * Joan DuHaime
 * John Donnelly
 * John Moehrke
 * - Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * - Mario Hyland
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Srinivasa Kukatla
 * - Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: Any new blocking RI Team issues Any new blocking Testing Team issues Review/fix new <span style="font-family: 'Times New Roman','serif'; font-size: 13.3333px;">subject:role typo Fix bad links SAML 2.0 subject discovery working session Review new text, diagram Subject guidance Roundtable

Meeting notes: Announcements: CGI is the official CONNECT dev team. Benson will try to reach out to the new CGI team to get them engaged with the spec factory. No objections were raised for fixing the typo error for the subject:role in the AF spec. The change will be included in the summer 2011 release.

In the 3.2.2 in the 2010 production specification the following occur:
 * [|http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0]
 * [|http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID]

These links indeed invalid, ejh offered to update them today and send them to Benson's team.



**2011-06-24 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * - Ann Clarke
 * Andrew Weniger
 * - Benson Chang
 * Bob Hall
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris
 * - Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * - Didi Davis
 * Gavin O'Brien
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * Joan DuHaime
 * John Donnelly
 * - John Moehrke
 * - Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * - Seonho Kim
 * Sergei Haramundanis
 * Srinivasa Kukatla
 * - Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: Any new blocking RI Team issues Any new blocking Testing Team issues Review/fix new <span style="font-family: 'Times New Roman','serif'; font-size: 13.3333px;">subject:role typo Namespace conflict xspa vs xacml SAML 2.0 subject discovery working session Review new text, diagram Subject guidance Roundtable

Meeting notes: __subject:role__ We decided to update the spec to show the correct namespace for the subject:role (2.0 instead of 1.0) and benson will send out a notice to the spec factory asking for objections.

The RI team found an issue in Auth Framework while working on the modular spec pilot. Entered as issue #82 on the FAQ spreadsheet:

Section 3.3.2.5 Role Attribute, the normative text requires the Name attribute to have a value of “urn:oasis:names:tc:xacml:**1.0**:subject:role”

But the example for Role Attribute and the value noted in SAML XSPA page 13 require the value “urn:oasis:names:tc:xacml:**2.0**:subject:role”

This probably did not surface as an issue until now because the value is correct in the example, but now that we have strong language about implementers following the normative text it is important that we fix this before the summer release.

__namespace conflict between xacml and xacml__

SSA noticed a discrepancy between the normative and non-normative values for the identifier of subject-id, sections 3.3.2.1 and 3.3.2.9 respectively. Issue ID #84 on the tracker. http://exchange-specifications.wikispaces.com/message/view/Spec+Factory+FAQ/40256096

I looked at the underlying specs and it appears that both the version referenced by Auth Framework and the latest version (November 1, 2009) of OASIS XSPA Profile of SAML for Healthcare v 1.0 has conflicting guidance for the value of subject-id.

[] (November 2009 version)

Section 2.12.1 Name states “The name will be typed as a string and in plain text with an identifying tag of <urn:oasis:names:tc:xspa:1.0:subject:subject-id> “

While Table 2 and Table 3 in section 3state that the identifier should have the value “urn:oasis:names:tc:xacml:1.0:subject:subject-id”

It is unclear if the identifier for the subject-id should have the value “…xspa:1.0…” as prescribed in the normative text for Auth Framework and XSPA or “…xacml:1.0…” as prescribed in the non-normative text of both documents

XSPA and XACML apparently both have the subject-id namespaces, with the same definitions.

CONNECT is apparently using xspa1.0, not xacml. The RI accepts both xspa and xacml. Need to determine what the RI transmits.

XUA extension used our xspa.

Straw poll: xspa would continue to be used instead. Reasons: XUA and other text use xspa this namespace, plus the AF normative text uses xspa. This fix would just to fix one example in the AF spec. Also, we don't apparently forbid the use of both the xspa and xacml.

Initial research appears to point out that xspa is is for logging, whereas xacml subject-is appears to be intended for automated processing and correlation to the xaxml rules. FYI: the subject-role is designed for automation. Do we have a list of subject-role roles??

As background: the subject-id is an opaque string with a descriptive name largely used for auditing purposes.



**2011-06-10 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Ann Clarke
 * Andrew Weniger
 * Benson Chang
 * Bob Hall
 * Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris
 * Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * - Gavin O'Brien
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * Joan DuHaime
 * John Donnelly
 * - John Moehrke
 * - Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * - Sandy Stuart
 * - Scott Robertson
 * - Seonho Kim
 * Sergei Haramundanis
 * Srinivasa Kukatla
 * - Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Meeting notes: Gavin O'Brien (NIST) has made some observations about the need for some higher level guidance. From SAML 2.0 we are using WS-Security. We are not using the SAML 2.0 protocols. We discussed that the SAML 2.0 models are too abstract, and the NwHIN specs are too detailed. Need a sufficient amount of each in the NwHIN specs. Stated that items such as SAML SSO and federated trust are out of scope and the decision of the internal organizations.



**2011-05-20 T-con**
Agenda: > Roll – 1 min
 * - Amram Ewoo
 * - Ann Clarke
 * Andrew Weniger
 * - Benson Chang
 * Bob Hall
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * - Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * - Joe Lamy
 * Joan DuHaime
 * John Donnelly
 * - John Moehrke
 * Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * - Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Srinivasa Kukatla
 * - Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

__Agenda:__

Working session to draft/edit text for summer 2011 production spec release. Focus was on SAML 2.0 guidance on subject confirmation methods, and related topics.



**2011-05-20 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * - Ann Clarke
 * Andrew Weniger
 * - Benson Chang
 * Bob Hall
 * Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris
 * Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * Didi Davis
 * - George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * Joan DuHaime
 * John Donnelly
 * John Moehrke
 * Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * - Seonho Kim
 * Sergei Haramundanis
 * Srinivasa Kukatla
 * - Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

__Agenda:__

Working session to draft/edit text for summer 2011 production spec release.



<span style="font-size: 1.3em; margin: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 5px;">2011-05-18 T-con
Agenda: Working session

Meeting notes: Today, a few people working on the edits for the up-comming 2011 NwHIN Production Release package held an unscheduled working session. Attendees were Eric Heflin, Didi Davis, and George Varghese. The purpose was to make progress on the outstanding issues for the Auth Framework. The purpose of this Wiki entry is to make the meeting outcomes transparent.

We drafted new text for the UUID, PurposeOfUse, and Exclusive Canonicalization issues.


 * __PurposeOfUse__**

The examples were corrected and emphsised in yellow. A note was added to call people's attention to the change. And the prior PurposeOfUse cautionary text was changed to the following:

//Non-normative implementation note: CAUTION: As of September, 2010, the Nationwide Health Information Network Exchange has become aware of a potentially breaking change related to the SAML 2.0 PurposeOfUse AttributeValue.//

//In prior versions of this specification, in the immediately prior non-normative example, the example text was incorrect and inconsistent with the remaining text in this document. Specifically, the example text stated “PurposeForUse” instead of the correct “PurposeOfUse”. The incorrect PurposeForUse attribute has been implemented by some Nationwide Health Information Network Exchange members and thus future implementors are cautioned to be aware of this potential interoperability issue.//

//For more detailed and more recent information on this topic, please see the Nationwide Health Information Network Exchange’s Wiki page at: http://exchange-specifications.wikispaces.com/Auth+PurposeOfUse+Research or the main Security and Privacy Workgroup page at: http://exchange-specifications.wikispaces.com/Security+and+Privacy+Team .//

__**Exclusive Canonicalization**__

The following next text was drafted and inserted into the AF spec:

//Normative: Exclusive Canonicalization MUST be used for SAML 2.0 Assertions XML-Digital Signatures as specified by the W3CExclusive XML Canonicalization Version 1.0 specification.//

//Non-normative: Use of Exclusive Canonicalization ensures that signatures created for any sub-document (apex) of an XML document can be verified independently of the context. This capability is important to ensure that the substantive content of an XML sub-document can be validated as being unmodified even if that sub-document is moved into a new document, or moved in relation to other content in the same document. One anticipated use of this capability is to allow intermediaries to add additional signatures or XML wrappers. Although other canonicalization methods are allowed by the underlying specifications, the Nationwide Health Information Network requires the use of Exclusive Canonicalization due to security vulnerabilities potentially exposed by other canonicalization methods.//

Note: the URL has changed for the referenced W3C spec,http://www.w3.org/TR/2001/WD-xml-exc-c14n-20011120 with an automatic redirect tohttp://www.w3.org/TR/xml-exc-c14n/. The spec itself has changed from a status of "Working Draft" to "Recommendation". Need to determine if the associate spec text has changed as well. In general, I propose that we remove URLs from the body of the spec, and include them in the references section. Thoughts??


 * __UUID__**

The examples in the AF specification text were updated to include an underscore character prepended to the UUID value.

In the Message Platform spec, the <Base128> encryption policy statement was commented to reflect it's non-normative nature. Associated text was created above the first instance of this example, guiding implementers to use this as a floor for the crypto policy.

Next steps: At the conclusion of the working session, Didi and George agreed to update the MP and AF specs, and send them to the Core Services and Security and Privacy team leads for review, and then forwarding on to their respective teams for broader review.



**2011-05-16 T-con**
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Ann Clarke
 * Andrew Weniger
 * Benson Chang
 * Bob Hall
 * Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * - Didi Davis
 * - George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * Joan DuHaime
 * John Donnelly
 * John Moehrke
 * Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * - Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Srinivasa Kukatla
 * Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

__Agenda:__

Working session to draft/edit text for summer 2011 production spec release

port assignment text insertion logistics text already written, is it sufficient and correct? http://exchange-specifications.wikispaces.com/Port+Assignment
 * Ports:**

Normative: The NHIN doesn't constrain the vlaue of the assertion ID; it is only constrianed by the unlying SAML and W3C specifications.
 * UUID:**

Non-normative:Prior examples documented the assertion ID technically correctly, but in a misleading manner. Specifically, they stated that the assertion ID should be a UUID, but the underlying specifications identify this is a W3C ID type. This resulted in some prior implementors assuming this identifier could be a UUID, which was incorrect as the assertion ID must not start with a number. Implentors are advised to treat this an an opaque data type. Based on evidence, implementers SHOULD construct this identifier by prepending an underscore character ("_") to a UUID value.

Normative: The Nationwide Health Information Network requires the use of XML Exclusive Canonization for SAML assertions. <<insert namespaces and other technical details>>
 * Exclusive Canonization**

Non-normative: Although other canonizational methods are allowed by the underlying specifications, the NHIN is requiring the use of Exclusive Canonization due to security vulnerabilities potentially exposed by other canonization methods.


 * PurposeOfUse example errors**


 * Issuer**

All, The NwHIN Security and Privacy Workgroup has been discussing a problem with the Authorization Framework SAML <Issuer> element brought forth by the RI and Testing Teams. The problem is that the AF specification is not clearly correct, or testable, with respect to the <Issuer> element. Currently it specifies that the human security officer at a NwHIN participating organization be identified. But it seems to be the intent of OASIS (and SAML’s specs) to identify not the human security officer, but instead, to unambiguously identify the system issuing the SAML assertion. The we are proposing the following changes, and are seeking to make all NwHIN participants (current and future) aware of this issue, and to solicit feedback on the proposed approach. We do not expect this to be a breaking change, but need to confirm that with you. PLEASE RESPOND, VIA EMAIL to Benson Chang (bechang@deloitte.com) and Eric Heflin (ehelfin@medicity.com), by May 1st if you have any objections to the following changes: Issue #1 For issue number 1 in the issue tracker, as discussed http://exchange-specifications.wikispaces.com/message/view/Spec+Factory+FAQ/32692914 and documented http://exchange-specifications.wikispaces.com/Auth.+Framework-+Incorrect+Issuer, the Security and Privacy Workgroup is proposing the following changes to the Authorization Framework section 3.3. Old Text: 4. The <Issuer> element shall identify the individual responsible for issuing the Assertions carried in the message. This element includes a NameID Format attribute which declares the format used to express the value contained in this element. This is normally the system security officer for the sending NHIO. SAML 2.0 NameID Formats are provided in Table 2 of this specification. Proposed New Text: 4. Normative: The <Issuer> element is not constrained by this specification; it is only constrained by the underlying OASIS SAML 2.0 core specification (Assertions and Protocols for Security Assertion Markup Language (SAML) V2.0), referenced elsewhere in this document. As per SAML, the <Issuer> MUST specify the SAML authority that is making the claim(s) in the assertion. The issuer SHOULD be unambiguous to the intended relying parties. Non-normative: The Nationwide Health Information Network, as of the time this text was written, has issued no policy constraining the <Issuer> element. In the absence of policy to the contrary, and based on historical evidence, implementers should use a name NameIDType Format of "x.509 Subject Name" type as specified in 8.3.3 of the OASIS SAML 2.0 core specification. Use of "8.3.1 Unspecified" as a NameIDType Format is not recommended. < > Proposed next steps: If the Spec Factory has no objections with the above proposed changes, we plan to confirm their correctness with the with the NIST and S&I framework test teams, and then post them to the spec changes page on this wiki. Also, I've confirmed that CONNECT 2.4.8 emits the following text (kindly provided from the Wright State log files, and cosmetically reformatted): <saml2:Assertion ID="q47df7c0a-ff3e-4b26-baeb-f2910f6d05a9" IssueInstant="2009-04-16T13:10:39.093Z" Version="2.0"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"> CN=SAML User,OU=Harris,O=HITS,L=Melbourne,ST=FL,C=US </saml2:Issuer> For the testing team, who brought forth this issue, our guidance is to automate testing to validate that the <Issuer> element is as per section 8.3 SAML core spec. By not further constraining the <Issuer> element at this time, this effectively severely limits automatic validation of this or the use of this field. The test team should inspect this value to ensure it is a syntactically valid element as per the SAML format value. It should not be the default value of "CN=SAML User,OU=Harris,O=HITS,L=Melbourne,ST=FL,C=US", and it should be a value obviously associated unambiguously with a sending system's identity provider. It also should not be empty. As an addition optional test, we suggest that the test team manually review the <Issuer> value for "reasonableness"; it should, for example, not have a value of "test". Outstanding issue: What is this element used for by the receiver? Is it automatically used for validation? Or is it just for logging purposes? We feel it is not being used at this time for any type of validation, just for logging. The general IHE approach is that one primary purpose of SAML assertions today, including the <Issuer> element, is to have a higher fidelity log file; not to necessarily enable programmatic use of all SAML elements (yet). Idea: Have the TT or other onboarding team issue a statement that a test value may be used for testing purposes, but that the Production <Issuer> must be a valid identifier as per 8.3 in the SAML spec.



**2011-05-13 T-con**
Agenda: > <span style="list-style-image: initial; list-style-position: initial; list-style-type: none; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Roll – 1 min
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">- Amram Ewoo
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">- Ann Clarke
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Andrew Weniger
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Benson Chang
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Bob Hall
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Chuck Hagen
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Charles Ndunda
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">- Dan Vigano
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Dave Colbert
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">David Colins
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">- David Morris
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">- Dave Arvin
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">David Roberts
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Deborah Harris
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Deborah Lafky
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Didi Davis
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">- George Varghese
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Gee Chia
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Jeff Tunkel
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Joe Lamy
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Joan DuHaime
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">John Donnelly
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">John Moehrke
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">- Josh Abraham
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Kanwarpreet Sethi
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Ken Salyards
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Kiran
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Karen Witting
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Laure Tull
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Larry Burris
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Les Westberg
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Marty Prahl
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Mastan Ketha
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Michael Nenashev
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Monalee Vyas
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Neelie Bajaj
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Negendra Midde
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Nick Vennaro
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Richard Ettema
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Randy Sermons
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Richard Thoreson
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Sandy Stuart
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Scott Robertson
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">- Seonho Kim
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Sergei Haramundanis
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">- Srinivasa Kukatla
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Shrikang Gajengi
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Seravina V
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Steven Cason
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Tom Davidson
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">Wendy Laposata
 * <span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0.5em; padding-bottom: 0px; padding-left: 3em; padding-right: 0px; padding-top: 0px;">- Eric Heflin

__Agenda:__

<span style="color: #1f497d; font-family: Calibri,sans-serif; font-size: 10pt;">Agenda: <span style="color: #1f497d; font-family: Calibri,sans-serif; font-size: 10pt;"> Announcements <span style="color: #1f497d; font-family: Calibri,sans-serif; font-size: 10pt;"> RI Team Issues <span style="color: #1f497d; font-family: Calibri,sans-serif; font-size: 10pt;"> Test Team Issues <span style="color: #1f497d; font-family: Calibri,sans-serif; font-size: 10pt;"> Coordinating Committee Report review (attached as presented to the NwHIN Coordinating Committee) <span style="color: #1f497d; font-family: Calibri,sans-serif; font-size: 10pt;"> Summer spec package working session

__<span style="color: #1f497d; font-family: Calibri,sans-serif; font-size: 10pt;">Discussion __ General questions related to the SAML 2.0 STS architecture. Provided guidance that STS should be distinct from the gateway. RI:



2011-04-29 T-con
Agenda: > Roll – 1 min
 * - Amram Ewoo
 * Ann Clarke
 * Andrew Weniger
 * - Benson Chang
 * Bob Hall
 * Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * - Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * - Didi Davis
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * - Joe Lamy
 * - Joan DuHaime
 * John Donnelly
 * John Moehrke
 * - Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Srinivasa Kukatla
 * Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

__Agenda:__ > Announcements > RI > TT > Triage outstanding issues from issue tracker in order to establish a list of issues to be addressed in the Summer 2011 NwHIN Package release. > Roundtable

__**Meeting notes:**__ Announced that Benson's team would be working with the RI and TT in a new effort to modularize the AF and MP specs. This will essentially supersede the sec and priv wg refactoring work. Announced that the RI team was to work on a new consent repository project. Scope and approach TBD. No blocking TT or RIT issues were brought forth. Largely discussed the summer 2011 production spec release. Decided that refactoring work was complete, other than the embedded spreadsheet, and other than the work the Benson's team will continue. Decided to also fix or remove the diagram in the AF releated to the SAML attributes as they are in the wrong order which can be misleading. Created new draft text for the PurposeOfUse fix. Text may be found at http://exchange-specifications.wikispaces.com/Auth+PurposeOfUse+Research Immediately below is the initial spreadsheet reviewed during the call: > Immediately below is the spreadsheet as edited during and just after the call today. > Both of these versions of the spreadsheet should be considered draft.

The team reached a tentative conclusion today to focus on the top 10 list of issues, as weighted in the spreadsheet in column O (Weight). Participants were asked to review the spreadsheet off line to ensure it seems reasonable. Also were asked to specifically review the weights, priority, effort, severity, and yes/no determination for the summer 2011 release. During the meeting no objections were raised regarding this draft approach.



2011-04-22 T-con
Agenda: > Roll – 1 min
 * - Amram Ewoo
 * - Ann Clarke
 * Andrew Weniger
 * - Benson Chang
 * Bob Hall
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris
 * - Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * - Didi Davis
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * - Joe Lamy
 * John Donnelly
 * John Moehrke
 * - Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Srinivasa Kukatla
 * - Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: > Triage outstanding issues from issue tracker in order to establish a list of issues to be addressed in the Summer 2011 NwHIN Package release.

Idea from the PQRI team. Make the NHIN stateless on both the IG and RG. Sourabh Pawar. Issue #77 on the tracker.



2011-04-18 T-con
Agenda: > Roll – 1 min
 * - Amram Ewoo
 * Andrew Weniger
 * - Benson Chang
 * Bob Hall
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris
 * Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * - Didi Davis
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * John Moehrke
 * Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * - Negendra Midde
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * - Srinivasa Kukatla
 * Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: > Triage outstanding issues from issue tracker in order to establish a list of issues to be addressed in the Summer 2011 NwHIN Package release.

Meeting Notes: TBD



2011-04-08 T-con
Agenda: > Roll – 1 min
 * - Amram Ewoo
 * Andrew Weniger
 * - Benson Chang
 * Bob Hall
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * - Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * - John Moehrke
 * - Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * - Richard Thoreson
 * - Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * - Shrikant Gajengi
 * Seravina V
 * Steven Cason
 * Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: > Announcements > RI team blocking issues (if any) > TT blocking issues (if any) > Triage outstanding issues from issue tracker (#5 today) > New issues > Roundtable

Meeting Notes:

Implementation guidance: We suggest implementers generate SAML IDs by generating UUIDs and then prepending an underscore to make it lexically compatible with validating parsers (as such a value of "ed62b6fb-4d73-4011-9f7c-43e0575b6317" as a UUID would be transformed into "_ed62b6fb-4d73-4011-9f7c-43e0575b6317"). Don't assume that others have followed this guidance. Implementers are advised to treat this an an opaque data type and it should not be parsed in an attempt to determine some type of intrinsic meaning.

Doc after today's call.

Benson: Continue working as much as possible given the possible govt shutdown.

__Issue Tracker Issue #5 UUID potentially invalid assertion ids:__

From Keith: need to def the namespace for xs. Review SAML schema. In the SAML 2 core, page 9, XML schema is used,

For discussion today:

From this page: http://exchange-specifications.wikispaces.com/message/view/Spec+Factory+FAQ/32694934

W3C defines xml:ID which is similar to xs:ID. Quoting from the W3C [] :

[|[XML 1.0]] and [|[XML 1.1]] provide a mechanism for annotating elements with unique identifiers. This mechanism consists of declaring the type of an attribute as "ID", after which the parser will validate that
 * the ID value matches the allowed lexical form,
 * the value is unique within the XML document, and that
 * each element has at most one single unique identifier

The xs:ID attribute is defined in the W3C "Schema for Schemas" found at http://www.w3.org/TR/xmlschema-1/ in section 5.4.

Topic #?? Related to the issue of the SAML elements being issued in an improper order, the SSA stated on the call today that at least some empirical evidence exists that issuing SAML 2 elements in the proper order doesn't appear to be a breaking change. Specifically, the SSA was using CONNECT 2.4.8 and was acting as the a responding gateway, receiving properly structured SAML 2.0 (as implemented in .NET), with the elements being emitted in the correct order. In this case, CONNECT successfully parsed the assertion.



2011-04-01 T-con
Agenda: > Roll – 1 min
 * - Amram Ewoo
 * Andrew Weniger
 * - Benson Chang
 * Bob Hall
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * - Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * - John Moehrke
 * - Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * - Sandy Stuart
 * - Scott Robertson
 * Seonho Kim
 * - Sergei Haramundanis
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: > RI team blocking issues (if any) > TT blocking issues (if any) > Triage outstanding issues from issue tracker (#5 today) > New issues > Roundtable

Meeting Notes:

__Issue Tracker Issue #5 UUID potentially invalid assertion ids:__

For discussion today:

From this page: http://exchange-specifications.wikispaces.com/message/view/Spec+Factory+FAQ/32694934


 * Problem:**

Section 3.3, SAML Assertions, specifies the "ID attribute which is an xs:ID as defined by [] ". But in the following example, it shows an id constructed as a UUID:

<saml2:Assertion ID="ed62b6fb-4d73-4011-9f7c-43e0575b6317"...

Numerous gateway implementers have followed this example and used UUIDs. UUIDs can often start with a number, which would make them invalid assertion ids. Recommend modifying the example and adding guidance that if UUIDs are used to prefix them with something valid, for example, "_" or "uuid-".

Is our interpretation correct?


 * Response:**

I've searched the spec, and only found two instances of this issue. Can you confirm?

In the current Auth Framework, section 3.3:

3. IssueInstant attribute which is an xs:dateTame as defined by http://www.w3.org/TR/xmlschema-2/ The following illustrates the syntax of this element: <saml2:Assertion ID="ed62b6fb-4d73-4011-9f7c-43e0575b6317" IssueInstant="2008-10-07T13:00:34.484Z" Version="2.0">

And I see another instance of this issue in the example 3.3.3.2 Authorization Decision Statement Example.

<saml2:AuthzDecisionStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Decision="Permit" Resource=""> <saml2:Action Namespace="urn:oasis:names:tc:SAML:1.0:action:rwedc">Execute</saml2:Action> <saml2:Evidence> <saml2:Assertion ID="da20c267-0f95-4cf4-8bc1-6daa5d84201e" ...

The RI team is using a leading underscore value to start the ID value.

For the CONNECT implementation, the UUID is currently being emitted

Are there any more examples of this problem that anyone is aware of?

Current text:

2. ID attribute which is an xs:ID as defined by http://www.w3.org/TR/xml-Id/

Proposed new text: 2. Normative: ID attribute which is an xs:ID as defined by http://www.w3.org/TR/xml-Id/.

Non-normative:The receiver should treat this value as an opaque data type. We recommend that implementers use a URN. A URN can hold either a UUID, or an OID,

ID is defined in the [|http://www.w3.org/TR/xmlschema-2/#ID] as that which is further defined by

The [|·] [|value space] [|·] of **ID** is the set of all strings that [|·] [|match] [|·] the [|NCName] production in [|[Namespaces in XML]]. The [|·] [|base type] [|·] of **ID** is [|NCName].

**NCName** represents XML "non-colonized" Names. The [|·] [|value space] [|·] of **NCName** is the set of all strings which [|·] [|match] [|·] the [|NCName] production of [|[Namespaces in XML]]. The [|·] [|lexical space] [|·] of **NCName** is the set of all strings which [|·] [|match] [|·] the [|NCName] production of [|[Namespaces in XML]]. The [|·] [|base type] [|·] of **NCName** is [|Name].

From http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName

[Definition:] A namespace is **declared** using a family of reserved attributes. Such an attribute's name must either be xmlns or have xmlns: as a prefix. These attributes, like any other XML attributes, may be provided directly or by [|default].
 * **Attribute Names for Namespace Declaration** ||
 * || [1] || NSAttName || ::= || [|PrefixedAttName] ||
 * ||  ||   || | [|DefaultAttName] ||
 * [2] || PrefixedAttName || ::= || 'xmlns:' [|NCName] || [ || NSC: [|Leading "XML"] ] ||
 * [3] || DefaultAttName || ::= || 'xmlns' ||
 * [4] || NCName || ::= || ([|Letter] | '_') ([|NCNameChar])* || /* || An XML [|Name], minus the ":" */ ||
 * [5] || NCNameChar || ::= || [|Letter] | [|Digit] | '.' | '-' | '_' | [|CombiningChar] | [|Extender] ||  ||

From this we can conclude that the ID must start with a letter or an underscore.

A "letter" is defined as:

http://www.w3.org/TR/REC-xml/#NT-Letter


 * || Letter || ::= || [|BaseChar] | [|Ideographic] ||
 * || BaseChar || ::= || [#x0041-#x005A] | [#x0061-#x007A] | [#x00C0-#x00D6] | [#x00D8-#x00F6] | [#x00F8-#x00FF] | [#x0100-#x0131] | [#x0134-#x013E] | [#x0141-#x0148] | [#x014A-#x017E] | [#x0180-#x01C3] | [#x01CD-#x01F0] | [#x01F4-#x01F5] | [#x01FA-#x0217] | [#x0250-#x02A8] | [#x02BB-#x02C1] | #x0386 | [#x0388-#x038A] | #x038C | [#x038E-#x03A1] | [#x03A3-#x03CE] | [#x03D0-#x03D6] | #x03DA | #x03DC | #x03DE | #x03E0 | [#x03E2-#x03F3] | [#x0401-#x040C] | [#x040E-#x044F] | [#x0451-#x045C] | [#x045E-#x0481] | [#x0490-#x04C4] | [#x04C7-#x04C8] | [#x04CB-#x04CC] | [#x04D0-#x04EB] | [#x04EE-#x04F5] | [#x04F8-#x04F9] | [#x0531-#x0556] | #x0559 | [#x0561-#x0586] | [#x05D0-#x05EA] | [#x05F0-#x05F2] | [#x0621-#x063A] | [#x0641-#x064A] | [#x0671-#x06B7] | [#x06BA-#x06BE] | [#x06C0-#x06CE] | [#x06D0-#x06D3] | #x06D5 | [#x06E5-#x06E6] | [#x0905-#x0939] | #x093D | [#x0958-#x0961] | [#x0985-#x098C] | [#x098F-#x0990] | [#x0993-#x09A8] | [#x09AA-#x09B0] | #x09B2 | [#x09B6-#x09B9] | [#x09DC-#x09DD] | [#x09DF-#x09E1] | [#x09F0-#x09F1] | [#x0A05-#x0A0A] | [#x0A0F-#x0A10] | [#x0A13-#x0A28] | [#x0A2A-#x0A30] | [#x0A32-#x0A33] | [#x0A35-#x0A36] | [#x0A38-#x0A39] | [#x0A59-#x0A5C] | #x0A5E | [#x0A72-#x0A74] | [#x0A85-#x0A8B] | #x0A8D | [#x0A8F-#x0A91] | [#x0A93-#x0AA8] | [#x0AAA-#x0AB0] | [#x0AB2-#x0AB3] | [#x0AB5-#x0AB9] | #x0ABD | #x0AE0 | [#x0B05-#x0B0C] | [#x0B0F-#x0B10] | [#x0B13-#x0B28] | [#x0B2A-#x0B30] | [#x0B32-#x0B33] | [#x0B36-#x0B39] | #x0B3D | [#x0B5C-#x0B5D] | [#x0B5F-#x0B61] | [#x0B85-#x0B8A] | [#x0B8E-#x0B90] | [#x0B92-#x0B95] | [#x0B99-#x0B9A] | #x0B9C | [#x0B9E-#x0B9F] | [#x0BA3-#x0BA4] | [#x0BA8-#x0BAA] | [#x0BAE-#x0BB5] | [#x0BB7-#x0BB9] | [#x0C05-#x0C0C] | [#x0C0E-#x0C10] | [#x0C12-#x0C28] | [#x0C2A-#x0C33] | [#x0C35-#x0C39] | [#x0C60-#x0C61] | [#x0C85-#x0C8C] | [#x0C8E-#x0C90] | [#x0C92-#x0CA8] | [#x0CAA-#x0CB3] | [#x0CB5-#x0CB9] | #x0CDE | [#x0CE0-#x0CE1] | [#x0D05-#x0D0C] | [#x0D0E-#x0D10] | [#x0D12-#x0D28] | [#x0D2A-#x0D39] | [#x0D60-#x0D61] | [#x0E01-#x0E2E] | #x0E30 | [#x0E32-#x0E33] | [#x0E40-#x0E45] | [#x0E81-#x0E82] | #x0E84 | [#x0E87-#x0E88] | #x0E8A | #x0E8D | [#x0E94-#x0E97] | [#x0E99-#x0E9F] | [#x0EA1-#x0EA3] | #x0EA5 | #x0EA7 | [#x0EAA-#x0EAB] | [#x0EAD-#x0EAE] | #x0EB0 | [#x0EB2-#x0EB3] | #x0EBD | [#x0EC0-#x0EC4] | [#x0F40-#x0F47] | [#x0F49-#x0F69] | [#x10A0-#x10C5] | [#x10D0-#x10F6] | #x1100 | [#x1102-#x1103] | [#x1105-#x1107] | #x1109 | [#x110B-#x110C] | [#x110E-#x1112] | #x113C | #x113E | #x1140 | #x114C | #x114E | #x1150 | [#x1154-#x1155] | #x1159 | [#x115F-#x1161] | #x1163 | #x1165 | #x1167 | #x1169 | [#x116D-#x116E] | [#x1172-#x1173] | #x1175 | #x119E | #x11A8 | #x11AB | [#x11AE-#x11AF] | [#x11B7-#x11B8] | #x11BA | [#x11BC-#x11C2] | #x11EB | #x11F0 | #x11F9 | [#x1E00-#x1E9B] | [#x1EA0-#x1EF9] | [#x1F00-#x1F15] | [#x1F18-#x1F1D] | [#x1F20-#x1F45] | [#x1F48-#x1F4D] | [#x1F50-#x1F57] | #x1F59 | #x1F5B | #x1F5D | [#x1F5F-#x1F7D] | [#x1F80-#x1FB4] | [#x1FB6-#x1FBC] | #x1FBE | [#x1FC2-#x1FC4] | [#x1FC6-#x1FCC] | [#x1FD0-#x1FD3] | [#x1FD6-#x1FDB] | [#x1FE0-#x1FEC] | [#x1FF2-#x1FF4] | [#x1FF6-#x1FFC] | #x2126 | [#x212A-#x212B] | #x212E | [#x2180-#x2182] | [#x3041-#x3094] | [#x30A1-#x30FA] | [#x3105-#x312C] | [#xAC00-#xD7A3] ||
 * || Ideographic || ::= || [#x4E00-#x9FA5] | #x3007 | [#x3021-#x3029] ||

A good reference for the above unicode characters may be found at: []

Related blog entry: http://healthcaresecprivacy.blogspot.com/2011/02/creating-and-using-unique-id-uuid-oid.html

This identifier was listed incorrectly in prior versions of this specification, in the two examples. The first example (immediately below) in the third bullet point in this section, and a second example may be found at "3.3.3.2 Authorization Decision Statement Example". In both cases, the ID was incorrectly listed as "da20c267-0f95-4cf4-8bc1-6daa5d84201e".

From Tom:

**3.3.1 Attribute Types** [|http://www.w3.org/TR/2000/WD-xml-2e-20000814#id] **Validity constraint: ID** Values of type **ID** must match the [|Name] production. A name must not appear more than once in an XML document as a value of this type; i.e., ID values must uniquely identify the elements which bear them.
 * [5] || Name || ::= || ([|Letter] | '_' | ':') ([| NameChar])* ||
 * [84] || Letter || ::= || [|BaseChar] | [|Ideographic] ||

[|http://www.w3.org/TR/xmlschema-2/#ID]

Conclusion: As of the end of today's meeting, we've decided to is that the examples are correct but misleading. Specifically, the examples are UUIDs. The problem, is that UUIDs are not constrained to starting with a letter; they will randomly start with a letter or a number. Thus, even though the examples are

correct, they can imply that any UUID is valid, which doesn't appear to be true.

Approach/Next steps: we plan to digest these layers, and to provide some non-normative text with guidance to implementors about the recomended approach, and a non-normative statement about what the rules are related to the SAML assertion ID content.



2011-03-25 T-con
Agenda: > Roll – 1 min
 * - Amram Ewoo
 * Andrew Weniger
 * Benson Chang
 * Bob Hall
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * - John Moehrke
 * Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * - Larry Burris
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Seravina V
 * Steven Cason
 * Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: > RI team blocking issues (if any) > TT blocking issues (if any) > Triage outstanding issues from issue tracker > New issues > Roundtable

Meeting notes:

Eric brought up the issue of how we get approval from the NwHIN exchange, for the SAML <Issuer> attribute issue, We are going to distribute the below text (in the meeting notes from last week's meeting) via email to the NwHIN exchange "all hands" email list and then mention it in at least two weekly all hands calls, seeking objections or changes. If none are raised, then the text will move forward.

Closed issue #46. See the discussion page for details. In summary, the RI team was seeking a better prefix for name spaces such as S12 vs. SOAP12. We indicated that these conventions were inherited from some base standards and specs such as from W3C.

The majority of today's call was devoted to a working session dealing with the SAML <Issuer> attribute. We directly edited the text (in the meeting notes for the call on the 18th) as can be seen below. It now will be sent out for a "vote".

The below text is being mailed to the full spec factory:

Issue #1 For issue number 1 in the issue tracker, as discussed http://exchange-specifications.wikispaces.com/message/view/Spec+Factory+FAQ/32692914 and documented http://exchange-specifications.wikispaces.com/Auth.+Framework-+Incorrect+Issuer, the Security and Privacy Workgroup is proposing the following changes to the Authorization Framework section 3.3. Old Text: 4. The <Issuer> element shall identify the individual responsible for issuing the Assertions carried in the message. This element includes a NameID Format attribute which declares the format used to express the value contained in this element. This is normally the system security officer for the sending NHIO. SAML 2.0 NameID Formats are provided in Table 2 of this specification. Proposed New Text: 4. Normative: The <Issuer> element is not constrained by this specification; it is only constrained by the underlying OASIS SAML 2.0 core specification (Assertions and Protocols for Security Assertion Markup Language (SAML) V2.0), referenced elsewhere in this document. As per SAML, the <Issuer> MUST specify the SAML authority that is making the claim(s) in the assertion. The issuer SHOULD be unambiguous to the intended relying parties. Non-normative: The Nationwide Health Information Network, as of the time this text was written, has issued no policy constraining the <Issuer> element. In the absence of policy to the contrary, and based on historical evidence, implementers should use a name NameIDType Format of "x.509 Subject Name" type as specified in 8.3.3 of the OASIS SAML 2.0 core specification. Use of "8.3.1 Unspecified" as a NameIDType Format is not recommended. < > Proposed next steps: If the Spec Factory has no objections with the above proposed changes, we plan to confirm their correctness with the with the NIST and S&I framework test teams, and then post them to the spec changes page on this wiki. Also, I've confirmed that CONNECT 2.4.8 emits the following text (kindly provided from the Wright State log files, and cosmetically reformatted): <saml2:Assertion ID="q47df7c0a-ff3e-4b26-baeb-f2910f6d05a9" IssueInstant="2009-04-16T13:10:39.093Z" Version="2.0"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"> CN=SAML User,OU=Harris,O=HITS,L=Melbourne,ST=FL,C=US </saml2:Issuer> For the testing team, who brought forth this issue, our guidance is to automate testing to validate that the <Issuer> element is as per section 8.3 SAML core spec. By not further constraining the <Issuer> element at this time, this effectively severely limits automatic validation of this or the use of this field. The test team should inspect this value to ensure it is a syntactically valid element as per the SAML Format value. It should not be the default value of "CN=SAML User,OU=Harris,O=HITS,L=Melbourne,ST=FL,C=US", and it should be a value obviously associated unambiguously with a sending system's identity provider. It also should not be empty. As an addition optional test, we suggest that the test team manually review the <Issuer> value for "reasonableness"; it should, for example, not have a value of "test". Outstanding issue: What is this element used for by the receiver? Is it automatically used for validation? Or is it just for logging purposes? We feel it is not being used at this time for any type of validation, just for logging. The general IHE approach is that one primary purpose of SAML assertions today, including the <Issuer> element, is to have a higher fidelity log file; not to necessarily enable programmatic use of all SAML elements (yet). Idea: Have the TT or other onboarding team issue a statement that a test value may be used for testing purposes, but that the Production <Issuer> must be a valid identifier as per 8.3 in the SAML spec.



2011-03-18 T-con
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Andrew Weniger
 * Benson Chang
 * - Bob Hall
 * Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * - John Moehrke
 * Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * - Monalee Vyas
 * Neelie Bajaj
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * - Sergei Haramundanis
 * Seravina V
 * Steven Cason
 * Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: > RI team blocking issues (if any) > TT blocking issues (if any) > Triage outstanding issues from issue tracker > New issues >> DSig for esMD > Roundtable

Meeting notes:


 * Issue Disposition**

RI team issue number 46 will be likely blocking the RI team.

__Issue #1__

For issue number 1 in the issue tracker, as discussed http://exchange-specifications.wikispaces.com/message/view/Spec+Factory+FAQ/32692914 and documented http://exchange-specifications.wikispaces.com/Auth.+Framework-+Incorrect+Issuer, I'm proposing the following changes to the Authorization Framework section 3.3 from:

code 4. The <Issuer> element shall identify the individual responsible for issuing the Assertions carried in the message. This element includes a NameID Format attribute which declares the format used to express the value contained in this element. This is normally the system security officer for the sending NHIO. SAML 2.0 NameID Formats are provided in Table 2 of this specification. code

To:

code 4. Normative: The <Issuer> element is not constrained by this specification; it is only constrained by the underlying OASIS SAML 2.0 core specification (Assertions and Protocols for Security Assertion Markup Language (SAML) V2.0), referenced elsewhere in this document. As per SAML, the <Issuer> MUST specify the SAML authority that is making the claim(s) in the assertion. The issuer SHOULD be unambiguous to the intended relying parties. code

Non-normative: The Nationwide Health Information Network, as of the time this text was written, has issued no policy constraining the <Issuer> element. In the absence of policy to the contrary, and based on historical evidence, implementers should use a name NameIDType Format of "x.509 Subject Name" type as specified in 8.3.3 of the OASIS SAML 2.0 core specification. Use of "8.3.1 Unspecified" as a NameIDType Format is not recomended.

< >

Proposed next steps: If the Sec and Priv WG is comfortable with the above changes, I plan to confirm them with the NIST and S&I framework test teams, and then post them to the spec changes page on this wiki.

Also, I've confirmed that CONNECT 2.4.8 emits the following text (kindly provided from the Wright State log files, and cosmetically reformatted):

code format="xml" <saml2:Assertion ID="q47df7c0a-ff3e-4b26-baeb-f2910f6d05a9" IssueInstant="2009-04-16T13:10:39.093Z" Version="2.0"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"> CN=SAML User,OU=Harris,O=HITS,L=Melbourne,ST=FL,C=US </saml2:Issuer> code

For the testing team, who brought forth this issue, our guidance is to automate testing to validate that the <Issuer> element is as per section 8.3 SAML core spec. By not further constraining the <Issuer> element at this time, this effectively severely limits automatic validation of this or the use of this field. The test team should inspect this value to ensure it is a syntactically valid element as per the SAML Format value. It should not be the default value of "CN=SAML User,OU=Harris,O=HITS,L=Melbourne,ST=FL,C=US", and it should be a value obviously associated unambiguously with a sending system's identity provider. It also should not be empty. As an addition optional test, we suggest that the test team manually review the <Issuer> value for "reasonableness"; it should, for example, not have a value of "test".

Outstanding issue: What is this element used for by the receiver? Is it automatically used for validation? Or is it just for logging purposes? We feel it is not being used at this time for any type of validation, just for logging.

Idea: Have the TT or other onboarding team issue a statement that a test value may be used for testing purposes, but that the <Issuer> must be a valid identifier as per 8.3 in the SAML spec.

IHE approach is that one primary purpose of SAML assertions today is to have a higher fidelity log file.

__Issue #2__

A new issue is in our pipeline, using some type of digital signature to attest to some action such as a provider attesting to the accuracy of a document, or that a provider has reviewed a document, etc. John M has identified a number of issues, in the entire system needed to support this functionality (training of end-users, developmental costs for EMRs to add this functionality, PKI costs, certificate issuance, work-flow, social costs and aspects of a digital sig vs. a wet signature, how long should the certificate revocation information be maintained (100 years or more), consistent time, identity proofing, and more). One interesting idea is the use of a "signature service" such as created by the USPS.

Another approach is to suggest that our current infrastructure, with audit logs and procedures, is sufficient to meet CMS requirements.

Perhaps suggest two approaches with the tradeoffs and then like the CMS chose the approach.

DEA esig for schedule II medication infrastructure may be leveraged perhaps. John's blog: http://healthcaresecprivacy.blogspot.com/2010/11/signing-cda-documents.html has a relevant entry.



2011-03-11 T-con
Agenda: > Roll – 1 min
 * Amram Ewoo
 * Andrew Weniger
 * - Benson Chang
 * Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris
 * Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * John Moehrke
 * Josh Abraham
 * - Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * - Monalee Vyas
 * Neelie Bajaj
 * Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * - Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: > RI team blocking issues (if any) > TT blocking issues (if any) > Any new issues > Triage outstanding issues from issue tracker > Roundtable

Meeting notes: At 7 after the hour the meeting was canceled due to lack of quorum. (Only 4 people were in attendance at that time.)



2011-03-07 T-con
Agenda: > Roll – 1 min
 * - Amram Ewoo
 * Andrew Weniger
 * - Benson Chang
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * - Dave Arvin
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * John Moehrke
 * Josh Abraham
 * Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * - Karen Witting
 * Laure Tull
 * Les Westberg
 * Marty Prahl
 * Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * - Nick Vennaro
 * Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * - Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Seravina V
 * Steven Cason
 * Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: > Review v4 of the package > Q&A to Deloitte > Roundtable

Held a review of the v4 package. Held a working session to fix identified issues on-the-fly (mostly editorial). New v5 is posted to the Wiki. Added a new "project" taxonomy. Decided to move forward with current package, as posted on this Wiki. We plan to show the package this week on the all-hands call to ensure everyone is on-board.



2011-03-04 T-con
Agenda: > Roll – 1 min
 * - Amram Ewoo
 * Andrew Weniger
 * - Benson Chang
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * John Moehrke
 * - Josh Abraham
 * - Kanwarpreet Sethi
 * Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Les Westberg
 * Marty Prahl
 * - Mastan Ketha
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Nick Vennaro
 * - Richard Ettema
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * - Sergei Haramundanis
 * Seravina V
 * Steven Cason
 * Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: > Announcements > New Aegis team SAML versions issues > Blocking RI team issues > Blocking TT issues > Final disposition of issues list items 1, 2, 5, and 39 > Roundtable

New version team is forming, meeting next Wed. All are welcome to join.

The SAML elements appear to be issued in the wrong order. 1) Documented elsewhere (insert link). 2) Aegis suspects this may be a breaking change. Need to confirm. KP in particular may be affected. 3) When do we roll this out? What is the impact to all? Need to ensure the entire spec factor has the chance to assess the impact to their implementation.

Possible solution path: 1) correct the examples in the AF spec. 2) make it clear to the community that non-normative text is not authoritative. 3) ask the NwHIN community for impact assessment. 4) fix CONNECT and release. CONNECT will test this ordering fix as the RG to assess if this breaks CONNECT 5) put this issue in a package release note for the Q1 2011!

Aegis has researched the issue (Jira ticket 322) whereby which PurpseForUse is used vs. PurposeOfuse. On the inbound side: It appears that CONNECT successfully parses both version of this, since they are intended for use by customized versions of CONNECT. The default CONNECT install ignores these values for all current shipping versions. On the outbound side, CONNECT will in the next release, be configurable to use zero, one, the other, or both elements. The default, if a properly is not overridden, is to use PurposeOfUse (which is correct). NEED TO DOCUMENT.

A related issue is that the type of the attribute is not being declared. Tom D will resh this issue.



2011-02-28 T-con
Agenda: > Roll – 1 min
 * - Amram Ewoo
 * Andrew Weniger
 * Benson Chang
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * - David Roberts
 * Deborah Harris
 * Deborah Lafky
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * John Moehrke
 * - Kanwarpreet Sethi
 * - Ken Salyards
 * Kiran
 * Karen Witting
 * Laure Tull
 * Les Westberg
 * Marty Prahl
 * Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Nick Vennaro
 * Randy Sermons
 * Richard Thoreson
 * - Sandy Stuart
 * - Scott Robertson
 * Seonho Kim
 * Sergei Haramundanis
 * Seravina V
 * Steven Cason
 * Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Goal: Finalize the Q1 2011 package definition

Agenda: Recap prior feedback from Dr. Fridsma Act on actionable items

Meeting minutes Amram will send a version of the delta between the 2010 production spec and the Q1 2011 package will be send to the spec factory to provide transparency and give all a change to provide feedback (approval, objections, etc.).

This package will be the official 2011 Q1 Production Specifications release.

Eric will update the table of contents to remove unused leaf nodes, and mark currently unused nodes with a "- TBD" to indicate that we anticipating using them in the future. A new v4 release will be posted today.

Models will be included, and clearly marked as DRAFT, NON-NORMATIVE.



2011-02-25 T-con
Agenda: > Roll – 1 min
 * - Amram Ewoo
 * Andrew Weniger
 * - Benson Chang
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * John Moehrke
 * Kanwarpreet Sethi
 * Kiran
 * Karen Witting
 * - Laure Tull
 * Les Westberg
 * Marty Prahl
 * Michael Nenashev
 * - Monalee Vyas
 * Neelie Bajaj
 * Nick Vennaro
 * Randy Sermons
 * - Richard Thoreson
 * Sandy Stuart
 * - Scott Robertson
 * Seonho Kim
 * - Sergei Haramundanis
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * Eric Heflin

Agenda: Announcements – Benson > ONC stated clearly that the Nationwide Health Information Network Exchange and the Direct Project > ONC booth well attended > NTC meeting on Monday > Coordinating Committee meeting today > Next meeting NTC Mar 28th, CC Mar 25th > The snapshot of documents approved as of early next week will go into the 2011 Q1 package > The packing wg needs to re-convene to finish the work for the Q1 package > Benson will announce a new meeting next Monday Recap of our HIMSS discussion – Tom > Met this week in person at HIMSS (small group) > Notes posted to this Wiki > Karen pointed out that the current Web Services spec list versioning info >> Is this being used by anyone? > Tom reviewed the document in detail > Using PurposeOfUse vs. PurposeForUse to force this issue to be addressed > The profile may, for example, including the version of the SAML header RI blocking issues – RI team TT blocking issues - TT CONNECT PurposeForUse implementation guidance for Aegis Review of items in Google docs – Eric Rouundtable



2011-01-28 T-con
Proposed Agenda: > Roll – 1 min
 * - Amram Ewoo
 * Andrew Weniger
 * - Benson Chang
 * Chuck Hagen
 * Charles Ndunda
 * - Dan Vigano
 * Dave Colbert
 * David Colins
 * - David Morris
 * David Roberts
 * Deborah Harris
 * - Deborah Lafky
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * - John Moehrke
 * - Kanwarpreet Sethi
 * Kiran
 * Karen Witting
 * Laure Tull
 * Les Westberg
 * Marty Prahl
 * Michael Nenashev
 * - Monalee Vyas
 * Neelie Bajaj
 * Nick Vennaro
 * Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: > 1) Quick update on the NTC discussion for our specs. They included our updated PurposeForUse vs. PurposeOfUse warning text. Should be published in the HHS web site in about 6 weeks. The group discussed using this issue as a "lightening rod" to facility a larger issue of version upgrades and NHIN cording committee. We suggested that the RI team implement both on the receiving side and make it a configuration option to send one or the other. Outsanding issue: we need to establish a support and sunset date. Is this a use case for the support of end point capabilities? Such as end-point responding vs. initiating.
 * 1) NTC Authorization Framework spec discussion
 * 2) S&I Framework Testing Team new issues
 * 3) S&I Framework RI team new issues
 * 4) TLS feedback discussion
 * 5) Discuss John's suggestion from last week (using OID to provide evidence doc ref)
 * 6) Roundtable

2-3) Any RI and TT Review backlog.

The RI team has discovered an apparent contradiction in the AF 2010 production spec. The subject-id in 3.3.2.1 is different than. This topic needs more research. The base specs (XSPA and XACML) appear to have contradictions. This is likely a breaking change.

<saml:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:subject-id"> <saml:AttributeValue>Walter H.Brattain IV</saml:AttributeValue> </saml:Attribute>

3.3.2.9 Attribute Statement Example <saml:AttributeStatement> <saml:Attribute Name="urn:oasis:names:tc:xacml:1.0:subject:subject-id"> <saml:AttributeValue>Dr Joe Smith</saml:AttributeValue> </saml:Attribute>

<saml:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:organization"> <saml:AttributeValue>Best Clinic</saml:AttributeValue> </saml:Attribute>

<saml:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:organization-id"> <saml:AttributeValue>urn:oid: 2.16.840.1.113883.3.18.101</saml:AttributeValue> </saml:Attribute>

<saml:Attribute Name="urn:nhin:names:saml:homeCommunityId"> <saml:AttributeValue>

New issue: The RI team has found an issue whereby which the WSDL is not well formed and inconsistent. Suggestion was made to pull the current CONNECT implementation as a pragmatic starting point. We need to include WSDLs with the NHIN 2010 production specs.

http://exchange-specifications.wikispaces.com/message/view/Spec+Factory+FAQ/33130480

4) TLS draft text. (The current draft text is at: TLS Encryption Clarification). a) Suggestion to add a specific TLS version and crypto family. Possibly for testing purposes. b) Question from several people regarding requirement to use FIPS if they are not exchanging with federal entities.

5) Discuss next steps in using an attribute for policy identification. We will discuss this on our next Sec and Priv WG call. We'll discuss in a few weeks and make a commendation once we have consensus at our level.

6) Other topics.



2011-01-28 T-con
Agenda: > Roll – 1 min
 * - Amram Ewoo
 * Andrew Weniger
 * - Benson Chang
 * - Chuck Hagen
 * Charles Ndunda
 * - Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * John Moehrke
 * Kanwarpreet Sethi
 * Kiran
 * Karen Witting
 * Laure Tull
 * Les Westberg
 * Marty Prahl
 * - Michael Nenashev
 * - Monalee Vyas
 * Neelie Bajaj
 * Nick Vennaro
 * - Randy Sermons
 * Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * Seravina V
 * Steven Cason
 * - Tom Davidson
 * Wendy Laposata
 * - Eric Heflin

Agenda: >> Didn't consider currently situation; spec is correct in normative section but all implementations are incorrect >
 * 1) TLS feedback discussion
 * 2) S&I Framework Testing Team new issues
 * 3) S&I Framework RI team new issues
 * 4) Discuss John's suggestion from last week (using OID to provide evidence doc ref)
 * 5) Working session to draft SAML OASIS spec text - postponed
 * 6) Review Coordinating Committee change management process they approved yesterday w/o public comment
 * 1) Roundtable

1) The TLS text received some feedback that needs to be discussed and addressed. a) Suggestion to add a specific TLS version. Possibly for testing purposes. b) Question from several people regarding requirement to use FIPS if they are not exchanging with federal entities. The current draft text is at: TLS Encryption Clarification. On the call today I'd like to consider both of these issues and resolve them, and draft next text (if needed) to sufficiently address these issues.

2-3) RI and TT Review backlog.

4) Discuss idea of using an attribute for policy identification. See the sample below of purposeofuse attribute. I believe what is being proposed is to use a similar structure for expressing the policy associated with a decision.

code format="xml" <saml:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse"> <saml:AttributeValue> <xua:PurposeOfUse xmlns:xua=”urn:ihe:iti:xua:2010” xmlns:hl7v3="urn:hl7-org:v3" xsi:type="hl7v3:CE" code="12" codeSystem="1.0.14265.1" codeSystemName="ISO 14265 Classification of Purposes for processing personal health information" displayName="Law Enforcement"/> </saml:AttributeValue> </saml:Attribute> code



2011-01-21 T-con
Agenda: > Roll – 1 min Topics: > CONNECT team > Used this timeslot to discuss S&I Framework Testing Team new issues > SAML OASIS SSTC > Updates/questions about the SAML TC/RI workgroup > Benson newbie session update > Roundtable
 * - Amram Ewoo
 * - Andrew Weniger
 * - Benson Chang
 * - Chuck Hagen
 * Charles Ndunda
 * Dan Vigano
 * - Dave Colbert
 * David Colins
 * - David Morris
 * David Roberts
 * Deborah Harris
 * Deborah Lafky
 * George Varghese
 * Gee Chia
 * - Jeff Tunkel
 * - Joe Lamy
 * John Donnelly
 * - John Moehrke
 * - Kanwarpreet Sethi
 * Kiran
 * Karen Witting
 * - Laure Tull
 * Les Westberg
 * Marty Prahl
 * - Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Nick Vennaro
 * Richard Thoreson
 * - Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * Seravina V
 * Steven Cason
 * Tom Davidson
 * - Wendy Laposata
 * - Eric Heflin

John M: IHE alternative, have the same functionality, but not using the embedded SAML assertion, by using the privacy OID as an attribute of the context. Similar to using a different evidence method would be via a policy OID or privacy OID. May become an IHE Change Proposal. Next step: Create draft text for circulation to NHINE participants for initial feedback. John M will send the draft and/or final CP text when available. Would apply to XUA++ profile. Question: Is their a use case for the NHINE for an embedded SAML assertion?

EJH action item: write new SAML OASIS core 2 spec draft text.

Benson: The "newbie call" is being posted to various ONC list serves and is expected to be well attended. Tom D will facility (lead) the call. Benson's team will capture detailed notes. Call will be 3-4 Eastern the 26th.

Joe L The testing team has some new issues. Mario's team is looking for some SAML issue guidance. Seeking status update on the exchange governance policy on updates and esp. breaking changes. This topic is on the NTC next call. The last policy and technical task group discussed this; but the discussion is not complete. Joe suggests we issue a statement of what we consider acceptable. We also discussed that we issue a initial draft migration strategy document to start the discussion. Perhaps an addendum in the documentation set. John M agrees on a transition strategy approach such as stating that relying parties should look at both for now for a period of time (e.g. PurposeOfUse vs. PurposeForUse). As a cross-check we'll vet our proposed policy against existing know issues facing us. Decision: We agreed to have the spec factor all hands group to form a new (short-lived) subcommittee to draft this text.



2011-01-10 T-con
Proposed Agenda: > Roll – 1 min Topics: > Announcement no meeting this Friday > Used this timeslot to discuss S&I Framework Testing Team new issues > SAML OASIS SSTC > Updates/questions about the SAML TC/RI workgroup > Two new questions from the Testing Team >> Transforms >> X.509 token profile > Roundtable
 * Amram Ewoo
 * - Benson Chang
 * - Chuck Hagen
 * - Charles Ndunda
 * Dan Vigano
 * - Dave Colbert
 * David Colins
 * - David Morris
 * - David Roberts
 * Deborah Harris
 * Deborah L
 * - George Varghese
 * Gee Chia
 * Jeff Tunkel
 * - Joe Lamy
 * John Donnelly
 * John Moehrke
 * - Kanwarpreet Sethi
 * - Kiran
 * Karen Witting
 * Laure Tull
 * Les Westberg
 * Marty Prahl
 * Michael Nenashev
 * - Monalee Vyas
 * Neelie Bajaj
 * Nick Vennaro
 * - Richard Thoreson
 * Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * - Seravina V
 * Steven Cason
 * Tom Davidson
 * Wendy Laposata
 * - Eric Heflin



2011-01-07 T-con
Agenda: > Roll – 1 min > Review new NIEM package > Working session to construct new version 3 > Publish v3 to the Wiki > Determine next steps > Broken Wiki links > Round table > Any new topics? > Recap plan for next week – 1 min
 * - Amram Ewoo
 * - Benson Chang
 * Chuck Hagen
 * Dan Vigano
 * Dave Colbert
 * David Colins
 * David Morris
 * David Roberts
 * Deborah Harris
 * - Deborah L
 * George Varghese
 * Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * John Donnelly
 * - John Moehrke
 * - Kanwarpreet Sethi
 * Karen Witting
 * - Laure Tull
 * Les Westberg
 * Marty Prahl
 * - Michael Nenashev
 * Monalee Vyas
 * Neelie Bajaj
 * Nick Vennaro
 * Sandy Stuart
 * Scott Robertson
 * Seonho Kim
 * Steven Cason
 * Tom Davidson
 * Wendy Laposata
 * - Eric Heflin



2011-01-03 T-con
Agenda: > Roll – 1 min > Review new NIEM package > Working session to construct new version 3 > Publish v3 to the Wiki > Determine next steps > Broken Wiki links > Round table > Any new topics? > Recap plan for next week – 1 min
 * - Amram Ewoo
 * - Benson Chang
 * Chuck Hagen
 * - Dan Vigano
 * - Dave Colbert
 * David Colins
 * David Morris
 * David Roberts
 * Deborah Harris
 * George Varghese
 * - Gee Chia
 * Jeff Tunkel
 * Joe Lamy
 * - John Donnelly
 * - John Moehrke
 * Kanwarpreet Sethi
 * Karen Witting
 * Laure Tull
 * - Les Westberg
 * Marty Prahl
 * Michael Nenashev
 * - Monalee Vyas
 * Neelie Bajaj
 * - Nick Vennaro
 * - Sandy Stuart
 * - Scott Robertson
 * - Seonho Kim
 * Steven Cason
 * Tom Davidson
 * - Wendy Laposata
 * - Eric Heflin

Meeting notes:

What license should be used for the NIEM package? BSD? BSD-like (such as the one adopted by CONNECT)?

Put testing guidance in the Excel spreadsheet documenting each attribute in the specifications.

Decided that version v3 of the package was ready for broader feedback. Next step: Take the the NHIN Exchange Spec Factory All Hands call to present the current package and get feedback. Then, pending on the results, the next step is probably to set up an demo with the ONC (Dr. Fridsma?) for more feedback.