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