Security+and+Privacy+Workgroup+Meetings+Q2+2011

toc

**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 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  “

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.



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  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. <>
 * 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  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  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  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  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  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  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):   CN=SAML User,OU=Harris,O=HITS,L=Melbourne,ST=FL,C=US  For the testing team, who brought forth this issue, our guidance is to automate testing to validate that the  element is as per section 8.3 SAML core spec. By not further constraining the  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.