Subject: Re: [security-services] Minutes and Action Items from the SSTC ConferenceCall (3 Nov 2009)
On 11/03/2009 12:21 PM, Nate Klingenstein wrote: > SSTC Conference Call Minutes > November 3, 2009, 12:00pm ET > > 1) Procedural: Quorum was achieved. Thomas will modify the minutes > slightly to reflect that the votes taken did include updates of > designated cross-references for the Holder-of-Key specification moves > to Committee Draft, with no objections, and the minutes as such were > approved. Prateek's slides were added to the agenda, as was the > planned Face-to-Face meeting for next year. > Roll Call: ====== Voting Members Scott Cantor Internet2 Nathan Klingenstein Internet2 Thomas Hardjono M.I.T. Hal Lockhart Oracle Corporation Anil Saldhana Red Hat David Staggs Veterans Health Administration Christian Guenther Nokia Siemens Networks GmbH & Co. KG Thinh Nguyenphu Nokia Siemens Networks GmbH & Co. KG Emily Xu Sun Microsystems Tom Scavo NCSA Members Prateek Mishra Oracle Corporation Observers Phil Hunt Oracle Corporation Quorum Achieved: 10 out of 19 voting members (52%) Status: Prateek gains voting rights. Bob Morgan, Kent Spaulding and DuaneD lose voting rights > 2) Celebration was held for the XSPA SAML Standard for Healthcare, > which has been approved as an OASIS Standard. Mike and David will be > speaking at RSA in March '10, including a little bit about the Standard. > > http://lists.oasis-open.org/archives/security-services/200911/msg00001.html > > > 3) All three of Scott's documents remain waiting for attestations > before they can proceed to OASIS Standard. They won't pass CS state > unless these attestations are received, but they can remain as CS > indefinitely. Scott suggested this item be removed from future agendas. > > 4) The updated CD's for the Holder-of-Key profiles have been uploaded > by Tom Scavo, and they are now ready to go to balloting by the group > for approval as CS. [AI] Hal will create the ballots. > > http://lists.oasis-open.org/archives/security-services/200911/msg00014.html > > > 5) Hal made an inquiry to Mary about whether we can remove a > non-normative appendix as part of an errata, but Mary would prefer > that we mark it as removed or non-operative. She also noted that the > SSTC's communications with IANA should proceed through her. As either > Scott or Bob comes up with the changes we'd like to propose for our > MIME type registration, we'll contact them through Mary, but there is > no rush since there's a minimum of six months before the next errata > can be issued. We'll strike the appendix as soon as possible in > accordance with Mary's email. > > http://lists.oasis-open.org/archives/security-services/200911/msg00016.html > > > 6) The Jira process has been slowed down because there's a manual > issuance of usernames which are not integrated with the rest of OASIS' > systems. A new individual is taking over the process, and there are > hopes this will be faster in the future. We do have an instance, and > Scott was able to log into it. [AI] He believes the chairs need to > assign access permissions, as he could only create issues. He'd like > to see it used as a substitute for the errata working document in the > future. > > 7) Discussion of the Kerberos holder-of-key profile work occurred. > XSD's should be uploaded alongside the main documents to Kavi, and > they're considered the main authority document. Scott prefers to > re-upload a fresh copy of the XSD just to have it next to the > documents in the repository. Anything that is part of a standard must > be placed into the official OASIS repository to ensure availability > and compliance with IPR rules. > > There was less certainty about what an OASIS standard was able to > reference normatively, in particular whether a piece of a Kerberos > Holder-of-Key profile could be standardized through the Kerberos > consortium. > > This arose because Josh couldn't find a way to do XML signing using a > Kerberos-based mechanism, and there's a window to get it included in > XML Signature 1.1. Scott believes it can be done, but he doesn't know > the technical details. Thomas and Scott will discuss whether there's > a need to go to the W3C directly, or whether something could be > published by the consortium. [AI] Hal received an Action Item to > check into that. > > 8) Bob wasn't on the call to discuss the Identity Assurance profile. > > 9) Hal didn't check on the progress of the Delegation Condition > Extension profile, but he'll make sure we get it going on the next > call. It was sent to Mary on 16 October. She asked for corrections, > and Scott issued those corrections, which Mary suggested be placed in > the repository as CD-02, the same name. He sent her the links and > that's the last he's heard, so we believe this will progress shortly. > > 10) Hal's porting of the Work Summary to the wiki is "in progress." > > 11) Anil says the CS version of the Text-based Challenge/Response > profile will be ready by next meeting. > > http://lists.oasis-open.org/archives/security-services/200911/msg00019.html > > > 12) Attribute Update functionality: > > http://lists.oasis-open.org/archives/security-services/200911/msg00000.html > > > Nokia-Siemens had earlier suggested that we add attribute update > functionality to SAML. Phil Hunt investigated the possibility and has > a high-level proposal that was formulated in a PowerPoint set that > they published yesterday. They're building on the Nokia-Siemens use > cases, which are moving beyond single sign-on into the desire of > applications to be able to update attributes. The slides have a > variety of use cases that are a little more complex than just set/get, > e.g. where a principal is added to a group, or values must be > manipulated. > > There are different approaches, including some WSDL specs in ID-WSF; > the question really is whether this should become a first-order SAML > protocol, rather than exist as a protocol built around SAML in another > space. The slide deck describes a full capability that would help > SAML move from single sign-on to full attribute exchange at a protocol > level. > > Reporting, e.g. returning a set of information on a query, would be > desirous as well. The scenario they think of is phone books, or > credential recovery, where the specific subject being searched for is > not known. > > They also want to see a redirect capability, so if the IdP can't do > the update, but knows a service that can do the update, the requester > can be redirected to that service. A managed subject request, where > subjects are added or modified, is another feature. There is no > additional delete because they believe the ManageNameIDRequest > terminate function will suffice for that need. > > They see this as a stepping stone towards ID-WSF, which can handle > discovery and routing to many providers at a higher level of > functionality, but the limited adoption of ID-WSF is a drawback for > them. SAML might also be able to offer greater simplicity to use of > ID-WSF or any other suite of standards. > > Phil also thinks that, in a federated environment, governance needs to > be more strongly documented. This includes some of the work > Liberty/Kantara did on privacy constraints that accompany data. He > would like to see the trust information layered in a privacy > constraints added to requests and responses. The payload is small > normally, generally as just a CARML declaration, which is relatively > lightweight because most of the information is static. The goal is to > allow a provider to use this data for access controls. Dynamic > constraints could also be used, such as, "I'm allowing my Social > Security Number to be exchanged, but you're not permitted to send it > on further." These could also be WS-Policy rules documenting > business-level constraints that need to be documented in the > transaction, which are very different from the protocol-level > constraints we've dealt with to date. > > Prateek would like to continue the dialog and get feedback on what the > SSTC believes are appropriate next steps. They would also propose to > try to put together a draft with some of these messages combining > Phil's proposal with Nokia-Siemens' proposal and publish it to the > SSTC as a draft submission. > > Scott holds that profiling ID-WSF is a lot more fruitful than coming > up with a new stack of standards, believing things like the messaging > model, security framework, and discovery are orthogonal in ID-WSF and > can be easily chopped out. He thinks updates will immediately run > into ways of needing to represent the user's role in the transaction, > ensuring they can be a participant in such a transaction; he doesn't > think cart-blanche allowing services to do anything they want to a set > of data is permissible. This requires a much richer security > framework than server-to-server security, but can be facilitated by > ID-WSF. > > Prateek says that in many of their use cases, user involvement is not > essential, though he can see that there's a natural set of use cases > where users granting some form of delegated rights is important. Phil > wonders whether it's possible to build the core protocol work of the > other operations to SAML, then allow things like ID-WSF actually build > on top of that effort to provide things like the user involvement. > > Scott agrees there's some duplication between SAML and ID-WSF, but the > separate layer is how exchanges are secured, particularly over a SOAP > binding. In ID-WSF, those are all over the SOAP security layer, which > has minimal adoption and problems. The alternative, though, is > reinvention of a different secure messaging framework on which to > layer the exchanges, which doesn't appeal to Scott very much. > > The key question is scoping and drawing the boundary to determine > which problems people need to address. Since Scott sees people trying > to address similar problems using e.g. OAuth supporting user > involvement, he thinks we need to ensure that what we build is at > least that capable. > > It's also a sufficiently large piece of work in Scott's mind that it > needs several participants involved to justify all effort, so he'd > like to see many vendors and interested parties working with it. > Scott thinks this is easily as much work as SAML 1.0, and Phil shares > those concerns. > > We'll approve this as a work item today, but we need to agree on the > scope and develop sufficient participation to get this going > somewhere. A paper spec is not the objective. > > [AI] Nokia-Siemens and Oracle will consult with one another, and will > develop a working draft or a proposal that captures some of the use > cases of interest and circulate that informally. But to make progress > beyond that, they would need to recruit some more people and add > clarity about scope and forward direction, and the relationship to > ID-WSF would need to be carefully explored. They'll report back on > their discussions on the next call. > > 13) Face-to-Face meetings have been held on an as-needed basis, and if > there are some good materials for discussion that would make a meeting > valuable, we may recruit hosts and determine some dates. The > attribute management protocol may be sufficient motive to have one, so > long as we can get a reasonable number of people together. > > There are no OASIS annual conferences to attach such a face-to-face > to. It could be done in conjunction with another Identity Management > industry event, but our experience is that if you go to a corporation, > they have good white boards, speakerphones, and meeting rooms, and > it's far cheaper than using bad infrastructure at a hotel. > > The chairs are open to offers to host such an event, if the hosts have > topics they would like discussed. > > > Next meeting will be on November 17, 2009. > > > ACTION ITEMS: > > [AI] Hal will create the ballots. > > [AI] Thomas and Hal will investigate the assignment of permissions > within the SSTC Jira instance. > > [AI] Hal will check the rules for normative references in > specifications issued by the SSTC; particularly, whether they can > reference standards issued by e.g. the Kerberos Consortium. > > [AI] Nokia-Siemens and Oracle will consult with one another about next > steps for an attribute management protocol, and will develop a working > draft or a proposal that captures some of the use cases of interest > and circulate it.