Pete,
While the transaction with the IdP is about the derived identifier (sort
of like that term actually), the RP uses the delegated identifier when
referencing the user.
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Pete Rowley
Sent: Wednesda
On 1-Nov-06, at 12:28 PM, John Kemp wrote:
> OK. Just checking. So an IdP/OP can choose whether or not to trust a
> particular RP, based on some out-of-ban criteria. And an RP can choose
> whether or not to trust the assertions of a particular IdP/OP? OK
> good.
Technically possible, yes for th
Dick Hardt wrote:
>> It would be nice to see a clear definition of an OP in order to
>> determine the exact differences between such an entity and an IdP, but,
>> in the absence of such, some questions:
>>
>> Dick Hardt wrote:
>>> Thanks David! ;-)
>>>
>>> Patrick, as you point out, Identity Provi
On 1-Nov-06, at 11:33 AM, John Kemp wrote:
> Hi Dick,
Hi John!
>
> It would be nice to see a clear definition of an OP in order to
> determine the exact differences between such an entity and an IdP,
> but,
> in the absence of such, some questions:
>
> Dick Hardt wrote:
>> Thanks David! ;-)
>
Hi Dick,
It would be nice to see a clear definition of an OP in order to
determine the exact differences between such an entity and an IdP, but,
in the absence of such, some questions:
Dick Hardt wrote:
> Thanks David! ;-)
>
> Patrick, as you point out, Identity Provider is a well understood
>
I'm afraid I still don't get it.
As far as I am concerned the authenticated identifier is the tuple:
(Identity-provider-Id, Identifier)
If we want to have a single identifier there has to be a mechanism for
establishing the scope of authority for each IdP over a specific subset of
identifi
Rowan Kerr wrote:
On Wed, 2006-11-01 at 11:33 -0500, John Kemp wrote:
I think you need the ability for a user to change his identifier at the
RP (as George notes below) and also at the IdP.
Isn't this was already covered in the spec? You accomplish this by
creating an HTML page on som
Thanks David! ;-)
Patrick, as you point out, Identity Provider is a well understood
term in SAML and WS-*. Here is the definition from SAML 2.0 [1]
Identity Provider: A kind of service provider that creates,
maintains, and manages
identity information for principals and provides principal
aut
Don't forget that the a more important constraint here is to prevent
impersonation.
I don't see how one can switch between genuinely autonamous IdPs in the way
suggested without allowing a rogue IdP to impersonate anyone they chose.
At what point do the synchronization mechanisms you build in e
On Wed, 2006-11-01 at 11:33 -0500, John Kemp wrote:
> I think you need the ability for a user to change his identifier at the
> RP (as George notes below) and also at the IdP.
Isn't this was already covered in the spec? You accomplish this by
creating an HTML page on some website you control with
Hello,
I think you need the ability for a user to change his identifier at the
RP (as George notes below) and also at the IdP. In addition, it should
be possible for the IdP to providing OpenID "forwarding" if the user
leaves for another IdP (perhaps the user will even pay for a forwarding
service
If we want identities to be persistent then we are going to need to introduce a
layer of indirection.
This normally gets me worried about patents and such. Fortunately Multics did
this, so did UNIX and VMS. Plenty of prior art.
If we are serious about decentralization then map the user identi
The reasons for raising this question was partly that I've been doing
some research on how people use e-mail addresses and sad to say, you can
not expect the user to make wise choices. And even so, companies go
broke even the best ones. Services comes and disappear. In my research
over half of
Bad statement of the principle. Centralized direction is
inevitable if there are to be unique, mnemonic
identifiers.
The questions are whether the centralized control is
accountable, whether the system has checks and balances and the confidence that
users can place in the registry continui
14 matches
Mail list logo
