Requiring Pseudonymous Identifier

Nat Sakimura sakimura at gmail.com
Wed May 13 16:41:47 UTC 2009


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/



More information about the specs mailing list