attribute exchange value encoding
Johnny Bufu
johnny at sxip.com
Tue May 29 04:54:44 UTC 2007
Hi Gouping,
On 28-May-07, at 9:22 PM, Guoping Liu wrote:
> I have a couple comments on Section 3.3.2 Default Encoding of a Binary
> Value.
>
> First, the character set of standard Base64 encoding is not URL-safe.
> Specifically, '+', '/' and '=' need to be URL-encoded. So, we need to
> URL-encode the value after base64 encoding.
I believe the HTTP encoding [1] in the OpenID spec will take care of
this part, i.e. before putting the OpenID + AX message on the wire,
the OpenID layer has to HTTP-encode it.
> Secondly, different platforms may have different binary formats for a
> given type of objects. There may be interoperability issues with
> binary
> values across different platforms. We may want to use a string
> representation of an object instead of its binary representation, like
> in any XML document. For example, for an integer value 1234 of
> attribute
> x we have openid.ax.x=1234. With this we will not need base64
> encoding.
> But, we will still need URL-encoding.
The attribute metadata can be used to define attribute-specific
encodings, which should deal with issues like this.
The AX protocol has to stay simple (that was overwhelming feedback
I've received at IIW). The base64 encoding is there as a convenience:
if a number of OPs and RPs agree on an attribute type (the classical
example being an avatar image) but don't want to go to the trouble of
publishing metadata information, they can use AX's base64 support for
transferring it. And yes, I'd expect numeric values to be transferred
as strings in >90% of the cases.
Johnny
[1] http://openid.net/specs/openid-authentication-2_0-11.html#anchor4
More information about the specs
mailing list