Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] Notes for Higgins Developers Call on February 19th

Higgins dev call – Feb 19, 2009

 

 

Attendees

 

* Brian Carroll - Serena

* Andy Hodgkinson - Novell

* Drummond Reed - Cordance

* Mary Ruddy - Meristic

Paul Trevithick - Parity

* Brian Walker - Parity

* Hank Mauldin – Cisco

* John Bradley

 

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

Agenda
1. [Brian] 1.1M6 - targeted for February 27  

  • See  http://wiki.eclipse.org/Higgins_1.1M6  for current list                   
  • 1.1 Milestone  planning http://wiki.eclipse.org/Higgins_1.1_Plan     
  • [BrianW]  Status on M6 -  still tentatively targeting February 27th.  Still contingent on getting additional feedback from owners on the wiki page. No use doing a build if they cannot be included. Reserve right to move date. 
  • [Drummond] I think we need to vote on moving the date.
  • [Mary] In theory yes, but since we know from previous milestones what the issues are with the possible continued delay of these specific items, in this case moving the date may just make sense.
  • [Drummond] … (understood).


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

  • Phase I update - held working call on 2/16.
  • Andy has developed two skeletal card store providers.
  • Next working call on 2/23.      
  • See updated Card Store Architecture [1]
  • [BrianW] Had good touch base meeting on Monday to go over the harmonization work.  Sent out notes on Monday.  Continue to drive forward for FC2 demo on  March 11. Andy had been making great progress. Will let him update you. Alex is building RESTful server on the back end.
  • [Andy] I did talk to Alex this am  - hoping to have updates tomorrow.
  • [Andy] Good.  Has been a good exercise to go through from my perspective. Helped to solidify the architecture. Look forward to Alex’s email.
  • [Paul] Andy, have you seen the updated diagram?
  • [Andy] I will look at it in more depth and respond to your email.
  • [Mary] Anything else for this item?
  • [Andy and BrianW]  That’s all for now.


3.  [Paul] RCP Selector for Higgins 1.1?

  • Mary: Interest to do demo for EclipseCON
  • Need new solutions page, build instructions
  • Need to build a connector for the Higgins Selector Switch
  • Need to switch it to using the standard HBX
  • [Paul] I wanted to clarify this issue.  I sent an email around about having the RCP selector for 1.1. Very little may need to be done to it, but it needs a solution page… and making it conformant with the Higgins architecture.  The same could be said for the GTK Cocoa selector.  If we are not going to include those things, I recommend we not include it in 1.1 as we are working towards a harmonized architecture.  I was looking for a volunteer. And Mary it is related to this demo for EclipseCON which brings me to the next item.


4.  [Paul]  “Embedded” RCP Selector?

  • Frank Gerhardt on the list on Tuesday was discussing his desire for an “embedded” RCP selector
  • Paul wrote: Such a ... solution with the selector code running in the same VM as the “client” code has some severe security challenges. It would be trivial for malicious Eclipse plug-ins to attack the card store, emulate the user, etc. Of course by its very nature this solution would only be used in a this special situation where you (a) had high trust in the other “peer” plug-ins running in the same VM+RCP platform and (b) the only cards that would be stored would be those for use with these surrounding plug-ins.
  • Paul added: Ideally the user would have a configuration choice to either (a) invoke the embedded selector [as you describe above] or (b) invoke a general purpose “external” selector via the “Higgins Selector Switch.” Note that this external selector might be the RCP selector, the AIR selector, the Cocoa selector or GTK selector.
  • [Paul] Frank, one of the co-presenters wanted…. I’m guessing that is exactly what the IBM Lotus folks have done.  If so, then it should be just a simple packaging exercise to create an “embedded” RCP selector.  What Frank is saying is wouldn’t it be cool if the window came up right in  the RCP window. So as I said in the email, there are security issues –  should only use in certain circumstances.  If we did build an embedded selector, it would be ideal to have a switch.  Maybe Mary if you follow-up with your colleagues you can talk to them about this.  It is very small change.
  • [Mary] OK.


