Dick, you are right that there are usability challenges with i-numbers and
XDI.org and the i-broker community is working to address them. Although
persistent identifiers are used everywhere in local systems (directories,
databases, object stores, etc.), and the concept has been around at the
Intern
There have been several long threads in the past about using email addresses
as OpenID identifiers. The conclusion each time has been to avoid it. I
don't remember all the arguments, but among them are:
* Privacy: the last thing many users want to give a website is their email
address.
* Reassigna
Chris, I'm a little slow here, please bear with me. What's the
reasoning for "without accessing other resources"?
I am with you if you said "we can't ask a user agent to first do a
MIME type of XRDS". But what's the difference between adding a new ad-
hoc link tag in the HTML to the Yadis ta
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 site would be covered by
t
I think I'd have to agree. Been thinking about this a lot recently and
the overhead within Yadis seems unreasonable for a browser to perform
against a RP. Technically the RP could not have anything in the HTML
meaning the browser would have to do Yadis on every page view.
I'd be inclined to use
On Oct 19, 2006, at 14:56, Josh Hoyt wrote:
I'm in favor of keeping the OpenID Authentication Protocol
specification as small as possible, with as few restrictions as
possible to get useful behavior.
Fully agree. The genius of HTTP and RSS and mass-market protocols
like them was not in what
Hi Johannes,
No - Yadis is inappropriate because user agents need to be able to
identify an OpenID login page (and endpoint if possible) *without*
accessing other resources.
Kind Regards,
Chris Drake
Friday, October 20, 2006, 10:33:40 AM, you wrote:
JE> Isn't this a case where the Yadis infras
In this case the link tag just points to the RP's OpenID login page, which
enables a browser to have a button that initiates OpenID login at the site
(provided you've been there before).
However the RP could have its own Yadis XRDS file, and the link tag could
point to that to discover this same i
Back at the dawn of the Web I made the mistake of thinking that the address bar
was the place you type a URI.
We now know that it is the place you type a search term that may be a URL in
canonical form or may be a domain name or may be a search term to be thrown at
a search engine. It was one o
In meeting with a large service provider this week, an issue around end
user usability came up. The concern they expressed was that users are
know how to enter usernames or email addresses to initiate the login
process. While directed identity allows the user to enter
"example.com", they feel tha
Isn't this a case where the Yadis infrastructure should be used
instead of Yet Another Link Tag?
On Oct 19, 2006, at 8:21, Drummond Reed wrote:
Martin, I agree with Dick, this is a fascinating idea. P3P had the
same idea
notion for a site advertising the location of the P3P privacy
policy
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> If you want that to happen, then you have to spec out that the RP is
> verifying the IdP-specific identifier and portable identifier binding
> when it receives it. That is not in the current proposal.
If that is not in there, then the proposal *
On 19-Oct-06, at 11:18 AM, Josh Hoyt wrote:
> On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
>> reread the attack. The portable identifier and the IdP do
>> match.
>
> In fact, this makes me think of an attack that *would* succeed if the
> IdP-specific identifer was not in the response:
>
Recordon, David wrote:
Combining this with the fact that there is no viable way to enforce
sections 8.1 or A.4 being MUSTs, I do not believe that they should be
changed from SHOULDs. The only conceivable way I could see of enforcing
something like this is telling a Relying Party that they cannot
On 10/19/06, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
> I think it's there for convenience because no practices document
> existed when that was inserted. I think Josh was considering removing
> it anyway, though.
I'm in favor of keeping the OpenID Authentication Protocol
specification as sm
Yes, section 8.1 is legacy from OpenID Auth 1.x as no best practices
document existed at the time, nor does one exist today separate from the
spec. If one did exist, I'd imagine that sections 8.1 and A.4 would
reference it saying Relying Parties SHOULD follow it.
Looking at ftp://ftp.isi.edu/in-n
# A procedural point: If it is out of scope why is 8.1, and in
# particular that line, in the spec? I submit that it evidently _is_
# in scope since it is there.
I think it's there for convenience because no practices document
existed when that was inserted. I think Josh was considering removing
Jonathan Daugherty wrote:
# This is true only if you never consider use cases for your protocol
# which cover usability. That would be unwise. I don't think I know of
# a protocol that was developed without regard to how it would be
# used.
I have said before that the form element name proposal
# This is true only if you never consider use cases for your protocol
# which cover usability. That would be unwise. I don't think I know of
# a protocol that was developed without regard to how it would be
# used.
I have said before that the form element name proposal is a good one,
and I don't t
Jonathan Daugherty wrote:
# we already know that browser-chrome plugins will be supporting
# OpenID - as soon as an RP picks some other field name, he'll get a
# flood of complains from users who can't log in to his site.
And that has nothing to do with the *protocol*. Put it in a Best
Practice
On 10/19/06, Josh Hoyt <[EMAIL PROTECTED]> wrote:
> when she has control
Sorry that I didn't put this all in one message, but:
I think it's worthwhile to be aware of what might happen in scenarios
where your identifier has been stolen, but it should not have much
bearing on which proposal gets ac
Martin Atkins wrote:
Granqvist, Hans wrote:
Why not simply call the idp "idp", and prefix it "OpenID idp"
if context or clarification is needed, all referencing an
OpenID spec def of "OpenID idp"?
While I guess I agree with your objection, I don't like the redundant
"ID" in "OpenID
On 19-Oct-06, at 10:23 AM, Josh Hoyt wrote:
> On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
>> I like your proposal. I would tweak the name:
>>
>> http://my.rp.com/openid/blah.cgi";>
>
> This is what Yadis was designed for. Since OpenID already requires
> Yadis, this should be implemented as
Andy,
I think it is incredibly useful in showing the technology
needed to help protect users with systems like this. I'd love to see it as
part of the Heraldry project, you are already a committer, assuming you'd
be willing to contribute it.
--David
From: [EMAIL PROTECTED]
[mailto:[EMAI
I'd be interested to hear if people
think the ph-off plugin is useful or not If not why not?
If people think it's useful then I will
happily extend it and make it more usable and I will put it into whatever
open source project would like to house it.
I built it as a proof of concept that
i
Dick Hardt wrote:
> Motivating Use Case
>
> The IdP would like to allow the user to click a link on the IdP to
> login to an RP. This requires a bare response to be able to be sent.
> A Trusted Party, acting as an RP would like to store a value at the
> IdP, but doe
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> reread the attack. The portable identifier and the IdP do match.
In fact, this makes me think of an attack that *would* succeed if the
IdP-specific identifer was not in the response:
when she has control, she initiates a log-in, but traps the
On 19-Oct-06, at 10:40 AM, Josh Hoyt wrote:
> On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
>> My head is a little moreclear this morning, so let me clarify.
>>
>> My key point is that the IdP cannot trust the discovery done by the
>> RP since what the request is unsigned and may have been m
Which is still described in the latest draft, see
http://openid.net/specs/openid-authentication-2_0-10.html#anchor42.
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Thursday, October 19, 2006 1:24 PM
To: Dick Hardt
Cc: specs@open
Granqvist, Hans wrote:
>
> Why not simply call the idp "idp", and prefix it "OpenID idp"
> if context or clarification is needed, all referencing an
> OpenID spec def of "OpenID idp"?
>
While I guess I agree with your objection, I don't like the redundant
"ID" in "OpenID IdP". It makes it awk
Drummond Reed wrote:
> Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea
> notion for a site advertising the location of the P3P privacy policy: it
> defined a standard HTML/XHTML link tag that could be put on any page of a
> site that told the browser where to locate the
Dick Hardt wrote:
>
> Bob has the i-name =foo. Alice has =foo reassigned to her. Bob does
> not know this. Bob goes to an RP, enters =foo and gets sent somewhere
> he cannot authenticate since =foo resolves somewhere else.
>
> Bob does not know what to do. =foo does not resolve to his i-numbe
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> Just to clarify then, you would suggest that the RP include a meta
> tag with a reference to the RPs Yadis document?
Any URL that wants to have a login URL associated with it can use
whichever of the mechanisms provided by Yadis to point to a Ya
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> My head is a little moreclear this morning, so let me clarify.
>
> My key point is that the IdP cannot trust the discovery done by the
> RP since what the request is unsigned and may have been modified
> between the RP and the IdP.
The IdP shoul
Dick Hardt wrote:
My key point is that the IdP cannot trust the discovery done by the
RP since what the request is unsigned and may have been modified
between the RP and the IdP.
Yep. Though trusting RPs for _anything_ is a bad idea. Users necessarily
need to trust IdP's, the IdP's should
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> > Your attack fails.
>
> reread the attack. The portable identifier and the IdP do match.
No the identifiers do not.
It did at one time, but not at the time that the attack takes place.
While she has control of your blog, she has control of yo
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> I like your proposal. I would tweak the name:
>
> http://my.rp.com/openid/blah.cgi";>
This is what Yadis was designed for. Since OpenID already requires
Yadis, this should be implemented as a Service entry in the Yadis
document for any page on w
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 realm that they are by
definition part of the same RP.
On 19-Oct-06, at 9:55 AM, Granqvist, Hans wrote:
> -1
>
> "OpenID provider" is too vague and makes little sense. What
> is provided? OpenID? How do you provide a specification?
The OpenID. The thing that iwantmyopenid.com is working to give the
user!
If you have a different, generic name fo
Does anyone NOT want to support these scenarios?
On 19-Oct-06, at 8:40 AM, Drummond Reed wrote:
> I agree the scenarios Dick proposes here make sense. However if the
> IdP can
> change an identifier parameter, it should be openid.portable,
> since: a)
> that's the one the RP is going to store
My head is a little moreclear this morning, so let me clarify.
My key point is that the IdP cannot trust the discovery done by the
RP since what the request is unsigned and may have been modified
between the RP and the IdP.
I was showing a potential attack vector where even though I think I
# we already know that browser-chrome plugins will be supporting
# OpenID - as soon as an RP picks some other field name, he'll get a
# flood of complains from users who can't log in to his site.
And that has nothing to do with the *protocol*. Put it in a Best
Practices document instead. Or crea
Hey Chris,
I like your proposal. I would tweak the name:
http://my.rp.com/openid/blah.cgi";>
Perhaps you can write it up and put a link on David's proposal wiki at:
http://www.lifewiki.net/openid/OpenIDProposals
I think I chewed through my proposal quota a while ago. ;-)
-- Dick
On 1
-1
"OpenID provider" is too vague and makes little sense. What
is provided? OpenID? How do you provide a specification?
Or...
If I am a browser with built in OpenID 2.0 authn support,
am I then not 'providing OpenID' to the user, so in effect
I am too an "OpenID provider", but now as a client
Hi David,
Besides other DIX lurkers, we know for sure that Dick, Andy, and
myself are all building "chrome" extensions and/or rich-clients, so I
think you'll have no problems getting a "consensus" on this.
My personal vote is for something like this:-
http://my.rp.com/openid/blah.cgi";>
either
Hi Jonathan,
I vote for MUST.
The opinion of unenforcability isn't a justification for SHOULD, and I
disagree with that opinion anyhow: we already know that browser-chrome
plugins will be supporting OpenID - as soon as an RP picks some other
field name, he'll get a flood of complains from users w
On 19-Oct-06, at 8:40 AM, Drummond Reed wrote:
> I agree the scenarios Dick proposes here make sense. However if the
> IdP can
> change an identifier parameter, it should be openid.portable,
> since: a)
> that's the one the RP is going to store, and b) that's the one the
> IdP MUST
> return
That provides clarity on the process, thanks. If the user knows that
their i-name has been changed,
then when you write here:
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
Summary of Motivations:
...
4. Enable RPs to take advantage of XRI Canonica
I agree the scenarios Dick proposes here make sense. However if the IdP can
change an identifier parameter, it should be openid.portable, since: a)
that's the one the RP is going to store, and b) that's the one the IdP MUST
return with a different value anyway in the directed identity use case (cas
I don't have time this second to go into more detail, but a quick high-level
observation about Dick's Cached Discovery Attack: if your blog (or the
target page of any portable OpenID identifier) can be hacked, you've already
lost your identity. All the hacker has to do is point the link tag at thei
Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea
notion for a site advertising the location of the P3P privacy policy: it
defined a standard HTML/XHTML link tag that could be put on any page of a
site that told the browser where to locate the P3P policy document for the
Exactly. An i-name being reassigned is very similar to a domain name being
reassigned -- the previous owner is going to know they no longer own it.
For example, if you register blame.ca, you're going to receive multiple
notices from your DNS registrar that you need to renew it, and if you don't,
y
Hi Prasanta,
That section shows as an example how to encode the two keys, mode and
error, in both Key-Value Form encoding as well as x-www-urlencoded
encoding as POST and GET arguments. Thus when Key-Value encoding you
delimit between keys and values with a colon, though in url encoding you
use an
Hi Chris,
It seems Dick marked it as deprecated when he made a new proposal
(http://openid.net/pipermail/specs/2006-October/000430.html).
I'd love to see the OpenIDHTTPAuth proposal standardized. I think it
would enable a lot of interesting things. Want to lead that with Mart?
I'm happy to help
I SVN blame Carl and Josh. :P
379 23 9/28/2006 7:33:55 PM j3h
A server receiving a properly formed request MUST send a
380 23 9/28/2006 7:33:55 PM j3h
response with an HTTP status code of 200.
381 89/5/2006 4:33:52 PM chowells
382 8
How would Alice buy =foo when Bob already owns it?
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Thursday, October 19, 2006 3:58 AM
To: Martin Atkins
Cc: specs@openid.net
Subject: Re: XRI confusion
On 19-Oct-06, at 12:44 AM,
On 19-Oct-06, at 12:44 AM, Martin Atkins wrote:
> Dick Hardt wrote:
>>
>> How would a user ever learn what their CanonicalID is?
>
> The user doesn't need to know his i-number. The system discovers that
> for him.
>
>> If there Portable Identifier (i-name) is reassigned, then they will
>> be sent
On 19-Oct-06, at 12:35 AM, Martin Atkins wrote:
> Dick Hardt wrote:
>>
>> In order for the RUA to detect that a site supports OpenID, it sees a
>> form with a single input with a "name" of openid_identiifier. The RUA
>> can then look at the action and post the data directly to the RP.
>>
>
> I th
On 19-Oct-06, at 12:29 AM, Martin Atkins wrote:
> Dick Hardt wrote:
>>
>> The IdP needs a unique identifier for the RP.
>> openid.realm is a wild card that could match multiple RPs.
>
> This was by design. An RP that is exposing multiple "RP endpoints"
> within the same realm is explicitly saying
Dick Hardt wrote:
>
> Rename Identity Provider to OpenID Provider in the spec
>
+1
Agreed.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Dick Hardt wrote:
>
> How would a user ever learn what their CanonicalID is?
The user doesn't need to know his i-number. The system discovers that
for him.
> If there Portable Identifier (i-name) is reassigned, then they will
> be sent to an IdP for the new Canonical ID is, expecting credenti
Dick Hardt wrote:
>
> In order for the RUA to detect that a site supports OpenID, it sees a
> form with a single input with a "name" of openid_identiifier. The RUA
> can then look at the action and post the data directly to the RP.
>
I think it'd be better to implement this as either a META
Dick Hardt wrote:
>
> The IdP needs a unique identifier for the RP.
> openid.realm is a wild card that could match multiple RPs.
This was by design. An RP that is exposing multiple "RP endpoints"
within the same realm is explicitly saying that it needs/wants them all
to be treated the same.
# Why SHOULD rather then MUST? [1]
#
# What valid reason is there for an RP to not have that field name?
The simple reason is that one can't enforce a MUST in this case. (And
even if one ammends the spec to make the field name a prerequisite for
OpenID, I question whether that is a good design c
Dick Hardt wrote:
> Forgive my lack of Yadis configuration expertise, but is this
> something that your average blogger can add to their WP or MT blog?
>
As long as the user's IdP is explicitly setting openid:Delegate in their
Yadis document, they should simply be able to point their
X-Yadis-
I expect I will have a number of OpenIDs, as well as lots of directed
identities. I would like my IdP to keep track of which identity I use
at what RP. I may forget which public identifier I used at a site,
and type in the wrong one, and end up creating a new account and be
confused. I may
After reading though:
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
I have concluded there is no caching advantage
Specifically if you look at these two sections:
RP Rules for Identifier Parameters
Case 3: URL WITH IdP-Specific Identifier
If Portable Identifier is a
67 matches
Mail list logo
