- From: Bajaj, Siddharth <SBajaj@verisign.com>
- Date: Mon, 8 Feb 2010 16:55:31 -0800
- To: "Bajaj, Siddharth" <SBajaj@verisign.com>, "McClure, Allan H." <amcclure@mitre.org>, "Thomas Hardjono" <hardjono@MIT.EDU>, <ben@digicert.com>, "Shan, Jeff" <JShan@etrade.com>, <gpercivall@opengeospatial.org>, <rsingh@opengeospatial.org>, <public-xg-mashssl@w3.org>, "Ravi Ganesan" <ravi@findravi.com>
- Message-ID: <F4E86EE3B25D5B4686A74658EB3593E1F9E7C2@mou1wnexmb03.vcorp.ad.vrsn.com>
Attendees: Ravi Ganesan Jeff Shan Siddharth Bajaj Allan McClure Thomas Hardjono Raj Singh Minutes: - Use Cases (contd) + Raj Singh described the Open Spatial use cases of relevance to MashSSL. For example imagine a EU geodata database that employees of governments of EU countries have free access. In this hypothetical scenario the EU system does not care about the identity of the user, simply want to know if they are coming from a web site belonging to a EU govt. In this case MashSSL fits the bill as it can be used to perform the server to server authentication, with the EU employee being the "friend in the middle". + Thomas Hardjano summarized the goals of the kerbweb project. Although vast number of desktops are Kerberos enabled (e.g. via Active Directory) in general it is not used much for cross domain authentication. Thomas described how there are efforts to make the linkage between SAML and Kerberos as one approach to making this happen. Ravi Ganesan described the SafeMashups GPL implementation of this use case, wherein a gateway within the domain of the enterprise uses SPNEGO to consume a Kerberos credential and then does cross domain MashSSL to allow the assertion to travel to the remote domain. + There was much discussion around whether MashSSL should retain the concept of a userid in the is_scrambled field (which was added to support the Kerberos use case). Everyone was in agreement that this would be confusing as MashSSL is *NOT* an identity federation protocol, and rather is a secure transport between an IP and an RP which can be used by any identity federation protocol. Therefore it was decided to eliminate this field, and to allow a general purpose extension point - which could be potentially be further specified in a different document and used to carry use-case specific information, for example a Kerberosprofile for MashSSL to carry kerberos-specific attributes. + There was some discussion on whether the MashSSL protocol could be used through a web-anonymiser service. Ravi is going to dig into this further to understand the impact, if any. + Ravi started mentioning the use case around 2-party MashSSL. While initially thought of as an optimization for the 3-party MashSSL protocol, this could be interesting in itself. - We need to further think through this. - Potential F2F meeting + Since many of us will be at the RSA conference in the first week of march, we will try and see if we can organize a couple of hours of face-to-face time. + Siddharth will send out an email to try and identify potential timeslots. - Next conference call will be Feb 11th, 1pm PT/4pm ET, Main agenda items will be + Complete conversation around 2-party MashSSL protocol and whether this should be considered in-scope. + F2F meeting at RSA conference + Discuss how we can abstract the use cases + Start discussing the outline for the group report. Please let me know if there are any additions/modifications to the minutes. Thanks, Siddharth
Received on Tuesday, 9 February 2010 00:56:17 UTC