On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote:
7.3.3. HTML-Based Discovery
A LINK tag MUST be included with attributes rel set to
openid2.provider
and href set to an OP Endpoint URL
A LINK tag MAY be included with attributes rel set to
openid2.local_id
and href set to the end
to that a sentence stating that you
SHOULD put both sets of tags when editing HTML pages in order to be
backwards compatible.
Thanks,
Marius
Thanks,
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Marius Scurtescu
Sent: Friday, May 18
On 18-May-07, at 11:45 AM, Josh Hoyt wrote:
On 5/18/07, Marius Scurtescu [EMAIL PROTECTED] wrote:
On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote:
In order to be backwards compatible the HTML page should have two
sets of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing
On Wed, 2007-18-04 at 23:25 -0700, Douglas Otis wrote:
On Apr 18, 2007, at 8:31 PM, Marius Scurtescu wrote:
Base64 encoding is a pretty good candidate for binary data, but you
cannot apply the same encoding to text fields.
RFC4648 URL and Filename safe Base 64 Alphabet might be a good
On 19-Apr-07, at 7:29 AM, Rowan Kerr wrote:
On 18-Apr-07, at 9:47 PM, Johnny Bufu wrote:
The core spec doesn't allow newline characters (\n) in any openid.*
values. Currently, Attribute Exchange doesn't specify a way to encode
newlines in attribute values.
Every indirect OpenID message
On 16-Oct-06, at 2:44 PM, Josh Hoyt wrote:
On 10/16/06, Recordon, David [EMAIL PROTECTED] wrote:
6.1 Signed List Algorithm
[...]
I'm thinking it would make sense to
change this algorithm to first alphabetically sort the arguments
to make
it very clear in terms of ordering.
I think it's
On 16-Oct-06, at 3:13 PM, Josh Hoyt wrote:
On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
Sorting of unicode strings while not terrible hard it is not trivial
either. Why bother? The list of signed fields gives an explicit
ordering, this is good enough IMO.
Sorting by UTF-8-encoded
On 13-Oct-06, at 12:20 PM, Drummond Reed wrote:
Marius wrote:
I was suggesting that portability can be resolved between the user
and
the IdP. I cannot see how the protocol can help this by passing two
identifiers. And if only the portable identifier is passed then
there is
no need to
On 13-Oct-06, at 12:59 PM, Drummond Reed wrote:
Yesterday we established consensus that with OpenID, identifier
portability
is sacred.
Today I'd like to establish consensus on the following postulate:
To achieve identifier portability in OpenID, it MUST be possible
for the RP
and
On 12-Oct-06, at 11:40 PM, Drummond Reed wrote:
Drummond wrote:
Since the RP has to do discovery on the i-name, the RP already
has the
i-number (CanonicalID). Further, as explained in previous
threads, the
CanonicalID is the primary key the RP wants to store for the user,
not the
On 12-Oct-06, at 12:10 PM, Recordon, David wrote:
We thus believe that any state tracking needed by a stateless RP
must be maintained as GET parameters within the return_to
argument. In the case of a stateful RP, it can either do the same
thing, or store state via other means such as
On 12-Oct-06, at 10:29 AM, Josh Hoyt wrote:
Both portable and IdP-specific identifiers
--
Include both the portable identifier and the IdP-specific identifier
in the request and response ([4]_ and
[5]_)::
openid.identity =
On 12-Oct-06, at 5:07 PM, Josh Hoyt wrote:
On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
If passing through all unrecognized parameters can cause problems
then there could be a special namespace for this purpose. For
example, all parameters with names starting with openid.pass
On 5-Oct-06, at 3:36 PM, Recordon, David wrote:
Conceptually I think I like this model. It does seem easier to
understand.
Other thoughts on this?
I am still not sure how the delegated identifier is useful. I did
miss the earlier discussions, so probably I don't have enough
background
14 matches
Mail list logo
