Claus Färber wrote:
Marius Scurtescu schrieb:
The new attribute values are needed in order to signal an OpenID 2
provider.
Why is this necessary? Is OpenID 2 incompatible? In other words, what
happens if an OpenID 2 Relying Party tries to talk to an OpenID 1.x
Provider?
If the
Marius Scurtescu schrieb:
The new attribute values are needed in order to signal an OpenID 2
provider.
Why is this necessary? Is OpenID 2 incompatible? In other words, what
happens if an OpenID 2 Relying Party tries to talk to an OpenID 1.x
Provider?
If the OpenID 1.x Provider just ignores
+1 for leaving our XRI and Yadis.
Claus Färber wrote:
Josh Hoyt schrieb:
On 5/17/07, Dmitry Shechtman [EMAIL PROTECTED] wrote:
There has been a simplification suggestion floating around since long ago:
resolve i-names via http[s]://xri.net/.
-1. If XRI is to be included, it should be done
As a relative newcomer to the OpenID community, I realize this may have
been debated endlessly already, and I may just be shouted down.
It definitely has been debated endlessly.
Or am I alone here?
No, you aren't. There are many who agree with this entirely, some of whom
have expressed their
On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote:
7.3.3. HTML-Based Discovery
A LINK tag MUST be included with attributes rel set to
openid2.provider
and href set to an OP Endpoint URL
A LINK tag MAY be included with attributes rel set to
openid2.local_id
and href set to the end
On 5/18/07, Marius Scurtescu [EMAIL PROTECTED] wrote:
On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote:
In order to be backwards compatible the HTML page should have two
sets of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing
to the same OP endpoint URL. Otherwise an OpenID 1.1
On 18-May-07, at 11:45 AM, Josh Hoyt wrote:
On 5/18/07, Marius Scurtescu [EMAIL PROTECTED] wrote:
On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote:
In order to be backwards compatible the HTML page should have two
sets of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing
to the
On 5/18/07, Dmitry Shechtman [EMAIL PROTECTED] wrote:
I'm sure that this will break a few implementations
It certainly will break PHP-OpenID.
Which implementation are you referring to as PHP-OpenID?
Josh
___
specs mailing list
specs@openid.net
I think this argument is bogus. There is hardly any additional
complexity aside from XRI and Yadis. I'm willing to entertain
suggestions for simplifying the handling of those discovery
mechanisms. The specification is significantly *longer*, but that's
primarily because it's much more
There is a proposed solution that we had consensus on (Dick's
fragment proposal.)
Would you please specify whom you are referring to by we? I understand
that various matters are being discussed outside of this list, but shouldn't
the whole community be part of the decisions made?
I didn't hear
On 5/17/07, Alaric Dailey [EMAIL PROTECTED] wrote:
There are 2 issues that I would like to see addressed.
1. Forcing Encryption, to protect users data en-route.
2. Validated assertions, validating certain bits of data with a third party.
I know both of these have come up before, but have
outstanding issues with the OpenID 2.0
Authenticationspecification
On 5/17/07, Alaric Dailey [EMAIL PROTECTED] wrote:
There are 2 issues that I would like to see addressed.
1. Forcing Encryption, to protect users data en-route.
2. Validated assertions, validating certain bits of data with a third
On 5/17/07, Alaric Dailey [EMAIL PROTECTED] wrote:
I hate to be a PITA but these issues were brought up a while ago by Eddy
Nigg and Myself.
I understand, but at that time, as now, I was trying to get the spec
to be finished. We've been in something of an informal feature-freeze
for a while.
13 matches
Mail list logo