Hello List
I have written up what I think are the requirements for identifiers
so that we can see if we agree to those. If so, then the proposal
revision I have below may be an acceptable solution that keeps things
simple and provides backwards compatibility.
Sorry that we are still having
-1 for these reasons:
Complexity: There is no reason for the RP to be managing the binding
between the IdP and the portable identifier. Both the IdP and the RP
are verifying this. There is no extra security, and more things to go
wrong in an implementation.
Privacy: There is no reason for t
On 22-Oct-06, at 9:04 PM, George Fletcher wrote:
>
>
> Dick Hardt wrote:
>>
>> On 22-Oct-06, at 7:00 PM, George Fletcher wrote:
>>
>>>
>>>
>>> Dick Hardt wrote:
With OpenID, there is a presumption the user has selected a trust
worthy IdP that will only present the user's identifiers wh
Dick Hardt wrote:
>
> On 22-Oct-06, at 7:00 PM, George Fletcher wrote:
>
>>
>>
>> Dick Hardt wrote:
>>> With OpenID, there is a presumption the user has selected a trust
>>> worthy IdP that will only present the user's identifiers when it
>>> really is the user.
>>>
>> Doesn't this imply that bo
Wouldn't it be nice if we could just bypass all the stupid email callback stuff
that we usually have to put up with?
Its easy to do, the only constraint being that the IdP has to be able to
advertise an SRV record.
IdP advertises
_openid.example.com SRV 1 100 80 openid1.example.com
Given a
Hi Johannes,
Yep - that's right. "Browser++" might also be an identity provision
service (eg: web site), or combination of service and browser
component. Component will need to be a browser plugin with access to
the source of the page, and opportunity to enact changes to it (eg:
fill in the user
On 22-Oct-06, at 7:00 PM, George Fletcher wrote:
>
>
> Dick Hardt wrote:
>> With OpenID, there is a presumption the user has selected a trust
>> worthy IdP that will only present the user's identifiers when it
>> really is the user.
>>
> Doesn't this imply that both the user and RP have to know
Dick Hardt wrote:
> With OpenID, there is a presumption the user has selected a trust
> worthy IdP that will only present the user's identifiers when it
> really is the user.
>
Doesn't this imply that both the user and RP have to know which IdP's
are "trust worthy"?
> Actually, idp.spammers.c
On 22-Oct-06, at 5:05 PM, George Fletcher wrote:
>
> Dick Hardt wrote:
>> What is different with OpenID vs email is that there is certainty
>> that the user actually is the user.
> I'm a little confused. How is there certainty that "the user
> actually is the user"? The viability of the ide
On 22-Oct-06, at 2:28 PM, Praveen Alavilli wrote:
>
>
> [EMAIL PROTECTED] wrote:
>> For starters please don't use Comic Sans in professional
>> correspondence. it is very hard to read (or take seriously)
>> http://bancomicsans.com/home.html
>>
>>
>> On Oct 22, 2006, at 11:44 AM, Praveen Alav
Dick Hardt wrote:
>
> On 20-Oct-06, at 10:14 AM, George Fletcher wrote:
>>
>> Of course, my expectation is that this syntax would be optional; the
>> user can always specify their full URI identifier.
>>
>> I agree that this kind of an identifier is not portable, but I'm
>> guessing that most u
[EMAIL PROTECTED] wrote:
For starters please don't use Comic Sans in professional
correspondence. it is very hard to read (or take seriously) http://bancomicsans.com/home.html
On Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote:
It's more of a problem with how we ca
In the case where there are two realms:
http://*.livejournal.com
http://dick.livejournal.com
I would have my IdP treat them as separate relying parties. If the RP
directly decided to set the realm differently, then I'd imagine the
application has a reason for doing so. This is of course differe
On 22-Oct-06, at 12:55 PM, Recordon, David wrote:
> In the case where there are two realms:
> http://*.livejournal.com
> http://dick.livejournal.com
>
> I would have my IdP treat them as separate relying parties. If the RP
> directly decided to set the realm differently, then I'd imagine the
> a
Dick Hardt wrote:
> What is different with OpenID vs email is that there is certainty
> that the user actually is the user.
>
I'm a little confused. How is there certainty that "the user actually
is the user"? The viability of the identifier representing the same
user is dependent on th
For starters please don't use Comic Sans in professional correspondence. it is very hard to read (or take seriously) http://bancomicsans.com/home.htmlOn Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote: It's more of a problem with how we can accept 3rd party OpenId users at AOL (we as an RP). Ob
On 22-Oct-06, at 10:44 AM, Martin Atkins wrote:
> Dick Hardt wrote:
>>
>> The issue here is that realm is an overloaded parameter. It is being
>> presented to the user for the user to decide if it wants to IdP to
>> provide similar results to any RP return_to that matches the
>> wildcard. It is a
> * Protocol has two distinct identifiers: public and IdP-local.
Relying
> party manages delegation. IdP does not even know that the delegation
has
> taken place and has no way to stop it happening [1]. RP now has to do
> more work, but identifier portability now comes for free.
I'm much more i
[Please pardon me if I am spamming
the spec mailing list with general comments/issues that might have been
discussed before]
It's not the problem of just making AOL users OpenId enabled, so they
can access 3rd party RPs (use http://www.aol.com/ or
http://aimpages.com/ or
http://journals.aol.co
On 22-Oct-06, at 11:44 AM, Praveen Alavilli wrote:
> It's more of a problem with how we can accept 3rd party OpenId
> users at AOL (we as an RP). Obviously for simple use cases like
> leaving comments on blogs it wouldn't really matter as long as the
> user is identified by someone (and someo
On 22-Oct-06, at 12:43 PM, Kaliya Hamlin wrote:
> For starters please don't use Comic Sans in professional
> correspondence. it is very hard to read (or take seriously) http://
> bancomicsans.com/home.html
Kaliya: The easy solution is to have your email program turn all
responses to plain
While I'd certainly agree that a goal is letting anyone setup and IdP
and have it work on any RP, I see that as utopia. The protocol should
certainly support that, as well as not do anything to actively thwart
it. With that said, OpenID as a protocol can be used in cases where
this may not be des
Dick Hardt wrote:
>
> The issue here is that realm is an overloaded parameter. It is being
> presented to the user for the user to decide if it wants to IdP to
> provide similar results to any RP return_to that matches the
> wildcard. It is also being used by the IdP to uniquely identify the
On 19-Oct-06, at 10:24 AM, Martin Atkins wrote:
> Dick Hardt wrote:
>>
>> Agreed that it is desirable to have multiple RP endpoints for an RP.
>> Does openid.realm then uniquely identify an RP? ie. no other RP will
>> use the same Realm?
>>
>
> I'd say that if two endpoints are within the same re
Dick Hardt wrote:
> On 21-Oct-06, at 10:52 PM, Josh Hoyt wrote:
>
>> On 10/21/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
>>> 2) the RP does not verify the binding between the portable
>>> identifier and the IdP-specific identifier in the response.
>>> to the one the attacker controls and
On 20-Oct-06, at 10:14 AM, George Fletcher wrote:
> [Sorry for the strange posting format. I got on the list after
> seeing the emails. --George]
>
> First, I'm new to the list and don't want to resurface an old and
> long debated topic.
>
> To me this proposal is about how to make finding t
On 20-Oct-06, at 12:17 PM, John Panzer wrote:
> Kaliya * wrote on 10/20/2006, 11:57 AM:
>
>> I think it is a terrible idea.
>>
>> 1) If you put something out into the market that looks like an e-
>> mail it will be used like an e-mail. I have personal experience
>> with this.
>>
>> I had a AIM
As much as I like the idea of a single link tag in the HTML, there
are many advantages to having a document.
As noted by others, requiring a browser to read each file as a Yadis
document is a non-starter.
Having a link tag pointing to the Yadis file and having a Yadis file
in a well known p
On 21-Oct-06, at 10:52 PM, Josh Hoyt wrote:
> On 10/21/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
>> 2) the RP does not verify the binding between the portable
>> identifier and the IdP-specific identifier in the response.
>> to the one the attacker controls and the IdP has mapped
>
> Th
29 matches
Mail list logo
