Thanks all,<br><br>If I understand correctly, I could use OpenId I suggested, but it may be better to do it using attributes, for reasons covered in this thread.<br><br>So, if there is an attribute exchange mechanism, why do I need to have a unique URL for my ID?
<br><br>For example, I may visit a university and want to use some service anonymously, why can&#39;t I use a generic ID like <a href="http://openid.myuni.edu.au/">http://openid.myuni.edu.au/</a>, and when I log in at myuni select how much info I want to share? Another day I might choose to use a service that requires myuni to pass my name and my favourite movies (to use the example in the spec).
<br><br>If users are logging in on different days with different attributes for different services, then surely the ID is no just the initial URL, it is a combination of that plus attributes? Or am I missing something?<br>
<br><br>Peter<br><br><div><span class="gmail_quote">On 5/23/07, <b class="gmail_sendername">David Fuelling</b> &lt;<a href="mailto:sappenin@gmail.com">sappenin@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Simon,<br><br>First off, I agree with others on the list that the Sun use of inferring attribute data is different than what Peter Sefton initially asked about.&nbsp; Even so, (for the record), I&#39;m not rock-solid against what you&#39;re advocating, but a few good arguments in favor of not using the 
<span id="st" name="st" class="st">OpenId</span> itself to indicate profile/attribute information are as follows:
<br><br>1.) Inferring attribute data from an <span id="st" name="st" class="st">OpenId</span> is IMHO an &quot;anti-Best Practice&quot; for an *OP* because it ties the hands of an OP (if the OP desires to not lose credibility in the marketplace later on).&nbsp; From P. Windley, &quot;What
if Sun decides to open it up to everyone next year and in the
meantime, systems have been deployed assuming that only Sun employees
are entitled to these identifiers?&quot;.&nbsp; Arguably, Sun won&#39;t be able to become a generic OP without upsetting a lot of RPs (assuming RP&#39;s actually deploy code that interfaces with Sun OpenIds in this way).<br><br>




2.) Inferring attribute data from an <span id="st" name="st" class="st">OpenId</span> is IMHO an &quot;anti-Best Practice&quot; for an *RP*, since an OP might change it&#39;s policies without notifying every RP.&nbsp; How will a given RP know if Sun decides to relax is policies concerning &quot;Sun OpenIds are only used by Sun Employees&quot;?&nbsp; This could create security headaches depending on what is inferred by a given 
<span id="st" name="st" class="st">OpenId</span>.  
<br><br>3.) The attribute inferences are way too subjective.<br>What exactly is a &quot;Sun Employee&quot;, anyway?&nbsp; For example, are sun contractors considered employees?&nbsp; I suppose the definition will be set by Sun somewhere, but it&#39;s not scalable for everybody to be defining their own attribute
data in this fashion, unless there is a common way to translate what this attribute
data *means* (AX is trying to do something like this).&nbsp; Without such standardization, how will RP&#39;s and OP&#39;s know which attribute info to infer from a given <span id="st" name="st" class="st">openid</span>? <div>
<span class="e" id="q_112b616f6a7b3acf_1"><br><br><br><div><span class="gmail_quote">
On 5/22/07, <b class="gmail_sendername">Simon Willison</b> &lt;<a href="mailto:simon@simonwillison.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
simon@simonwillison.net</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 5/22/07, David Fuelling &lt;<a href="mailto:sappenin@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">sappenin@gmail.com</a>&gt; wrote:<br>&gt; Only a few weeks ago, when Sun announced that all of their employees would
<br>&gt; have OpenId&#39;s (and by proxy, all of these employees could identifi
<br>&gt; themselves as sun employees using these ids) there was a lot of discussion<br>&gt; (around the web) relating to why this is a bad idea.<br><br>I&#39;d really like to see some URLs for this - as far as I was aware the
<br>only public negative commentary was here - and even that wasn&#39;t very<br>strongly worded:<br><a href="http://www.windley.com/archives/2007/05/sun_supports_openid_and_opens_the_question_of_reputation.shtml" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">



http://www.windley.com/archives/2007/05/sun_supports_openid_and_opens_the_question_of_reputation.shtml
</a><br><br>As someone who is a big proponent of the idea of OpenIDs from<br>different providers&nbsp;&nbsp;meaning different things I would be very<br>interested in hearing the arguments against.<br><br>Cheers,<br><br>Simon<br></blockquote>




</div><br>
</span></div><br>_______________________________________________<br>general mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:general@openid.net">general@<span id="st" name="st" class="st">
openid</span>.net</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://openid.net/mailman/listinfo/general" target="_blank">http://<span id="st" name="st" class="st">openid</span>.net/mailman/listinfo/general
</a><br><br></blockquote></div><br><br clear="all"><br>-- <br><br>Peter Sefton<br>Senior Research Fellow / RUBRIC Technical Manager<br>RUBRIC Project, DeC<br>University of Southern Queensland<br>Toowoomba Queensland 4350 AUSTRALIA
<br><br><br>Work: <a href="mailto:sefton@usq.edu.au">sefton@usq.edu.au</a><br>Private: <a href="mailto:pt@ptsefton.com">pt@ptsefton.com</a><br><br>p: +61 (0)7 4631 1640<br>m: +61 (0)410 326 955<br><br>RUBRIC Website: <a href="http://www.rubric.edu.au">
http://www.rubric.edu.au</a> <br>USQ Website: <a href="http://www.usq.edu.au">http://www.usq.edu.au</a><br>Personal Website: <a href="http://ptsefton.com">http://ptsefton.com</a><br><br>RUBRIC is supported by the Systemic Infrastructure Initiative as part of
<br>the Commonwealth Government&#39;s Backing Australia&#39;s Ability - An<br>Innovative Action Plan for the Future<br>(<a href="http://backingaus.innovation.gov.au">http://backingaus.innovation.gov.au</a>)<br><br>The University of Southern Queensland is a registered provider of
<br>education with the Australian Government.<br><br>(CRICOS Codes: QLD 00244B | NSW 02225M | VIC 02387D | WA 02521C)