On 18-Nov-06, at 9:46 PM, Johannes Ernst wrote:
>
> On Nov 18, 2006, at 15:34, John Kemp wrote:
>
>>> OpenID 1.1 did not have a large payload. We expect the payloads
>>> to be
>>> much larger with OpenID 2.0.
>>
>> I guess the payload size will vary according to the RP and IdP
>> implementations, no?
>
> Yes. And so far the only need for large payload sizes that I have
> seen relate to a still somewhat controversial spec that will only
> be implemented by less than 100% of all RPs and IdPs (how far less
> we can all guess).
>
> Making something that has much broader appeal (auth) substantially
> more restrictive because of the needs of another spec, that uses
> it, and that may not even be implemented by everybody, sounds like
> an architectural no-no to me. The obvious workaround: if that
> additional spec only works with one of the several alternatives
> supported by the auth spec, make the additional spec require to use
> that particular mode (POST) only when it is used.
Controversy? now you are just throwing mud!
The return_to parameter is used by the RP to manage state. One could
imagine an RP wanting to include a large amount of data in a OpenID
Authentication call, hence would need more then what can be
guaranteed to be on a URL parameter, since it is wanting to use the
that amount of data for the URL parameter itself.
>
>>> We will see if the JS requirement is an issue. I do not think it is
>>> given what I know now.
>>
>> Well, admittedly, if no-one except me thinks that redirects should be
>> supported in OpenID 2.0, then I certainly expect to lose that
>> argument ;)
>
> This whole discussion sounds it's on the wrong foot to me in any
> case. From my perspective, something is seriously wrong with an URL-
> based protocol for authentication that works for one HTTP verb
> (POST) but not for any other.
The protocol is for more then authentication, and it is changing
state. Per W3C, a GET should not be changing state.
See:
http://www.w3.org/DesignIssues/Axioms.html#state
excert ...
In HTTP, GET must not have side effects.
The introduction of any other method apart from GET which has no side
effects is also incorrect, because the results of such an operation
effectively form a separate address space, which violates the
universality. A pragmatic symptom would be that hypertext links would
have to contain the method as well as the URI in order to able to
address the new space, which people would soon want to do.
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
