Peter Watkins schrieb:
7.3.3 in draft 11 says
The openid2.provider and openid2.local_id URLs MUST NOT include entities
other than amp;, lt;, gt;, and quot;. Other characters that would
not be valid in the HTML document or that cannot be represented in the
document's character encoding
Josh Hoyt schrieb:
There has been a little discussion in the past about the restriction
on allowed character entity references. I don't think there has been
any about numeric character references, except in lumping them in with
character entity references.
These restrictions live on from
Marius Scurtescu schrieb:
The new attribute values are needed in order to signal an OpenID 2
provider.
Why is this necessary? Is OpenID 2 incompatible? In other words, what
happens if an OpenID 2 Relying Party tries to talk to an OpenID 1.x
Provider?
If the OpenID 1.x Provider just ignores
Johnny Bufu schrieb:
So I've rewritten the encoding section, such that:
- for strings, only the newline (and percent) characters are required
to be escaped,
(to comply with OpenID's data formats), using percent-encoding;
This means that '%' characters need to be encoded up to three
Dmitry Shechtman schrieb:
This is definitely an interesting proposal. However, it only attempts to
solve the recycling problem, whereas canonical IDs would solve this and
several more.
I think the best solution would be a Persistent Identifier. If the
OpenID Provider returns a different
Peter Watkins schrieb:
I don't think it's reasonable to expect RP code to be capable of parsing
every possible charset in which an HTML page might be encoded.
I also don't think it's reasonable to specify specific charsets that RPs
should be able to decode and then require OpenID users to
Johnny Bufu schrieb:
On 28-May-07, at 5:55 AM, Claus Färber wrote:
Johnny Bufu schrieb:
So I've rewritten the encoding section, such that:
This means that '%' characters need to be encoded up to three times:
I'm not sure I follow your reasoning all the way; please see my
comments below
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
Nat Sakimura schrieb:
1) Storing many users' private key on the server in decryptable format is
not very safe.
In your proposal, it looks like that OP is going to hold the private key for
each user in decryptable format. Considering that most large scale privacy
leakage happens at the
10 matches
Mail list logo
