Haven't fully caught up on the thread, so replying to the initial
message, but we're contradicting ourselves since section 15.2 says the
following:
<section title="User Agents">
<t>
Since this protocol is intended to be used interactively,
User Agents will primarily be common Web browsers. Web
browsers or their hosts may be infected with spyware or
other malware, which limits the strength of the
authentication assertion, since untrusted software makes it
impossible to know whether the authentication decision has
been made with the End User's approval. With that said, many
web applications and protocols today rely on the security of
the Web browser and their hosts.
</t>
<t>
Cross-site-scripting attacks against OPs may be used to the
same effect. For the best security, OPs should not depend
on scripting. This enables User Agents that do not support
scripting, or have scripting disabled, to still employ the
protocol.
</t>
</section>
--David
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Adam Nelson
Sent: Sunday, November 12, 2006 5:25 PM
To: [email protected]
Subject: OpenID Auth 2.0 and user-agent neutrality (or, OpenID with
REST/SOAP)
I've been tracking OpenID auth from 1.0 with great interest. Last
summer Johannes Ernst explained to me how it was that one might use
openid to authenticate a non-interactive user agent such as a REST API
consumer by intercepting the RP's redirect and providing the info from
the IdP itself. Given OpenID's design goals (decentralized,
lightweight, flexible identity management), and its seemingly inevitable
adoption into the mashup-minded web 2.0 ecosystem (God help me I'm
buzzwording!), it seems to me that OpenID's value is significantly
enhanced if the identities it enables can be used to authenticate to
SOAP and REST APIs as well as interactive web sites.
Having said that, I was surprised to note in draft 10 of OpenID Auth 2.0
that the HTTP redirect method of communication between the RP and the
IdP is deprecated in favor of an HTML forms-based approach. This
suggests to me that OpenID Auth 2.0 is not compatible with REST or SOAP
or any other binding that doesn't involve the exchange, parsing, and
submission of HTML forms.
I'm curious why this decision was made, and if its implications have
been fully considered. Has there been any thought given to an
alternative means of authentication, perhaps via custom HTTP headers or
some other non-HTML means? If not, does this mean OpenID is not
intended to support authentication to programmatic APIs?
Thanks,
Adam
_______________________________________________
specs mailing list
[email protected]
http://openid.net/mailman/listinfo/specs
_______________________________________________
specs mailing list
[email protected]
http://openid.net/mailman/listinfo/specs
