Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] Notes from Higgins Developers Call on March 5th

Higgins dev call – March 5, 2009

 

 

Attendees

 

* Brian Carroll - Serena

* Andy Hodgkinson - Novell

* Mike McIntosh - IBM 

* Drummond Reed - Cordance

* Mary Ruddy - Meristic

* Markus Sabedello - Parity

Paul Trevithick - Parity

* Brian Walker - Parity

Tom Carroll - Parity 

* Hank Mauldin - Cisco

* John Bradley

* Anubhav Sharma - Ospera

* Brian Carroll - Serena

* Andy Hodgkinson - Novell

* Drummond Reed – Cordance

 

Logistics
Time: noon EST
Dial-in:
1-866-362-7064 / 892048#

Agenda
1. [Brian] 1.1M6 - targeted for March 6  

  • See  [1]   
  • [Brian]  Status on M6:  had targeted for this Friday.  I propose we push that out one more week to March 13th.  Talked to Oracle [Mohamad]. He has IdAS Google CP item, the only major candidate. He’s hopping to have this finished by then. I took all the other high priority candidates to M7 and updated the wiki page accordingly. The M7 target date is April 24th  for the WS-Trust , SOAP and IdAS registry items that Greg was working on. Any question or comments? I can send an email out to the Higgins-dev list.                 


2. [Brian, Alexander, Andy] Selector Architecture Harmonization

  • See [2]  
  • [BrianW] Andy is on the call, and I’ll let him talk to the client side about all his great work. The main focus is now to prepare for the FC2 meeting next week in Paris. They have been working on taking the latest version of the Cocoa client working against the backend services that Alex has developed to demo on a Mac machine. Had meeting yesterday and sent out high level summary.
  • [Andy] I have the basic operations, add, delete, modify and retrieve working. It is also working in the GTK client also, though there are some minor performance issues. Have the cocoa more complete now than the GTK  Sent version out to Paul and Markus yesterday. Feedback is that it is working and will at least have something to demo. Meantime, we’re going to address performance issues from multiple backend trips to the server.
  • [Markus] I tried it today, and it all works.  I was able to access my account and use my cards, so that is good. But it is just working for p-cards now. 
  • [Andy] I think Alex is working on that. It will accept and store m-cards, just need to get it to return them.
  • [Brian] Yes.


3.  [Markus] Should IdAS authentication materials be just a Java Object?

  • Would it make sense to   
    1. Define an identifier for every common type of authn materials.
    2. Have an IAuthnMaterials interface that defines method for (de-) serializing authn  materials?
  • OTIS REST [3] has solved both problems by inventing its own authn material identifiers and serialization structures.
  • Responses from Jim
  • [Markus]  Haven’t made too much progress on that on my end since last week.  The idea is to do two things … and find some way to serialize and de-serialize them so can store than and send them over the wire.  We could introduce an  interface of authentication materials. There has been some feedback from Jim on that issue. Jim said that he agrees with the first idea.  So I will try to start a list, make a first proposal, and then on the second issue, I think Jim’s opinion was that it would make sense.  I will also make a proposal. 
  • [Hank] Not really clear on all of this, so when you write up the proposal can you write up the benefits as part of the proposal?
  • [Markus] The main benefit it to make it possible for someone one who wants to open an IdAS context to know what kind of authentication is needed. Today, there is no way to learn this programmatically, so you need to know it before hand. If we had this we could do that and open contexts dynamically without knowing anything about them in advance.


4.  [Anubhav] Eclipse Swordfish [9] and SOPERA [10]

  • SOPERA 3.2 is using the Higgins STS.      
  • Has implemented renew functionality in the Higgins STS via an extension.   
  • Swordfish can be used as a SOA runtime; can deliver a swordfish binding for Higgins STS.
  • Offering to donate this to Higgins.     
  • [Mary] We have as special guest this week [Anubhav] who has been using the Higgins STS and extending it.  He is releasing a commercial product SOPERA 3.2 that is using the STS, and is also involved with the Eclipse Swordfish project.
  • [Anubhav] I’m Anubhav Sharma from Ospera in Germany. Will give you a brief background. We have a product based on SOA and we have a suite of products and infrastructure services and security services and toolings. With the latest version,  we have already released 3.2, we have integrated the Higgins STS.  We looked for open source and found Higgins and were very successful.  It was useful to use WS-Trust and Higgins. We had to extend Higgins to support existing production functionality. We had to use extension points to have integration with enterprise hosts.
  • [Anubhav] Want to work closely and share ideas.
  • [Anubhav] We also have an Eclipse project called Swordfish, and we are already headed to general release. For Galileo release can’t use STS, but in the future, really want to use it.
  • [Anubhav] We want to contribute back the extension we have already done.  Swordfish could also use this.  I propose delivering a Swordfish binding for the STS. That is the basic idea, why I’m contributing in this con–call.
  • [Mary] Thank you. To propose a contribution to Higgins, the next step is to enter a bugzilla item with the code in an attachment and send it to the list.
  • [Mike] You should enter a bugzilla item with an attachment.
  • [Mary] Yes, that would be great.
  • [Anubhav]  Yes, I will do that…
  • [Anubhav]  Also will be providing  a Swordfish binding. Not sure how it fits.  Would help for integration.
  • [Mary] Enter a bugzilla item for that also.
  • [Anubhav]  It is  a proposal. We have a Swordfish binding to  connect to the Higgins STS. It is not yet done. Not looking for any announcement.
  •  [Mike] Can you tell us a little more about Swordfish?  Is it an alternative to??
  • [Anubhav]  Are providing an environment in OSGi. We have integrated Apache. Now providing support for Jaxvx Interface. These are all OSGi components that can be deployed directly into Equinox.
  • [Mike] Ok.
  • [Anubhav] I will do a bugzilla item and wait for comments and decision. I ‘m going at a high level [on this call]. To go into detail is a lot.
  • [Mary] Looking at the code will help us to get up to speed.
  • [Mary] Thanks for joining our call today.
  • [Anubhav] Thanks.


