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