Notes for Higgins dev call - September 24, 2009
Attendees * John Bradley * Drummond Reed - Cordance * Mary Ruddy - Meristic * Markus Sabedello - Harvard Law Lab * Paul Trevithick - Azigo * Brian Walker - Azigo * Hank Mauldin - Cisco * Alexander Yuhimenko - Azigo LOGISTICS: Time: noon Eastern (16:00 UTC) U.S. Dial-in: 1-201-793-9022 passcode 7990866# - NOTE NEW DIAL IN NUMBER AGENDA 1) [Brian, Paul] HIGGINS 1.1M8 PLANNING * Walk through the Higgins 1.1 plan [1] and schedule items * Clean-up of links underway to point to latest builds * The download page does have green links * [Brian] For the GTK selector we are actively working on packaging that. * [Paul] That may be for M8. That will be great. * [Paul] Internationalization, etc., we can gradually work on * [Paul] The selector switch page has been updated. 2) [Paul] Higgins Auth Service * Begin design discussions of [4], with a focus on objectives, rationale, requirements (not implementation, tech etc.) * [Paul] Alexander, can we use this page to capture the requirements of this service? It is to be used to authenticate to all Higgins back end services. * [Paul] Alexander do you have any feedback on the pages? * [Alexander] .. SAML token like access token. for each of the services after then get access token they verify the. * [Paul] So one concept you are proposing is that the client would make a key pair with the server (asymmetric public key approach). Is that to allow a client to later connect to a service? In the current approach it doesn't use PKI, you are proposing a different approach? * [Alexander].. What should be the access token? A SAML token or ?? * [Paul] So one of the open questions is the token type itself. Another is the protocol. Because we are using restful rather than SOAP services, we might want to look at OAuth. To my knowledge OAuth doesn't have any restrictions on the token? So could you use a SAML token? * [John] They are symmetric tokens so I'm not sure if that makes sense. OAuth is symmetric not PKI based. * [Paul] Do you think OAuth is a good protocol to use for this? OAuth usually starts with a request token. * [John] An OAuth token doesn't contain information. It probably isn't a good idea to encode semantics into those tokens. If what we want to do fits that model, it is potentially a good model. * [Paul] So the first thing we should do on this wiki page is define the high level requirements. The basic idea was to split authentication into two services. * [Markus] Sounds like an STS you authenticate to. * [Paul] The authentication materials, we don't want them to use Username and Password. * [John] You can authenticate to an RST with a key pair. * [Paul] The other reason is we were trying not to make this SOAP based. * [Paul] Correct me if I'm wrong, you go to this service, and embedded magically in the client is a serial number and the idea is that material key is something that is a secret only that selector and the auth service knows. * [John] If it is a secret only the selector knows. * [John] If it is asymmetric, then it can be only that selector knows. * [Paul] We were thinking along the lines of a shared symmetric key and when the person installs the selector it stores it very securely and uses it to sign things. * [John] So a shared secret with sufficient entropy.. * [Markus] What is it that you signing? * . * [John] You do an authentication token and the access token and in the OAuth case your persistent token is traded for a session token. * [John] We may not need the first part of OAuth. OAuth is mostly about how you get that shared secret, by embedding the shared secret in the client you bypass most of the OAuth stuff. * [Paul] I think there needs to be a separate setup. First it is serialized, then the user needs to come up with a user name for the account. (Can group all the selector clients of a given use under one account.) Want to prevent other users who gain physical access to that selector from using the selector. * [Paul] The user name groups. The password is to prevent masquerading the serial selector * [John] But anyone can get a serialized selector. * [Paul] .. * [John] You could attach it to the account before, then download it, but if they are truly independent, that will be difficult. * [John] In this model the party providing the selector is independent of the service provider. How does the auth service get this shared secret? * [Paul] The auth service is also the download site. It generates the symmetric key itself. * [John] You are providing a service that provides no value, but can stop the selector from functioning. * [Paul] If company A runs the Auth service, and B provides all the backend services for the Selector. Party A may have existing identities it manages anyway, what they want to do is say you don't need to create a new user name and password to attach a selector to that account. * [John] So you don't want the third party running the backend wallet service to know the username and password. Who is grouping these selectors into an account A or B? * [Paul] At his point John you have raised a number of difficult questions so I'd like to stop this topic. It has been enormously helpful to me. We have only 15 minutes less. I sent out a new Agenda. 3) [Paul] Change our Higgins web page process * Our current process is that we first make changes to the /ver2 folder, then let folks review the changes and then copy the changes to the main folder * I'd like to revise this in the interest of speed * New proposal: developers directly update the PHP web pages immediately except for the home page or other "marketing/positioning" oriented web pages. * This way pages like [3] could be updated immediately by solution owners * For example, Markus could just add the missing links to [3] for his solutions * [Paul] Discussed the above proposal. There were no objections. 4) [Brian, Paul] HIGGINS 1.1M7 TOUCH UP * Add missing build links to [3] * [Paul] Have been working on fixing the missing links. 5) [Mary] Website updates . Sitrus Android Password Manager announcement . Moved components page to Higgins Community navigation section . [Mary] There is a new announcement on the website that Situs has contributed an Android Password Manager. Also we've move the link to the components page to the Community section of the Higgins navigation area.. . [Paul] ..Mary should talk to Igor about a different solution page and PR. . [Mary] If have suggestions for improvements let us know. . [Paul] Another area for a similar announcement is Coresiceo's contributions. They are a German company, we have done work together. You know Elmar, see if there is any interest on their part. . [Paul] Brian says the Higgins components pages are now updated with respect to the selector switch. . [Paul] Just use Ver2 if people want to stage, but if someone wants to change the downloads page, they should just change it. We should still go through the review process for the home page or pages with marketing impact. . [Paul] So we will add access for more committers to have access to the web pages. . [Mary] That makes sense. 6) [Drummond] Stork Project * [Drummond] I finally connected with the stork team this month. (ICF to Stork Team.) They were very interested in learning that ICF is headed in a multi-protocol direction as they have a commitment to SAML. They also really want to see a multi-protocol client. STORK specs need to be implemented in open source, so they were very interested in multi-protocol support in Higgins. They really want to encourage that and wanted to know when that would be in the Higgins time line and want to be part of that. * [Paul] That was a conversation with which hat? * [Drummond] With my ICF Executive Director hat. * [Drummond] They have a specific interest in native SAML support on the client side, but it doesn't meet their security needs. They are working on a specification that includes "holder of key" which requires browser changes. Their message is if they knew there was an open source client that did what they needed, they think their members would support that for that use. * [Paul]That is awesome. How do we engage? One thing that is in the works is an "OpenID selector "for lack of a better name. Even if it requires things that don't exist today, such as discovery of a trusted OpenID, there is huge interest in this, I think that you will see that happen fast. * [John] They don't care that much about OpenID. They want a client that can do the SAML holder of key dance between different services. * [Paul] I'm encouraging Drummond that we are on that wavelength. How can Mary and I engage? * [Drummond] The two action items are 1) they would like a wider community to review the common specification as soon as it is ready in the next 2 or 3 weeks. I will send a message to Higgins-dev and ICF lists. 2) is to open up lines of communications to the Higgins project. I suggested we start an email thread with then and potentially invite them to a call. * [Paul] Cool. * [John] Where the real potential strategic advantage lies is they may have leverage with the browser vendors. To do this requires a change to the browser. If they can get the browser vendors to give us access to the key store., then we can also do this for IMI and have something that is legitimately LOA-4 compliant. * [Paul] So Drummond you will follow us by introducing us? You can conveniently create an introduction. 7) [Paul] R-CARD PAPER * [Paul] Last item * [Paul] I included a link to a very rough draft of a R-Card paper. It is partly for Hank's benefit, if he is interested. * [Hank] Yes, I am. * [Paul] It is a first attempt to go public with a strategy that has been buried in the Higgins' wiki. I'm interested in any feedback. I want to put in use cases. It needs an intro. I played with a different color treatment of the mouse. . [Paul] Thanks everyone. [1] http://wiki.eclipse.org/Higgins_1.1_Plan [2] http://wiki.eclipse.org/Higgins_1.1M8 [3] http://www.eclipse.org/higgins/downloads.php [4] http://wiki.eclipse.org/Authentication_Service_1.1
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
