ULX Telecon 2010-03-31

Two weeks ago we had a discussion on this topic and a couple of days ago Gael sent this email to the list:

Some clarifications below on envisioned TECHNICAL SPECIFICATIONS:

Section (4) DRAFT TECHNICAL SPECIFICATIONS: second bullet addition: this may be fine, we'd like to learn more about the nature of the ISA (e.g. does it assume an unmodified browser?)
- GAEL: Yes we assume an ISA in the network accessed through a possibly unmodified browser (as opposed to the ISA in the device = browser add-on).

Section (4) DRAFT TECHNICAL SPECIFICATIONS: third bullet addition: we don't entirely understand this. Seems to imply that we shouldn't make up entirely new things; try to reuse existing SAML metadata. Perhaps "newly designed features should be as compatible and consistent as possible with existing specifications" is part of the intent here.
- GAEL: In fact, we envisoned here that some specifications already exist and could be extended to enable IDPs to express their capabilities and presentation characteristics (same as what is refered as "Identity Provider Inputs" here : http://kantarainitiative.org/confluence/display/ulx/Inputs+to+the+RP+Pop+Up+UI). For a SAML IDP, we can leverage the SAML Metadata specifications, for OpenID OPs, we can maybe leverage the YADIS/XRDS specifications, ... We have presented the following slides in the IDPS session last week on this topic : http://kantarainitiative.org/confluence/download/attachments/41027190/IDP+Metadata+Status+and+Evo+v02.ppt that describe lacks in existing specs and evolution proposals (we already had some comments during the session and on the mailing list). So our intent is as you wrote : "newly designed features should be as compatible and consistent as possible with existing specifications" but it does not mean that there is nothing to do and we are opened to discuss all technical solutions (including entirely new things if it makes sense).

ULX Teleconference 2010-03-31