From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent: Thursday, July 26, 2007 2:42
PM
To: Higgins
(Trust Framework) Project developer discussions
Cc: 'Higgins
(Trust Framework) Project developer discussions';
higgins-dev-bounces@xxxxxxxxxxx
Subject: RE: [higgins-dev] Notes
from today's Higgins development
call (noon ET)
And how does native code help that ? I agree that
there are security issues, but I don't agree that native code is the way to fix
all these. So in your scenario how do you know the browser itself is not
infected ?
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Paul
Trevithick" ---07/26/2007 01:29:19 PM---Here’s an
example of an issue… In the H1 configuration HBX communicates with the
back end “agent service” (RPPS, etc.). For
|
From:
|
"Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx>
|
|
To:
|
"'Higgins \(Trust Framework\) Project developer
discussions'" <higgins-dev@xxxxxxxxxxx>
|
|
Date:
|
07/26/2007 01:29 PM
|
|
Subject:
|
RE: [higgins-dev]
Notes from today's Higgins
development call (noon ET)
|
Here’s an example of an issue… In the H1
configuration HBX communicates with the back end “agent service”
(RPPS, etc.). For the agent service to know that it is talking to a legitimate,
unmodified copy of HBX and not a rogue, HBX may need to hold a secret (e.g. a
key). Because HBX is in _javascript_ I can’t see how it can keep this key
from being discovered by another browser add-on.
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx]
On Behalf Of Anthony Nadalin
Sent: Thursday, July 26, 2007 2:12 PM
To: Higgins (Trust
Framework) Project developer discussions
Cc: 'Higgins (Trust
Framework) Project developer discussions'; higgins-dev-bounces@xxxxxxxxxxx
Subject: Re: [higgins-dev] Notes from today's Higgins
development call (noon ET)
I don't
understand the issue around "native" code being more
"secure", as its not, in the Cardspace case its not that its native
code its that it runs with some process isolation
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Paul Trevithick" ---07/26/2007 01:02:32
PM---Attendees
|
From:
|
"Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx>
|
|
To:
|
"'Higgins \(Trust Framework\)
Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
|
|
Date:
|
07/26/2007 01:02 PM
|
|
Subject:
|
[higgins-dev] Notes from today's Higgins
development call (noon ET)
|
Attendees
=========
Alex Amies - IBM
* Paula Austel - IBM
Jeff Broberg CA
Andy Hodgkinson - Novell
Duane Buss - Novell
* Greg Byrd - NCSU/IBM
* Brian Carrol - Serena
* Tom Doman - Novell
Valery Kokhan - Parity Ukraine
David Kuehr-Mclaren - IBM
* Mike McIntosh - IBM
Nataraj Nagaratnam - IBM
Dale Olds - Novell
Uppili Srinivasan - Oracle
Drummond Reed - Cordance
* Bruce Rich - IBM
* Mary Ruddy - Parity/SocialPhysics
* Markus Sabedello - Parity
* Jim Sermersheim - Novell
* George Stanchev - Serena
* Daniel Sanders
Abhi Schelat - IBM
* Paul Trevithick -
Parity/SocialPhysics
Igor Tsinman - Parity
--
* Present
Agenda
======
1) New deployment (see [1])
2) Progress on build automation (configuration, idas, icard)
3) Milestone 0.9 progress (see [2])
4) HBX: security considerations, native code
5) HBX: need for IE version
6) CardStoreStrategy: status update
[1]
http://wiki.eclipse.org/Deployments#RP_Enablement:_CardSpace-interoperable_R
elying_Party_Demo_App
[2] http://wiki.eclipse.org/index.php/Milestone_0.9
1) New Deployment (see [1])
---------------------------
* Paul created this new table
* Bruce agreed to be the owner and to fill in the needed wiki pages
* Brian pointed out that we (he!) should add another deployment: ALF/STS
integration
2) Progress on build automation
-------------------------------
* Since Valery couldn't be on the call Paul mentioned that we should by
tomorrow have a new approach working for these components: (configuration,
idas and icard). The new approach involves making modifications to the
existing eclipse2ant plugin to make it produce buildaux.xml along wit
hbuild.xml and dependency.xml.
* Mike asked if the new approach was well documented (so he could try it
with STS).
* Paul agreed that after tomorrow, we'd pause to document the new approach
on the wiki, and then resume enhancing it some more.
3) Milestone 0.9 progress (see [2])
-----------------------------------
* There was a brief discussion as to whether we should delay M0.9 and
declare it done only when all Components can be automatically/nightly built
4) HBX: security considerations, native code
--------------------------------------------
* Paul began the discussion by explaining that the HBX needs some native
code in order to make it more secure (e.g. harder for hackers to make rogue
HBXes, hardened from attack by other browser plug-ins, etc.)
* Mike suggested that we should go further. HBX should just launch a native
"I-Card Selector" app (as both Microsoft CardSpace and Higgins H2 do it) and
get rid of HBX's UI code.
* Paul: This would work if the I-Card Selector app could be used to either
consume a local agent service (RPPS and on down). [This is exactly what the
Novell folks have been planning for H2 --a local or remote agent service]
* Jim pointed out that the Novell H2 I-Card Selector can run on any platform
(including Windows).
* In summary the requirements are:
o uses native code
o is relatively small in size
o can be configured to use a local or remote agent service
* It does appear that these requirements could be met by using a native
I-Card Selector component/app as an alternative to adding some native
security code to HBX
* This approach has the benefit that creating other versions of HBX (e.g.
for IE and Safari) is much easier because there is less code in HBX
* Mike reminded us all that security and install-ability are key for 1.0
5) IE HBX --was not discussed
6) CardStoreStrategy --nobody from IBM Zurich was on the line so we didn't
get an update.
Action Items
============
Bruce: to flesh out wiki page for RP demo app configuration
Brian: to add a new table to Deployments page for ALF's STS integration
Valery: after tomorrow, document the new build approach well on the wiki.
Well enough that MikeM could try to apply it to the STS components.
Paul/Mary: consider delaying M0.9 until nightly build situation is done
Paul: consider moving HBX UI into I-Card Selector app; evaluate existing H2
I-Card Selector code. Can it be modified to be used in the H1 deployment
configuration?
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
