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