Johnny Bufu schrieb:
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.
Maybe Base 64 Encoding with URL and Filename Safe Alphabet (RFC 3548,
section 4) should be
Johnny Bufu schrieb:
The attribute metadata can be used to define attribute-specific
encodings, which should deal with issues like this.
Ah, so the _usual_ way is that the metadata (Can this be renamed to
datatype definition? metadata is very misleading.) defines the
encoding. For binary
I agree with Claus. We may not need a base64 type.
Guoping
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Färber
Sent: Tuesday, May 29, 2007 3:33 AM
To: specs@openid.net
Subject: Re: attribute exchange value encoding
Johnny Bufu schrieb:
The
Allen,
On 5/29/07, Allen Tom [EMAIL PROTECTED] wrote:
From an implementation perspective, it might make sense for the OP to
verify the RP during the association request, so that the association
handle is only returned after the RP has been verified.
Were you concerned about implementation
Hi Josh,
Having the OP verify the realm/return_to as part of the Authentication
Request is fine. OPs should cache the verifcation status to reduce
latency for RPs that send many users to the OP.
At least from my perspective, it always seemed odd that the Association
Request is just an interface
Been silently observing many of the email exchanges over the last couple of
weeks and from an end-customer perspective I am somewhat concerned. Some of the
general themes I have observed are:
1. Too much focus on breaking compatibility with OpenID 1.1. While you have had
some success, now is
Hi Claus,
On 28-May-07, at 3:58 PM, Claus Färber wrote:
Johnny Bufu schrieb:
Encoded for AX using Key-Value Form Encoding (OID 2, 4.1.1.)
openid.ax.foo.uri:http://example.com/foo/100%2525pure
AX has nothing to do directly with key-value encoding. I see no
reference to percent-encoding
Amen. Great list.
I would add one more: let's focus single-mindedly on things that we
actually know are demanded by the market without which adoption does
not occur, instead of growing the amount of technology that needs to
be implemented into places where ROI (for implementors, deployers,
