[OpenID] 7 suggested OpenID sessions at IIW next week

George Fletcher gffletch at aol.com
Fri May 15 16:13:13 UTC 2009


I've been planning on doing a session around "Issues of becoming an 2.0 
RP". Don't know if others are interested in sharing their experiences. 
It's lead me to believe that we need some changes in spec language and 
capabilities to make it a little easier (even with all the open source 
libraries:) If this was covered at the last IIW (which I missed) let me 
know.

Thanks,
George

Eric Sachs wrote:
> All of the "volunteers" I suggested for the 7 OpenID sessions have 
> agreed to lead them, and looks like Allen can lead and 8th.  Most of 
> the "volunteers" will only be at IIW on Tuesday and Wednesday, so I 
> suggest we try to schedule the majority of the sessions on those two days.
>
> On Tue, May 12, 2009 at 4:27 PM, Allen Tom <atom at yahoo-inc.com 
> <mailto:atom at yahoo-inc.com>> wrote:
>
>     I'd like to give a Usability session where the OpenID UI Work
>     Group can present the OpenID UI Extension, as well as an official
>     kickoff for the OpenID UI Committee. I'll be able to contribute
>     the results of a (very modest) study that Yahoo did recently on
>     the effectiveness of a Popup UI, and we'll have some wireframes
>     documenting RP and OP best practices.
>
>     Allen
>
>     Eric Sachs wrote:
>>     At the last IIW confernece, the OpenID community came up with a
>>     suggested list of sessions ahead of time.  While we changed it a
>>     bit during the IIW event, it still helped us coordinate an OpenID
>>     "track" that led to a lot of important discussions.  In the hope
>>     of doing something similar, I thought I would throw out an
>>     initial list of 7 potential sessions (and potential leaders)
>>     based on some of the discussions on the list.  I would love to
>>     get feedback on whether people think these are the right
>>     sessions, or have other ideas.  And for the "leaders" that I
>>     volunteered, I'd like to see if they would really be willing to
>>     lead some of these topics.
>>
>>     Title: Evolution of Discovery & OpenID
>>     Leaders: "Dirk Balfanz" <balfanz at google.com
>>     <mailto:balfanz at google.com>>, "Eran Hammer-Lahav"
>>     <blade at yahoo-inc.com <mailto:blade at yahoo-inc.com>>
>>     Topic: Have Eran give an update on the evolution of discovery
>>     standards.  Then have Dirk Balfanz give a specific example of how
>>     Google is using those standards to help RPs support scenarios
>>     where an enterprise has outsourced their IDP to a
>>     service-provider such as Google Apps.  Also discuss the reverse
>>     where a website has outsourced their RP to a service-provider
>>     such as Janrain's RPX.
>>
>>     Title: Best practices for very-secure RP/IDP interaction
>>     Leader: "John Bradley" <jbradley at mac.com <mailto:jbradley at mac.com>>,
>>     Topic: Describe some of the current suggested best practices for
>>     increasing the security of RP/IDP interaction, and then try to
>>     create a community document of best practices.  Look at NIST &
>>     PCI compliance as example targets.
>>
>>     Title: How RPs can handle phishing of a user's IDP account
>>     Leader: "Breno de Medeiros" <breno at google.com
>>     <mailto:breno at google.com>>, "Luke Shepard" <lshepard at facebook.com
>>     <mailto:lshepard at facebook.com>>
>>     Topic: Many websites that are not RPs have mechanisms to detect
>>     that a user might have been phished, and if so they try to help
>>     the actual user recover their account just as by requiring that
>>     the password on the account be changed.  Once a website becomes
>>     an RP, its recovery mechanisms have to change.  Breno/Dirk will
>>     discuss how to address this need using some OpenID extensions
>>     that can allow the RP to detect things such as the last time the
>>     user changed their password, or entered it on the computer, as
>>     well as more advanced methods to enable the RP to redirect the
>>     user to the IDP to automatically route the user into the change
>>     password flow (or re-enter password, or require the user to
>>     manually re-approve the identity assertion)
>>
>>     Title: Best practices for using CAPTCHAs, such as to meet
>>     NIST/PCI type compliance
>>     Leader: "Eric Sachs" <sachse at google.com <mailto:sachse at google.com>>
>>     Topic: Some RPs require that IDPs comply with guidelines such as
>>     NIST/PCI, and in particular the sections about reducing hackers
>>     ability to do online attacks to guess a user's password.  Many
>>     major consumer oriented websites protect against those types of
>>     attacks using CAPTCHAs as well as temporary time-out mechanisms. 
>>     Eric will describe some of the current suggested best practices
>>     for preventing these attacks, and then try to create a community
>>     document of best practices.
>>
>>     Title: RPs who DONT want any PII (personally identifiable
>>     information)
>>     Leader: "John Bradley" <jbradley at mac.com
>>     <mailto:jbradley at mac.com>>, "Dirk Balfanz" <balfanz at google.com
>>     <mailto:balfanz at google.com>>
>>     Topic: Some websites are especially privacy sensistive and would
>>     like to avoid collecting any PII from user's, including global
>>     IDs such as Email address, blog URLs, or OpenID URLs that are
>>     sent to multiple RPs.  John will lead a discussion about
>>     potential best practices for how an RP/IDP can interact without
>>     exchanging PII, and then try to create a community document of
>>     best practices.  Dirk will then lead a discussion about how an RP
>>     can indicate what type of URL (or URLs) it wants such as these
>>     non-PII URLs, or a blog/profile URL, or a global URL which won't
>>     necessarily have any interesting information about the user.
>>
>>     Title: Invisible detection by RP of user's login state at IDPs
>>     Leader: "Luke Shepard" <lshepard at facebook.com
>>     <mailto:lshepard at facebook.com>>, "Brian Eaton" <beaton at google.com
>>     <mailto:beaton at google.com>>,
>>     Topic: The OpenID community still does not have a solid best
>>     practice for how RPs can determine a user's IDP without the
>>     usability problems of lots of buttons or a raw URL entry box. 
>>     Another possible option is for the RP to try to invisibly detect
>>     whether the user is logged into an IDP, and then promote that IDP
>>     option to the user.  Luke will discuss his ideas on how an RP
>>     might do this with an IDP today.  Brian will discuss how we might
>>     build upon that model to let the RP check the login state at a
>>     few shared-domains that could return a list of IDPs where the
>>     user is logged in.  For example, Google hosts many
>>     enterprise/school's E-mail, and could potentially provide a way
>>     for an RP to get a list of which such domain(s) a user is
>>     currently logged into.
>>
>>     Title: Bronze/Silver certifications for OpenID IDPs
>>     Leader: "John Bradley" <jbradley at mac.com <mailto:jbradley at mac.com>>
>>     Topic: Some identity communities such as InCommon have defined
>>     some optional mechanisms for IDPs to show they meet specific
>>     requirements, especially around security.  For example, InCommon
>>     has their Bronze/Silver certification as described at
>>     http://www.incommonfederation.org/assurance.  How might we
>>     package some of the OpenID communitie's best practices into some
>>     levels like this, and if we did so, what form might certification
>>     take against those levels?
>>
>>
>>
>>     ------------------------------------------------------------------------
>>     _______________________________________________
>>     general mailing list
>>     general at openid.net <mailto:general at openid.net>
>>     http://openid.net/mailman/listinfo/general
>>       
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>   



More information about the general mailing list