[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Minutes and Action Items from the SSTC Conference Call (3 Nov 2009)
Hi everyone, I believe that the Security Services Issues Tracker project is now up-to-date; everyone who did not previously have a login/password should have recieved notification to set their password. Regards, Mary On Nov 3, 2009, at 1: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. > > 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. > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]