<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
Allen<br>
<br>
Eric Sachs wrote:
<blockquote
 cite="mid:c4161f510905121050l219bf113ibecbfd02e1bfc4a5@mail.gmail.com"
 type="cite">At the last IIW confernece, the OpenID community came up
with a suggested list of sessions ahead of time.&nbsp; 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.&nbsp; 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.&nbsp; I would love to get feedback on whether
people think these are the right sessions, or have other ideas.&nbsp; And
for the "leaders" that I volunteered, I'd like to see if they would
really be willing to lead some of these topics.<br>
  <br>
Title: Evolution of Discovery &amp; OpenID<br>
Leaders: "Dirk Balfanz" &lt;<a moz-do-not-send="true"
 href="mailto:balfanz@google.com" target="_blank">balfanz@google.com</a>&gt;,
"Eran Hammer-Lahav" &lt;<a moz-do-not-send="true"
 href="mailto:blade@yahoo-inc.com" target="_blank">blade@yahoo-inc.com</a>&gt;<br>
Topic: Have Eran give an update on the evolution of discovery
standards.&nbsp; 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.&nbsp; Also discuss the reverse where a website has outsourced
their RP to a service-provider such as Janrain's RPX.<br>
  <br>
Title: Best practices for very-secure RP/IDP interaction<br>
Leader: "John Bradley" &lt;<a moz-do-not-send="true"
 href="mailto:jbradley@mac.com" target="_blank">jbradley@mac.com</a>&gt;,
  <br>
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.&nbsp; Look at NIST &amp; PCI
compliance as example targets.<br>
  <br>
Title: How RPs can handle phishing of a user's IDP account<br>
Leader: "Breno de Medeiros" &lt;<a moz-do-not-send="true"
 href="mailto:breno@google.com" target="_blank">breno@google.com</a>&gt;,
"Luke Shepard" &lt;<a moz-do-not-send="true"
 href="mailto:lshepard@facebook.com" target="_blank">lshepard@facebook.com</a>&gt;<br>
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.&nbsp; Once a website becomes an RP, its recovery
mechanisms have to change.&nbsp; 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)<br>
  <br>
Title: Best practices for using CAPTCHAs, such as to meet NIST/PCI type
compliance<br>
Leader: "Eric Sachs" &lt;<a moz-do-not-send="true"
 href="mailto:sachse@google.com" target="_blank">sachse@google.com</a>&gt;<br>
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.&nbsp; Many major consumer
oriented websites protect against those types of attacks using CAPTCHAs
as well as temporary time-out mechanisms.&nbsp; 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.<br>
  <br>
Title: RPs who DONT want any PII (personally identifiable information)<br>
Leader: "John Bradley" &lt;<a moz-do-not-send="true"
 href="mailto:jbradley@mac.com" target="_blank">jbradley@mac.com</a>&gt;,
"Dirk Balfanz" &lt;<a moz-do-not-send="true"
 href="mailto:balfanz@google.com" target="_blank">balfanz@google.com</a>&gt;<br>
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.&nbsp; 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.&nbsp; 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.<br>
  <br>
Title: Invisible detection by RP of user's login state at IDPs<br>
Leader: "Luke Shepard" &lt;<a moz-do-not-send="true"
 href="mailto:lshepard@facebook.com" target="_blank">lshepard@facebook.com</a>&gt;,
"Brian Eaton" &lt;<a moz-do-not-send="true"
 href="mailto:beaton@google.com" target="_blank">beaton@google.com</a>&gt;,
  <br>
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.&nbsp; 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.&nbsp; Luke will
discuss his ideas on how an RP might do this with an IDP today.&nbsp; 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.&nbsp; 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.<br>
  <br>
Title: Bronze/Silver certifications for OpenID IDPs<br>
Leader: "John Bradley" &lt;<a moz-do-not-send="true"
 href="mailto:jbradley@mac.com" target="_blank">jbradley@mac.com</a>&gt;<br>
Topic: Some identity communities such as InCommon have defined some
optional mechanisms for IDPs to show they meet specific requirements,
especially around security.&nbsp; For example, InCommon has their
Bronze/Silver certification as described at <a moz-do-not-send="true"
 href="http://www.incommonfederation.org/assurance" target="_blank">http://www.incommonfederation.org/assurance</a>.&nbsp;
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?<br>
  <br>
  <br>
  <br>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
  </pre>
</blockquote>
<br>
</body>
</html>