Requiring Pseudonymous Identifier
andrewarnott at gmail.com
Wed May 13 16:41:18 UTC 2009
Agreed. There is no reason for OpenID to mandate how pseudononymous
identifiers are created. That should be left up to the OP.
"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: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.
> 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.
>> 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.
>> 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?
>> specs mailing list
>> specs at openid.net <mailto:specs at openid.net>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the specs