But it seems superflous: Since you cannot depend on args to
be ordered[1], you'll still need to iterate and match prefix
to values.
Also, any change adds complexity: You'll need to specify
semantics to what happens if the list of extensions is
not there, or if it is incorrect, or if you use
On 5-Jun-07, at 8:53 AM, Granqvist, Hans wrote:
But it seems superflous: Since you cannot depend on args to
be ordered[1], you'll still need to iterate and match prefix
to values.
Martin's proposal seems like a minor improvement to me - iterating
thorough openid.ns.* or splitting the value
So I ask again - does anyone see any issues with the
fragments being used like this:
http://openid.net/pipermail/specs/2007-May/001767.html
Seems reasonable in essence. But it adds complexity and
removes some immediacy of URL identifiers-as-is.
Do fragments need special handling
Hi Johnny,
Just so we're all on the same page: Can you post a link
to the referenced proposal?
Thanks,
Hans
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Johnny Bufu
Sent: Friday, April 27, 2007 3:46 PM
To: OpenID specs list
Subject: Re:
All,
Over the last several weeks, I have tried [1][2] to ask
the list to clarify into the state of the current OpenID
2.0 specification draft.
There seems to be little interest in finalizing 2.0. The
current draft 11 is over three months old. Draft 5 dates
back over ten months, and who
Cool, thanks!
-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED]
Sent: Monday, April 30, 2007 9:51 AM
To: Granqvist, Hans
Cc: OpenID specs list
Subject: Re: encoding newlines in attribute values
Hans,
On 30-Apr-07, at 9:22 AM, Granqvist, Hans wrote:
Just so
, 2007 10:35 AM
To: Granqvist, Hans; 'Dick Hardt'; 'McGovern, James F ((HTSC, IT))'
Cc: specs@openid.net
Subject: RE: Java RP
Hans-
I didn't see XRI support in joid - was I mistaken?
-Gabe
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED
:
On 26-Mar-07, at 12:22 PM, Josh Hoyt wrote:
On 3/20/07, Granqvist, Hans
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
OpenID 2.0 has been cooking for quite a
while
How did you / others deal with this? There are quite a few
...
Same way that you do/propose -- by using the default values if they
are not present.
-Hans
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Josh, thanks for posting! See my comments inline -Hans
...
Other relevant issues:
...
* Any technology that prevents phishing will require
user-agent support or else will fundamentally change the flow
of OpenID (prevent relying-party-initiated sign-in)
Is that entirely true?
+1. A lot of thought went into the KeyInfo element design.
And the spec can define a valid subset of KeyInfos, too, if needed.
-Original Message-
From: Recordon, David [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 09:50 AM Pacific Standard Time
To: Grant Monroe
Cc:
It has had some voices against it, but how about considering
this template (used in for example W3C xmldsig and
xmlenc):
http://openid.net/[year]/[month]/[project]#[type]
Time-dependent (rather than version--dependent) namespaces
can evolve freely and will not be tied down to specific
I want to avoid the
wait-I-thought-we-decided-something-else or
ahh-yes-seems-we-forgot-it-had-an-impact-there
delays . . .
Spec work gain tremendously by unambiguous up-front
definitions of what *exactly* is voted on.
A good way to do this is to force the vote to be
on an explicit
I can see potential use-cases where Alice doesn't want the
idp to know what her portable URL is. This would not work
if the protocol requires both as per below. Can it be
solved by sending a hash of the portable identifier?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
. Once an IDP knows of and starts tracking my vanity
identifier (bound to happen) I cannot easily give up that
identifier.
-Original Message-
From: Drummond Reed [mailto:[EMAIL PROTECTED]
Sent: Friday, October 13, 2006 9:11 AM
To: Granqvist, Hans; 'Josh Hoyt'; specs@openid.net
To achieve identifier portability in OpenID, it MUST be
possible for the RP and the IdP to identify the user using
two different identifiers: an identifier by which the RP
knows the user (the portable identifier), and an identifier
by which the IdP knows the user (the IdP-specific
I think the 2.0 spec extension mechanism could handle signed
credentials. For example, credentials=s where s is of
a (string) format that contains a type + signature, say
credentials=OATHVIP:WW91IGhhZCB0byBjaGVjaywgZGlkbid0IHlvdT8gOyk=
The format could also further specify mechanism types,
Behavior needs to be specified before it can be recommended.
So the spec MUST specify how to deal with the multiple
parameters before it can set the use thereof as NOT
RECOMMENDED.
Hans
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Recordon,
+1 on removing SIGNALL
There are significant security risks with signing unseen data,
which SIGNALL in effect allows. Such chosen plaintext attacks can
be devastating to protocols.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David
I think the real topic of this discussion is whether or not
multiple
parameters with the same name should be allowed by the
specification.
I'd support the motion of not doing that.
Johannes, just to clarify, are you against allowing
multiple same-name params?
Hans
Well, then +1 to disallowing such multiplicity!
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Tuesday, September 26, 2006 4:15 PM
To: Granqvist, Hans
Cc: Barry Ferg; specs@openid.net
Subject: Re: Request for comments: Sorting
21 matches
Mail list logo
