Drummond Reed wrote:
I initially agreed as well. But to play devil's advocate, the link-to-XRDS
option could actually be pretty efficient. Any HTML page could simply
advertise the availability of its Yadis XRDS file using an XRDS link in the
header. Assuming that many or all of the pages on a
smime.p7m
Description: S/MIME encrypted message
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Erm, it seems that my message was blanked, maybe because of my S/MIME
signature? I'll try without, then.
Oh, what a good start :)
Cheers,
Toby
-Ursprüngliche Nachricht-
Von: Baier, Tobias
Gesendet: Freitag, 20. Oktober 2006 10:51
An: specs@openid.net
Betreff: OpenID newbie
Hello
# The thing is they aren't really giving them their email address.
# Rather an identifier which looks like an email address to a user and
# in some cases may also be an email address.
Isn't that likely to create a lot of confusion?
--
Jonathan Daugherty
JanRain, Inc.
Yes, potentially. It is a bit of a hybrid approach I guess.
--David
-Original Message-
From: Jonathan Daugherty [mailto:[EMAIL PROTECTED]
Sent: Friday, October 20, 2006 12:59 PM
To: Recordon, David
Cc: Drummond Reed; specs@openid.net
Subject: Re: [PROPOSAL] Handle http://[EMAIL
[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 the
user's IDP simpler using something the customer is already
It might create some confusion depending on the audience. For the
audience that doesn't run their own web server, or have their own blog,
it might be confusing to enter a URI.
This approach would help those users make the transition without
restricting the users who do get it from entering
# It might create some confusion depending on the audience. For the
# audience that doesn't run their own web server, or have their own
# blog, it might be confusing to enter a URI.
By confusion, I mean entering something that looks like an email but
probably isn't, and trying to figure out just
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 handle for the Mac part of the universe [EMAIL PROTECTED] (it
On 10/20/06, John Panzer [EMAIL PROTECTED] 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 handle
On 10/19/06, Recordon, David [EMAIL PROTECTED] wrote:
The proposal we came up with was within the spec describing what to do
if someone were to enter [EMAIL PROTECTED] in a Relying Party's OpenID
login form.
Here are the past threads that I could find about this issue:
1.
# I'm not actually proposing the IdP make an assertion about
# [EMAIL PROTECTED] It would only be used during the discovery phase
# and then an assertion for a URL be returned.
Ok, I misunderstood. But even in the case where the IdP makes an
assertion about a different identifier, that's
We actually built some code some time ago to explore this. The basic
insight was:
if we can do Yadis discovery on XRIs (which aren't rooted in DNS),
then we can do Yadis discovery on any other kind of identifier,
whether it's an e-mail address or an ISBN number or what have you --
and
Title: Re: [PROPOSAL] Handle [EMAIL PROTECTED] For Discovery Only
I guess I shouldn't have said http://[EMAIL PROTECTED].
All that is being suggested is the following language (on my Treo):
If a string in the format of [EMAIL PROTECTED] at a RP, the RP MUST treat the domain after @ as the
On 10/20/06, Granqvist, Hans [EMAIL PROTECTED] wrote:
I propose renaming the existing OpenID 2.0 work to be OpenID 1.2.
(moved over to the specs list, since it hasn't had enough traffic lately)
I think it'd be great to put what we have out as OpenID 1.2. That way,
the debate and proposals here
Right now we have things like http://openid.net/signon/1.1,
http://openid.net/sreg/1.0, etc. This doesn't really seem to scale,
populating the main http://openid.net namespace.
Could we do something like
http://specs.openid.net/authentication/2.0/signon or
It has had some voices against it, but how about considering
this template (used in for example W3C xmldsig and
xmlenc):
http://openid.net/[year]/[month]/[project]#[type]
Time-dependent (rather than version--dependent) namespaces
can evolve freely and will not be tied down to specific
As requested [1], I have made a patch to the specification [2] that
specifies the two-identifier mechanism for portable identifier
support. It's attached to this message. The net effect is adding one
line to the source XML file.
I hope this proves useful in evaluating the proposal.
Josh
1.
18 matches
Mail list logo
