>> One thing that is not clear is the scope, is this WG also going to deal with the server side, that is dealing with the delivery of various JS bundles to the client?<div><br></div><div>Short answer is no.</div><div>
<br></div><div>There is interest from a subset of proposers in the future to build an open-source JS widget that implements a subsection of the account-chooser functionality that could be contained in JS. The IPR for that would be handled under an open source policy instead of a specs working group IPR policy. If there is progress in that area, then some of those people might create a working group to define a spec for the connections between a JS AccountChooser widget and a server. Google is going to try to help bootstrap such an effort by splitting the JS widget in the GoogleIdentityToolkit into two pieces. The higher level UI piece could be a starting point for such a project (<a href="https://sites.google.com/site/gitooldocs/customidps">see initial article</a>), whereas the lower layer piece would be specific to GITKit.</div>
<div><br></div><div>However multiple websites and vendors want to build an AccountChooser without having to agree on the connection between their JS widget and server. Based on feedback from potential websites customers of vendor products, the website customers generally don't feel the need to standardize that connection, but do want to be confident they could switch from vendor A to vendor B (or build their own) and still get the same customer facing functionality.</div>
<div><br></div><div>In the near term though I wasn't able to get enough interest from people outside Google to work on either a spec for this connection, or the open source implementation, so I didn't put that in the charter. However if anyone is interested in working in this area in the near term....hint hint :-)</div>
<div><br></div><div><br></div><div><br><div class="gmail_quote">On Thu, Sep 8, 2011 at 1:25 PM, Anthony Nadalin <span dir="ltr"><<a href="mailto:tonynad@microsoft.com">tonynad@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">One thing that is not clear is the scope, is this WG also going to deal with the server side, that is dealing with the delivery of various JS bundles to the
client? <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> Eric Sachs [mailto:<a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a>]
<br>
<b>Sent:</b> Wednesday, September 07, 2011 11:35 AM<br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> Anthony Nadalin; Christopher Messina; John Bradley; OpenID Specs Mailing List; Chuck Sievert; Basheer Tome; Kevin Long; Andrew Dahley; Don Thibeau; Wei Tu</span></p><div><div></div><div class="h5"><br>
<b>Subject:</b> Re: Charter submission for Account Chooser Working Group<u></u><u></u></div></div><p></p><div><div></div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">>> Can we combine or close the old WG and make sure we have 1 effort?<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">That idea was discussed by a few of the proposers, but we could not come up with a good logistical way to do that. One idea was to have a really broadly defined WG on user-experience, but then there were concerns from multiple proposers
that from a corporate/legal/IPR perspective they wanted a more constrained charter for the WG. So the current charter was an effort to find a middle ground.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Maybe in hindsight we should have used a more specific name like Popup UX working group as opposed to its current very generic "User Interface WG" name.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">One suggestion that might be worth considering in the future is to categorize workgroups on <a href="http://wiki.openid.net/w/page/12995249/Working%20Groups" target="_blank">the formal page that lists them</a>, and to list both the Popup and AccountChooser
WG as items in the UX category. But that might still require "formally" changing the name of the older WG from "UserInterface" to "Popup" and I don't know how to do that. Or as Mike suggests, maybe we can just close the older "UserInterface" WG in the future
to avoid the confusion.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Wed, Sep 7, 2011 at 11:33 AM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#002060">We should close all the inactive working groups when we have the next membership vote. (It takes a membership vote to close a working
group.)</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#002060"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#002060">We should do this when we send the Connect specs out for the Implementer’s Draft vote.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#002060"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#002060"> -- Mike</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#002060"> </span><u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt">
<a href="mailto:openid-specs-bounces@lists.openid.net" target="_blank">openid-specs-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-bounces@lists.openid.net" target="_blank">openid-specs-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Anthony Nadalin<br>
<b>Sent:</b> Wednesday, September 07, 2011 10:59 AM<br>
<b>To:</b> Eric Sachs</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><br>
<b>Cc:</b> Christopher Messina; John Bradley; OpenID Specs Mailing List; Chuck Sievert; Basheer Tome; Kevin Long; Andrew Dahley; Don Thibeau; Wei Tu<u></u><u></u></p>
</div>
<p class="MsoNormal"><b>Subject:</b> RE: Charter submission for Account Chooser Working Group<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">OK, that captures what I was after.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">We have an active “User Interface Workgroup” already so this charter seems to be addressing that WG but this is a request to start a
new WG. Can we combine or close the old WG and make sure we have 1 effort?</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> Eric Sachs [mailto:<a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a>]
<br>
<b>Sent:</b> Tuesday, September 06, 2011 4:29 PM<br>
<b>To:</b> Anthony Nadalin<br>
<b>Cc:</b> Dick Hardt; Christopher Messina; John Bradley; OpenID Specs Mailing List; Chuck Sievert; Basheer Tome; Kevin Long; Andrew Dahley; Don Thibeau; Wei Tu;
<a href="mailto:Axel.Nennker@telekom.de" target="_blank">Axel.Nennker@telekom.de</a><br>
<b>Subject:</b> Re: Charter submission for Account Chooser Working Group</span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">>> So this brings up the issue of backwards compatibility<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Yes. Fortunately in our past group/industry discussions we have found that a side effect of being protocol agnostic is that it also seems to provide some forwards/backwards compatibility.
However achieving that goal took a lot of evolution of the design to find the right abstraction points. We seem to have found an abstraction that works for generally any federation protocol that relies on URL redirects. But only time will tell.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">For example, when MSFT moved from WRAP to OAuth2 Google's AccountChooser implementations did not need to change. Similarly we are experimenting with Google's IDP moving from OpenID
v2 to OpenIDConnect and similarly found no change was needed. Our AccountChooser implementations are built on top of a lower layer outside the AccountChooser that handles protocol details. That part changed, but not the logic on top.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">>> it looks like you want to keep compatibility with V2 and the extensions that were done for V2 an d not limit the scope to OpenID Connect, is this right?<u></u><u></u></p>
<div>
<p class="MsoNormal">Correct<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">>> You want the compatibility to be covered in the charter and specifications?<u></u><u></u></p>
<div>
<p class="MsoNormal">After reading your email I went back and looked at the charter description and it does not say anything specific about this goal of being somewhat protocol agnostic and forward/backward
compatible. Below is a suggestion of a modification to the charter that adds one clarifying sentence in red. I will go ahead and make that change unless anyone has different suggested wording.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<blockquote style="margin-left:30.0pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">The account chooser model can in some cases improve usability on a website even if it does not support identity providers, or a website
that only supports identity providers, or a website that only supports a single identity provider. <span style="color:#FF6666">The model should be protocol agnostic where possible to support both multiple protocols or multiple versions of the same major protocol.</span> The
account chooser model can also allow a relying party to customize the set of buttons it shows during the "add account" flow based on IP geolocation of the user to help promote a larger number of identity providers around the world instead of just a small number
of providers as is generally shown on a NASCAR UI. The working group will discuss all of these use cases.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On Tue, Sep 6, 2011 at 3:55 PM, Anthony Nadalin <<a href="mailto:tonynad@microsoft.com" target="_blank">tonynad@microsoft.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">So this brings up the issue of backwards compatibility, as it looks like you want to keep compatibility with V2 and the extensions that
were done for V2 an d not limit the scope to OpenID Connect, is this right? You want the compatibility to be covered in the charter and specifications?</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> Eric Sachs [mailto:<a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a>]
<br>
<b>Sent:</b> Tuesday, September 06, 2011 9:33 AM<br>
<b>To:</b> Anthony Nadalin<br>
<b>Cc:</b> Dick Hardt; Christopher Messina; John Bradley; OpenID Specs Mailing List; Chuck Sievert; Basheer Tome; Kevin Long; Andrew Dahley; Don Thibeau; Wei Tu;
<a href="mailto:Axel.Nennker@telekom.de" target="_blank">Axel.Nennker@telekom.de</a></span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>Subject:</b> Re: Charter submission for Account Chooser Working Group<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Adding Axel Nannker who also asked to be listed as a proposer for this new working group.<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Does anyone on the specs council have additional questions or suggestions on how we could improve the charter? I believe the present membership of the specifications council is:<u></u><u></u></p>
<ul type="disc">
<li class="MsoNormal">
Johnny Bufu<u></u><u></u></li><li class="MsoNormal">
Mike Jones<u></u><u></u></li><li class="MsoNormal">
Breno de Medeiros<u></u><u></u></li><li class="MsoNormal">
Dick Hardt<u></u><u></u></li><li class="MsoNormal">
David Recordon<u></u><u></u></li><li class="MsoNormal">
Nat Sakimura<u></u><u></u></li><li class="MsoNormal">
Allen Tom<u></u><u></u></li></ul>
</div>
<div>
<div>
<p class="MsoNormal">I have talked or exchanged email on this thread with everyone except
<span style="color:red">Johnny Bufu</span> and Mike Jones. Johnny, if you are still monitoring this list could you let us know if you have questions/suggestions? That just leaves Mike, but he just got back from vacation about a week ago and pinged me that
he is reviewing it. I am hoping we can get his ideas for improving the charter this week, and then have a formal specs council vote.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On Tue, Aug 30, 2011 at 10:02 AM, Eric Sachs <<a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">>> Is the “account chooser” just use to select account and not user consent?<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal">That is generally correct. One of the specific goals was a UX that would work with multiple redirect based protocols (which is already true of a NASCAR style UI) so the past work
in this area has explicitly stayed away from specifying changes that IDPs need to make, or changes in protocols.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">At the same time, the spec does say that RPs should send the user to an IDP to "get user consent" to access their photo/name/identifier, and the spec then describes specific ways
to use that information. The methods for doing that vary across OpenIDv2+AX, OpenIDv2+SREG, and OpenIDConnect, as well as existing OAuth2 IDPs like Facebook/WindowsLive/Salesforce. I do think it would help to describe in more detail how to use specific protocols
to get that information. However I hoped the working group could decide whether it is better to do that in the spec itself, or in related documentation that is outside the actual spec.<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">>> How does this fit into OpenID Connect?<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal">The current specs of OpenIDConnect suggest a set of attributes in the default response from an IDP that happen to contain the minimal information that an RP would need to deploy
an account chooser based on the initial draft spec. So the attribute exchange part will require less work then integrating with an OpenID v2 IDP.<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">>> Is there a wire format to be done at all? <u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal">The minimum "wire formats" already exist in the protocols, but as noted it is not clear how much this AccountChooser spec should reference them in detail. There is also the suggestion
that the spec should define a standard way (for at least one protocol) that the RP could use to tell an IDP that it is using an account chooser in case the IDP wants to behave differently. That could certainly be done within this spec if the specs council
suggests it is worth including.<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">>> So still confused, I assume that “user interface” refers to UI and semantics? <u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal">It definitely includes those 2 components, but it only works if the RP website has a protocol, (or protocols) it can then use to talk to identity providers. This spec needs to
at minimum talk about that protocol integration at a generic level, but it could give examples/details for integration with particular protocols. There is also the edge case of websites that are interested in deploying an Account Chooser without supporting
identity providers. A few sites have asked about that, though in all those cases they wanted to do it as a stepping stone to becoming an RP. The current proposed charter says the spec would describe how a site could implement that mode, and that would not
require any protocol integration.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Another more generic thing to keep in mind is that Google has been asked to "do the right thing" to make sure there are no IPR concerns (at least with Google's IP) about vendors
or individual websites implementing their own account chooser. We have received a number of requests along those lines, and we hope that a side effect of this working group is that its scope would help address any such existing IPR concerns. It won't be
sufficient by itself because there are other things like code people want us to open source, and icons people want us to transfer to the OIDF. However that "do the right thing" goal was definitely part of the input to the earliest drafts of the working group
charter.<u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On Tue, Aug 30, 2011 at 12:34 AM, Anthony Nadalin <<a href="mailto:tonynad@microsoft.com" target="_blank">tonynad@microsoft.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">So still confused, I assume that “user interface” refers to UI and semantics? Is there a wire format to be done at all? How does this
fit into OpenID Connect? Is the “account chooser” just use to select account and not user consent?</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt">
<a href="mailto:openid-specs-bounces@lists.openid.net" target="_blank">openid-specs-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-bounces@lists.openid.net" target="_blank">openid-specs-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Eric Sachs<br>
<b>Sent:</b> Monday, August 29, 2011 7:53 PM<br>
<b>To:</b> Dick Hardt<br>
<b>Cc:</b> Christopher Messina; John Bradley; OpenID Specs Mailing List; Chuck Sievert; Basheer Tome; Kevin Long; Andrew Dahley; Don Thibeau; Wei Tu<br>
<b>Subject:</b> Re: Charter submission for Account Chooser Working Group</span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Agreed. I updated the charter posted at <a href="https://sites.google.com/site/oauthgoog/workinggroupcharter?pli=1" target="_blank">https://sites.google.com/site/oauthgoog/workinggroupcharter?pli=1</a><u></u><u></u></p>
<div>
<p class="MsoNormal">On Mon, Aug 29, 2011 at 6:34 PM, Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal">I'd suggest replacing/removing the word "guidelines" in the Statement of Purpose and Scope -- here is a suggested change<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Statement of Purpose</span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">This workgroup intends to produce user interface specifications for how a relying party can implement an account chooser for both
adding accounts, and selecting an account that was previously added.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Scope</span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">Produce a specification for the account chooser user interface.</span><u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On 2011-08-29, at 6:29 PM, Eric Sachs wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <u></u><u></u></p>
<p class="MsoNormal">>> <span style="font-size:10.0pt;color:#333333;background:white">Is your proposal to create "guidelines" or "requirements"?</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><span style="color:#333333">The current goal is "requirements" for a website <or vendor product> that wants to say it has implemented an "OpenID account chooser v1." As an example,
the very rough draft spec has some elements that are described as a MUST. For example, this section:</span><u></u><u></u></p>
</div>
<blockquote style="margin-left:30.0pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="color:#333333"><a href="https://docs.google.com/document/d/1ES9vo1euh3ArzKRaAmCfZWWwTm5bluNuH49hFec5a_I/edit?hl=en_US#heading=h.5y8muzxvbm92" target="_blank">https://docs.google.com/document/d/1ES9vo1euh3ArzKRaAmCfZWWwTm5bluNuH49hFec5a_I/edit?hl=en_US#heading=h.5y8muzxvbm92</a></span><u></u><u></u></p>
</div>
</blockquote>
<div>
<p class="MsoNormal">Even the sections with SHOULDs allow a website/product to say things like they "implemented an OpenID account chooser v1 with the optional navigation bar support."<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Obviously websites may still choose not to implement all the MUSTs, in which case they are using the spec more as a guideline. However some of the frequent feedback from website
owners about the account chooser is the desire to know that they could switch between vendor products, or their own implementation, or even mix/match components, and still provide their users with a consistent experience. For example, a website might get
a JavaScript library from one vendor that implements a lot of the UI elements, but hook it up to a product from another vendor that supports the key functional logic. Or a website might get an end-to-end solution from one vendor, and later they want to replace
it with a different vendor without loosing major functionality in the the user experience.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">There is also another perspective on "interoperable." The community has talked a lot about the idea of people being able to expect a consistent/interoperable user experience across
websites that are RPs, similar to how the Bluetooth mark might cause them to expect a similar pairing experience across a mix of phones & headsets. That type of interoperable has value as well, but likely involves more components then just a spec. Separately
we did ask Scott David to investigate the idea of marks and talk about them to the OIDF board in the future.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">On Mon, Aug 29, 2011 at 5:49 PM, Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal">Hi Eric<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I'm getting hung up on some semantics in your proposal. An important objective of a specification is to standardize a practise to enable interoperability. In your proposal, you
describe the specification to consist of guidelines. Guidelines sound like "nice to have" attributes rather than requirements. If this is a best practises document, I don't think it needs to go through the specs committee. If it will be branded OpenID and
there are compliance requirements, then it does.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Is your proposal to create "guidelines" or "requirements"?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">-- Dick<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">On 2011-08-29, at 4:59 PM, Eric Sachs wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">>> <span style="font-size:10.0pt;color:#333333;background:white">Can you give us a idea as to what the content and format of the design spec might look like?</span><u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#333333">There is a bit of intro to answers those questions at the top of </span><a href="https://sites.google.com/site/oauthgoog/workinggroupcharter" target="_blank">https://sites.google.com/site/oauthgoog/workinggroupcharter</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">The goal is to look something like the section of the existing OpenID user interface extension that has guidelines outside protocol specs. However the UI guidelines would be much
more detailed then the few sentences in that spec. We posted <span style="font-size:10.0pt;background:white">an <a href="https://docs.google.com/document/d/1ES9vo1euh3ArzKRaAmCfZWWwTm5bluNuH49hFec5a_I/edit?hl=en_US" target="_blank"><span style="color:#4E7DBF">initial
rough spec</span></a> using that approach. Some people have suggested adding one bit of protocol to the spec which is a way for the RP to tell the IDP that it is implementing an account chooser so that the IDP could do something different, just as it does
for the popup spec. However we have not been able to determine what the "different" behavior would be.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">There may be related output from the work in this area like open source JS code. There will hopefully also be easier to read implementation guides that are not in the spec format,
but include things like mocks and flowcharts. There are some examples of something like that at <a href="http://accountchooser.com/ux.html" target="_blank">http://accountchooser.com/ux.html</a>. However that type of output seemed to be outside the bounds
of what a WG charter should cover.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On Mon, Aug 29, 2011 at 4:46 PM, Allen Tom <<a href="mailto:allentomdude@gmail.com" target="_blank">allentomdude@gmail.com</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">Hi Eric,<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks for submitting the Account Chooser WG proposal. As far as I know, this is the first time a non protocol spec WG has been proposed. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Can you give us a idea as to what the content and format of the design spec might look like? Will it be a set of wireframes? Mockups? Flowcharts? Will it cover only the login form?
Will it also cover account linking and account recovery?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Allen<u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On Mon, Aug 29, 2011 at 10:46 AM, Eric Sachs <<a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a>> wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal">This is a formal submission to the OpenID Specs Council to approve the Account Chooser Working Group. The draft charter is posted at <a href="https://sites.google.com/site/oauthgoog/workinggroupcharter" target="_blank">https://sites.google.com/site/oauthgoog/workinggroupcharter</a> and
the current version has been copied below. If possible, we would like to get a response from the Specifications Council before the September OpenID Summit so we can use that event for more discussions on this topic.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Name</span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">OpenID Account Chooser Working Group</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Background Information</span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">The term "NASCAR UI" is used to refer to one of the most common user experiences on Relying Parties to enable users to login with
an identity provider. There are a number of known usability problems with that UI, especially in terms of supporting a large number of identity providers, and for offering users the ability to log in with either an identity provider or a traditional email/password.
The identity community has had discussions about building a “cloud based” identity selector to deal with some of those problems. The idea has been to mix the user experience advantages of Information Cards, the popularity of consumer identity providers,
and still support large numbers of identity providers as InCommon has done. The end result is a user experience that is being called an Account Chooser. For background, see
<a href="http://accountchooser.com/" target="_blank">accountchooser.com</a>.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">The account chooser model can in some cases improve usability on a website even if it does not support identity providers, or a website
that only supports identity providers, or a website that only supports a single identity provider. The account chooser model can also allow a relying party to customize the set of buttons it shows during the "add account" flow based on IP geolocation of the
user to help promote a larger number of identity providers around the world instead of just a small number of providers as is generally shown on a NASCAR UI. The working group will discuss all of these use cases.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Statement of Purpose</span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">This workgroup intends to produce user interface guidelines for how a relying party can implement an account chooser for both adding
accounts, and selecting an account that was previously added.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Scope</span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">Produce a specification for the account chooser user interface guidelines.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Out of Scope </span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">The working group is not expected to define a protocol specification.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Specifications </span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">OpenID Account Chooser User Interface 1.0.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Anticipated audience</span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">All those interested in improving the usability of relying parties.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Language of business</span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">English. </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Method of work</span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">Mailing list discussion. Posting of intermediate drafts in the OpenID Wiki. Virtual conferencing on an ad-hoc basis. </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Basis for completion of the activity</span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">The OpenID Account Chooser User Interface 1.0 final specification is completed. </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Proposers</span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">Basheer Tome,
<a href="mailto:basheer@basheertome.com" target="_blank">basheer@basheertome.com</a>, independent</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">John Bradley,
<a href="mailto:jbradley@me.com" target="_blank">jbradley@me.com</a>, independent</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">Nat Sakimura,
<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>, NRI</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">Kevin Long,
<a href="mailto:kevin@janrain.com" target="_blank">kevin@janrain.com</a>, Janrain</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">Pam Dingle,
<a href="mailto:pdingle@pingidentity.com" target="_blank">pdingle@pingidentity.com</a>, Ping</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">Eric Sachs,
<a href="mailto:Esachs@google.com" target="_blank">Esachs@google.com</a>, Google</span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">Chuck Sievert,
<a href="mailto:csievert@google.com" target="_blank">csievert@google.com</a>, Google</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">Wei Tu,
<a href="mailto:weitu@google.com" target="_blank">weitu@google.com</a> Google</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">Andrew Dahley,
<a href="mailto:andyd@google.com" target="_blank">andyd@google.com</a>, Google</span><u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white">Chris Messina,
<a href="mailto:messina@google.com" target="_blank">messina@google.com</a>, Google</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;background:white">Initial Editors</span></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;background:white"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;color:#888888;background:white">Eric Sachs,
<a href="mailto:Esachs@google.com" target="_blank">Esachs@google.com</a>>, Google</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">--
<u></u><u></u></p>
<div style="margin-top:7.5pt">
<p class="MsoNormal" style="line-height:18.0pt">
<span style="color:#555555;border:solid #D50F25 1.5pt;padding:2.0pt">Eric Sachs |</span><span style="color:#555555;border:solid #3369E8 1.5pt;padding:2.0pt"> Senior Product Manager |</span><span style="color:#555555;border:solid #009939 1.5pt;padding:2.0pt"> <a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a> </span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">--
<u></u><u></u></p>
<div style="margin-top:7.5pt">
<p class="MsoNormal" style="line-height:18.0pt">
<span style="color:#555555;border:solid #D50F25 1.5pt;padding:2.0pt">Eric Sachs |</span><span style="color:#555555;border:solid #3369E8 1.5pt;padding:2.0pt"> Senior Product Manager |</span><span style="color:#555555;border:solid #009939 1.5pt;padding:2.0pt"> <a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a> </span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">--
<u></u><u></u></p>
<div style="margin-top:7.5pt">
<p class="MsoNormal" style="line-height:18.0pt">
<span style="color:#555555;border:solid #D50F25 1.5pt;padding:2.0pt">Eric Sachs |</span><span style="color:#555555;border:solid #3369E8 1.5pt;padding:2.0pt"> Senior Product Manager |</span><span style="color:#555555;border:solid #009939 1.5pt;padding:2.0pt"> <a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a> </span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal">--
<u></u><u></u></p>
<div>
<div>
<div style="margin-top:7.5pt">
<p class="MsoNormal" style="line-height:18.0pt">
<span style="color:#555555;border:solid #D50F25 1.5pt;padding:2.0pt">Eric Sachs |</span><span style="color:#555555;border:solid #3369E8 1.5pt;padding:2.0pt"> Senior Product Manager |</span><span style="color:#555555;border:solid #009939 1.5pt;padding:2.0pt"> <a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a> </span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">--
<u></u><u></u></p>
<div style="margin-top:7.5pt">
<p class="MsoNormal" style="line-height:18.0pt">
<span style="color:#555555;border:solid #D50F25 1.5pt;padding:2.0pt">Eric Sachs |</span><span style="color:#555555;border:solid #3369E8 1.5pt;padding:2.0pt"> Senior Product Manager |</span><span style="color:#555555;border:solid #009939 1.5pt;padding:2.0pt"> <a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a> </span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal">--
<u></u><u></u></p>
<div style="margin-top:7.5pt">
<p class="MsoNormal" style="line-height:18.0pt">
<span style="color:#555555;border:solid #D50F25 1.5pt;padding:2.0pt">Eric Sachs |</span><span style="color:#555555;border:solid #3369E8 1.5pt;padding:2.0pt"> Senior Product Manager |</span><span style="color:#555555;border:solid #009939 1.5pt;padding:2.0pt"> <a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a> </span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div style="margin-top:7.5pt">
<p class="MsoNormal" style="line-height:18.0pt"><span style="color:#555555;border:solid #D50F25 1.5pt;padding:2.0pt">Eric Sachs |</span><span style="color:#555555;border:solid #3369E8 1.5pt;padding:2.0pt"> Senior
Product Manager |</span><span style="color:#555555;border:solid #009939 1.5pt;padding:2.0pt"> <a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a> </span><span style="color:#555555"><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div></div></div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85, 85, 85);font-family:sans-serif;font-size:small"><span style="border-top-width:2px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-top-style:solid;border-right-style:solid;border-bottom-style:solid;border-left-style:solid;border-top-color:rgb(213, 15, 37);border-right-color:rgb(213, 15, 37);border-bottom-color:rgb(213, 15, 37);border-left-color:rgb(213, 15, 37);padding-top:2px;margin-top:2px">Eric Sachs |</span><span style="border-top-width:2px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-top-style:solid;border-right-style:solid;border-bottom-style:solid;border-left-style:solid;border-top-color:rgb(51, 105, 232);border-right-color:rgb(51, 105, 232);border-bottom-color:rgb(51, 105, 232);border-left-color:rgb(51, 105, 232);padding-top:2px;margin-top:2px"> Senior Product Manager |</span><span style="border-top-width:2px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-top-style:solid;border-right-style:solid;border-bottom-style:solid;border-left-style:solid;border-top-color:rgb(0, 153, 57);border-right-color:rgb(0, 153, 57);border-bottom-color:rgb(0, 153, 57);border-left-color:rgb(0, 153, 57);padding-top:2px;margin-top:2px"> <a href="mailto:esachs@google.com" target="_blank">esachs@google.com</a> </span></div>
<br>
</div>