5.  [Mary] Swordfish

  • Have been approached by German Company that is using our STS and has implemented renew functionality in the Higgins STS via an extension.  
  • They are offering to deliver a Swordfish binding.
  • Have invited them to talk on future dev call.
  • [Mary] Wanted to give folks a heads-up about this.  Are in the process of scheduling a representative to give us an overview on one of the up-coming dev calls.
  • [Paul]  New topic.  Wanted to add if right people are on the call to talk about it.
  • [Paul] The r-card xml spec doesn’t specify how to authenticate to IdAS.  Markus and I talked about it this morning. We need to work on the r-card format so that authenticated is taken care of. It can be dealt with …
  • [Paul] It is just a pointer, it has no additional information on how one might authenticate. Markus says maybe need java interface that is recognizable. …Maybe leverage…..
  • [Paul] Since r-cards are a superset of managed cards, the r-card itself could contain authentication materials.  Or the other way to go, is the way the manage card works, is to just indicate the type of authentication and out of band the client app comes up with the authentication material  (i.e. the managed card approach.) Markus proposed to have the auth materials (optionally) in the card.  It has become one of the last remaining design issues for r-cards.  We need to resolve it.
  • [Hank]  Since it is a superset of a managed card, I would think that following the same way...
  • [Paul] When we say superset, the managed card has an endpoint reference, list of claims and type of authentication it supports.  An r-card provides a second pointer, UDI, that eventually through discovery resolves to an endpoint.  With an r-card, if can authenticate you can access this independent of the managed card’s method.
  • [Hank] There are potentially two authentications involved in an r-card.
  • [Paul] The way managed cards do it ,they don’t include the authentication materials, just indicate one of 4 proscribed types of authentication. With the r-card it is completely undefined.  You are right Hank.  It is a different type of thing.
  • [Hank] I would think if we handled it in a similar fashion to managed cards, generally seems to make more sense.  Including the material might be an optimization.  I’m not coding this so…
  • [Drummond] I agree it sounds nice to be symmetric with the m-card, but will probably have r-card endpoints that aren’t  STS’s so what strikes me is what is more important from a stand point of parallelism is a way for the card to describe the authentication for the r-card endpoint the way it describes it for the STS.  They may be the same options.  I think there is a security issue with the cards carrying the authentication materials. One of the options being looked into from the XDI point of view is a signature option – reverse lookup of the public key.  That form of authentication isn’t an option with m-cards.  So it may be that there are some r-card authentication options that are different. They may also have the same ones. 
  • [John]  (Note that John had a bad phone connection and most of what he said on the call was garbled.)  …designed to work with different endpoints.  One of the obvious things to authenticate to IdAS is the r-card. There is no way to specify that. 
  • [?] Using the r-card to authenticate to that point is not in list as is self referential.  Trying to keep it as similar as possible. 
  • [Drummond] It is a disjoint set, not a superset. 
  • [John] There are situations where there is no STS for the r-card…
  • [Drummond] John is saying that there are cases where there is no corresponding STS.
  • [Paul] Every r-card doesn’t leverage all of a managed card.
  • [John] garbled.
  • [???] If the r-card works as an m-card, then having you authenticate to the STS, then need coordinate between the r-card and STS – sometimes this may be feasible, sometimes not.
  • [John] But there needs to be some coordination anyway. 
  • [Drummond] The r-card endpoint that is exposed may be accessed by something other than cards.
  • [Drummond] It seems to make sense for r-cards to hand their policy the same way, but with a different set of options.  They should be enumerated the same way. 
  • [John] It is more like an RP than an STS.
  • [Drummond] Whatever those set of things are.
  • [Paul] This has been a really good discussion. Would anyone like to volunteer to put a draft out?  Pick a few… one of the URI is this signature thing, or UN/PW. Have a straw man.
  • [Drummond] Where would that be?  Part of the r-card page in the Higgins wiki?
  • [Paul] That’s what I would have thought.
  • [Drummond] I’m provisionally willing to work on that as long as John also does.
  • [Paul] Also Markus and Parity folks need this. Let throw something there and get experience with it.
  • [Drummond] Great.
  • [Paul] There is a page on the wiki:  r-card. You wrote a lot if it.
  • [Drummond] When I reviewed it yesterday, I saw other things there that were interesting.
  • [Paul] Maybe have 1 sentence or paragraph on each use case. Will try to loop Jim S. into this. He has relevant experience.
  • [John] So is the first part of this IdAS or XDI?
  • ????
  • [John] Is this the restful IdAS or XDI?
  • [Paul] It uses UDI discovery. We need a proposal. There is something cute about the r-card being just one URI, but are there use cases. where….. won’t do design on the fly.
  • [John] Garbled.
  • [Paul] If you guys….
  • [Drummond] Doing it as a claim in the card – it will work either way.  Rather than having to discover the XRD, can include the XRD in the card.  If….
  • [Paul] …
  • [John] May want to deliver the discovery info as a claim.
  • [Paul] You want to have the r-card UDI be a claim type in the returns token for the managed card.  This is very important if you are bootstrapping. There would be a claim type for r-card target, the value of that claim would be the r-card UDI.
  • [Drummond] If r-card is ….
  • [Paul] If you want to hand someone a relationship card and you want to piggy back on the m-card to establish trust, you may want to include the value of the r-card’s UDI as a claim value… That is an ancillary issue.  The claims type for an r-card UDI when …
  • [John] At least in the XDI case, if you deliver one of the claims, is the XRD....
  • [John ] You can use the structure of the XRD to delivery…endpoints…
  • [Paul] OK. Starting that thread off and some XML we can code up in the next few weeks would be great.
  • [Paul] Any other topics?
  • [Hank] As people are doing this, if you think about documenting, send me a note. Ultimately we want to get this in the paper.  Don’t think about your task as being separate from the paper.  As you think about it, drop me an email.
  • [John ] At some point need to sort out m-card backed by p-card. Need to make sure it is compatible with what Microsoft is doing with CardSpaceTM.
  • [Drummond] The IMI TC has addressed – Only John fully grasps this issue. He should sync up with anyone who has or will implement this so it works every place.
  • [John] STS’s who have non EV certificate where STS is issuing an m-card backed by a p-card, I think that probably doesn’t work.
  • [Paul] I think we should file a bug for that.
  • [Paul] In Higgins there are two STS’s: C++ and Java – we need to look at them both.
  • [John] It is part of the card issuing [not STS].
  • [Paul] There is card issuing code that is part of Higgins. I think that is the only one.
  • [Andy]  I don’t know with our IdP offering if that has separate card issuing code or if it is using the code bundled with the STS. Daniel would know.
  • [Paul] I recall, Daniel had a separate project that is not one of Mike’s projects that does the card generation. STS information card generator – Daniel is the owner.  I don’t think there are any duplicates of that component.
  • [John] Then that is probably the only place that has this issue. When you select an m-card backed by a p-card does the Higgins selector actually use the …or does the selector actually get the target certificate and use it to calculate the PPID?
  • [John] Garbled.
  • [Paul] This is something… we need at least Mike McIntosh to join a call. Not this call. This is a highly specific issue. 
  • [John] Garbled.
  • [Paul] We are out of time.  There are lots of issues here.
  • [Paul] John, maybe you can propose some topics for the next call, and get the right players on the call and get some agreement.

[1] http://wiki.eclipse.org/Selector_Architecture_Harmonization#Synchronizing_Card_Store_.28Component_Set.29


Back to the top