<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
 /* List Definitions */
 @list l0
        {mso-list-id:459348149;
        mso-list-type:hybrid;
        mso-list-template-ids:-1136245846 873738226 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;
        mso-fareast-font-family:Calibri;
        mso-bidi-font-family:"Times New Roman";}
@list l1
        {mso-list-id:546455792;
        mso-list-type:hybrid;
        mso-list-template-ids:1330659528 -820724140 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;
        mso-fareast-font-family:Calibri;
        mso-bidi-font-family:"Times New Roman";}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Was my expectation of system behavior reasonable?<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Im used to myopenid &#8211; which sets my mental model of how
openid auth - the protocol &#8211; is intended to be used: setup a personality the
first time on visit to a realm, and decide by realm whether its auto-invoked
(the next time). If there is no auto-invocation (*) &#8211; which would be normal
on a commenting site - the user must select a personality each time (which
implies choice of release set, each time).<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>( * note c, and k, in different declensions of to invoke! Isn&#8217;t
English weird. )<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<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;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Andrew Arnott
[mailto:andrewarnott@gmail.com] <br>
<b>Sent:</b> Saturday, April 04, 2009 8:40 PM<br>
<b>To:</b> Peter Williams<br>
<b>Cc:</b> Breno de Medeiros; Deron Meranda; general; John Bradley<br>
<b>Subject:</b> Re: [OpenID] About Facebook, MySpace and OpenID<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Peter,<o:p></o:p></p>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>The scenario you ask about doesn't exist. &nbsp;With Google,
the user can't opt-out of sending the email address. &nbsp;Either Google
totally ignores the email request because it's in if_available, or the RP puts
it in 'required', and then Google won't complete auth at all without the user's
consent to include the email. &nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'><br clear=all>
--<br>
Andrew Arnott<br>
&quot;I [may] not agree with what you have to say, but I'll defend to the death
your right to say it.&quot; - Voltaire<br>
<br>
<o:p></o:p></p>

<div>

<p class=MsoNormal>On Sat, Apr 4, 2009 at 8:29 PM, Peter Williams &lt;<a
href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>&gt; wrote:<o:p></o:p></p>

<div>

<div>

<p><span style='font-size:11.0pt;color:#1F497D'>If I&#8217;m an RP taking
authenticated comments from a google subscriber for the first time and the user
denies the release of the optional email attribute, is there any way for the
user to release it the next time s/he attempts to post a comment?</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>i.e. depending on the nature of
the&nbsp; comment or the thread, the user may wish &nbsp;to release or not
release the email identifier (to signal that followup email dialog is
available, or to receive events that the comments received followup). Lets
assume that the site processing the comments does not maintain an account for
the commenting user.</span><o:p></o:p></p>

<p><span style='font-size:11.0pt;color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p><b><span style='font-size:10.0pt'>From:</span></b><span style='font-size:
10.0pt'> <a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>
[mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>]
<b>On Behalf Of </b>Breno de Medeiros<br>
<b>Sent:</b> Saturday, April 04, 2009 6:38 PM<br>
<b>To:</b> Deron Meranda<br>
<b>Cc:</b> general; John Bradley</span><o:p></o:p></p>

<div>

<p class=MsoNormal><br>
<b>Subject:</b> Re: [OpenID] About Facebook, MySpace and OpenID<o:p></o:p></p>

</div>

</div>

</div>

<p>&nbsp;<o:p></o:p></p>

<p>It is not true that you need to request all your attributes for the Google
OP or else you will be locked out. If you add a request for a new attribute we
will prompt the user to authorize and then send it.&nbsp; That also happens if
the value of the attribute changed since the user approved (re-prompt and
send). <o:p></o:p></p>

<div>

<div>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>

<p>On Apr 3, 2009 9:35 PM, &quot;Deron Meranda&quot; &lt;<a
href="mailto:deron.meranda@gmail.com" target="_blank">deron.meranda@gmail.com</a>&gt;
wrote:<br>
<br>
On Fri, Apr 3, 2009 at 11:08 PM, Andrew Arnott &lt;<a
href="mailto:andrewarnott@gmail.com" target="_blank">andrewarnott@gmail.com</a>&gt;
wrote:<br>
&gt; ...&nbsp;All the RPs are upgrading their email requests to required<o:p></o:p></p>

