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. -- 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:41 AM, Nat Sakimura <sakim...@gmail.com> wrote: > I think RP discovery is needed anyways. > > For deciding whether RP wants psudonym for this transaction or not, > I am not sure if RP discovery alone is enough, though. > RP might want non-psudonym for a particular type of transaction. > So, yes, RP's XRD would be able to specify the default behaviour, > but it would also be useful to be able to override it per transaction. > > As a matter of fact, I do not strongly feel that we should bake the > psudonym generation > algorithm into the spec. However, thinking concretely would clarify the > requirement to other portions, like what has to be written in the XRD, etc. > so I think it is useful. > > To indicate the quality of the identifier and the assertion, we should > utilize PAPE. > > =nat > > On Thu, May 14, 2009 at 1: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 > >> > >> > > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ >
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
