[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Proposed Agenda for SSTC Conference Call (Tue 21 Sept 2010)
> 2. Need a volunteer to take minutes. Nate volunteered. Quorum was achieved. > 3. Approval of minutes from last meetings: > > Minutes from SSTC Call on 7 Sept 2010: > > http://www.oasis-open.org/apps/org/workgroup/security/email/archives/201009/msg00016.html Anil moved to approve the minutes and Scott seconded. The minutes were approved. > (c) SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0 as a CS > - Status: CS created and publsihed. > > (d) SAML V2.0 Holder-of-Key Assertion Profile Version 1.0 > - Status: CS created and publsihed. These have both been created and published. Nate has not updated the Wiki yet, but will do so. > (e) Kerberos related items. [Josh/Thomas] > - Kerberos Attribute Profile: > - AI: Josh/Thomas will suggest additions to Attribute Profile. The profile is still being retooled alongside the team from CMU who provided the additional use case discussed in prior minutes. The revision is probably almost done and an updated version should land in the SSTC within the next several weeks. > (f) SAML V2.0 Identity Assurance Profiles, Version 1.0 > - Status: 15-day review closed on 10 Sept. > - Any comments received? Bob and Scott were not aware of any further comments received on the Profiles. Paul attested to the fact that no further comments were received, that CD-02 was reaffirmed and unchanged; Scott seconded it. No objections or concerns were raised. Nate then moved to create a CS ballot for CD-02 of the Identity Assurance Profiles. Paul seconded Nate's motion. Thomas will submit a request to Mary for the ballot. > (g) SAML V2.0 Metadata Profile for Algorithm Support Version 1.0: > - Status: now in 60-day public review. (Closes 13 October) > - Any updates? Scott had observed that the examples were broken in this profile, and he'll update a new working draft shortly. > (h) Service Provider Request Initiation Protocol and Profile Version 1.0 > - Status: now in 60-day public review. (Closes 13 October) > - Any updates? No updates. > (i) NSN Attribute Management proposal (Thinh/Phil) - any updates? Draft 2 was sent to the list on Monday. The terminology has been cleaned up so that notify issuer and notify target are more explicit. The references have been updated. The core protocol is largely the same; the major change is that instead of using a SAML subject, a SAML NameID/EncryptedID is referenced in the schema instead. Front-channel and back-channel have been renamed to asynchronous and synchronous. The terminology here is meant to match the rest of SAML's terminology. Scott said this was never deeply discussed, and the goal was to create profiles that were not specifically tied to bindings. The goal was to keep bindings separate from profiles, and Scott came up with arbitrary categories for those bindings. Scott suggested the examples be moved to the core protocol section. In retrospect, he's comfortable with the categories, but not so much the way it was laid out in this document. He just wants to see a core protocol that is binding-agnostic, and a profile that defines use and bindings of the protocol; Thinh agreed with the approach. Either terminology is comfortable for him, and placing both into the same document is fine. A conformance section, which is a requirement to conform to OASIS rules, most sensically matches a profile, since conformance to a protocol is a less meaningful concept. The issuer can now state which protocols it is capable of using. If it suggests a non-SAML protocol such as SPML or OpenID to subsequently pass the data, omitted is how they would handle the use of different types of identifiers. But Scott observed that SAML does not have a fixed set of identifiers; it has a structure to allow you to use any type of identifier you would like, and that should suffice to handle this aspect of the multi-protocol use case. Tom Zeller submitted some questions to the list about this tonight regarding clarification of the differences between a ManageNameID request and a RetireSubject in the Notify protocol. Frederick was a little confused as to why PoCo was included, since there is relatively little protocol included in PoCo. The idea, put forth by Salesforce.com, was that a notification could be sent using ChangeNotify. They wanted to use PoCo as the payload for a large bulk transfer, and would "secure the channel and do whatever." Phil expresses no opinion about how this next step is performed, considering it out of scope for this proposal. The same is true for LDAPv3, SPML, etc.; the notification is the only part that SAML is responsible for if SAML is not the transfer protocol. It is a purely informative reference and does not affect the SAML operations, and as such the references are non-normative. In section 2.5.1, if the Notify Issuer indicates that many protocols are available, a question was outstanding whether there should be a way to indicate preference, e.g. through another attribute or an ordering of the URI's. The other way to do this would be through the SLA. Scott suggested text indicating that, in the absence of out-of-band information, the order in the element SHOULD be taken as preference. It should be clarified that a response will use one protocol, as the alternatives allowing for the use of many protocols to respond to a single ChangeNotify were too complicated to countenance. Scott will look at the schema for the next call. The next step for Phil will be to complete the profile section and to move the examples into the profiles to give a cleaner separation. There's a fair number of empty paragraphs left to do. Detailing how an AuthnRequest works with a ChangeNotify, for example, is a goal. This would differentiate between an ordinary AuthnRequest, and the initiation of identity federation via presentation of an AuthnRequest. Thinh proposed another scenario where a ChangeNotify would lead to an AuthnRequest that would suggest an identifier that could be used to create a new identity at the recipient of the AuthnRequest, followed by a ChangeNotify Response. Phil has some concerns about mixing the protocols in such a way. Given the complaints and problems about getting the user-agent to the providers in the right sequence at the right time, Scott is dubious that such a mix can be performed well, and a consensus was reached that a cleaner separation between the two, rather than an encapsulation, would be a better approach. Scott suggested a Metadata section needs to be added to the document as well. > (j) SOA-TEL Token Correlation Profile (Federico/TI) - any updates? Federico had no updates on the document itself. He analyzed the specification again after Scott's comments regarding the applicability of the delegation work to Federico's use case. Federico is still not sure whether the token correlation requirements and semantics are sufficiently different from the delegation work. He's also not sure whether the token correlation profile and syntax are complete and correct. Some of the restrictions have been placed on Federico's company by their vendor, due to limitations of the IdP implementation. It was more comfortable sending two separate assertions. It also more simple for them to implement the issuance of SAML assertions that are generally usable at a number of services, rather than issuance of specific assertions for every application, because the IdP requires less knowledge of the business services. It's also nice to decouple business policies from the actual technical implementation. He's still concerned about the processing of the expiration time of the first SAML assertion, and whether and how to imbed the link from the second assertion to the first assertion, particularly without invalidating the signature on the assertion. Requiring that both assertions be valid makes the profile a little simpler. Federico also thought it might be interesting to place the correlation element out of the assertions themselves, and use it as an entirely standalone token. Federico understands if this profile is not considered the best approach within the SSTC on the basis that existing SAML specifications could achieve his goals. Scott sees a subjective question and an objective issue. Subjectively, he thinks it's inappropriate to create a profile that allows an RP to ignore the validity of one of the assertions. Nate agreed. The objective issue with regards to this profile is there is no way to use the condition that he's trying to create outside of the signed content and keep it in the assertion. If the correlation condition is not expressed in the assertion, then it's not in SAML, and needs to be done somewhere else, such as WS-Security, where there are already ways to chain multiple tokens to a single message, which may be a more appropriate foundation. If you want to recycle elements of SAML in another protocol or context, that's fine, but it's still not a SAML issue. Federico explained that the WS-Security working group is on maintenance status, so it's a difficult place to do further work. As such, Nate suggested that Federico try this series of actions: 1) Analyze the delegation profile to see whether its semantics and technical requirements can solve his use case. 2) If not, make sure that token correlation can be expressed at the assertion level, rather than at a message level, or outside the assertion. The SSTC is not the right place for definition of message level constructs. 3) If token correlation can be expressed as a <Condition> in an <Assertion>, and the requirement that both <Assertion>s be valid is okay, then continuation of work on the Token Correlation Profile in the SSTC is appropriate. > (k) Channel binding proposal -- Scott. Scott has been playing around with some strategies for incorporation of the channel binding concept for pairing SAML to GSS or SASL. He's come up with a way to allow the IdP to be a mediator for channel binding negotiation, a cool little trick that can really improve the phishing story. One very simple application of the material would be to plug a MITM hole in the existing SOAP binding, where the SOAP binding is often authenticated with the SOAP signature because client TLS is more painful. From the people who have looked at it, some consensus has arrived that it could be useful. He plans to move this along independently, but in parallel, will produce a new version of the ECP that uses the channel bindings in this proposal and also adds holder-of-key support. The presentation of the profile would also be simplified so it would be less confusing. This has a ways to go, but he wants to move this along fairly quickly, in order to encourage a GSS proposal(at the IETF, likely in KITTEN rather than the SASL working group) to move more rapidly too. This will likely lead to some natural liaison work with the SSTC. > (l) Metadata extension for Login/Discovery -- Scott. > Scott hopes this document will speak for itself, and it has been alluded to on a number of other calls. This is a specific proposal from Sampo, he believes, to use the Organization elements in metadata to include descriptions of IdP's and SP's and include logos. Back then, individuals thought it distasteful to do it, but based on experience and embedded base that have accrued since then, it seems clear that the use case is important and some extensions are necessary to address it. The extensions are in two subsets; one is for user interface, and the other set of extensions relates to hinting information to allow discovery tools to potentially derive guesses about the IdP to use, particularly from client information, such as network address. Some strawman implementations are being fiddled with right now, but the standards process doesn't need to be rushed.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]