On 10/18/06, Recordon, David <[EMAIL PROTECTED]> wrote:
> Yeah, the XML file can be based elsewhere.
It is especially noteworthy that unless users are combining services,
the XRDS document can be the same one that the IdP has issued to go
with the IdP-specific URL.
For instance, if I want to use
Hey Drummond
In reviewing:
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
...
Summary of Motivations
4. Enable RPs to take advantage of XRI CanonicalDs to protect End-
Users from ever having their Portable Identifier reassigned (and thus
their identity taken over).
On 18-Oct-06, at 10:33 PM, Recordon, David wrote:
> This isn't worth me standing in the way. If you can get general
> consensus of those actively participating in the spec process then I
> won't stand in the way of the community, in fact if this happens
> I'd be
> happy to make the change to t
This isn't worth me standing in the way. If you can get general
consensus of those actively participating in the spec process then I
won't stand in the way of the community, in fact if this happens I'd be
happy to make the change to the spec.
There seems to be other ways to deal with this though,
I agree with Josh's reasoning
(http://openid.net/pipermail/specs/2006-October/000503.html). So
willing to change it, I would've added "meaning changed from OpenID Auth
1.1" as one of your pros, but also don't see it as being something
critical. If people come up with a term that is liked, I'm hap
Well, not quite let it rest. :-)
There was no comment on the "action" in the form for check_immediate.
Is that ok to go in the spec if it is a SHOULD?
-- Dick
On 18-Oct-06, at 10:04 PM, Dick Hardt wrote:
> Unfortunate that was not captured in the notes. When I said that we
> needed tags to de
(writing this up so that it can go in David's proposal wiki :-)
Motivation:
* Liberty specifications use the term Identity Provider (IdP) to
refer to a site that provides any kind of identity assertion about
the user, and this term has come to have that general meaning in the
market. Since
Unfortunate that was not captured in the notes. When I said that we
needed tags to detect, there was consensus that was not a problem.
We are building a rich client. It will be available in the not-too-
distant-future.
We are working on what it will take to implement, and have figured
out ho
Here are notes from the June meeting, which we all looked over before I
sent them out. All I see in relation to rich clients is that DIX
supported them, though I don't remember any decision being made that a
requirement of OpenID Authentication was every relying party enabling
the use of a rich cl
Thanks!
On 18-Oct-06, at 9:38 PM, Recordon, David wrote:
> Sorry, pointer to Josh's email?
>
> Yeah, the XML file can be based elsewhere. Might be worth a quick
> skim
> of the Yadis spec (http://yadis.org/papers/yadis-v1.0.pdf) Only three
> pages, section six, which talks about this.
>
> --D
That is news to me that supporting Rich Clients is not a requirement.
Rich client support was a discussion point back in July at the
meeting in VeriSign, and there was consensus to support Rich Clients
then
Would you point me to the list of requirements so that we can all get
on the same p
Sorry, pointer to Josh's email?
Yeah, the XML file can be based elsewhere. Might be worth a quick skim
of the Yadis spec (http://yadis.org/papers/yadis-v1.0.pdf) Only three
pages, section six, which talks about this.
--David
-Original Message-
From: Dick Hardt [mailto:[EMAIL PROTECTED
The spec is an authentication spec which does not discuss rich clients
anywhere.
As I've said, and I'd think others would agree, it is not a requirement
of the spec to enable rich clients. It is great to have them and great
for it to enable them. Whether the spec says this is a MUST or not
you'l
Agreed that it is a power user that wants multiple IdPs, but per
Josh's email. someone can't use OpenID 2.0 unless they do this. I
think that is a very common use case.
Can the meta-tag point to an XML file on another site? (sorry for
being lazy and not figuring it out myself)
(multiple IdP
Please see the RFC. SHOULD is used if there is a valid reason for it
not being a MUST.
If the RP does not have the tag, the a rich client will not work.
Authentication cannot proceed. That is broken as far as the user is
concerned.
What if doing HTML disco was a SHOULD instead of a MUST? Th
Upload an XML file and add a meta-tag which points to it...
Somehow I doubt that someone who can't do that will really be interested
in the use case you described. In any case, it is surprising what
people can do when following "Internet tutorials".
--David
-Original Message-
From: Dic
Forgive my lack of Yadis configuration expertise, but is this
something that your average blogger can add to their WP or MT blog?
-- Dick
On 18-Oct-06, at 7:28 AM, Recordon, David wrote:
> At that point then I'd argue that the feature shouldn't be supported;
> Yadis was developed to handle use
In my view, it is because the authentication protocol can proceed with
no problems if this field is named something different. As things won't
break, as far as the protocol is concerned, this would also be nearly
impossible to enforce or justify. It is easy to tell a developer to fix
how they're
We are the counter-example at NetMesh. The field names in our code
precede OpenID and its conventions, and we would like to keep the
names of our fields without running afoul of the OpenID spec.
Granted, it wouldn't be terrible if we had to change the name of our
fields, but then, I think t
Why SHOULD rather then MUST? [1]
What valid reason is there for an RP to not have that field name?
[1] http://www.ietf.org/rfc/rfc2119.txt
-- Dick
On 18-Oct-06, at 1:28 PM, Recordon, David wrote:
> Agreed, just like the spec already says "The form field's "name"
> attribute SHOULD have the val
Hi Scott,
All solutions for client-based MITM and phishing prevention can easily
be built on top of OpenID 2.0 if we adopt the OpenIDHTTPAuth proposal.
We can then leave these people to build their tools and protection
howsoever they like, safe in the knowledge that when it's *done*,
there will b
Hi Guys,
Please remember to make your Perl code run in "taint" mode; If you're
having problems or not sure what that is - I'm happy to help out.
Kind Regards,
Chris Drake
Thursday, October 19, 2006, 12:34:35 AM, you wrote:
RD> Dick,
RD> Good news, but I guess I already knew about this. :P
RD
On 10/18/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> Thanks Drummond, but what if I am using HTML-based discovery? (that
> is what I am going to use in my vanity domain, much easier to implement)
>
> http://openid.net/specs/openid-authentication-2_0-10.html#html_disco
HTML discovery is in there so
Agreed, just like the spec already says "The form field's "name"
attribute SHOULD have the value "openid_identifier" as to allow User
Agents to automatically prefill the End User's Identifier when visiting
a Relying Party."
I'm all for this feature, as well as even identifying the form itself,
tho
Agreed, it is currently worded "The form field's "name" attribute SHOULD
have the value "openid_identifier" as to allow User Agents to
automatically prefill the End User's Identifier when visiting a Relying
Party.". A RP not doing this does not break the protocol itself.
--David
-Original Me
# Proposal
#
# Modify 8.1 to:
# ...
#
# The form field's "name" attribute MUST have the value
# "openid_identifier" as to allow User Agents to automatically prefill
# the End User's Identifier when visiting a Relying Party.
This should be a SHOULD, not a MUST.
--
Jonathan Daugherty
JanRain
I was reviewing draft 10 to make sure our implementation complies
with all MUSTs, and I believe I've spotted an issue with the wording
in sections 5.1.2.1 and 5.1.2.2, specifically:
"5.1.2.1. Successful Responses
A server receiving a properly formed request MUST send a response
with an HTT
I'm having trouble envisioning a situation where realm is an insufficient key
for authentication purposes. If this isn't for authentication purposes, it
absolutely needs to live in an extension. IMO.
-mike
On Wed, 18 Oct 2006 00:06:42 -0700
Dick Hardt <[EMAIL PROTECTED]> wrote:
> Motivati
I think this will fall down when the RP tries to validate the authentication
response. From the 2.0-10 spec, section 8.3.3:
A tag MUST be included with attributes "rel" set to "openid.server", and
"href" set to an IdP Endpoint URL
which you would have to torture hideously to interpret as per
Keeping track of requirements does not imply a waterfall model to
development, in my experience. It does imply being conscious of not
adding requirements towards the end of the intended process unless
absolutely necessary. It is that second item that I'm advocating.
As the traffic on the li
On Oct 17, 2006, at 15:16, Recordon, David wrote:
As I said back in September, I'm only tracking proposals listed on the
wiki page. :)
We have a process, yea!
More power to the guy who gave us a process!!!
Let's drive it to a conclusion, shall we? ;-)
Cheers,
Johannes.
Johannes Ernst
Ne
Dick,
Good news, but I guess I already knew about this. :P
Will Sxip be contributing these libraries to the Heraldry project
(http://incubator.apache.org/projects/heraldry.html) like JanRain has
already done with their 1.1 libraries, intends to do with their 2.0
libraries, and VeriSign has done wi
At that point then I'd argue that the feature shouldn't be supported;
Yadis was developed to handle use cases like this. While HTML-based
Discovery is certainly easier, I'm happy not adding to it beyond what
was in 1.1 and telling people to use Yadis when they need something more
complex. I think
Thanks Drummond, I think that clarifies where we are for me
somewhat ... I have some thoughts on how we might move forward on
bringing those world views inline that I will share tomorrow.
Having looked over my recent posts, I am clearly not writing crisp,
clear text at this point this evenin
Thanks Drummond, but what if I am using HTML-based discovery? (that
is what I am going to use in my vanity domain, much easier to implement)
http://openid.net/specs/openid-authentication-2_0-10.html#html_disco
-- Dick
On 17-Oct-06, at 11:46 PM, Drummond Reed wrote:
> In the directed identity
btw: this came up as we were working to implement an IdP ... so it is
a real requirement, happy to learn how others dealt with this and if
there is a different way to resolve
On 18-Oct-06, at 12:06 AM, Dick Hardt wrote:
> Motivating use cases:
>
> 1) The IdP would like to remember what the us
Motivating Use Case:
Rich User Agents (RUA) can enhance the OpenID user experience. RUAs
are either browser that have been extended, or that have an extension
that supports OpenID.
In order for the RUA to detect that a site supports OpenID, it sees a
form with a single input with a "name" o
Motivating use cases:
1) The IdP would like to remember what the user has said a given RP
can and can't do. The IdP needs a unique identifier for the RP.
openid.realm is a wild card that could match multiple RPs.
openid.return_to is a URL that has no guarantee is being used again
by the sa
I don't think anything is missing from your previous posts, nor do I think
you've missed anything from other's previous posts. I think we've discussed
this issue thoroughly from all sides.
As you say, "It is a different way of thinking about what OpenID is doing".
In other words, it's a worldview
39 matches
Mail list logo
