Table of Contents | ||||||||
---|---|---|---|---|---|---|---|---|
|
Logistics
- Time: 08:00 PT | 11:00 ET | 16:00 UTC/GMT | 18:00 CEST (Time Chart)
- Skype: +9900827042954214
- US Dial-In: +1-201-793-9022
- Room Code: 295-4214
Agenda
1) Roll Call
Voting:
- Scott Cantor
- RL "Bob" Morgan
- Keith Uber
- Paul Trevithick
- John Bradley
- Benoit Bailleux
Voting, but not present:
- Axel Nennker
Not present
- Philippe Clement
- Gael Gourmelen
- Valeska O'Leary
- Trent Adams
- Bob Pinhero
Quorate meeting (6 of 6)
2) Minutes
Approved the following minutes (with Keith's correction that he was in fact present last week):
3) Trent's email
http://groups.google.com/group/wg-ulx/browse_frm/thread/6dea05e0dcb854c0#
Wherein he suggested:
- We need to go through the mock-up code
- make sure the components used are compatible with our IPR regime for distribution
- insert into each file (HTML, JS, etc) the applicable copyright notice and reference to the license.
- Move the mock-up code into a subversion (or similar) repository so we can effectively start tracking version
Paul: This in process. Sounds like we'll use Google code as the repository.
4) ULX and the HTTP request header
- Should we include ISA-related preference info in HTTP request header
- Info
- the user's choice of cloud selector URL
- the user's active client selector capabilities (if present)
- the user's set of preferred service providers (e.g. IdPs)
- How?
- Long term: Browsers could build this in
- Short term: a small browser extension could implement
- Why?
- Would provide a standard way for the user to exert their preference
Bob: #3 above could be provided by a minimally active client.
Scott: We're really trying to standardize a cookie. The SAML cookie got messed up in the transition from Liberty to Kantara. You have to have some way to describe the IdP.
Bob: ...yes and the user isn't going to expect to type in the IdP
Scott: Right
Bob: Hm...this is a "fish me here" cookie in essence.
Scott: This is a not a new idea. Issues include only making this go to the desired RPs, etc.
JohnB: This is like xauth.org--that was a network-based cookie priming. I talked to them 3-4 months ago. It doesn't seem to have been made much progress. Lots of privacy/security issues.
Scott: Yes, if you take things a little bit too far (xauth.org) folks realize that this isn't the right thing to do.
Scott: Because OpenID is purely redirect based, the RP may not know that there's an active client but there may be initiating the redirect.
Scott: What we're proposing here may be a more reasonable 1/2 way step. But the problem of making this other than just a cookie is that this raises the bar for RP a bit. OTOH this moves away from cookie nonsense a bit.
5) Role of the icons in the UX
Scott: It turns out the contrast between what Andreas was doing and what the latest Shib stuff is smaller than I realized. They already have found that there are cases where the text name of an IdP is the same, so having an icon there helps. I still don't love it but I see that there's an argument for adding an icon.
Bob: I'm not sure having an icon helps the discrimination, but hover text might help.
Scott: We've reached the stage where we need bring in a UX expert on this topic.
Bob: There's been a cultural gap between the discovery UIs that the few commercial providers (e.g. Janrain, etc) and things that have been done in spaces that have dozens or hundreds of more of IdPs that have stuck (in the past) with text. We're looking to bring these worlds together somehow.
Scott: I added the keywords element to the SAML Metadata Extention for User Interface spec.
Paul: AI: I'll talk to Valeska about this "role of the icons (and hover text) in the UI" in both the proposed "see all" and the "filtered view". We have questions like: What kinds of icons are going to be required based on different roles. The descriptive text is in this same bucket as the icons. For example, how do you discriminate between two IdPs have the same name (e.g. two universities with the same name (which has already shown up as a use case in the Shib world)).
Adjournment
Next Meeting (Nov 29th)
- Time: 08:00 PT | 11:00 ET | 16:00 UTC/GMT | 18:00 CEST (Time Chart)
- Skype: +9900827042954214
- US Dial-In: +1-201-793-9022
- Room Code: 295-4214