[Concordia] Notes for 22 Apr 2008 Concordia call

[Mike Jones]

Sorry I missed this.  There wasn't anything in my calendar for this call and so I just plain forgot about it.  (No, it's not a good excuse, but it's what actually occurred.)

Particularly since the times have changed, can the organizer of the series of calls please send a recurring calendar message out with the call-in numbers so it lands in my (and other's) calendars?

The main point about Concordia/OSIS coordination is that it doesn't make sense to ever give the appearance of there being "competing" interops again.  No, they weren't competing really, but that wasn't at all obvious to outside observers.  The appearance caused actual problems for at least one strong Liberty supporter, for instance.  Roger and I don't think actual merging makes sense for a lot of reasons but having Concordia primarily collect and act upon use cases and OSIS primarily run interop events (some of which may be co-branded with Concordia and include Concordia use cases), and having both the appearance and actual tight coordination between the two efforts does.  I'll be glad to talk about this on the next call.

                                -- Mike

-----Original Message-----
From: community-bounces at projectconcordia.org [mailto:community-bounces at projectconcordia.org] On Behalf Of Eve Maler
Sent: Tuesday, April 22, 2008 11:25 AM
To: Concordia Community list
Subject: [Concordia] Notes for 22 Apr 2008 Concordia call

== Attendance ==

Eve Maler, Dervla O'Reilly, Britta Glade, George Fletcher, Mike Beach,
Brett McDowell, Scott Cantor, Damien Carru, Ashish Jain, Ari Kermaier,
Colin Wallis, Bill Young, Jeff Hodges, Vijay Simha

== Next meeting ==

We're going to switch our "standard hour" for telecons to 11am-noon
Pacific on Tuesdays, and our next telecon will be 6 May 2008 at that
hour.  This will help a number of people attend on a more regular basis.

== Concordia futures and relationship to OSIS / upcoming F2F
opportunities ==

At the OSIS steering committee meeting, the topic of OSIS/Concordia
similarities was discussed.  Someone commented that if OSIS were to do
a press release, it would look very similar to the Concordia press
release.  Confusion and fragmenting may result if we continue without
tighter coordination.  A distinction between them to date has been
Concordia's involvement with deployers and their use cases, but there
are still a lot of similarities.  Some people thought we should
somehow merge; Mike Jones took an AI there to look into this, but he's
not on the call today.

What would a merging look like?  The OSIS steering committee wondered
if OSIS should do workshops (interop workshops?) and Concordia should
do deployer input (which Eve notes is often conducted at F2F workshops).

Mike Beach notes that Concordia's charter is friendlier to enterprise,
with mention of WS-* and SAML and such, and OSIS is more about open
source and consumer-related technologies.  Might Boeing lose interest
and go away if we were to merge?  Brett notes that the media has paid
attention to the Concordia "brand" because of the deployer role.

Britta mentions that Burton is interested in Concordia doing another
workshop at Catalyst in June (based on Britta's outreach, mentioned
back last December), and that Roger Sullivan has gathered deployer
interest in offering use cases and feedback on the XACML/policy, which
perhaps we could do at such a workshop.  Ashish reports that OSIS
folks haven't focused on Catalyst yet because of the European ID
conference going on this week.

Eve proposes that we all, at the least, coordinate joint messaging for
the Catalyst timeframe.  Brett has a concrete proposal: As one way of
connecting, Concordia can work with deployers to gather feedback on
OSIS scenarios.  Ashish comments that this could be useful because
OSIS is set up more as a vehicle for technology providers.  We can
also get OSIS feedback in the process of prioritizing our next bunch
of Concordia scenarios (see below).

AI: Brett agrees to cycle with Mike J. on further discussion and
coordination, including the possibility of some sort of joint meeting
at IIW in mid-May to continue the discussions.

== Further deliverables on Scenarios 1 and 2 ==

There was consensus at RSA that formal profiling (a la work done at
SSTC these days) and formal interop testing (a la work done at Liberty
these days) would be useful.

Scott and Jeff indicate interest in helping out with formal profiles.
We think these might include an InfoCard profile for SAML: e.g., authn
context representations, requesting SSO assertions and responding with
them, profiling bearer tokens, and dealing with the claim type vs.
value limitation.  One live-wire issue is whether we should follow the
protocol or the implementations!  The InfoCard protocol has support in
it for things like transmitting policy, but the CardSpace
implementation doesn't support this feature yet.  Perhaps we should
profile InfoCard itself for this purpose.  (Mike B. brought up the
immaturity of CardSpace at RSA.)

Eve notes that Boeing and NZ SSC both have representation on the
SSTC.  Bill thinks that an InfoCard profile of SAML could wait a
while, until implementations in the market catch up, because
deployments are realistically years ago.  Scott dissents, on the
theory that implementations can be influenced and incentivized by a
profiling effort.  Mike B. agrees with Scott.

Eve observes that the earliest SAML1.1 interop at an RSA conference
helped to inform the ongoing ID-FF, SAML2, and Shib work on SP-
initiated SSO, a scenario that was demo'd at that interop (governed by
an extensive scenario document) but was not part of standard SAML
flows yet.

SSTC members on this call agree that we should be able to get a stable
SSTC Committee Draft quickly -- Scott thinks by mid-summer!  We could
target winter 2008-2009 for formal interop testing.

Eve relays news from Pat Patterson, who's traveling today: He will
publish a small extension to OpenSSO that reflects the sum total of
code written for the RSA workshop interop event.  This would be
available to anyone to look at and use.  Colin asked if this applies
to SSOCircle -- yes, it does, if they choose to use/build on the
extension.

The WS-Fed wauth parameter stuff might need a protocol translation
profile; perhaps this should wait until WS-Fed itself is a final OASIS
Standard.

There's room for a WS-Fed<->SAML (Scenario 2) mapping profile as well;
Scott is willing to help anyone else who wants to write such a
profile.  Mike B. notes that the TCSP effort is still ongoing, so we
might want to wait for their further input.  No one else expressed
urgent interest in working on such a profile right away.

== Variants on Scenarios 1 and 2 ==

Bill notes that the NZ SSC IVS scenario includes a user using a
selector to get their IVS card, which would in turn want to use a
managed card to authenticate the individual.  This is what Eve had
been calling "managed card proxying" at the RSA workshop when Danny
presented.  Scott thinks this may be allowable per the InfoCard
protocol (which he believes allows full recursion), but isn't
supported in the CardSpace implementation.  Bill will check out that
possibility.

== Other scenarios to consider ==

NZ SSC also has an interest in InfoCard bootstrapping to ID-WSF.
(This is in addition to earlier interest that had been expressed in
OpenID bootstrapping to ID-WSF.)  These form a natural bucket.

AI: Eve to reach out to Peter Williams to ask for use case input on
OpenID + SAML.

Mike B., among others, indicated interest to Roger Sullivan on fine-
grained authorization use cases (likely involving XACML).

Another that may (or may not) be a live wire: InfoCard+SAML Enhanced
Client.  A number of research papers have been appearing on this
subject.



Eve Maler                                         +1 425 947 4522
Principal Engineer                            eve.maler @ sun.com
Business Alliances group                    Sun Microsystems, Inc.

_______________________________________________
Community mailing list
Community at projectconcordia.org
http://lists.projectconcordia.org/mailman/listinfo/community

Participating in this discussion list does not grant any intellectual property rights or any commitment by the participants of the content discussed to any organization.