Agreed. RP requests a pseudonymous identifier and it's up to the OP
to figure out how to make one and ideally communicate back to the RP
that it did so.
--David
On May 13, 2009, at 9:41 AM, Andrew Arnott wrote:
Agreed. There is no reason for OpenID to mandate how pseudononymous
identifiers are created. That should be left up to the OP.
--
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:28 AM, George Fletcher <[email protected]>
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 <[email protected] <mailto:[email protected]
>> 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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://openid.net/mailman/listinfo/specs
_______________________________________________
specs mailing list
[email protected]
http://openid.net/mailman/listinfo/specs
_______________________________________________
specs mailing list
[email protected]
http://openid.net/mailman/listinfo/specs
