Yes, I think an RP may want different identifier types for different use cases.  But the RP discovery XRDS can handle that just fine by having two different return_to URIs in the XRDS, one that accepts each type of identifier.  Each return_to URI, after validating the assertion, would forward the user on to whatever use case consumes that kind of login.<br clear="all">

--<br>Andrew Arnott<br>&quot;I [may] not agree with what you have to say, but I&#39;ll defend to the death your right to say it.&quot; - Voltaire<br>
<br><br><div class="gmail_quote">On Wed, May 13, 2009 at 9:41 AM, Nat Sakimura <span dir="ltr">&lt;<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

I think RP discovery is needed anyways.<br>
<br>
For deciding whether RP wants psudonym for this transaction or not,<br>
I am not sure if RP discovery alone is enough, though.<br>
RP might want non-psudonym for a particular type of transaction.<br>
So, yes, RP&#39;s XRD would be able to specify the default behaviour,<br>
but it would also be useful to be able to override it per transaction.<br>
<br>
As a matter of fact, I do not strongly feel that we should bake the<br>
psudonym generation<br>
algorithm into the spec. However, thinking concretely would clarify the<br>
requirement to other portions, like what has to be written in the XRD, etc.<br>
so I think it is useful.<br>
<br>
To indicate the quality of the identifier and the assertion, we should<br>
utilize PAPE.<br>
<font color="#888888"><br>
=nat<br>
</font><div><div></div><div class="h5"><br>
On Thu, May 14, 2009 at 1:28 AM, George Fletcher &lt;<a href="mailto:gffletch@aol.com">gffletch@aol.com</a>&gt; wrote:<br>
&gt; I&#39;m perfectly fine with using RP discovery as a mechanism for the RP to<br>
&gt; specify what &quot;policy&quot; it requires. I believe that unsolicited assertions are<br>
&gt; going to become more common, so we need to support it.<br>
&gt;<br>
&gt; What I don&#39;t want OpenID to do is specify the actual syntax of the<br>
&gt; pseudonymous identifier. I agree that the RP has to trust the OP (in some<br>
&gt; sense) or make it&#39;s own determination that the OP is not honoring the RP&#39;s<br>
&gt; wishes and then take some action.<br>
&gt;<br>
&gt; For RP&#39;s behind firewalls, it would be nice to allow them some mechanism<br>
&gt; other than RP discovery to assert their requirements, but that should<br>
&gt; preclude the discover option.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; George<br>
&gt;<br>
&gt; Andrew Arnott wrote:<br>
&gt;&gt;<br>
&gt;&gt; leaves out the scenario of unsolicited assertions.A new directed identity<br>
&gt;&gt; value that the RP passes to the OP to indicate it wants a psuedononymous<br>
&gt;&gt; identifier.  Consider this:<br>
&gt;&gt;<br>
&gt;&gt; An OP needs to perform RP discovery (already), and probably does so before<br>
&gt;&gt; sending an unsolicited assertion in order to find out what the assertion<br>
&gt;&gt; receiving URI would be for a given realm.  DNOA does this already.  If that<br>
&gt;&gt; RP&#39;s XRDS document included a TypeURI element that had a special<br>
&gt;&gt; psuedononymous-identifier-only-please value the OP could pick up on this,<br>
&gt;&gt; and send the unsolicited assertion using the appropriate type of claimed_id.<br>
&gt;&gt;<br>
&gt;&gt; Likewise, when an RP sends an ordinary directed identity request to an OP,<br>
&gt;&gt; the OP would again notice the RP&#39;s XRDS during RP discovery and see what<br>
&gt;&gt; kind of identifier the RP wants and assert accordingly.<br>
&gt;&gt;<br>
&gt;&gt; Yes, some OPs won&#39;t honor the RP&#39;s wishes, and some OPs don&#39;t do RP<br>
&gt;&gt; discovery at all.  Perhaps to help the RP detect whether the OP respected<br>
&gt;&gt; its wishes would be to send a PAPE extension or some other openid.*<br>
&gt;&gt; parameter to say &quot;yes, this is a pseudo- identifier.&quot;  RPs have no way to<br>
&gt;&gt; analytically be certain that some identifier is psuedononymous anyway, so<br>
&gt;&gt; ultimately the RP has to trust the OP (whether implicitly or through a white<br>
&gt;&gt; list is up to the RP).<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Andrew Arnott<br>
&gt;&gt; &quot;I [may] not agree with what you have to say, but I&#39;ll defend to the death<br>
&gt;&gt; your right to say it.&quot; - Voltaire<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Wed, May 13, 2009 at 8:44 AM, George Fletcher &lt;<a href="mailto:gffletch@aol.com">gffletch@aol.com</a><br>
&gt;&gt; &lt;mailto:<a href="mailto:gffletch@aol.com">gffletch@aol.com</a>&gt;&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;    I don&#39;t think OpenID should specify how pseudonymous identifiers<br>
&gt;&gt;    are generated. That should be up to the OP. But I like the idea of<br>
&gt;&gt;    using a fixed URI as the claimed_id value to specify the behavior<br>
&gt;&gt;    desired by the RP. If, however, we need to grow this to cover<br>
&gt;&gt;    anonymous based identifiers (i.e. the claims based models from<br>
&gt;&gt;    earlier in this thread) then it might make sense to look at a PAPE<br>
&gt;&gt;    extension that covers the type of identifier requested.<br>
&gt;&gt;<br>
&gt;&gt;    Thanks,<br>
&gt;&gt;    George<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;    Nat Sakimura wrote:<br>
&gt;&gt;<br>
&gt;&gt;        Sorry for a slow response. This week is especially busy for me...<br>
&gt;&gt;<br>
&gt;&gt;        I borrowed the notion from Austrian Citizen ID system.<br>
&gt;&gt;        In there, the services are divided into &quot;sectors.&quot;<br>
&gt;&gt;        A sector may span several agencies.<br>
&gt;&gt;        They call ID as PIN (Personal Identification Number).<br>
&gt;&gt;<br>
&gt;&gt;        There is a secret PIN (sPIN) which is not used anywhere but in<br>
&gt;&gt;        their SmartCard.<br>
&gt;&gt;        Then, sector sepcific PIN (ssPIN) is calculated in the manner of :<br>
&gt;&gt;<br>
&gt;&gt;        SHA1(sPIN + SectorID)<br>
&gt;&gt;<br>
&gt;&gt;        (Note, there is a bit more details but...)<br>
&gt;&gt;<br>
&gt;&gt;        I have thrown OP secret into it.<br>
&gt;&gt;        To avoid the analytic attack, I agree that it is better to use<br>
&gt;&gt;        individual secret, as some of you<br>
&gt;&gt;        points out.<br>
&gt;&gt;<br>
&gt;&gt;        Regards,<br>
&gt;&gt;<br>
&gt;&gt;        =nat<br>
&gt;&gt;<br>
&gt;&gt;        On Tue, May 12, 2009 at 5:55 PM, Dick Hardt<br>
&gt;&gt;        &lt;<a href="mailto:dick.hardt@gmail.com">dick.hardt@gmail.com</a> &lt;mailto:<a href="mailto:dick.hardt@gmail.com">dick.hardt@gmail.com</a>&gt;&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;            On 12-May-09, at 1:36 AM, Nat Sakimura wrote:<br>
&gt;&gt;<br>
&gt;&gt;                Reason for using RP&#39;s Subject in XRD instead of simply<br>
&gt;&gt;                using realm is<br>
&gt;&gt;                to allow for something like group identifier.<br>
&gt;&gt;<br>
&gt;&gt;            would you elaborate on the group identifier concept?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;                This is just one idea. Downside of this approach<br>
&gt;&gt;                is that we need to set up a WG.<br>
&gt;&gt;<br>
&gt;&gt;                I am sure there are more ideas. It might be possible<br>
&gt;&gt;                to utilize AX<br>
&gt;&gt;                so that it will only be a profile that does not<br>
&gt;&gt;                require a WG.<br>
&gt;&gt;<br>
&gt;&gt;                So shall we start discussing which direction we want<br>
&gt;&gt;                to go forward?<br>
&gt;&gt;<br>
&gt;&gt;            sure!<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;    _______________________________________________<br>
&gt;&gt;    specs mailing list<br>
&gt;&gt;    <a href="mailto:specs@openid.net">specs@openid.net</a> &lt;mailto:<a href="mailto:specs@openid.net">specs@openid.net</a>&gt;<br>
&gt;&gt;    <a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
<br>
<br>
<br>
</div></div><div><div></div><div class="h5">--<br>
Nat Sakimura (=nat)<br>
<a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
</div></div></blockquote></div><br>