Hey Lists
We realized in a meeting today that we had talked to some people in
the community, but had never made a formal statement.
Sxip is writing and will be releasing Java and Perl libraries for
OpenID 2.0 under an Apache license.
You should see them shortly after the spec is finished,
I would like to use different IdPs for my vanity URL, blame.ca. In an
OpenID 2.0 world, I can provide either of my IdP URLs to the RP and
then select blame.ca and login.
Does this work? What having two openid.server tags suffice? How would
the RP know which delegate tag goes with which IdP?
In the directed identity case, the IdP URL or XRI you give to the RP
resolves to your IdP's XRDS document. Each of your IdPs would have a
different one. If they support directed identity, each would have a Service
with a Type tag value of http://openid.net/identifier_select/2.0. This
service
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
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
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 solely
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
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 value
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
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: Dick
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?
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
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
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
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
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.
--David
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).
17 matches
Mail list logo
