Re: [security-services] Minutes and Action Items from the SSTC Conference Call (3 Nov 2009)

[Mary McRae <mary.mcrae@oasis-open.org>]

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