<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:"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";}
span.apple-style-span
        {mso-style-name:apple-style-span;}
span.apple-converted-space
        {mso-style-name:apple-converted-space;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
-->
</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 style='word-wrap: break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Out of interest, what happens the second time (on the same OP
session)?<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'>In the SAML websso protocol, as an RP I&#8217;m used to
requesting an &#8220;ispassive-constrained&#8221; assertion (with fixed &nbsp;attribute
set) when folks on the RP site navigate to the internal home pages of certain
site modules within the realm &#8211; where the authZ policy enforced by that particular
module&#8217;s class loader requires a recent act of user (re)authentication (using
an RSA securid time-synced tokencode, typically) and reconfirmation that the
member has an attribute indicating s/he is (still) in good standing with the
IDP&#8217;s membership policies. As our basic RP session is 60m or longer , the
guards are necessary &#8211; to ensure for timeliness of user auth required by higher
accountability and control requirements in those site areas.<o:p></o:p></span></p>

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

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Our OP/RP openid implementation happens to be a multi-stage gateway
&#8211; &nbsp;SAML and openid auth protocol engines operating in a pretty
common co-resident fashion in a single process at a security domain boundary. If
the SAML RP issues a authentication requests, the &#8220;fixed&#8221; attribute
contract in the bilateral SAML metadata becomes a list of openid auth req &#8220;required&#8221;
sreg/ax attributes. If the SAML RP makes a followup request 5m later, with
ispassive=true (no UI allowed), the same set of attributes will be required. There
is no context for the second protocol run, given the first &#8211; that enable
it to ask for more or less attributes the second time.<o:p></o:p></span></p>

<div style='mso-element:para-border-div;border:none;border-bottom:solid windowtext 1.0pt;
padding:0in 0in 1.0pt 0in'>

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

</div>

<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'>Google OP seems to be making assumptions about how RPs are
design and built &#8211; which is biasing how openid auth protocol operates in
their case. Against conventional standards wisdom, intentionally or otherwise, their
interpretation of what openid auth/sreg/ax conformance requires seems to be is forcing
a particular security policy, persistence and session implementation architecture
on RPs &nbsp;- to know to use a particular code path when working with Google OP
&nbsp;concerning persistence of RP-session attributes.<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'>Google is always a fascinating (and very POSTIIVE) case study
for me. Only two years ago, the real estate bit of Google refused to
contemplate ever being an IDP sharing such sensitive commercial consumer data
as the Google account holders attributes with RPs like us &nbsp;(they were obviously
wrong, given the Google OP!), and we do already have the means for individual
realtors acting in reverse handoff to assert their rights (as a member of the
home listing service) to post a home listing to Google Base - for distribution of
some of the listing attributes into that particular search engine - &nbsp;in
the hope it will generate a sales lead. <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'>&nbsp;I have hopes that I can put the two functions (consumers using
openid websso to followup a lead listing in Google to get to us as RP, and realtors
using our IDP/OP to posting off listing &#8220;lead&#8221; attributes to Google
Base) together now, to create an web application which would migrate away from Google
Base&#8217;s proprietary auth mechanism to websso standards. What I cannot do,
however, is be required to know of or use any particular implementation architecture,
to accomplish that &#8211; as the same Rapattoni code base has to work according
to the same technical standard with all the other (one day, similarly openid-powered)
lead generation sites, too. <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"'> John Bradley
[mailto:john.bradley@wingaa.com] <br>
<b>Sent:</b> Saturday, April 04, 2009 9:12 PM<br>
<b>To:</b> Peter Williams<br>
<b>Cc:</b> Breno de Medeiros; Deron Meranda; general<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>If you ask google for a required AX attribute, email as an
example and the user declines to send it to you Google sends back a
negative&nbsp;assertion&nbsp;and you never find out the users claimed_id.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=MsoNormal>In my tests of Google a user has the option of continuing
with the login and returning the required AX attributes
or&nbsp;canceling&nbsp;and not&nbsp;logging&nbsp;in.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=MsoNormal>If the user cancels the RP would need to send a second
checkid_setup without the required AX attribute&nbsp;request. &nbsp;Log the
user in and then&nbsp;perform&nbsp;some&nbsp;additional&nbsp;separate openID
step to get the AX attributes.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=MsoNormal>For a RP to deal&nbsp;properly&nbsp;with a Google openID
they should separate the Auth from the AX exchange otherwise if the the user
declines sending the attributes to the RP they also decline sending
the&nbsp;authentication.&nbsp;<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=MsoNormal>Technically&nbsp;they are not violating the AX spec but to
be&nbsp;useful&nbsp;the flow needs to be&nbsp;different&nbsp;from what RPs are
doing with other OPs.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=MsoNormal>That is why I am hinting at the need for
some&nbsp;higher-level&nbsp;definition/standard for the UX flows.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=MsoNormal>Regards<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>John Bradley<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<div>

<div>

<p class=MsoNormal>On 4-Apr-09, at 8:29 PM, Peter Williams wrote:<o:p></o:p></p>

</div>

<p class=MsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
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><span style='color:black'><o:p></o:p></span></p>

</div>

<div>

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

</div>

<div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
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><span
style='color:black'><o:p></o:p></span></p>

</div>

<div>

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

</div>

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

<div>

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

<div>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:black'>From:</span></b><span class=apple-converted-space><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>&nbsp;</span></span><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'><a
href="mailto:general-bounces@openid.net">general-bounces@openid.net</a> [<a
href="mailto:general-bounces@openid.net">mailto:general-bounces@openid.net</a>]<span
class=apple-converted-space>&nbsp;</span><b>On Behalf Of<span
class=apple-converted-space>&nbsp;</span></b>Breno de Medeiros<br>
<b>Sent:</b><span class=apple-converted-space>&nbsp;</span>Saturday, April 04,
2009 6:38 PM<br>
<b>To:</b><span class=apple-converted-space>&nbsp;</span>Deron Meranda<br>
<b>Cc:</b><span class=apple-converted-space>&nbsp;</span>general; John Bradley<br>
<b>Subject:</b><span class=apple-converted-space>&nbsp;</span>Re: [OpenID]
About Facebook, MySpace and OpenID</span><span style='color:black'><o:p></o:p></span></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal><span style='color:black'>&nbsp;<o:p></o:p></span></p>

</div>

<p><span style='color:black'>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></span></p>

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

<div>

<p class=MsoNormal><span style='color:black'>On Apr 3, 2009 9:35 PM,
&quot;Deron Meranda&quot; &lt;<a href="mailto:deron.meranda@gmail.com">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">andrewarnott@gmail.com</a>&gt; wrote:<br>
&gt; ...&nbsp;All the RPs are upgrading their email requests to required<o:p></o:p></span></p>

</div>

<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><span
style='color:black'><o:p></o:p></span></p>

<div>

<p class=MsoNormal><span style='color:black'>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><span style='color:#888888'>Deron Meranda</span><span style='color:black'><o:p></o:p></span></p>

</div>

</blockquote>

</div>

</div>

</div>

</div>

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

</div>

</div>

</div>

</body>

</html>