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