Manger, James H wrote:
A related hassle is that when my OP supports a new authentication method
(such as a strong password-authenticated key agreement scheme (eg SRP)),
existing RPs will not recognize this method as strong enough for the RP’s
expectations – regardless of the method’s actual
Justin S. Peavey wrote:
I fully agree with you in your example above until you mention money.
In the Amazon example for book purchases, the user is not the one
affected by a mis-authenticated transaction, Amazon and the credit-card
companies are; the user is indemnified by most credit card
I have made an early draft of a spec called OpenID Exchange on the wiki:
http://openid.net/wiki/index.php/OpenID_Exchange_1.0
The goal of this protocol is to allow user-accompanied HTTP requests.
user-accompanied means that a consumer makes a request to a service on
behalf of a user and
this is exactly what we are trying to come up (at AOL) too. This fits in
well for bridging Open Authentication with Open Web Services.
Although in our version (internal - not published yet) we tried to keep
the EndPoint (SP) OP separate and use a security token instead of the
transaction
It would be very helpful if you could write up a full example
scenario executing the protocol flow. Using something like a
(hypothetical) Mashup as an example.
On Dec 13, 2006, at 4:43, Martin Atkins wrote:
I have made an early draft of a spec called OpenID Exchange on the
wiki:
On 12/12/06, Joaquin Miller [EMAIL PROTECTED] wrote:
How about one of these:
When a message is sent as a POST, OpenID parameters MUST be sent only in
the POST body and the parameters processed MUST be only those from the POST
body.
When a message is sent as a POST, OpenID parameters
Josh Hoyt wrote:
It's confusing to me make the failure response to an immediate mode
request be id_res, especially if that is not the failure response
for setup mode. I can't see a reason that they can't both use the
cancel response to indicate that the OP or end user do not wish to
