ULX Telecon 2010-03-31
- Time: 16:00-17:00 Eastern
- Skype: +9900827042954214
- US Dial-In: +1-201-793-9022
- Room Code: 295-4214
0) Roll Call
- John Bradley
- Valeska O'leary
- Scott Cantor
- Paul Trevithick
- Bob Blakley
1) IdPS + ULX WG Common Charter
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).
The group discussed the above and is in general agreement.
AI: Paul to read the Liberty IdP Selector MRD that's been circulated to the ULX list today and call out to the list any issues that he sees (to the list).
AI: Paul to ask at the Kantara LC telecon this evening on the procedural steps involved in merging the ULX + IdP Selector WGs
2) Status of Web Mockup
- Kevin (the contractor) is now working (budget approved). He hopes to have a new version by April 8th
3) Inputs & Parameters
- Scott has sketched out Inputs to the Selection UI
- Paul suggested that it might be good if in the unmodified browser case with an "IMI" account-button when the user clicks on the account-button (e.g. IdP "XYZ") it the Pop Up UI would redirect the user's browser to a Web page on the "XYZ" site that would be the place where the user could register, create such and account (and an associated i-card).
- Paul added that if in this same case the IdP, in addition to IMI, also supported OpenID or SAML, that the Pop Up should use one of those protocols instead of IMI