On 8/31/07, James Henstridge <[EMAIL PROTECTED]> wrote:
>
>
> You still want the user involved in the granting of an authentication
> token though, right? Trying to replace the "UA" in the authentication
> workflow is quite a big change, and limits what the OP can do.
Yes, granting the secret mu
Hans,
Yes, the Client App is expected to implement all the important parts of an
OpenID 2.0 Relying Party. This means it will support XRI, Yadis, and HTML
discovery.
It's unlikely systems will have clashing namespaces, but is possible (most
corporate user accounts don't begin with "=", "@", "+",
Interesting. I like that it's short and technically well written.
So in practice a Client App would need to be able to distinguish the classes
of OpenID identifiers, so it know when to do the OpenID authn call, right?
Does that mean some existing systems may have clashing namespaces (for
instance,
The Inline Authentication Extension attempts to solve the problem of legacy
and interactive applications (Telnet/SSH) that are unable to launch a client
Web Browser to perform an authentication request.
http://extremeswank.com/openid_inline_auth.html
This is done through the use of "verification