5. [Paul] Password Cards

  • [4] Discusses how I-Cards in an enhanced client (i.e. enhancements to the Higgins Browser Extension as well as to the Selector) can be used to login to unmodified un/pw-accepting websites.
  • There are three design options [6] for how the card metaphor is applied. Some of the tradeoffs between them are listed [7].
  • Paul’s blog post [5].
  • [Paul]  Wanted to let people know about his interesting idea. How can we take advantage of the metaphor of a selector  and card.  I took the opportunity to create this wiki page. There are a lot of people interested. The biggest most interesting question is there are three metaphor design options. The question is how do those username and password pairs relate to cards? There are three ways we could do it.
  • [Paul] From the wiki page: 1) every un/pw is on its own card.  There is only one pair on each card. If a user had their account at Amazon they would have their card.
  • [Paul]Another step is to collapse all the accounts at Amazon (buying book for work vs. home).  What if we collapsed them per site.  Going still further “per role”.  It  has been suggested that a person may have as few as one un/pw card, if they have only one persona and don’t have multiple accounts on any website. If they did have more than one account on  a particular website, maybe If I have a card for personal use and a card for work use, or if a mom is sharing a computer with two kids they may each have their own card. Typically you would only have a few, 1-3, role cards.  So it has the benefit of a smaller number of cards.  I’m interested in gathering feedback. It need to be fleshed out further.
  • [Mike] It seems like one thing to argue about password cards are personal cards.  The alternative is if the p-card contains the set of un/pw you then have a problem if you were to synchronize your card store between two boxes. You’d have to recognize the card type any time any password changes….
  • [Paul] First of all , I wrote up only about personal pw cards but you are absolutely correct there could be managed password card  We at Parity have already implemented that before. Your issue of re-syncing is more of a problem with the per roles approach. But that is a really good point.  I will add to the pros and cons…
  • [Mike] The problem is that the per account and per site model had the potential to generate way too many cards.  Managing that whole giant list will be difficult.
  • [Paul] That is a common point that is made. It is true that there would be a lot of cards. You would have to put extra UI in to manage lots of cards. You would only see 1-3 cards in a selector. Only time see lots of card is in the card manager view. We believe that can be handled in the UI.  Microsoft’s design center is that a person has only a very few cards, and so their UI only handles a few cards.
  • [Mike] IBM [employee] example: It seems wasteful to create an extra card for every one of those websites I would go to internally at IBM (as they would reuse the same authentication.]
  • [Paul] That is a disadvantage of the per-site approach.
  • [Brian] Is there any other scenario where a card could have multiple passwords on it.....?
  • [Mike] The problem is passwords expire at different times on different systems. The other problem is that if we encourage that it is  encouraging not the best process.
  • [Brian] Though in that case hopefully the password is better.
  • [Mike] When we get back a message about a password expiring, it would be awesome if we could somehow generate a strong password that conforms to the password policy, that the user never has to type in.  We can generate different one for every site.
  • [Paul] Mike you are right. I‘ve been saying that for three years.
  • [Hank] Great. You are talking about a pw manager plug-in that is available on most operating systems.  On Mac iPassword stores all your un/pw’s. For an OS you could have a pw managed card that has that function as a single card that uses that metaphor.
  • [Mike] I think you could have a card for each role
  • [Hank] Could separate between business and personal.
  • [Mike] You are really talking about something people do. IBM acquired Accentuate. It screen scrapes and stores un/pw for every site. To me the benefit here is the consistent user experience regardless of the underlying protocol.
  • [Paul] Amen to that.
  • [Hank] If you have this card manager, vs. the idea of having 100’s of potential cards, it seems different. That almost becomes a different management issue. I like the idea of having fewer cards. I think what you are describing is already available. So it seems to me we would take the best of this and combine it with the UI of having a card.
  • [Paul] That was a great discussion.  I sense a leaning towards the idea of  the per role card we came up with.  I proposed it based on our work with r-card., but I’m not sure that is a good approach.
  • [John] Hopefully by the time we have a r-card with Amazon, they will also take it for login.
  • [Paul] It may be two different cards. Maybe it is ok or good to separate that which  gets you in the door from your persona inside the room.
  • [John]. If Amazon took the Equifax card, that is fine, but it only has a few fields about you. For the r-card  with Amazon, I largely provide the fields. Maybe that is fine.
  • [Hank] I don’t think that is a problem. When the user goes to the site, both cards come up.  The user could choose either one. The issue.. .
  • [John] It is likely only one card would come up.
  • [Drummond] Agree..
  • ……
  • [Paul] Maybe it is not good to extend the r-card per site thing to how they get in.
  • [Drummond] There seems to be a natural progression. Password cards are for site that just take passwords and aren’t information card enabled yet. The kind that is on a personal card. If they are issuing a relationship card, that is what they would ask for and what would pop up in the selector.
  • [Paul] That is a great point.
  • [Paul] Can I just take a straw poll?  Is there anyone who thinks the per site and per account per site is the best way to go?
  • [Tom] One thing I would say about the other option is it requires a different UI and ceremony for the user. If I have two cards associated with two accounts on a …
  • [Paul] No, you would just use a card and the system would accept it.
  • [Paul] You have two accounts and if you have problem factoring your life into a card, two cards will pop up. The other possibility is you haven’t factored your life and have two accounts, one account per card.
  • [John] Problem can’t put two accounts on one site.
  • ………
  • [Drummond] I’m finding myself moving from the per site to the per role camp… There is only one question have to ask the user. Should be fairly quick process of reviewing the role list.. For each site that has more than one account they will assign them..
  • [Paul] Not only is that not too much trouble, reviewing the list is also an opportunity to identify the ones that are wrong…
  • [Paul] I also started off in the per account camp and migrated to the per site and now I’m in the per role camp. [reference to Brian’s comment.]
  • [John] Per role is more UI work but makes it easier…
  • [Drummond] If have one, then done. If have two, just choose a role and go.
  • [John] Independent of which choices we make, we still have the fundamental security problem of how to secure between the selector and browser plugin.
  • [Paul] That problem has to be solved anyway. It is somewhat orthogonal to this.
  • [John] This was a problem that no one could take advantage of.
  • [John] It only really applies to no SSL RP’s. Once we have the ability to give out passwords for individual sites,  Today, the most people are exposed to any plugin,.. It is at least a separate process.  So that there is some friction there. The integrated one, where the selector is part of the plugin…..
  • [Mike] Even if you assume that you are not going to give away info in the card, if you can hijack the browser, in a session that has been established correctly, what is the difference?  If I can install a browser plug-in and you use that browser to access your bank account and you go in and select a card, the mean time, the token you used to access your bank account is sitting in your selector. You can just relay the token…. 
  • [Paul] If someone is willing to install a rogue browser plug-in, there is nothing we can do, unless we can lock down the browser and selector there is very little we can do. We can make it convenient to be as secure as we are now. I hope that this leads to passwords going away.
  • [Mike] I agree once people use cards, bumping them up to something more secure will be easy to do.
  • [Paul] We have one more item on the  agenda.
  • [Mary] It is proposed changed to the Higgins website left-hand navigation.

