I dont think this fits either PAPE or AX.

I cant see how the privacy characteristics of an identifier are part of 'authentication policy'. How the user authenticates to the OP is (mostly) orthogonal to the nature of the identifier the OP asserts.

Nor does it fit the AX description of attribute as "a unit of personal identity information".

regards

paul

Andrew Arnott wrote:
This scenario doesn't fit what I've always felt AX was for. I don't expect a fetch request to change anything about the underlying openid transport other than prompting the user for information disclosure at the OP. PAPE fits better in my mind. But again, if PAPE is the only way to get a psuedo-anonymous identifier, then unsolicited assertions can't get it right. But if we allow PAPE requests to ask for one, and for it to also be discoverable via the RP return_to service in its XRDS, then both unsolicited assertion and RP-behind-firewall scenarios work.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


On Wed, May 13, 2009 at 4:58 PM, David Recordon <da...@sixapart.com <mailto:da...@sixapart.com>> wrote:

    Does it make more sense to use a PAPE policy requesting a
    pseudonymous identifier or an AX attribute requesting one?  Any of
    these approaches would work, I just don't think we've mapped out
    the pros/cons of each.

    --David


    On May 13, 2009, at 8:44 AM, George Fletcher 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 <mailto:specs@openid.net>
    http://openid.net/mailman/listinfo/specs


------------------------------------------------------------------------

_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Reply via email to