# If running code is the authority, DotNetOpenAuth uses
# preferred_auth_level*_types*.
The openidenabled.com Python implementation of draft 5 uses that,
also.
--
Jonathan Daugherty
___
specs mailing list
specs@openid.net
http://openid.net/mailman
cases (e.g., excessive redirects) there isn't a sane
interop behavior, only a sane fallback behavior. +1 for
_recommending_ a maximum number of redirects in the spec so
implementors have some idea of what is sane. I think any more than 10
is pathological.
--
Jo
> Can somebody confirm that sending pape.max_auth_age is wrong and it should
> be pape.auth_time instead?
Hi Eddy,
The PHP library implements Draft 1 of PAPE, not Draft 2. The same is
true of the other openidenabled.com implementations.
--
Jonathan Dau
quested, the RP is interested in other information
such as the authentication age." I think that is speculative and
should be removed. If it isn't removed, I think it should be
moved to a section discussing the protocol flow more generally.
Thanks,
--
Jonathan Dau
modes of authentication is a
fine idea, but that doesn't really address the original issue: the
spec does not define "active" ("direct") authentication.
--
Jonathan Daugherty
JanRain, Inc.
irc.freenode.net: cygnus in
t it's not necessarily a limit on the type of
authentication it's asking for.)
# On the same topic, I have suggested before and there seemed to be
# agreement[1] that it's more useful if auth_age in the response is
# actually a timestamp (auth_time).
Ah, good point. Th
low after we knock these out. Thanks!
[1]
<http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-01.txt>
--
Jonathan Daugherty
JanRain, Inc.
irc.freenode.net: cygnus in #openid
cygnus.myopenid.com
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
parameter names to underscores, so if you do go this route
you'll need code[1] to fix it. Otherwise I think it's a fine idea. :)
[1] Auth_OpenID::getQuery()
http://openidenabled.com/files/php-openid/repos/2.x.x/Auth/OpenID.php
--
Jonathan Daugherty
JanRain, Inc.
irc.freenode.n
er spec or a
best practices document.
--
Jonathan Daugherty
JanRain, Inc.
irc.freenode.net: cygnus in #openid
cygnus.myopenid.com
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
# Perhaps we should have explicit feature-freezes.
+1
--
Jonathan Daugherty
JanRain, Inc.
irc.freenode.net: cygnus in #openid
cygnus.myopenid.com
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
ECTED]
Thanks,
--
Jonathan Daugherty
JanRain, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
# Looks like the article got Slashdottedthere's some interesting
# commentary going on, with some FUD, plenty of confusion, and some
# acceptance.
Not surprisingly, that describes reader reaction to most Slashdot
content. :)
--
Jonathan Daugherty
JanRain
du' (the URL of their IdP/OP) into the OpenId login
# form.
Then why not just enter 'http://any.edu' or 'any.edu' instead?
--
Jonathan Daugherty
JanRain, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
that look like email addresses would
be misleading.
--
Jonathan Daugherty
JanRain, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
s like one.
So maybe 2.5 times as much confusion. :)
--
Jonathan Daugherty
JanRain, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
hat's confusing, too; you
enter something that looks like an email (and maybe your provider
tells you it even is), but you log into the site as something else,
right?
--
Jonathan Daugherty
JanRain, Inc.
___
specs mailing list
specs@openid.net
http://
rstand this, and that is
going to create a lot of confusion.
--
Jonathan Daugherty
JanRain, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
# The thing is they aren't really giving them their email address.
# Rather an identifier which looks like an email address to a user and
# in some cases may also be an email address.
Isn't that likely to create a lot of confusion?
--
Jonathan Daugherty
Ja
oving
it anyway, though.
--
Jonathan Daugherty
JanRain, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
don't think anyone else disagrees that having a consistent name
would be good for usability. Regardless, this design choice is out of
scope for the OpenID 2.0 authentication spec.
--
Jonathan Daugherty
JanRain, Inc.
___
specs mailing list
specs@
stead. Or create an OpenID Rich Client
specification.
--
Jonathan Daugherty
JanRain, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
esign choice.)
I agree that it would be extremely useful to have a consistent form
field name for just the reasons you cited, and the current spec
reflects that. If the spec is the place one would put preferences,
then they should be RECOMMENDEDs or SHOULDs: not MUSTs.
--
Jonathan Daug
# 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 M
# Although it's easy to dismiss the privacy issue, there *can* be use
# cases under which an end-user may not want to reveal to their IP the
# identifier they present to the RP.
What is an example of such a use case?
--
Jonathan Daugherty
JanRain
24 matches
Mail list logo
