Well, as I've said before, I strongly believe that tying
authentication to one particular HTTP verb is a bad idea, and
unnecessary.
I also believe that involving JavaScript in what is fundamentally an
HTTP-level kind of protocol is a hack. It very likely is either
unnecessary or points to a flaw in the conceptual model of the
protocol, or both.
The same may be true about having different protocols for thin-client
and rich-client.
Having said that, I am not making this point more strongly than I
have because I don't think these issues are fatal and I don't want to
raise more issues that delay OpenID 2.0 auth further. So I will log
this as a bug against auth 2.0 as soon as it is published (and as
soon as there is a place where to file bugs against the spec ;-)) but
will bite my tongue in the meantime.
On Nov 12, 2006, at 20:29, Dick Hardt wrote:
On 12-Nov-06, at 8:19 PM, Adam Nelson wrote:
Hi Dick:
I think REST support is a really useful feature, and have described
how that might happen in the past, but right now we are pretty
focussed on getting browser based auth finalized, and I think the
mechanisms for rich clients will be related, but slightly different.
That all makes sense, thanks. Is that to say that rich client
support
isn't a goal of v2.0 of the spec, or just a goal subsequent to the
conclusion of browser-based auth?
Not a goal of OpenID Authentication 2.0
I think it would make sense to make it a separate document, and would
value your involvement!
-- Dick
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Johannes Ernst
NetMesh Inc.
http://netmesh.info/jernst
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
