Requiring Pseudonymous Identifier
andrewarnott at gmail.com
Wed May 13 16:44:57 UTC 2009
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.
"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 <sakimura at 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.
> On Thu, May 14, 2009 at 1:28 AM, George Fletcher <gffletch at 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
> > 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
> > 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
> >> 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
> >> 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
> >> RP's XRDS document included a TypeURI element that had a special
> >> psuedononymous-identifier-only-please value the OP could pick up on
> >> and send the unsolicited assertion using the appropriate type of
> >> Likewise, when an RP sends an ordinary directed identity request to an
> >> 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
> >> 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
> >> analytically be certain that some identifier is psuedononymous anyway,
> >> ultimately the RP has to trust the OP (whether implicitly or through a
> >> list is up to the RP).
> >> --
> >> Andrew Arnott
> >> "I [may] not agree with what you have to say, but I'll defend to the
> >> your right to say it." - Voltaire
> >> On Wed, May 13, 2009 at 8:44 AM, George Fletcher <gffletch at aol.com
> >> <mailto:gffletch at 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.hardt at gmail.com <mailto:dick.hardt at 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 at openid.net <mailto:specs at openid.net>
> >> http://openid.net/mailman/listinfo/specs
> Nat Sakimura (=nat)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the specs