Hello,
I started writing up the use of fragment identifiers for URL-recycling
for the OpenID 2.0 authentication spec, and I ran into some unforseen
challenges. It's not obvious how a relying party should behave when a
URL with a fragment is entered. How should the discovery process work?
How shoul
On May 30, 2007, at 13:28, Josh Hoyt wrote:
After thinking this over for a while, I'm no longer convinced that
using URI fragments as the uniquifying value is the right
approach.
I agree with you. Our reasons may differ slightly, but the result is
the same.
I have no problem in not solving
At some point, the weak link will be humans trying to disambiguate
http://joe.example.org/ from http://joe.example.org/2 (or
http://joe.example.org/#2). I don't think there's a big difference
between the two in that context, and I don't think that OID2 needs to
solve this more deeply than allo
John Panzer wrote:
>
> Has there been a discussion about an extension to map to/from i-numbers
> via AX? If there were a generic attribute you could stuff an i-number
> or a hash of an internal ID in there to help solve the disambiguation
> problem. Alternatively it'd be nice to have a way to
On 30-May-07, at 6:21 PM, Martin Atkins wrote:
> John Panzer wrote:
>>
>> Has there been a discussion about an extension to map to/from i-
>> numbers
>> via AX? If there were a generic attribute you could stuff an i-
>> number
>> or a hash of an internal ID in there to help solve the disambigu
On 30-May-07, at 1:28 PM, Josh Hoyt wrote:
> How should the discovery process work?
> How should fragments work with delegation (both as the claimed
> identifier and the provider-local identifier)?
Here's how I see the fragments approach working:
a) Discovery: strip the fragment from the user-s
Josh,
On 30-May-07, at 1:28 PM, Josh Hoyt wrote:
> Providers can also provide a redirect from the general form of the
> identifier to the current version of the identifier so that users do
> not need to remember or type the uniquified version. This is pretty
> much equivalent to the fragment sche
On May 30, 2007, at 21:02, Johnny Bufu wrote:
...The bottom line is
that it can't be done easily - a mechanism similar to XRI's canonical
ID verification would have to be employed, to confirm that the i-
number actually 'belongs' to the URL on which discovery was
initiated. (Otherwise anyone co
>>> John Panzer wrote:
>>>
>>> Has there been a discussion about an extension to map to/from i-
>>> numbers
>>> via AX? If there were a generic attribute you could stuff an i-
>>> number
>>> or a hash of an internal ID in there to help solve the disambiguation
>>> problem. Alternatively it'd b
Johannes:
What about the point Dick posted earlier in this thread, that the problem
with using a public key is if the private key gets compromised? Persistent
identifiers need to persist independent of any attribute changing or being
revoked.
=Drummond
-Original Message-
From: [EMAIL PR
If we cannot assume that nobody manages to obtain a secret they
should not have gotten in the first place, then OpenID as it stands
is rather useless as we cannot trust its authentication scheme.
Note that the surface through which the D-H shared secret can escape
is about twice as large as
On 29-May-07, at 2:33 AM, Claus Färber wrote:
> 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
As discussed at IIW, the OASIS XRI TC is now moving swiftly to close and
vote on the XRI Resolution 2.0 spec (which has been at the Working Draft 10
stage during the entire evolution of OpenID Authentication 2.0) so it can be
referenced by OpenID Authentication 2.0 when it goes final.
To that end,
13 matches
Mail list logo