6. [Paul] Higgins website nav change

  • See [8] for proposal
  • In a way it’s really just following through on the “3 doors” structure that we’ve implemented on the home page.
  • [Paul] …I feel like that is working. And I propose that we apply it consistently throughout our navigation structure and flatten out solutions. Solution is a duplicate of info in doors one, two and three. They are in conflict. I propose we get rid of the concept of solution.
  • [Paul] I’m willing to do all the work, I want to make sure that it all make sense.
  • [John] Would you carry this over into the components? I don’t think this will make it any worse that it is.
  • [Paul] Components are just building blocks and can be used cross solutions so need to keep that separate.
  • [Hank] If we change the solutions, it will change how we link in the components anyway.
  • [Paul] We have space on the left. Does anyone object?
  • [Hank] I don’t see any problem. 
  • [Paul] The problem is that we have two places that describe solutions: one is PHP and one is wiki. This makes it simpler and avoids duplications.
  • [Hank] I think that works. We would want to keep the information on third parity products that use Higgins.
  • [Mary] We could move that up into the higher level link.
  • [Hank] It could have its own navigation thing.
  • [Hank] Maybe it could be elevated.
  • [Mary] Exactly.
  • [Paul] Ok, good. We are out of time.


[1] http://wiki.eclipse.org/Higgins_1.1M6
[2] http://wiki.eclipse.org/Selector_Architecture_Harmonization
[3] http://code.bandit-project.org/trac/wiki/OTIS/Doc/Task/Authenticate/AuthenticateUser
[4] http://wiki.eclipse.org/Password_Cards
[5] http://www.incontextblog.com/?p=177
[6] http://wiki.eclipse.org/Password_Cards#Metaphor_Design_Options
[7] http://wiki.eclipse.org/Password_Cards#Metaphor_Design_Option_TRADEOFFS
[8] http://wiki.eclipse.org/Website_Backlog#Flatten_Solutions_into_the_3_solutions_areas_.28nav_structure_change.29
[9] http://www.eclipse.org/swordfish/
[10] http://www.sopera.de/en/home/


Back to the top