<p><span style='color:#500050'>&gt; so that they work with Google.
&nbsp;Apparently they really wanted email and they &gt; were getting it unt...</span><o:p></o:p></p>

<p>Maybe its useful to think about attributes other than email to see<br>
where &quot;optional&quot; perhaps makes more sense.<br>
<br>
Consider a possible Time Zone attribute (yes SReg has this). &nbsp;This is a
case<br>
where it is easier to see what an RP might mean by &quot;optional&quot; -- that
if the<br>
OP can provide it it wants it; but if not, the RP still wants the
authentication<br>
to proceed and not to fail, because it can deal easily enough with not<br>
getting the time zone.<br>
<br>
It could also be argued that the OP *should* ask the user which optional<br>
attributes it wants to give. &nbsp;You might not think time zone is important<br>
enough to ask the user for permission; unless perhaps your time zone<br>
happened to be America/Havana for example and you didn't want this<br>
RP to know you're in Cuba.<br>
<br>
I can see Google's perspective on this; and it is a combination of<br>
trying to make a simple UI for non-technical users (which we all<br>
agree is something OpenID desperately needs), as well as the<br>
spec being somewhat silent on what its expectations are for the<br>
OP and RP.<br>
<br>
<br>
However, at this point, with Google's current interpretation, there is<br>
effectively no utility in having optional attributes. &nbsp;The distinction is<br>
made meaningless. &nbsp;And since we don't want RP's to special-case per<br>
OP; then effectively, in practice today anyway, it is pointless for<br>
OpenID AX to pretend there is an optional/required dimension.<br>
<br>
Now one can argue that Google is right and the spec was trying to<br>
make two categories when only one made sense; or that Google is<br>
wrong and OPs should definitely treat optional attributes differently<br>
than required ones. &nbsp;I'm not sure which is correct; but I do think<br>
that the spec should be made very clear one way or the other.<br>
Because if the behavior is left up to the OP, as Google has done, then<br>
the spec is made pointless in practice and its all just unnecessary<br>
noise words.<br>
<br>
<br>
I would say, another thing that Google does that may play into all<br>
this is that they don't always send AX attributes back at all. &nbsp;If the<br>
RP and OP have communicated before concerning a certain<br>
identity; then the RP may actually get no attributes whatsoever<br>
on subsequent interactions (Google assumes that the RP will<br>
remember these attributes the first time, which means that in<br>
practice the RP will be forced to remember these attributes).<br>
<br>
This also coerces the RP to try to request ALL the attributes it thinks<br>
it might ever need the very first time it interacts with Google. &nbsp;And since<br>
it also using is directed identity (where the RP doesn't know the identity<br>
before hand), this effectively means that the RP is going to have to<br>
request all the possible AX attributes it might ever desire for any user,<br>
effectively as a *requred* attribute, on every single request! &nbsp;Because if<br>
it guesses wrong and decides not to ask for a particular attribute even<br>
once, it may then be locked out of ever getting that attribute in the future.<br>
<br>
This makes it very hard to implement an RP. &nbsp;Either it asks for too<br>
many attributes, and the authentication fails because the user doesn''t<br>
want to return ALL of them (or Google doesn't support a hypothetical<br>
Time Zone AX attribute and treats optional as-if required so it fails).<br>
-- &nbsp;Or on the other hand the RP doesn't ask for enough attributes; but<br>
then has to live with never being able to ask for them in the future when<br>
it later decides it does want to know them.<br>
<br>
And the directed identity on top of this means the RP has to make this<br>
difficult choice just once per OP, rather than a finer grained per identity.<br>
I think this existing behavior, although defensible from Google's<br>
perspective; pretty much renders a good portion of the AX spec<br>
completely useless.<br>
<br>
Either an RP is never going to use AX at all because it doesn't want<br>
to risk causing an authentication to fail; or an RP is always going to<br>
request as many attributes as possible all as required (even if it<br>
doesn't need them right now), because it doesn't want to miss out on<br>
it's one chance to get that information the first time.<br>
--<br>
<span style='color:#888888'>Deron Meranda</span><o:p></o:p></p>

</blockquote>

</div>

</div>

</div>

</div>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><o:p></o:p></p>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</div>

</body>

</html>