Requiring Pseudonymous Identifier

Andrew Arnott 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.
--
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 <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.
>
> =nat
>
> 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
> 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 <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)
> http://www.sakimura.org/en/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090513/63b598b5/attachment.htm>


More information about the specs mailing list