We all acknowledged that the "without add-on" case was overwhelmingly the status quo
We modified the use case by adding the precondition that Alice has never been to this RP site
We modified the use case by adding the precondition that Alice has not yet defined a "default" account (OP, Infocard, SAML IdP).
At least some folks felt that the concept of the add-on having the notion of a "default" account might be useful
It was noted that this usecase presumes the ability of the RP to declare the set N>1 of IdPs that it trusts.
IMI is limited to 0..1 and thus can't support this
OpenID has no standardized way to do this
Scott noted that if we're designing around work with a long lead time to deployment (i.e., clients), changes to protocols could be in scope as well.
Scott and Nate led a discussion of the fact that the "step 2" (the "account selector window" mockup) introduces an RP-driven bias into the presentation of the set of accounts/IdPs that Alice sees. This bias prejudices Alice's choice of what kind of credentials might be acceptable [ulx:LOA filtering aside]:
The mockups showed the icons of popular web brands (e.g. Yahoo, AOL, etc.) and the feeling was that in order to be on an equal footing SAML federations would have to put marketing effort into branding, etc. and all participating RPs and IdPs would have to use this logo.
It was discussed that there could be an alternative approach wherein the types of IdPs or entire groups (e.g. federations) of IdPs) could be advertised instead of individual IdPs.
It's also the case that for some RPs, not all IdPs would be interchangeable in terms of gaining access. This is potentially related to LOA, but also to attributes/claims.
Scott made the general point that the NIH site we're using is part of the InCommon federation and that its SAML-based usage comes mainly from that relationship today. Other SAML usage could come into play, and probably should be considered by this group.
3. General Observations
We all agreed that our standard procedure should be to work through each use case from two perspectives:
With an browser add-on
Without a browser add-on
There was a general sense that each of us needs to work to help structure this conversation in such a way that all of the relevant communities' inputs are brought to bear.
4. Meeting Frequency
The consensus was that we should meet weekly as at least some in the group felt that this work is urgently needed and that we could move faster with weekly calls than bi-weekly.