Security+and+Privacy+Workgroup+Meetings+Q3+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-15 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.