What you are calling discovery is what I would term location.
URL - Uniform Resource Locator
The locator is completely self contained, no discovery necessary, all the
information you need to resolve is there.
> -Original Message-
> From: Dick Hardt [mailto:[EMAIL PROTECTED]
> Sent: Th
I agree with Johannes here. DNS is not user accessible (for good reason)
Documents on a web server are relatively more accessible.
wrt. DNS, I think DNSSEC could have a significant role in providing
server to server discovery, specifically of key key material.
-- Dick
On 8-Nov-06, at 8:00 PM,
So I spent tonight running through the spec with Brad Fitzpatrick.
Checked in the changes as revision 97, though mainly wording changes.
Few open issues:
1) 9.1 in the openid.ns parameter talks about using this value in
regards to compare with a lower version number of the protocol. Looking
at t
Hey Dick,
Couldn't one make the opposite argument -- that most people's email address
NOT working when they plug it into the OpenId login field could actually be
a good thing? (especially in the beginning of OpenID)
I say this because such scenarios (user enters email, and RP fails because
the em
Just commenting on the XRDS discovery from HTTP URLs bit.
Using DNS as a mechanism, given a URL, to discover the location of,
or obtain the content or equivalent of, the XRDS file, was proposed
back then in Yadis 0.x days, and rejected. The reason being that any
such mechanism would require
Hi Drummond,
If what we're trying to express is merely that an OpenID can provide an
authentication assertion, then I agree that "authentication authority"
is quite appropriate.
I would note that in SAML at least (as I understand it - correct me if
I'm wrong Eve!), an authentication authority is
Quite a few years went into the design of DNS.
The concern I have here is that to influence the wider network is a very
serious challenge.
Innovation in naming is the single hardest thing to do in a network protocol. I
have seen UDDI, Realnames, X.500, so many proposals.
When someone tells me
>-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Peter Watkins
Sent: Wednesday, November 08, 2006 4:21 PM
To: [EMAIL PROTECTED]
Cc: specs@openid.net
Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
>
>Recordon, David wrote:
>> In
Phillip,
Please don't shoot me -- I am just the messenger -- but a year-long effort
(Yadis) went into the design and deployment of XRDS documents as the
discovery infrastructure for OpenID.
There are numerous reasons for this, but they boil down to this: the XRDS
layer of identity is rooted at a
Recordon, David wrote:
> Involving DNS seems to make this too complex. If we're going to involve
> DNS, we might as well re-architect Yadis to use it as yet another
> discovery option.
Yes, the TXT proposal seems complex. I prefer Phillip's second
suggestion, but I think something more unique wou
Many sites allow users to register for services using an e-mail
address. Often such sites require the user to verify ownership of the
e-mail address by sending an e-mail to the just registered address, but
not always. When a site allows such a registration they also request
the user to create
You can make things complex in two ways, one is by adding too many
curlicues to a design, another is by refusing to use the deployed
infrastructure for its intended purpose.
The signaling and discovery infrastructure of the Internet is the DNS.
I have seen so many attempts to reinvent it.
>
Hi David
A Homesite is a new concept for users, so when they see a prompt for
it, they will know they have one or not. They are not just typing in
a random URL.
Pretty much every user has an email address, so a prompt asking for
an email would suggest to user that their email will work -- w
Involving DNS seems to make this too complex. If we're going to involve
DNS, we might as well re-architect Yadis to use it as yet another
discovery option.
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, No
Please don't map to Http this way.
It would be fine to define a fixed mapping from a user identifier to http. But
it has to respect the http scheme design and be crafted to avoid operability
concerns.
http://example.com/user would be acceptable as meeting the scheme design. It is
absolutely cr
I wonder if it would help our discussion to clarify what is meant when we
say that an email address is an "identifier".
While an email address does technically identify SOMETHING, here I'm using
it more as a "mapping".
So, the way I'm conceiving of things is that the email is in fact a REAL
ema
Hi Philip,
I'm not sure I understand "Please don't use HTTP this way".
I was suggesting that the user enter an email address. The RP then maps the
email address to a URL (which would be in the proper scheme).
> -Original Message-
> From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED
Dick,
It seems like the same problem exists if a user types an IdP URL. If that
URL (e.g., example.com) isn't a valid OpenId IdP, then the user will still
encounter a problem.
Shouldn't the RP show an "educational page" if a
Homesite/i-name/OpenId/email doesn't resolve to something that OpenID c
Please don't use HTTP this way. That is not the semantics for http URLs.
A better scheme would be to use mailto:[EMAIL PROTECTED] or to define
openid:[EMAIL PROTECTED]
There are two issues here:
1) The user presentation of the identifier
2) The machine presentation
The two do not need to be t
# So, if in a hypothetical world where we have 4 potential OpenId
# "values" that a user could enter, AND the goal is to reduce
# confusion, then does it really make sense to cut out the most common
# "value" (which is an email address)?
IMHO, because using identifiers that look like email address
I agree. In fact, given that most people don't know what an XRI is, we
might say there will be 3.5 times as much confusion.
;)
So, if in a hypothetical world where we have 4 potential OpenId "values"
that a user could enter, AND the goal is to reduce confusion, then does it
really make sense t
Please see my questions/ideas enclosed...
Thanks!
David Fuelling
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Drummond Reed
> Sent: Friday, October 20, 2006 1:04 AM
> To: 'Recordon, David'; specs@openid.net
> Subject: RE: [PROPOSAL] Handle "http
# SIDE NOTE: For those who argue against email addresses in the OpenId
# login form on the grounds of confusion, these 2 email proposals
# should be no less "confusing" than trying to educate a user that the
# Identity URL they type in (e.g., http://aol.com) is not their
# identity. Both will/woul
Hi All,
Sorry to re-open this can of worms, but I'm just getting a chance to chime
in. I actually think David Recordan's idea re: email address to URL
resolution would be a great idea!
My vote would also be to allow an Email address to map to an Identity
Provider URL. NOTE: The email ad
Just to be clear, "identity provider" in SAML isn't intended to mean
that this system entity is providing an identity to a digital
subject -- it means that this system entity is providing identity
information (specifically verification/authentication info) to a
relying party/service provider.
that's correct - you can use
an auto submit form with GET or use _javascript_
(document.location.replace) or META redirect tag to make the browser do
a GET. We are doing this for a very very long time too - mainly the
_javascript_ method as it helps in restoring the back button
functionality (b
On 7-Nov-06, at 12:34 PM, Recordon, David wrote:
> Moving this to the list, I really should have started it there in the
> first place.
>
> --David
>
> -Original Message-
> From: Recordon, David
> Sent: Monday, November 06, 2006 2:06 PM
> To: 'Dick Hardt'; Josh Hoyt
> Subject: RE: IdP's A
27 matches
Mail list logo
